03.11.2016 18:07
temujin 74 24700 Источник

Как бы вы руководили разработкой крупнейшего проекта с открытыми исходниками, в котором порядка 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) захотел сделать то, что умел делать лучше других — осуществить обратную разработку[3] 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 '\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 в переводе.

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


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


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


В качестве резюме, предлагаю комментарий на 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.
  3. ^ Реверс-инжиниринг.
Поделиться с друзьями
-->

Комментарии (74)


  1. D_E_S
    03.11.2016 22:53
    #9894024
    +3

    Очень познавательная и хорошея статья! Может мы чего-то не знаем о github и почта остаётся на сегодняшний день одним из надёжных вариантов?


    1. bromzh
      04.11.2016 02:20
      #9894178
      +3

      Гитхаб как-то закрывал роскомнадзор. Почта в этом плане гораздо надёжнее.


      1. kazarey
        04.11.2016 10:20
        #9894366
        +1

        Гитхаб закрывал Роскомнадзор, или Роскомнадзор — Гитхаб? :)


        1. Erelecano
          04.11.2016 10:52
          #9894408
          +5

          Эх, если бы гитхаб закрыл Росцензуру это был бы рай.


      1. GamePad64
        04.11.2016 15:29
        #9894760
        +1

        Нет, с гитхабом было всё в порядке. А вот нас от гитхаба закрыл роскомнадзор.


  1. Vjatcheslav3345
    03.11.2016 22:54
    #9894028
    +3

    Может, просто добавить в современные инструменты кое какой функционал [консольных] почтовых программ?
    Сами почтовые сообщения, применяемые в разработке, ещё больше стандартизировать, снабдить спецразметкой.
    В итоге письма можно будет генерировать, пересылать и обрабатывать автоматически.
    И никто не останется обиженным — даже "Штирлиц"-путешественник, выходящий на связь раз в неделю в сиесте под сенью африканских баобабов.


    1. funca
      03.11.2016 23:03
      #9894036
      +5

      И тогда он взял и за один день написал Git.
      Ребятам, которые делают GitHub, надо бы устроить акцию просвещения среди мейнтейнеров ядра. Иначе кто-то снова сядет, и напишет за один день. Они это могут, и кто его знает, что тогда будет с этим вашим GitHub через два года. :)


      1. melon
        04.11.2016 00:00
        #9894088
        +5

        И тогда он взял и за один день написал Git.

        Ага, конечно! За один день!!! За 1 день написал и потом 9 дней отлаживал разве что))) Я конечно понимаю, что многие любят приукрашивать, но это имхо перебор!

        P.S. Вот тут интервью в котором Линус говорит, что первая версия была написана за 10 дней https://geektimes.ru/post/248744/.


        1. temujin
          04.11.2016 00:02
          #9894092
          +3

          И да и нет. За 1 день Линус написал, git, который мог коммитить сам себя. Ссылки по гуглежу или по требованию.


          1. asdf87
            04.11.2016 01:11
            #9894126
            +4

            Скорее всего меня сейчас дико заминусуют, но я все же скажу.

            Скорее всего "… и нет". Но эта история похоже сильно разукрашена. Иначе так можно говорить про каждый удачный прототип, еще и созданный по идеям уже существующих программ того же класса. Как-то нечестно получается по отношению к другим программам и их разработчикам.

            Для меня, время создания продукта (и в том числе git'а) — это время выхода первой стабильной версии (1.0.0 по semver'у). Судя по зеркалу git'a на github'e (https://github.com/git/git) первый сохранившийся коммит в git был 3 апреля 2005 года, а релиз 1.0.0 — 21 декабря 2005. Похоже 10 дней немного растянулись, не говоря уже про 1.


            1. Areso
              04.11.2016 05:32
              #9894220
              +1

              Некоторые продукты никогда не зарелизятся (или не имеют релизной версии), но ими уже пользуется значительное число людей.
              Версия 1.0.0 еще ни о чем не говорит. Посмотрите на сегодняшние игры, в их «релизную» версию зачастую играть нельзя без патча первого дня.


              1. asdf87
                04.11.2016 11:27
                #9894432
                +1

                О каких продуктах идет речь? Можно пример? а лучше несколько :-)

                И что такое значительно число людей в вашем понимании?

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

                Если некоторое количество людей пользуется продуктом до релиза — это фактически не говорит ни чего о готовности программы. Автор может найти какой-нибудь фатальный недостаток и все переделать или вообще разочароваться в идее и свернуть разработку. Но после релиза уже появляются определенные обязательства и гарантии, которые дает автор. То что не все производители добросовестно к этому относятся это уже совсем другой вопрос.


                1. vsb
                  04.11.2016 12:08
                  #9894466

                  Версия 1.0 не говорит о том, что это релиз. Каждый разработчик вкладывает свой смысл в версию. Для кого-то 1.0 это релиз, а 0.9 это бета. Для кого-то 0.0.0 это релиз, а 0.0.0-BETA это бета. Мне ближе второй вариант, например, потому что числа считают с нуля, а не с единицы, поэтому версия 1.0 это по сути вторая версия программы, не совместимая с первой.


                  1. stokker
                    04.11.2016 12:34
                    #9894496
                    +1

                    Это только программисты так считают ))


                  1. asdf87
                    04.11.2016 22:30
                    #9895152

                    Что вы так привязались к этим цифрам? Чего они вам покоя не дают?

                    В моем исходном сообщении фраза «1.0.0 по semver'у» была в качестве примера, а не строгого определения. Ключевой вопрос в том как посчитать длительность создания продукта? т. е. временной интервал от начала работы над продуктом и до появления первой законченной версии версии программы, которую пользователь может взять установить и пользоваться.

                    И я сказал, что, на мой взгляд, второй из этих дат должна быть дата стабильного релиза, а не дата завершения прототипа, проведения большоего бенчмарка или чего-то еще. Как ее определить? Этот вопрос как правило требует отдельного расмотрения в каждом отдельном случае.

                    Да, возможно с версией git'a 1.0.0 я и погорячился. Скорее всего там не использовалось сематическое весионирование. Но для такого софта как git стабильной версией, как правило, считается та версия продукта, которая уже где-то внедрена в продакшен, на которую какой-то пользователь готов «поставить» свои деньги, кусочек своего бизнеса, репутации и т. п. Т. е. это как минимум 16 июня 2005 когда был первый релиз linux'a под git'ом. Очевидно, где-то в эти же дни должен был быть релиз очередной версии самого git'a.

                    В любом случае, это говорит о том что git создавался больше чем 1 день (или 10 дней, кому что ближе).


                1. Areso
                  04.11.2016 20:37
                  #9895060

                  Как пример, у меня установлена программа Popcorn Time, и её версия 0.3.10. Надеюсь, в её популярности и широте аудитории у вас нет сомнений. Еще на память приходит syncthing, но его ниша несколько более узкая по понятным причинам. Увы, у меня сейчас нет под рукой большого числа установленных программ, потому что я пережил очередную переустановку системы из-за глюка, который кочует из релиза (старше единички) ОС в релиз (старше единички) уже много лет. До переустановки у меня было несколько программ в использовании с мажорной версией меньше единицы.

                  Автор всегда может найти фатальный недостаток и все переделать между мажорными версиями, или вообще разочароваться в идее и свернуть разработку — независимо от версии, потому что это его личное право. Особенно, если это проприетарное ПО.

                  Никаких гарантий не появляется, большинство ПО распространяется WITH NO WARRANTY даже если оно платное, думаю, вы знакомы со значительным числом лицензий, включающих в себя такую оговорку… Некоторые лицензии могут иметь размер неплохого романа, но вряд ли там 300 страниц гарантийных обязательств.
                  Зачастую, настоящие гарантии стоят отдельных денег и идут отдельным договором.


                1. Akhristenko
                  05.11.2016 11:30
                  #9895420

                  О каких продуктах идет речь? Можно пример?

                  Например, composer в мире php стал популярным и стандартом де-факто еще до выхода версии 1.0.0


          1. melon
            04.11.2016 22:20
            #9895142

            Всё-таки git — это система контроля версий и умение коммитить самого себя — это конечно круто, но для контроля изменений и нормальной работы — вообще ни фига недостаточно. Можно сказать, что Линус стартанул проект git — за один день. А рабочий прототип сделал через 10. Было бы интересно, если бы ты дал пруф на то, когда его впервые ввели в использование внутри какого-то проекта, скорее всего первым проектов конечно же было ядро Linux.


    1. temujin
      03.11.2016 23:19
      #9894054
      -1

      Я тоже об этом думал, и одним из тезисов GRH за электронку было то, что она легко интегрируема в разные среды. Ну так и интегрируйте, для покорителей Лимпопо и обделенных безлимитным интернетом за смешные деньги.


    1. fshp
      04.11.2016 08:06
      #9894274

      Вообще-то git и так сам формирует письмо.


      1. Vjatcheslav3345
        04.11.2016 08:17
        #9894278
        +1

        Тут наоборот надо — письмо "в git", которое писаться может человеком о нём даже не слышавшим, а git должен его обработать правильно.
        Другой вариант, — это когда git пользуются, но без постоянного интернета и при его дороговизне — тут попроще, так как программа всегда сможет сгенерировать и отправить понятное другой программе письмо.


        1. fshp
          04.11.2016 08:23
          #9894280

          Да никто не будет писать руками патчи. Если патч не будет оформлен правильно, Линус сам лично пошлет в грубой форме такого разработчика. А git умеет сам отправлять письма и получать патчи из почтового ящика. Руками ничего делать не нужно.


          1. Vjatcheslav3345
            04.11.2016 08:30
            #9894286

            Тогда в чём весь сыр-бор в статье? Может, просто надо было выпустить отдельное подробное руководство с переводом его на нац-е языки типа "Использование возможностей электронной почты в git", постараться сделать почту в git удобной, да и всё (и все любители почты в разработке станут использовать git ещё и как почтового клиента)?


            1. fshp
              04.11.2016 15:44
              #9894774

              Так на хабре уже было такое руководство.


      1. am-amotion-city
        04.11.2016 11:32
        #9894438
        -2

        git не формирует никаких писем, конечно же. github — тот да, формирует. Но цветастые и, давайте будем честными, гораздо менее внятные, чем голые патчи.


        1. maydjin
          04.11.2016 15:01
          #9894724
          +1

          man git-send-email


          1. am-amotion-city
            04.11.2016 15:19
            #9894744
            -4

            dict "формирует"

            :)


            1. OYTIS
              04.11.2016 15:23
              #9894752
              +1

              Формирует (вместе с git format-patch) и отправляет, что не так?


              1. am-amotion-city
                04.11.2016 15:40
                #9894768
                -5

                Пока эта команда не повешена на хук, письма эксплицитно формирует человек, так же, например, как git не формирует коммиты и git не формирует пулл-реквесты.


                Ладно, это совершенно терминологический нюанс, пардон.


                1. fshp
                  04.11.2016 15:46
                  #9894776
                  +3

                  А может git ещё и код за вас писать будет? Может разработчик заребейзит свой код. Откуда git узнает в какой момент отправлять письмо?


        1. fshp
          04.11.2016 16:55
          #9894866

          Я не совсем понимаю, какие письма формирует github?


          1. am-amotion-city
            04.11.2016 17:34
            #9894900
            -1

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


            Это письмо и формирует гитхаб.


            1. fshp
              04.11.2016 19:21
              #9894986

              Пока эта команда не повешена на хук, письма эксплицитно формирует человек, так же, например, как git не формирует коммиты и git не формирует пулл-реквесты.

              Но кнопку отправки пулл-реквеста нажимает пользователь. Не вижу разницы между нажатием кнопки и вводом команды в консоли. Везде отправку письма инициирует человек.


              1. am-amotion-city
                04.11.2016 20:07
                #9895032
                -1

                Это уже больше смахивает на занудство с моей стороны, но я все же принесу извинения за это и постараюсь донести мысль: git — система управления версиями. Ей невозможно пользоваться не совершая таких действий, как commit, push и pull. Ну, то есть, возможно, но не очень понятно зачем.


                Сразу после установки софта к себе на компьютер, вы получите возможность создать репозиторий, или склонировать чужой, или даже закоммитить что-нибудь куда-нибудь.


                При этом у гита есть биндинги к почтовому клиенту, которые написаны на перле и являются простым врапом перловской библиотеки. Они никаким образом не принадлежат ядру гита и [наверняка] большинству пользователей не нужны, или даже не известны. На работу гита они не влияют. Можно годами работать с гитом и не знать про них.


                Если же вы работаете с гитхабом, то почта вам начнет сыпаться фактически без вашего участия, по умолчанию. В этом разница.


                1. maydjin
                  06.11.2016 16:25
                  #9896502

                  Не знает, тот кто не читал встроенную документацию.
                  Лично я пользовался сей фичей и отнюдь не для разработки ядра.
                  Вот вам юзекейс:


                  Вы работаете в банке, у вас нет доступа к..., да ни к чему кроме почты, даже для самба шары надо месяцок подождать пока служба безопасности примет решение.
                  А хочется ревью и командной работы.


                  И скажу я, тут, будь ещё формализованный способ оставлять комментарии к диффу в почтовой рассылке — я бы предпочёл сей вариант как минимум для разработки закрытого ПО, что github'у, что gitlab'у, что stash'у. Ну может быть со стороны билд инженера хабы были бы и поудобней конечно, но со стороны разработки — это лишние рюшечки.


                  А удобно это именно благодаря git-am, git-format-patch и git-send-email. Даже кнопок меньше нажимать и кроме терминала для работы ничего не нужно.


                  1. am-amotion-city
                    07.11.2016 08:55
                    #9897038

                    Ну раз лично вы читали, знаете, и пользовались, то тогда конечно.

                    > будь ещё формализованный способ оставлять комментарии к диффу в почтовой рассылке

                    Он есть, формализованный, в гитхабе.

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


                    1. maydjin
                      07.11.2016 13:30
                      #9897474

                      Есть такая вещь, как протокол.


                      Например unified diff это протокол, для хранения и передачи информации об изменениях, и его поддерживает не только git, но так же все остальные современные системы контроля версий, так же как и огромное количество софта напрямую никак не связанного с контролем версий (diff, patch, vim, emacs, meld, e.t.c).


                      Почему бы не подготовить протокол совместимый с unified diff для хранения комментариев к изменениям, когда протокол для хранения изменений уже имеется?


                      В гите его нет

                      В git есть низкоуровневые протоколы внутреннего устройства, и поддержка кучи совместимых открытых протоколов (вплоть до формата лога совместимого с svn, что бы разработчикам gui меньше переделывать). Однако, протоколу комментариев и не место в git, и где хранить сии комментарии привязанные к хэшу изменения + номер в патче напимер не суть важно, это не дело протокола определять такие вещи а дело реализации. Единственный неудобный момент в сей идее — это как связать патч и коммит, не уверен, что git am соблюдает в итоге хэши коммитов (хотя git-format-patch сию информацию в патчи заносит).


                      Он есть, формализованный, в гитхабе.

                      Он закрытый, совместимый только с гитхабом, никак не экспортируемый(ну на самом деле есть rest api, но решения для хранения отвязанного от идентификаторов gh нет). Закройся гитхаб (что в свете последних тенденций не так уж и маловероятно) пропадёт вся история комментариев по ревью.


                      Это не так критично, как пропажа кода, поэтому не так развито пока что. Однако, это как с распределёнными ide.


                      1. sumanai
                        07.11.2016 17:15
                        #9897902
                        +1

                        Закройся гитхаб (что в свете последних тенденций не так уж и маловероятно)

                        Закрывается не Гитхаб, а доступ к нему из одной слабозаселённой страны.


                        1. bromzh
                          07.11.2016 18:03
                          #9897998

                          Не из одной


                          Но и сам гитхаб иногда тупит или не отвечает. Иногда это только веб-морда, но порой и репозитории тоже недоступны.


                      1. am-amotion-city
                        07.11.2016 18:06
                        #9898004

                        > неудобный момент в сей идее — это как связать патч и коммит

                        Это не «неудобный», а нерешаемый момент, потому что (см. выше) в распределенных системах контроля версий нет «главного» репозитория. Ваш коммит может существовать только в вашей локальной версии репозитория (скажем, если был `squash`, или еще что). В общем случае, без мастер-репозитория привязка чего угодно к коммитам не имеет никакого смысла.

                        > он закрытый, совместимый только с гитхабом, никак не экспортируемый

                        Ох. Да он из коробки не только _экспортируемый_,  но и _экспортированный_ уже. В вашу же почту. И в почту всех людей, которые подписаны на эти изменения. Все, что нужно для полного воссоздания истории по этим письмам — поддерживать _полную_ актуальную копию мастер-репозитория у себя.
                        Если гитхаб закроется (я не очень понял, что вы имели в виду под «в свете последних тенденций не так уж и маловероятно», но допустим) — простейший скриптик на awk, или чем угодно еще, — и вуаля.


                        1. maydjin
                          08.11.2016 11:39
                          #9898870

                          Это не «неудобный», а нерешаемый момент

                          Однако, он решён целым рядом средств. Понятно что отличие там, что центральный репозиторий всё-таки есть. Однако, сделать свой дополнительный ключ в коммите git не так уж и сложно.


                          В вашу же почту. И в почту всех людей, которые подписаны на эти изменения

                          И можно продолжить ревью с тем же уровнем инструментильной поддержки без участия gh? Ой ли.


                          простейший скриптик на awk

                          И в каком формате будет выхлоп? Ну если только в формате вызовов rest api по добавлению комментариев обратно на gh.


                          1. am-amotion-city
                            08.11.2016 13:02
                            #9899010

                            > можно продолжить ревью с тем же уровнем
                            > инструментильной поддержки без участия gh? Ой ли.

                            Да, если отказаться от инструмента, то продолжать что-либо с его поддержкой невозможно. Это следует из определений слов «отказаться», «инструмент» и «поддержка», гитхаб тут ни при чем.

                            > Ну если только в формате вызовов rest api
                            > по добавлению комментариев обратно на gh.

                            Мы в ветке обсуждения сценария «гитхаб закрылся». Я теряю нить, простите.

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

                            Я не понимаю, вам семи баксов в месяц на закрытый проект жалко? Да, проблема решена целым рядом средств, и гитхаб там занимает почетное первое место с гигантским отрывом. Если вам милее велосипеды — это прекрасно, сделайте такой велосипед и убедите мир, что он лучше гитхаба (так, кстати, сделал Линус со своим гитом). Ну а мы пока продолжим пользоваться благами цивилизации.


                            1. maydjin
                              08.11.2016 17:29
                              #9899500

                              если отказаться от инструмента, то продолжать что-либо с его поддержкой невозможно

                              Контр примеры:
                              Я могу отказаться от pidgin в пользу empathy.
                              Я могу отказаться от vimdiff в пользу meld.
                              Я могу отказаться от sendmail в пользу postfix.


                              Для этого и придумывают протоколы..


                              Я не понимаю

                              В точку.
                              Видимо моих коммуникативных навыков не хватит донести до вас сию мысль.


                              1. am-amotion-city
                                09.11.2016 09:34
                                #9900354

                                Или, как вариант, у вас не хватает мысли. Не говоря о том, что просто следить за дискурсом вам тоже не удается. Да и что такое «протокол» вы тоже не понимаете, почитайте хотя бы википедию. То, что вы называете «протоколом» является по сути унифицированным форматом. Например, `patch` — это не протокол, это формат.

                                Апеллирование к неполным цитатам — это вообще за гранью нормального ведения дискуссии.

                                Просто для случайно забредшего читателя подытожу: создание протокола поддержки почты для `git` невозможно по сразу двум причинам.

                                1. `git` (в отличие от, например, jabber с его XEP’ами) не поддерживает расширений.
                                2. для унификации почтовых отправлений требуется центральный репозиторий, который полностью противоречит идеологии гита.

                                Поэтому почта _навсегда_ останется read-only средством нотификации в гите. В системах с центральным репозиторием, напротив, почтовые сообщения могут быть привязаны к коммитам и имплементация уже существует.


                                1. maydjin
                                  09.11.2016 11:14
                                  #9900512

                                  Ну, в чём то вы правы — unified diff, это формат пакета протокола, если быть точным в определениях. Содержит список файлов, и набор операций, по воспроизведению изменений для каждого файла.
                                  В случае git-send-email и git-am он дополнительно инкапсулирован в пакет с заголовками, содержащими хэш, сообщение в лог, дату и автора изменения.
                                  А поток таких пакетов передаётся в пакете e-mail сообщения.


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

                                  Чем это отличается от требований к ревью на gh и иже с ним? Видимо всё таки не полностью нарушает идеологию? Идеология git скорее в том, что бы дать возможность работать в том стиле как удобно, хочешь централизованный репо — не вопрос, ограничь себя сам или с помощью подсадки на набор инструментов.


  1. melon
    04.11.2016 00:01
    #9894090

    И тогда он взял и за один день написал Git.

    Ага, конечно! За один день!!! За 1 день написал и потом 9 дней отлаживал разве что))) Я конечно понимаю, что многие любят приукрашивать, но это имхо перебор!

    P.S. Вот тут интервью в котором Линус говорит, что первая версия была написана за 10 дней https://geektimes.ru/post/248744/.


  1. DmitryKoterov
    04.11.2016 08:40
    #9894296
    +4

    Я думаю, тут дело в другом — почему почта хороша для этих целей, а инструменты код-ревью и гитхаб — не очень. Мейнтейнеры линукса могут себе позволить быть ооочень строгими и привередливыми. Например, присылает кто-то патч — а они могут вместо ревью просто нажать Reply и отправить: «Код попахивает, работайте еще». Или: «Я ничего не понял, слишком сложно — думайте». И так — несколько раз. Т.к. желающих протащить патчи в ядро огромное можество, и желание это обычно исключительно сильное, люди вылизывают патчи до невозможности, а также разбивают свои изменения на множество мелких патчей, практически идеальных по отдельности. В принципе, для качества продукта это хорошо, а за скоростью никто и не гонится.

    В то же время, обычные компании такого себе позволить не могут. Потому у них в почете и системы код-ревью, и гитхаб, и все остальное. Там, если кто-то прислал дифф на ревью — надо его похвалить, подбодрить, надо обязательно написать комментарии ко всем спорным местам и т.д. Иначе инженер расстроится или, не дай бог, обидется — а лучше, когда инженеры счастливы.


    1. DmitryKoterov
      04.11.2016 08:45
      #9894304

      Ну т.е. электронная почта лучше для строгих и быстрых ревью диффов. Проглядел, прислушался к своей интуиции, черкнул 1 строчку, отправил, заархивировал — следующий! А там уже «на той стороне» пусть потеют. Зато масштабируется: это можно понять, «той стороны» много, а «этой» — мало.


      1. Vjatcheslav3345
        04.11.2016 09:33
        #9894342

        Отсюда следует практический вывод — патчи в ядро линукса д. б., по возможности, только из одной строчки кода и 1-5 строк письма или комментария к коду — так меньше вероятность того, что майнтейнер что то не поймёт или зарежет патч из за сомнений или просто из за переутомления от чтения супердлинных "войны и мира" на Си.


  1. JIghtuse
    04.11.2016 09:42
    #9894348

    Линус пояснял, почему Github не пригоден для него. Другой причиной можно считать более низкий порог вхождения — правки минуют мэйнтейнеров, и каждый пользователь Github может спамить исправлениями опечаток (взгляните хотя бы на количество PR к этому репозиторию).


    Наконец, последние тенденции Github неплохо подорвали его репутацию. Многие перезжают на Gitlab.


    1. OYTIS
      04.11.2016 13:10
      #9894564

      Подорвали репутацию? По-моему, nobody cares.


      1. Casus
        04.11.2016 18:30
        #9894944

        То ли еще будет… если не одумаются. Nobody cares — это ровно до тех пор, пока пару громких дел не будет.
        За GitHub уже замечались политизированные решения. Найм полиции нравственности плюсов им не прибавит.

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


        1. OYTIS
          04.11.2016 21:35
          #9895090
          +1

          Nobody cares, пока это не затрагивает реальные интересы клиентов. Пока «цензура» касается оскорбительных терминов в доцументации, комментах или даже именах переменных, это никому не мешает. Более того, большинство мантейнеров прислушиваются к таким замечаниям совершенно искренне. Преобладание белых мужчин в индустрии сильно беспокоит бизнес по причине нехватки кадров, и если есть слабая надежда, что замена Master/Slave на Leader/Follower поможет утолить кадровый голод, то за нее охотно хватаются.
          Конкуренция — это в любом случае хорошо, но «политкорректность» — это последний критерий, на который бизнес ориентируется. Если гитхаб наймет сотню боевых феминисток, а гитлаб ляжет на день или потеряет пару репозиториев, то люди выберут гитхаб.


          1. Casus
            07.11.2016 19:05
            #9898102
            +1

            Подобные изменения уже касаются многих. Пример — Composer (менеджер пакетов в php) подписались под «Contributor Code of Conduct», и теперь в случае merge request на изменения, контрибьютор автоматом соглашается на этот свод правил. На которые, лично я, не согласен, от слова — совсем.

            Плюс ли это для меня — нет.
            Плюс ли это для компосер — нет.

            В результате для кого это введение?
            Для дебилов озабоченных толерантностью названий master/slave vs leader/follower?
            На них ли построили себе имена GitHub и в частном случае Composer?


            1. OYTIS
              07.11.2016 19:46
              #9898154
              +1

              Понимаете, человек, не озабоченный толерантностью не заметит этих изменений вовсе. А большинство озабоченных в «первом мире», где и происходит все самое важное в IT, озабочены в левую, а не в правую сторону (руководители Github и мантейнеры Composer тому пример). Причины разнятся от идеологических до сугубо прагматических, которые я озвучил выше.
              Я вот недавно был на Embedded Linux Conference в Берлине и ее организаторы сочли необходимым на открытии дать слово одной (достаточно умеренной, впрочем) феминистской группе, которая занимается привлечением девочек в IT-вузы. ACM меня тоже весьма настойчиво пытается подписать на рассылку, посвященную поддержке женщин в CS. Это не подрывает репутацию ELCE и ACM, наоборот, это считается круто и прогрессивно. Главное — блюсти приоритеты: бизнес-интересы в первую очередь, social justice — во вторую. Вот если Github начнет банить значимых профессионалов за непочтительность к лесбиянкам и выпиливать репозитории — это заметят, а пока все путем.


  1. AlexMal
    04.11.2016 13:10
    #9894562
    +3

    обратную разработку BitKeeper

    Думаю, лучше написать: реверс-инжиниринг


    1. temujin
      05.11.2016 11:33
      #9895426

      Принято, добавил внутреннюю ссылку.


  1. immaculate
    04.11.2016 13:16
    #9894578
    +9

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

    А то хипстеро-фейсбуко-реакто-флюксо-муксо-писатели не в курсе, что где-нибудь в Индии, на Шри Ланке, в Доминиканской Республике, и массе других мест интернет еще тарифицируется по трафику, и очень-очень медленный и ненадежный. И там все эти мигалки, которые неплохо работают на безлимитном соединении 100 Мбит/с, становятся абсолютно бесполезными. Загрузки страницы чаще всего не дождаться — обламывается по таймауту загрузка какой-нибудь очередной супер-пупер обертки над XMLHttpRequest весом в 2Мб. После 20-30 попыток счет за интернет разбухает до неприличной величины, а нервы просто раскалены.


  1. darkmind
    04.11.2016 14:37
    #9894694
    +3

    Честно говоря причины бредовые.

    Возьмем к примеру упомянутый gerrit:
    Говорится что почтой легче например завернуть патч со словами tl:dr. Но чем это отличается от — Нажал Reply..., написал тот же комент, нажал Post. Все. Какого то яростного преимущества почты я в этом сценарии не вижу.

    Т.е. все те недостатки web инструментов пор которые они говорят абсолютно так же есть и в почте. Все преимущества почты есть и в web тулзах.
    Единственно момент с отсутствием интернета, это да, у почты в этом фора.

    Еще непонятный момент — почему критикуя web тулзы они говорят именно про github? Вон в каментах упоминают Gitlab например или вообще что мешает поднять свой для разработки ядра? Таким подходом можно было б и добавить фичу «скачать все патчи за раз». Я так понимаю именно на этот сценарий они упирают в аргументе про постоянный доступ к интернету?


    1. DmitryKoterov
      04.11.2016 18:27
      #9894942
      +2

      Не знаю конкретно про ядро, но в меня была такая история: год назад один человек попросил меня поревьювить его код, пока он тренируется. Мы перепробовали несколько разных инструментов, но в итоге остановились на том, что он шлет мне просто код на почту, а я его прямо в apple-клиенте на айфоне смотрю и отвечаю. Могу сказать, что это было очень удобно — для меня (я мог ответить молниеносно из любого места, где бы ни находился, и не надо было расчехлять комп). Цикл обратной связи сократился очень сильно. А тут вдруг эта статья про разработку ядра линукса…


      1. am-amotion-city
        04.11.2016 20:08
        #9895036

        У гитхаба есть довольно удобный мобильный клиент.


    1. Randl
      05.11.2016 13:15
      #9895496

      Да и проблему оффлайна можно решить управлением через мейл: отправил письмо на определенный ящик, и автоматически создался PR. Отвечать на комментарии через почту на гитхабе можно и сейчас


  1. Londoner
    04.11.2016 18:03
    #9894924

    Да, если писем много, то браузерный таб с веб-мордой GMail начинает выкушивать почти гиг памяти. Кто знает как можно вылечить эту беду?


    1. xRay
      04.11.2016 20:08
      #9895034
      +1

      Не держать Gmail все время открытым во вкладке. И периодически перезапускать браузер.


      1. Londoner
        04.11.2016 20:11
        #9895038

        Пробовал, после перезапуска гы-мейлу требуется примерно пол-часа чтоб навестать пожираемый объём памяти. Каждые пол-часа перезапускать? Бред ведь…


        1. xRay
          04.11.2016 20:16
          #9895046

          Я тоже с этим столкнулся. По-этому не держу Gmail все время открытым во вкладке в браузере.


          1. Londoner
            04.11.2016 20:25
            #9895050

            Эхе-хе… А корпорация добра конечно, блин, не может как-то по-доброму пофиксить багу…
            Осто надоело...


    1. tautomer
      04.11.2016 23:07
      #9895186

      Так во время загрузки страницы, над полосой загрузки есть ссылка «открыть упрощённую HTML-версию». Конечно, она уведомлений о письмах присылать не будет. https://mail.google.com/mail/u/0/h/


  1. Ahcai5oh
    04.11.2016 22:35
    #9895158
    +5

    Ого, кто-то взялся рассказать поколению гитхаба про списки рассылки.


  1. Saffron
    05.11.2016 08:47
    #9895338

    Всё правильно делают. Свежее поколение уже забыло, что интернет — это не только веб. Ничего, подрастает новое, которое думает, что интернет ограничен социальными сетями. Но на самом деле веб — это только один из нескольких фундаментальных протоколов.

    Есть базовые потребности интернет пользователей — передать файл, опубликовать данные для неопределённого круга лиц, либо организовать общение между двумя (несколькими) определёнными пользователями. Для этих базовых потребностей давным давно были придуманы такие же базовые и примитивные протоколы. FTP для файлов. Web (HTTP + HTML) для публикации. Для общения сразу два: IRC и email. Так много вышло не от хорошей жизни — технические ограничения препятствовали универсальному решению.

    Универсальные протоколы хороши как раз тем, что не ограничивают тебя определённым клиентом. Ставь любимый и работай с ним. Неужели вы думаете, что разработчики ядра из веб интерфейса почты патчи Ctrl-C копируют? У них там небось уже давно все нужные скрипты написаны, круче любой готовой системы для code review. Готовые системы — это замечательно просто, но ничто не сравнится по удобству с подстроенной под себя системой.

    Просто она стоит дороже — надо личное время тратить. Но если ты его уже потратил, ты не захочешь отказываться от своих вложений. Поэтому разработчики и не хотят менять свой воркфлоу. Их он всем устраивает, и для этого они приложили много усилий. Что им может предложить гитхаб?

    Вебсервисы вообще часто оказываются неуклюжими в использовании и малопригодными для кастомизации/автоматизации. Пытаться реализовать общение через веб — это всё равно что отдавать веб-странички через email бота. Можно построить троллейбус из хлеба, но зачем? email на уровне протокола поддерживает все необходимые абстракции.

    Конечно, ещё есть опция сделать специализированный протокол, например, пресловутый REST API. Проблема со всеми специализированными API — что их слишком много, каждый изобретает свой, да ещё и меняет раз в два месяца. Естественное поведение коммерческой программы — предельно усложнить использование API вне пределов своих собственных продуктов. API вроде бы есть, а как бы и нет. Что существенно отличается от того подхода, который использовали древние ITшники для организации глобальной сети. Это заметно по одному тому факту, что все древние протоколы поддерживают федерацию. Подразумевается, что серверов в сети может быть много, у разных владельцев и разных бизнесов, и что клиент может прозрачно взаимодействовать со всем этим многообразием. Так устроен и веб, и почта, и IRC, и даже более новый XMPP.

    Это всё древние протоколы, рассчитанные на старые реалии, имеют множество известных недостатков, текст-ориентированность почты, склонность к спаму, отсутствие логирования оффлайн сообщений в IRC/XMPP и прочее. Жить со всем этим легаси можно, есть обходные пути. Необходимость обновления, правда, уже давно назрела.

    Но бессмысленно обвинять пользователей старых протоколов, если ты не готов предложить новых. А бизнес не хочет предлагать новых, первым делом он задаёт вопрос «а в чём моя прибыль», и каждый раз когда он начинает оптимизировать прибыль, лучшие намерения превращаются в компост. А пользователи не виноваты, что они привыкли к свободе и не желают лезть в клетку.


    1. stokker
      05.11.2016 22:50
      #9896000
      +1

      Думаю, что на новых протоколах то-же можно неплохую прибыль поднять…


  1. Randl
    05.11.2016 13:17
    #9895514

    В общем и целом, все сказано в выводах: причина именно в том что Линус и ко умеют работать так, а не иначе, и им так удобно. Остальное вторично


    1. Erelecano
      09.11.2016 01:04
      #9900152

      Я бы даже вас поправил. Не в том, что они умеют так работать, а в том что когда начиналась разработка ядра именно так работать было удобней и реальней всего. Я не удивлюсь если на каких-то других проектах, о которых меньше известно, ГКХ и Линус могут работать с чем-то иным. Я не удивлюсь если в повседневной жизни Линус пишет жене вопрос «Когда у тебя тренировка заканчивается?» в телеграм и созванивается с Грегом в воцаппе, что бы сказать ему «Грег, ты не прав».
      Но именно так(через почту) было удобней всего вести разработку в то время, когда все начиналось. Плюс e-mail, особенно отправленный в рассылку, является явным и точно написанным, его видят все участники рассылки и от него уже не отмажешься. Я тоже предпочитаю формализацию через e-mail при работе с заказчиками вне трекеров, увы, не все заказчики на это идут, некоторым удобней через Телеграм и мне приходится с этим мириться.


      1. Randl
        09.11.2016 13:07
        #9900704

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