Как бы вы руководили разработкой крупнейшего проекта с открытыми исходниками, в котором порядка 15 тыс. разработчиков и 222 компании вносят более 12 тыс. изменений между релизами или 7 / 8 правок каждый час? Чем пользуются создатель кернела Линус Торвальдс, мейнтейнера стабильной ветки Грег Кроа-Хартман (GKH) и другие товарищи, чтобы успешно координировать работу проекта и обеспечивать своевременный выход каждой новой версии?

Этим чудо-инструментом является текстовый клиент электронной почты: Mutt у GKH и Alpine у Линуса Торвальдса. Третий по рангу разработчик ядра Эндрю Мортон, также вовсю использует электронку для управления mm веткой.

With the wide variety of more “modern” development tools such as github, gerrit, and other methods of software development, why is the Linux kernel team still stuck in the 1990’s with ancient requirements of plain text email in order to get patches accepted? This talk will discuss just how the kernel development process works, why we rely on these “ancient” tools, and how they still work so much better than anything else.^[1]

Попробуем разобраться, как это могло случиться. Какова роль технологического фактора и личностного? Может быть текстовый емайл действительно идеальное средство координации сверх-сложных проектов?

Долгий путь к Git

Вспомним, как все начиналось. 25-го августа 1991 г. никому неизвестный финский студент написал письмо в новостную группу comp.os.minix, в котором анонсировал свою работу над свободной операционной системой и скорое ее завершение. В октябре того же года он выложил версию 0.0.2 на ftp в директории Linux, известил об этом комрадов хакеров и понеслось…

С самого начала разработка осуществлялась распределенной командой энтузиастов. Первое время Линус Торвальдс проверял каждый патч, переписывал и сам же его устанавливал. Команда росла, патчей становилось все больше, ядро росло и усложнялось. Пришлось патчи ставить на скорую руку, зачастую без всяких изменений. В этой ситуации Линус принял единственно верное решение — делегировать и доверять работу, тем у кого получается. Этот процесс хорошо иллюстрирует письмо известное как Линус не масштабируется, в котором Линус жалуется на перезагрузку перегрузку и предлагает назначить мейнтейнеров различных подсистем ядра.

Linus doesn’t scale, and his current way of coping is to silently drop the vast majority of patches submitted to him onto the floor. Most of the time there is no judgement involved when this code gets dropped. Patches that fix compile errors get dropped. Code from subsystem maintainers that Linus himself designated gets dropped. A build of the tree now spits out numerous easily fixable warnings, when at one time it was warning-free. Finished code regularly goes unintegrated for months at a time, being repeatedly resynced and re-diffed against new trees until the code’s maintainer gets sick of it. This is extremely frustrating to developers, users, and vendors, and is burning out the maintainers. It is a huge source of unnecessary work. The situation needs to be resolved. Fast.

Собственно, вся история развития проекта укладывается в эту схему. Линус все меньше кодил, все больше координировал работу проекта, и так постепенно из хакера превратился в архитектора. Это происходило не без внутренних трений и шероховатостей, но движение продолжалось. В то же самое время формировался костяк старших разработчиков и оформлялся стиль совестной работы. Так как емайл был основным орудием совместного труда с самого начала, то все кто были в проекте, приспособились передавать патчи по электронной почте и даже зафиксировали в документации, как это правильно делать.

-rw-r--r-- 1 root root 36604 янв 11  2016 /usr/src/linux/Documentation/SubmittingPatches
-rw-r--r-- 1 root root 11186 янв 11  2016 /usr/src/linux/Documentation/email-clients.txt

Тем не менее к 2000 г. стало понятно, что нужна система контроля версий. Народ стал роптать, что разработка тормозится из-за механического способа работы Линуса. Это было сущей правдой, и тогда команда взяла на вооружение BitKeeper, который в то время являлся закрытым программным продуктом, предоставляемым бесплатно разработчикам открытых программ. Прагматичному Линусу это было до лампочки, но в команде были и принципиальные ребята, не глухие к голосу Ричарда Сталлмана, готовому без устали гвоздить все то, что содержит хоть байт закрытого кода. Alan Cox — программист написавший первый приличный сетевой стэк для ядра, был одним из них.

Какое-то время все шло вроде бы неплохо, BitKeeper значительно облегчил жизнь разработчикам. Им не надо было больше заботиться о том, кто имеет права на какие изменение, каждый из них мог работать в своей ветке древа исходников, возможность распределенных слияний^[2] исходного кода давала значительную экономию усилий для всех. Подспудно, назревал кризис, который и привел к созданию Git.

