curl: повадки проекта
Карточка вида: чем живёт, как принимает чужаков, кто в нём работает. Наблюдения по коду, переписке и тому, что проект пишет о себе сам
miki/curl-povadki-proekta · v5
Карточка вида: чем живёт, как принимает чужаков, кто в нём работает. Наблюдения по коду, переписке и тому, что проект пишет о себе сам
Что это. Программа, которая скачивает что-нибудь из интернета и отдаёт обратно. Звучит скучно ровно до того момента, как понимаешь, где она стоит: в телевизорах, автомобилях, банкоматах и внутри почти каждого сайта.
Возраст. Первый коммит в репозитории — 29 декабря 1999 года, автор Daniel Stenberg, сообщение из двух слов: Initial revision. Он же ведёт проект сегодня. Двадцать семь лет одним человеком во главе — сама по себе редкая черта.
Размер. 42 700 звёзд, 7 300 форков на сентябрь 2026.
Самое интересное: curl записал свои правила в docs/CONTRIBUTE.md, и то, что видно в переписке, с этим текстом совпадает.
Молчание считается отказом — и об этом предупреждают заранее:
As your changes are reviewed and discussed, you are expected to address any flaws pointed out and update accordingly. Otherwise your changes risk stalling and eventually being deleted without action... We take lack of replies as a sign that you are not anxious to get your patch accepted and we tend to drop such changes.
От вас ждут, что вы ответите на замечания и поправите. Иначе изменения застрянут и в итоге будут удалены. Отсутствие ответов мы считаем признаком того, что вам не очень нужно принятие правки, и обычно такие изменения отбрасываем.
Именно это и произошло 10 июля 2022-го с PR про IPFS: два месяца тишины — и закрытие. Не каприз мейнтейнера, а написанное правило.
Некоторым правкам нужны голоса:
A pull request... might get labeled
needs-votes... this pull request must also receive more "votes" of user support. More signs that people want this to happen.
Правку могут пометить «нужны голоса»: помимо всех прочих проверок ей требуется поддержка пользователей — сообщения или «пальцы вверх».
То есть у чужой фичи есть не только техническая планка, но и социальная.
Новые фичи ждут окна:
For new features... we require that the feature window is open... typically a three week period that starts ten days after a previous release.
Для новых возможностей требуется открытое «окно фич» — обычно три недели, начинающиеся через десять дней после очередного релиза.
Это отчасти объясняет, почему поддержка IPFS шла восемнадцать месяцев: даже одобренная фича ждёт своей форточки.
Наблюдения из PR #8805 — 283 комментария за шестнадцать месяцев:
- Отвечает быстро. Первая реакция мейнтейнера — на следующий день после открытия.
- Отказ объясняет абзацами, а не ярлыком. Три развёрнутых возражения за один день, каждое с причиной, а не «не подходит».
- Закрывает с приглашением вернуться. «Feel free to reopen when things move again» — дверь закрыта, но не заперта.
- Требует документацию раньше кода. Первое же замечание: нет документации и тестов — судить не о чем.
- Спорит открыто и без грубости. Полтора года несогласия, две стороны не соглашаются два месяца подряд — ни одной резкости в адрес человека.
- Хранит авторские даты. Коммит, влитый через восемнадцать месяцев и десятки ребейзов, сохранил дату написания.
Что из этого следует для того, кто придёт со своей правкой. curl не отшивает, но и не облегчает: он требует документации, тестов, ответов на замечания и терпения длиной в релизный цикл. Тот, кто выдерживает, попадает внутрь вместе со своим именем в истории.
Сообщение коммита пишется по шаблону, и шаблон записан:
С тремя требованиями, которые многие проекты только подразумевают, а curl выписал: повелительное наклонение (change, а не «changed» и не «changes»), строчная буква в начале, никакой точки в конце. Первая строка должна годиться в список изменений релиза как есть.
Стиль кода проверяется машиной: make checksrc до отправки. Оговорка честная — «проверяет не всё, но если ругается — значит работа есть».
Право писать в репозиторий можно просто попросить:
Feel free to ask for this, if this is what you want. You are required to have posted several high quality patches first.
Просите смело, если хотите. Сначала нужно прислать несколько хороших правок.
Заметьте контраст: в той же истории человек не мог даже открыть свой закрытый PR — прав не хватило. Права здесь дают за сделанное, а не за намерение.
Всё ниже — из docs/CONTRIBUTE.md самого проекта, а не из наших догадок. Практически это самая полезная часть карточки.
Одна правка — одна беда.
It is annoying when you get a huge patch from someone that is said to fix 11 odd problems, but discussions and opinions do not agree with 10 of them.
Раздражает, когда приходит огромная правка, которая якобы чинит одиннадцать проблем, но по десяти из них согласия нет.
И отдельно — причина, которая вспомнится через годы: отдельные правки делают возможным поиск виноватого коммита пополам — «enable bisecting much better».
Не шевелите чужое по дороге.
Remember that it is likely that other people have done changes in the same source files as you have… If you bring completely new functionality, try writing it in a new source file.
Скорее всего, другие люди правили те же файлы… Новое лучше писать в новом файле.
Тест обязателен, и причина названа честно:
Every feature that is added should get at least one valid test case… If every submitter also posts a few test cases, it does not end up a heavy burden on a single person.
Каждая новая возможность обязана получить хотя бы один тест… Если каждый пришлёт по паре тестов, это не ложится тяжёлым грузом на одного человека.
А если тест написать нельзя — требуют объяснить, как именно вы проверяли.
Про документацию говорят без пафоса:
Writing docs is dead boring and one of the big problems with many open source projects but someone's gotta do it.
Писать документацию смертельно скучно, и это одна из больших бед открытых проектов, но кто-то должен.
Люди, встреченные в наших разборах этого проекта. Подробные карточки — в «Определителе».
- bagder — Daniel Stenberg. Ведёт curl с самого начала. В истории с IPFS: ответил на следующий день, закрыл по неактивности с приглашением, трижды за день сказал «нет», сам предложил выход и сам влил через полтора года.
- markg85 — Mark Gaiser. Принёс поддержку
ipfs://. Восемнадцать месяцев между датой написания коммита и датой вливания; 82 комментария из 283. - lidel — Marcin Rataj, Protocol Labs. Пришёл со стороны IPFS и выступил против того, чтобы шлюз его же команды стоял в curl по умолчанию.
- jzakrzewski — Jakub Zakrzewski. Прохожий с идеей: зашёл со словами «a wild idea» и предложил компромисс, который в итоге и приняли.
- dfandrich — Dan Fandrich. Через два дня после вливания починил пути к логам в новых тестах.
- «Две даты одного коммита» — поддержка IPFS, спор о шлюзе по умолчанию, восемнадцать месяцев от написания до вливания.
Карточка собрана 01.09.2026 из открытых источников: репозиторий, документация проекта, переписка в PR. Фотографий и личных данных здесь нет и не будет. Нашли неточность или хотите, чтобы вас убрали, — напишите, поправим без вопросов.
Related lists
Люди и проекты из разборов — по поступкам, датам и ссылкам. Как определитель птиц: не оценивает, а помогает узнать, кого встретил
Найти в открытом проекте настоящую историю поломки, восстановить ход мысли по написанному и закончить проверкой своего кода
Пятеро разработчиков ERPNext по очереди чинили одну трещину, и никто из них не ошибался. Пока один не спросил: а почему это вообще работает? Оказалось — по случайному свойству чужой базы данных.
Семнадцать дней копий не было, и это выглядело точно так же, как если бы они были. Разбор чужой истории: флаг, который умел только портиться, мусор, забивший диск, и починка, приехавшая боком.
comlink-python: проверки на отказ стучались в адрес, который сервер не защищает, — и пять месяцев скрывали настоящую ошибку подписи
Better Auth: ограничение частоты считалось от последнего запроса, включая отклонённые, — и разблокировка не наступала никогда
