Розробка ядра Linux тримається на електронній пошті

Як би ви керували розробкою найбільшого проекту з відкритими вихідними кодами, у якому близько 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 will talk discuss just how the kernel development process works, why we rely on these «ancient» tools, and how they still so much work better than anything else.[1]
Спробуємо розібратися, як це могло статися. Яка роль технологічного фактора і особистісного? Може бути текстовий емайл дійсно ідеальний засіб координації понад-складних проектів?
Довгий шлях до Git
Згадаймо, як все починалося. 25-го серпня 1991 р. нікому невідомий фінський студент написав лист в новинну групу comp.os.minix, в якому анонсував свою роботу над вільною операційною системою і швидке її завершення. У жовтні того ж року він виклав версію 0.0.2 на ftp в директорії Linux, сповістив про це комрадов хакерів і понеслося...
З самого початку здійснювалася розробка розподіленої командою ентузіастів. Перший час Лінус Торвальдс перевіряв кожен патч, переписував і сам же його встановлював. Команда росла, патчів ставало все більше, ядро росло і ускладнювалося. Довелося ставити патчі на швидку руку, часто без всяких змін. У цій ситуації Лінус прийняв єдино вірне рішення — делегувати і довіряти роботу, тим у кого виходить. Цей процес добре ілюструє лист відоме як Лінус не масштабується, в якому Лінус скаржиться на перезавантажити перевантаження і пропонує призначити мейнтейнерів різних підсистем ядра.
Linus doesn't scale, and his way of current 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) email of in 2067 individual messages:
З них, як мінімум, 237 живих листів в розсилку, Грег читає їх все.
237 emails mailing lists to 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 "з" line specifying the patch author (only if needed 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 market 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 '\302\240 ' ('\xC2\xA0\x20'), 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 в перекладі.
Перевірка патчів в листах — відстій порівняно з 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.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.