Затем автор Самбы Tridge (Andrew Tridgell) захотел сделать то, что умел делать лучше других — осуществить обратную разработку BitKeeper, чего по условиям лицензии деть было нельзя ни в коем случае. Разгорелся конфликт, Линус пытался его погасить, но не преуспел в том. И тогда он взял и за один день написал Git. Что было дальше — всем известно: в таком деликатном и консервативном сегменте ПО как VCS, Git сумел всего за несколько лет опрокинуть конкурентов.

Основное преимущество — широчайшая доступность

Недавно мейнтейнер стабильной ветки Linux ядра Грег Кроа-Хартман, выступая на одной конференции, выложил свои доводы за текстовую электронную почту и против использования систем совместной разработки, инспекции исходного кода, таких как GitHub или Gerrit.

Перечислив те очевидные достоинства, благодаря которым GitHub обрел огромную популярность среди разработчиков, докладчик несколько раз подчеркнул, что тот отлично работает для небольших проектов, но для крупных не годится, так как плохо масштабируем. В доказательство этого тезиса он привел Kubernetes, с 4600 открытыми заявками и около 600 pull request-ами. В презентации эти цифры были на 10% ниже.

Другие претензии GKH к Гитхабу:

• Требует постоянного доступа к интернету, но не все разработчики имеют к нему доступ.
• Pull request-ы и рассылки сами по себе.
• Внутренние проверки трудноосуществимы.
• Претензии к UI, мучительно трудно отслеживать заявки.

Впрочем, докладчик несколько раз сделал оговорку, что некоторые проблемы постепенно находят решение, сервис постоянно меняется в лучшую сторону. Сам Грег хостит usbutils на Гитхабе.

Остальным системам совместной разработки и инспекции исходников и вовсе досталось на орехи: единственным аргументом за использование Gerrit оказался тот факт, что он люб менеджерам проектов. Не удивительно, что больше всего похвал собрала текстовая электронная почта. Тезисы за емайл были таковы.

1. Простота
2. Широчайшая аудитория
3. Масштабируемость
4. Способствует росту сообщества
5. Внутренние проверки без проблем
6. Локализация и перевод текста
7. Быстрый обзор патчей
8. Возможность удаленной проверки
9. Отсутствие менеджера проекта

Первые три пункта на самое деле разные грани одного и того же: емайл прост и доступен каждому. Слепому, а по словам GKH в проекте есть ряд классных, но слепых программистов, электронная почта доступна а WWW — нет. Тем, кто сидит за корпоративным файрволом, git недоступен, а с электронкой никаких проблем нет. Мейнтейнеры часто путешествуют, выступают на конфах меняют пароли и явки и им проще дождаться подключения к сети интернет, скачать и отправить письма, нежели найти время и место, чтобы проверить статусы заявок в Gerrit. Кто-то умудрялся подолгу путешествовать на велосипеде по Африке и таки присылать патчи по расписанию.

Четвертый пункт тоже очень важен. Каждые недели-две в поле зрения GKH появляется новобранец. Ему стандартно советуют включится в список рассылки и просто побыть недельку в режиме read-only, чтобы составить впечатление о происходящем и вникнуть в детали. Это очень хороший способ отличить важные темы от второстепенных, выявить глубину и детализацию обсуждаемых проблем. В то же время, если отправить новичка почитать форумы где-то там, то это может встретить непонимание и обиду.

Остановимся теперь подробнее на некоторых недостатках использования plaintext электронной почты, как основного инструмента управления и разработки Linux.

Я получаю много писем

Так называлась запись в блоге Грега, в котором он рассказывает о трудовых буднях с электронной почтой.

Overall, in 24 hours I received 18,799,115 bytes (18Mb) of email in 2067 individual messages:

Из них, как минимум, 237 живых писем в рассылку, Грег читает их все.

237 emails to mailing lists that I read everything that is posted. This includes a number of openSUSE mailing lists, systemd, linux-usb, linux-pci, linux-hotplug, IP, and a variety of other lower traffic lists.

Среди всех мейнтейнеров у него самая большая нагрузка и количество подписанных коммитов.

Причем, эти цифры постоянно растут! Судя по всему GKH неплохо масштабируется.

О том как должен выглядеть образцовый патч написано в Documentation/SubmittingPatches. Никаких MIME и прочих глупостей, только plaintext. Патч должен содержаться в теле письма, а не быть к нему прикреплен.

6) No MIME, no links, no compression, no attachments.  Just plain text.
-----------------------------------------------------------------------

Linus and other kernel developers need to be able to read and comment on the changes you are submitting.  It is important for a kernel developer to be able to "quote" your changes, using standard e-mail tools, so that they may comment on specific portions of your code.

For this reason, all patches should be submitted by e-mail "inline".
WARNING:  Be wary of your editor's word-wrap corrupting your patch, if you choose to cut-n-paste your patch.

