Comments 75
Может, просто добавить в современные инструменты кое какой функционал [консольных] почтовых программ?
Сами почтовые сообщения, применяемые в разработке, ещё больше стандартизировать, снабдить спецразметкой.
В итоге письма можно будет генерировать, пересылать и обрабатывать автоматически.
И никто не останется обиженным — даже "Штирлиц"-путешественник, выходящий на связь раз в неделю в сиесте под сенью африканских баобабов.
И тогда он взял и за один день написал Git.Ребятам, которые делают GitHub, надо бы устроить акцию просвещения среди мейнтейнеров ядра. Иначе кто-то снова сядет, и напишет за один день. Они это могут, и кто его знает, что тогда будет с этим вашим GitHub через два года. :)
И тогда он взял и за один день написал Git.
Ага, конечно! За один день!!! За 1 день написал и потом 9 дней отлаживал разве что))) Я конечно понимаю, что многие любят приукрашивать, но это имхо перебор!
P.S. Вот тут интервью в котором Линус говорит, что первая версия была написана за 10 дней https://geektimes.ru/post/248744/.
Скорее всего "… и нет". Но эта история похоже сильно разукрашена. Иначе так можно говорить про каждый удачный прототип, еще и созданный по идеям уже существующих программ того же класса. Как-то нечестно получается по отношению к другим программам и их разработчикам.
Для меня, время создания продукта (и в том числе 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.0.0 еще ни о чем не говорит. Посмотрите на сегодняшние игры, в их «релизную» версию зачастую играть нельзя без патча первого дня.
И что такое значительно число людей в вашем понимании?
Реализная версия говорит не только о том, что в ней не должно быть критических багов, а также о том что автор уверен в выбранном им подходе и как минимум ключевой функционал программы реализован.
Если некоторое количество людей пользуется продуктом до релиза — это фактически не говорит ни чего о готовности программы. Автор может найти какой-нибудь фатальный недостаток и все переделать или вообще разочароваться в идее и свернуть разработку. Но после релиза уже появляются определенные обязательства и гарантии, которые дает автор. То что не все производители добросовестно к этому относятся это уже совсем другой вопрос.
В моем исходном сообщении фраза «1.0.0 по semver'у» была в качестве примера, а не строгого определения. Ключевой вопрос в том как посчитать длительность создания продукта? т. е. временной интервал от начала работы над продуктом и до появления первой законченной версии версии программы, которую пользователь может взять установить и пользоваться.
И я сказал, что, на мой взгляд, второй из этих дат должна быть дата стабильного релиза, а не дата завершения прототипа, проведения большоего бенчмарка или чего-то еще. Как ее определить? Этот вопрос как правило требует отдельного расмотрения в каждом отдельном случае.
Да, возможно с версией git'a 1.0.0 я и погорячился. Скорее всего там не использовалось сематическое весионирование. Но для такого софта как git стабильной версией, как правило, считается та версия продукта, которая уже где-то внедрена в продакшен, на которую какой-то пользователь готов «поставить» свои деньги, кусочек своего бизнеса, репутации и т. п. Т. е. это как минимум 16 июня 2005 когда был первый релиз linux'a под git'ом. Очевидно, где-то в эти же дни должен был быть релиз очередной версии самого git'a.
В любом случае, это говорит о том что git создавался больше чем 1 день (или 10 дней, кому что ближе).
Автор всегда может найти фатальный недостаток и все переделать между мажорными версиями, или вообще разочароваться в идее и свернуть разработку — независимо от версии, потому что это его личное право. Особенно, если это проприетарное ПО.
Никаких гарантий не появляется, большинство ПО распространяется WITH NO WARRANTY даже если оно платное, думаю, вы знакомы со значительным числом лицензий, включающих в себя такую оговорку… Некоторые лицензии могут иметь размер неплохого романа, но вряд ли там 300 страниц гарантийных обязательств.
Зачастую, настоящие гарантии стоят отдельных денег и идут отдельным договором.
О каких продуктах идет речь? Можно пример?
Например, composer в мире php стал популярным и стандартом де-факто еще до выхода версии 1.0.0
Тут наоборот надо — письмо "в git", которое писаться может человеком о нём даже не слышавшим, а git должен его обработать правильно.
Другой вариант, — это когда git пользуются, но без постоянного интернета и при его дороговизне — тут попроще, так как программа всегда сможет сгенерировать и отправить понятное другой программе письмо.
Тогда в чём весь сыр-бор в статье? Может, просто надо было выпустить отдельное подробное руководство с переводом его на нац-е языки типа "Использование возможностей электронной почты в git", постараться сделать почту в git удобной, да и всё (и все любители почты в разработке станут использовать git ещё и как почтового клиента)?
man git-send-emailЯ не совсем понимаю, какие письма формирует github?
Пока эта команда не повешена на хук, письма эксплицитно формирует человек, так же, например, как git не формирует коммиты и git не формирует пулл-реквесты.
Но кнопку отправки пулл-реквеста нажимает пользователь. Не вижу разницы между нажатием кнопки и вводом команды в консоли. Везде отправку письма инициирует человек.
Не знает, тот кто не читал встроенную документацию.
Лично я пользовался сей фичей и отнюдь не для разработки ядра.
Вот вам юзекейс:
Вы работаете в банке, у вас нет доступа к..., да ни к чему кроме почты, даже для самба шары надо месяцок подождать пока служба безопасности примет решение.
А хочется ревью и командной работы.
И скажу я, тут, будь ещё формализованный способ оставлять комментарии к диффу в почтовой рассылке — я бы предпочёл сей вариант как минимум для разработки закрытого ПО, что github'у, что gitlab'у, что stash'у. Ну может быть со стороны билд инженера хабы были бы и поудобней конечно, но со стороны разработки — это лишние рюшечки.
А удобно это именно благодаря git-am, git-format-patch и git-send-email. Даже кнопок меньше нажимать и кроме терминала для работы ничего не нужно.
Есть такая вещь, как протокол.
Например 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.
Это не «неудобный», а нерешаемый момент
Однако, он решён целым рядом средств. Понятно что отличие там, что центральный репозиторий всё-таки есть. Однако, сделать свой дополнительный ключ в коммите git не так уж и сложно.
В вашу же почту. И в почту всех людей, которые подписаны на эти изменения
И можно продолжить ревью с тем же уровнем инструментильной поддержки без участия gh? Ой ли.
простейший скриптик на awk
И в каком формате будет выхлоп? Ну если только в формате вызовов rest api по добавлению комментариев обратно на gh.
если отказаться от инструмента, то продолжать что-либо с его поддержкой невозможно
Контр примеры:
Я могу отказаться от pidgin в пользу empathy.
Я могу отказаться от vimdiff в пользу meld.
Я могу отказаться от sendmail в пользу postfix.
Для этого и придумывают протоколы..
Я не понимаю
В точку.
Видимо моих коммуникативных навыков не хватит донести до вас сию мысль.
Ну, в чём то вы правы — unified diff, это формат пакета протокола, если быть точным в определениях. Содержит список файлов, и набор операций, по воспроизведению изменений для каждого файла.
В случае git-send-email и git-am он дополнительно инкапсулирован в пакет с заголовками, содержащими хэш, сообщение в лог, дату и автора изменения.
А поток таких пакетов передаётся в пакете e-mail сообщения.
для унификации почтовых отправлений требуется центральный репозиторий, который полностью противоречит идеологии гита.
Чем это отличается от требований к ревью на gh и иже с ним? Видимо всё таки не полностью нарушает идеологию? Идеология git скорее в том, что бы дать возможность работать в том стиле как удобно, хочешь централизованный репо — не вопрос, ограничь себя сам или с помощью подсадки на набор инструментов.
И тогда он взял и за один день написал Git.
Ага, конечно! За один день!!! За 1 день написал и потом 9 дней отлаживал разве что))) Я конечно понимаю, что многие любят приукрашивать, но это имхо перебор!
P.S. Вот тут интервью в котором Линус говорит, что первая версия была написана за 10 дней https://geektimes.ru/post/248744/.
В то же время, обычные компании такого себе позволить не могут. Потому у них в почете и системы код-ревью, и гитхаб, и все остальное. Там, если кто-то прислал дифф на ревью — надо его похвалить, подбодрить, надо обязательно написать комментарии ко всем спорным местам и т.д. Иначе инженер расстроится или, не дай бог, обидется — а лучше, когда инженеры счастливы.
Отсюда следует практический вывод — патчи в ядро линукса д. б., по возможности, только из одной строчки кода и 1-5 строк письма или комментария к коду — так меньше вероятность того, что майнтейнер что то не поймёт или зарежет патч из за сомнений или просто из за переутомления от чтения супердлинных "войны и мира" на Си.
Линус пояснял, почему Github не пригоден для него. Другой причиной можно считать более низкий порог вхождения — правки минуют мэйнтейнеров, и каждый пользователь Github может спамить исправлениями опечаток (взгляните хотя бы на количество PR к этому репозиторию).
Наконец, последние тенденции Github неплохо подорвали его репутацию. Многие перезжают на Gitlab.
За GitHub уже замечались политизированные решения. Найм полиции нравственности плюсов им не прибавит.
Лично я, своим знакомым, больше не рекомендую использовать github как основной репо для своих наработок.
Конкуренция — это в любом случае хорошо, но «политкорректность» — это последний критерий, на который бизнес ориентируется. Если гитхаб наймет сотню боевых феминисток, а гитлаб ляжет на день или потеряет пару репозиториев, то люди выберут гитхаб.
Плюс ли это для меня — нет.
Плюс ли это для компосер — нет.
В результате для кого это введение?
Для дебилов озабоченных толерантностью названий master/slave vs leader/follower?
На них ли построили себе имена GitHub и в частном случае Composer?
Я вот недавно был на Embedded Linux Conference в Берлине и ее организаторы сочли необходимым на открытии дать слово одной (достаточно умеренной, впрочем) феминистской группе, которая занимается привлечением девочек в IT-вузы. ACM меня тоже весьма настойчиво пытается подписать на рассылку, посвященную поддержке женщин в CS. Это не подрывает репутацию ELCE и ACM, наоборот, это считается круто и прогрессивно. Главное — блюсти приоритеты: бизнес-интересы в первую очередь, social justice — во вторую. Вот если Github начнет банить значимых профессионалов за непочтительность к лесбиянкам и выпиливать репозитории — это заметят, а пока все путем.
обратную разработку BitKeeper
Думаю, лучше написать: реверс-инжиниринг
А то хипстеро-фейсбуко-реакто-флюксо-муксо-писатели не в курсе, что где-нибудь в Индии, на Шри Ланке, в Доминиканской Республике, и массе других мест интернет еще тарифицируется по трафику, и очень-очень медленный и ненадежный. И там все эти мигалки, которые неплохо работают на безлимитном соединении 100 Мбит/с, становятся абсолютно бесполезными. Загрузки страницы чаще всего не дождаться — обламывается по таймауту загрузка какой-нибудь очередной супер-пупер обертки над XMLHttpRequest весом в 2Мб. После 20-30 попыток счет за интернет разбухает до неприличной величины, а нервы просто раскалены.
Возьмем к примеру упомянутый gerrit:
Говорится что почтой легче например завернуть патч со словами tl:dr. Но чем это отличается от — Нажал Reply..., написал тот же комент, нажал Post. Все. Какого то яростного преимущества почты я в этом сценарии не вижу.
Т.е. все те недостатки web инструментов пор которые они говорят абсолютно так же есть и в почте. Все преимущества почты есть и в web тулзах.
Единственно момент с отсутствием интернета, это да, у почты в этом фора.
Еще непонятный момент — почему критикуя web тулзы они говорят именно про github? Вон в каментах упоминают Gitlab например или вообще что мешает поднять свой для разработки ядра? Таким подходом можно было б и добавить фичу «скачать все патчи за раз». Я так понимаю именно на этот сценарий они упирают в аргументе про постоянный доступ к интернету?
Да и проблему оффлайна можно решить управлением через мейл: отправил письмо на определенный ящик, и автоматически создался PR. Отвечать на комментарии через почту на гитхабе можно и сейчас
Ого, кто-то взялся рассказать поколению гитхаба про списки рассылки.
Есть базовые потребности интернет пользователей — передать файл, опубликовать данные для неопределённого круга лиц, либо организовать общение между двумя (несколькими) определёнными пользователями. Для этих базовых потребностей давным давно были придуманы такие же базовые и примитивные протоколы. FTP для файлов. Web (HTTP + HTML) для публикации. Для общения сразу два: IRC и email. Так много вышло не от хорошей жизни — технические ограничения препятствовали универсальному решению.
Универсальные протоколы хороши как раз тем, что не ограничивают тебя определённым клиентом. Ставь любимый и работай с ним. Неужели вы думаете, что разработчики ядра из веб интерфейса почты патчи Ctrl-C копируют? У них там небось уже давно все нужные скрипты написаны, круче любой готовой системы для code review. Готовые системы — это замечательно просто, но ничто не сравнится по удобству с подстроенной под себя системой.
Просто она стоит дороже — надо личное время тратить. Но если ты его уже потратил, ты не захочешь отказываться от своих вложений. Поэтому разработчики и не хотят менять свой воркфлоу. Их он всем устраивает, и для этого они приложили много усилий. Что им может предложить гитхаб?
Вебсервисы вообще часто оказываются неуклюжими в использовании и малопригодными для кастомизации/автоматизации. Пытаться реализовать общение через веб — это всё равно что отдавать веб-странички через email бота. Можно построить троллейбус из хлеба, но зачем? email на уровне протокола поддерживает все необходимые абстракции.
Конечно, ещё есть опция сделать специализированный протокол, например, пресловутый REST API. Проблема со всеми специализированными API — что их слишком много, каждый изобретает свой, да ещё и меняет раз в два месяца. Естественное поведение коммерческой программы — предельно усложнить использование API вне пределов своих собственных продуктов. API вроде бы есть, а как бы и нет. Что существенно отличается от того подхода, который использовали древние ITшники для организации глобальной сети. Это заметно по одному тому факту, что все древние протоколы поддерживают федерацию. Подразумевается, что серверов в сети может быть много, у разных владельцев и разных бизнесов, и что клиент может прозрачно взаимодействовать со всем этим многообразием. Так устроен и веб, и почта, и IRC, и даже более новый XMPP.
Это всё древние протоколы, рассчитанные на старые реалии, имеют множество известных недостатков, текст-ориентированность почты, склонность к спаму, отсутствие логирования оффлайн сообщений в IRC/XMPP и прочее. Жить со всем этим легаси можно, есть обходные пути. Необходимость обновления, правда, уже давно назрела.
Но бессмысленно обвинять пользователей старых протоколов, если ты не готов предложить новых. А бизнес не хочет предлагать новых, первым делом он задаёт вопрос «а в чём моя прибыль», и каждый раз когда он начинает оптимизировать прибыль, лучшие намерения превращаются в компост. А пользователи не виноваты, что они привыкли к свободе и не желают лезть в клетку.
В общем и целом, все сказано в выводах: причина именно в том что Линус и ко умеют работать так, а не иначе, и им так удобно. Остальное вторично
Но именно так(через почту) было удобней всего вести разработку в то время, когда все начиналось. Плюс e-mail, особенно отправленный в рассылку, является явным и точно написанным, его видят все участники рассылки и от него уже не отмажешься. Я тоже предпочитаю формализацию через e-mail при работе с заказчиками вне трекеров, увы, не все заказчики на это идут, некоторым удобней через Телеграм и мне приходится с этим мириться.
Разработка ядра Linux держится на электронной почте