Do not attach the patch as a MIME attachment, compressed or not.
Many popular e-mail applications will not always transmit a MIME attachment as plain text, making it impossible to comment on your code.  A MIME attachment also takes Linus a bit more time to process, decreasing the likelihood of your MIME-attached change being accepted.

Exception:  If your mailer is mangling patches then someone may ask you to re-send them using MIME.

See Documentation/email-clients.txt for hints about configuring your e-mail client so that it sends your patches untouched.

Как будто не сложно, но на самом деле не все почтовые программы справляются. В числе главных неосиляторов MS Outlook, Gmail (Web UI) и Lotus Notes.

(5:534)$ grep -A2 Lotus /usr/src/linux/Documentation/email-clients.txt

Lotus Notes (GUI)
Run away from it.

Компании, которые их используют, всегда имеют выделенную рабочую станцию Linux для отправки патчей.

Помимо всего прочего, в числе 16 правил четко определены формат темы и содержания сообщения.

The canonical patch subject line is:
    Subject: [PATCH 001/123] subsystem: summary phrase

The canonical patch message body contains the following:
- A "from" line specifying the patch author (only needed if the person sending the patch is not the author).
- An empty line.
- The body of the explanation, line wrapped at 75 columns, which will be copied to the permanent changelog to describe this patch.
- The "Signed-off-by:" lines, described above, which will also go in the changelog.
- A marker line containing simply "---".
- Any additional comments not suitable for the changelog.
- The actual patch (diff output).

Зачастую, с письмами случаются странные казусы. Линус жалуется, что KMail Дмитрия Торохова надо сжечь к чертям, так как он портит пробелы и табуляции, из-за этого копипаста выдает мусор.

I cannot just cut-and-paste the whole line, because your tabs and spaces aren’t tabs and spaces, they are some horrible abomination.

What looks like a tab above, when I save it and look at it with "od", it shows it true nasty life: it’s not a tab, and it’s not even eight spaces, it’s four copies of the byte sequence ‘302240 ‘ (‘xC2xA0x20’), ie some horrid nasty three-byte sequence where one character is a space, and the previous two characters are some utf-8 abomination.

А вот Линус отчитывает техподдержку GMail за то, что их спамбот лажается в 20% случаях.

Еше могут возникнуть проблемы взаимопонимания между программистом и мейнтейнером. Комментарий на LWN в переводе.

Проверка патчей в письмах — отстой по сравнению c push —force. Станет мейнтейнер брюзжать, если я пришлю в ответе v2 одного из патчей в обработке или наоборот, он станет брюзжать, если вместо этого я целиком пришлю свежий v2 одним блоком? Заметит ли он v2, чтобы применить ту что нужно, я ведь не могу поменять статус своего pull request-а. Как мейнтейнер, смогу ли я в такой же ситуации верно применить корректировку?

Общий баланс и выводы

Трудно отделаться от впечатления, что Линус со товарищи канонизировали свои старые привычки 1990-х. Это и есть субъективная фактор, но он же упирается в фактор объективный. Хакеры, создавшие ядро Linux 25 лет назад, благодаря чему сообщество открытого ПО обрело материальную силу и нравственное лидерство, умеют с большой отдачей созидать именно таким способом. Если взять талантливых выпускников [МГУ Бауманка MIT Berkeley ваш_любимый_ВУЗ] и полностью заменить ими всех мейнтейнеров, то через год-два они сами перейдут на GitHub, или напишут что-то свое и будут на слайдах доказывать, насколько повысилось их продуктивность. Доказательством могут служить наличие сопоставимо крупных проектов, которые спокойно творят без патчей в теле текстовых писем. Также Гугл использует Gerrit, для разработки Android а Docker.

В качестве резюме, предлагаю комментарий на LWN.

Согласно моему тезису, в 90-х открытые сообщества имели самые лучшие программные средства сотрудничества, и в этом причина того, что мы преуспели. Затем проприетарщики нас догнали и перегнали. Мы должны снова инвестировать в свой инструментарий и обновлять его, или про крайней мере перенимать лучшие их образцы, если хотим продолжать преуспевать.

А что думает по этому поводу Хабр?

Использованные материалы

1. Why kernel development still uses email
2. 10 Years of Git: An Interview with Git Creator Linus Torvalds
3. Слайды презентации GKH

---

1. ↑ Почему, при всем богатстве выбора «современных» средств разработки, таких как: github, gerrit и т. д., программисты ядра Linux застряли в 1990-х со своими дремучими правилами оформления патчей в теле простого текстового электронного сообщения? Вы узнаете как осуществляется разработка кернела, почему мы полагаемся на «древние» орудия труда и чем они настолько превосходят всех остальных. Со страницы анонса выступления GKH,
2. ↑ Distributed merge.

Автор:

Источник