nginx переезжает на GitHub

Поменяли шило на мыло. Github введёт санкции против России и опять будут бегать как зайцы.

Кто заблокирует на GitHub американскую компанию F5 Networks?

Nginx уже лет как пять американский Web-server.

Всё получается? Больше ничего значимого на Mercurial (Hg) не осталось из Open Source проектов? Пал последний оплот Mercurial (hg)

• 2020: OpenJDK перешёл на Git и GitHub: https://www.opennet.ru/opennews/art.shtml?num=53815
• 2020: Mercurial удаляется из хостинга кода BitBucket, который его по сути и популяризовал: https://bitbucket.org/blog/sunsetting-mercurial-support-in-bitbucket
• 2021: SDL перехал с Mercurial на Git и GitHub: https://discourse.libsdl.org/t/sdl-moving-to-github/28700
• 2023: Mozilla переводит разработку Firefox с Mercurial на Git: https://www.opennet.ru/opennews/art.shtml?num=60061
• 2024: NGINX переходит с Mercurial на Git/GitHub: https://www.opennet.ru/opennews/art.shtml?num=61821

Теперь Mercurial полная маргинальщина получается? Что ещё на нём осталось сидеть?

радоваться или плакать ?

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

https://wiki.mercurial-scm.org/ProjectsUsingMercurial

Желающие могут сами проверить, что из этого ещё использует mercurial.

Постоянно веселит этот аргумент «упрощению доступа к разработке и взаимодействию с сообществом». Так и вижу: мне хватило ума поправить код в nginx, но не хватает ума как отправить патч по почте/Track.

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

Ну так пишут, что в Track есть PRы.

радоваться или плакать ?

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

удобный инструмент в виде пуллреквестов

У ядра есть https://patchwork.kernel.org/ и они мержат в среднем около 1.5К патчей каждую неделю. На гитхабе такое количество PR это неуправляемое месиво.

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

Во-вторых, хотя тезис про патчи по почте известный, все его принимают на веру. А почему, собственно, не подходит-то? В чем конкретно проблема?

Чем PR лучше? Патч отправил по почте, она у всех есть, и ждешь ответа. Что бы отправить PR нужно сделать все тоже самое, + зарегистрироваться на мутном сайте принадлежащем Microsoft, указав почту.

Я ж говорю закапывают его. Будут принимать патчи от домохозяек которые смогли на гитхабе зарегиться.

Хватило ума внести изменения в код, протестировать их и … как же патч то сделать и отправить!? Желательно без описания что это и зачем!

Не понял вопрос. Как отправить патч без Гитхаба?

Главная проблема не столько в email, а в том, что все бегут на чертов Гитхаб со смайликами. Централизуется и огораживается все под благим видом. Вот забанили (я так понял, что уже) Гитхаб в России и все — не вышлешь патч даже в лабораторку ХиллБилли из Оклахомы. А со всеми этими 2FA даже через ВПН не авторизируешся.

Пусть вводит, им какое дело до этого?

Уход с Mercurial на Git одобряю. Выбор конкретно GitHub — нет.

Чем PR лучше?

Ревьюверу удобно просматривать изменения, комментировать и отслеживать их. В емейлах сколько-нибудь длинная дискуссия превращается в невнятную стену цитирования.

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

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

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

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

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

Я говорю про общую концепцию PR на сайте, а не про конкретный сайт.

А со всеми этими 2FA даже через ВПН не авторизируешся.

На гитхабе TOTP, какие проблемы-то?

В емейлах сколько-нибудь длинная дискуссия превращается в невнятную стену цитирования

нет, если придерживаться правил и не оверквотить.

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

email это такая же децентрализованная штука как git. вы не потеряете историю переписок и её целостность просто по желанию левой пятки владельца какого-то сервиса.

дискуссии в емейлах древовидные в отличие от комментариев в PR. вы можете фокусироваться только на том, что вам реально нужно.

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

набор патчей в патчсете можно менять - добавлять, удалять, менять порядок, добить на более мелкие, объединять вместе или вставлять в середину. в случае PR правка истории изменений это цирк с конями. по сути у вас есть только git rebase со всеми его недостатками.

Так и вижу: мне хватило ума поправить код в nginx, но не хватает ума как отправить патч по почте/Track.

А зря ёрничаешь. Такие даже тут встречались → багу поправил, но регаться на багтрекере софтины не будет, потому что ну его нафиг, везде регаться.

Я скорее в частном багтрекере зарегюсь (собственно и регался на нескольких) чем на сайте микрософта, пытающемся монополизовать хостинг реп.

Видимо решили закопать его.

НУ ТАК ЧТО, ПЕРЕХОДИМ НА АПАЧ?

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

Поздрвляю, ты входишь в небольшой процент тех, кто это сделает.

Это шутка была, насчёт того, что нет ничего сложного в этом. Я отправлял патчи напрямую по почте, когда зеркало репы на гитхпбе было недоступно.

Конкретно в Гитхабе еще бесит, что при изменении кода комментарии к нему скрываются. Также нельзя комментировать код который не менялся в данном ПР.

Да, видел я тут такие посты. Но дело в том, что были тут и посты о том, что «помогите, у меня нет учетки на Гитхабе».
Но главная суть не в этом. Протолкнуть патч это, обычно, переписки, и раунды изменений. Почти уверен, что если у человека не хватает желания зарегистрироваться в Track или отправить email (у нормального проекта же есть почтовые списки?), то у него, тем более, нет желания возиться с проталкиванием своего патча.

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

А зачем его комментировать, если он не менялся?

Чтобы задать вопрос рецензентам. Когда меняешь в одном месте часто возникают вопросы и по другим участкам кода: «Нужно ли еще там изменить? Я не уверен».

О_о можно вставить ссылку на фрагмент кода.

Теперь Mercurial полная маргинальщина получается? Что ещё на нём осталось сидеть?

Самое время начать ему поклоняться в лучших традициях ЛОРа - объявить гит раздутым хипстерским говном, жрущим ресурсы почем зря, запилить какой-нибудь васянский дистр свободный от гита, и не забывать между делом вставлять в разговоре «сам то я конечно на Mercurial…»

Чем PR лучше? Патч отправил по почте, она у всех есть, и ждешь ответа.

Ну товарищ, ты даешь! У тебя не разу не было такого, что ты смотря да хоть в собственный код через пару лет уже не помнишь, почему это сделано именно так, а не иначе? Сделал блейм, нашёл коммит, поднял Джиру, прочитал суть задачи, комментарии к ней, прыгнул на ПР и вот тебе всё дерево обсуждений, кто зачем и почему. Выковыривать патчи из почты, ну на здоровье конечно, если заняться больше не чем, но это конечно мазохизм. Особенно если ты новенький на проекте и никакой истории в почте у тебя еще нет.

Можно. Но это менее удобно и не согласуется с остальной задумкой ПРа.
Так ссылку куда добавить? В общий коммент под ПРом? Тогда отдельной дискуссии не получится и оно смешается с остальными дискуссиями, так как там не веток.

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

Задумка пр - решить проблему, которая он затрагивает.

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

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

Я не о холиваре, а о ссылке на issue или task. Ссылки на них при отправке патча по почте никуда не исчезнут.

Я не хочу править — я хочу (сперва) спросить.

Задумка пр - решить проблему, которая он затрагивает.

Я ее и решаю. Изменил код в файле А, и мне кажется, что это повлияет на код в файле Б. Потому я хочу обсудить с коллегами код в файле Б. Это не отдельная проблема — ПР может быть сломан, если не изменить файл Б. А может и не быть. Это и нужно выяснить прежде чем сливать.

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

Ну например мне хватит ума написать какой-нибудь модуль ядра для Линукса, а вот отправить код в апстрим мне уже ума не хватит. Там какая-то архаичная система со списками рассылки и патчами по почте.

Почта? Да даже если там спросишь, то ничего страшного, если это не сильно от темы о ходит текущей.

Ну так это же важная часть обсуждений предложенных ПРом. Понятно, что ее можно и по почте, и по телефону обсудить. Но хотелось бы вот тут прямо, все в одном месте.

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

Часто до собственно выполнения задачи точно неизвестно что она затронет. Бывает, что задача вообще на исследование — хотелось бы сделать кнопку «Сделать хорошо» но не знаем на сколько это сложно, а давайте попробуем сделать PoC-PR. Вот походу работы и выясняются какие-то новые моменты, которые нужно где-то зафиксировать, обсудить.

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

Плюсую. Почта там просто потому что так привыкли.

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

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

1. Детально объяснять свои изменения, что часто помогает в поиске источника проблем
2. Тестировать коммит в отрыве от других патчей, что делает банальный git bisect рабочим.
3. Не срать в историю фиксами фиксов, которые ещё даже не попали в апстрим. Тут действительно видна вина гитхаба, который учит людей тому, что ребейз это плохо, потому что после него возникает страшное сообщение про push –force.
4. И всё-таки если это фикс, то можно тегом пометить что конкретно он фиксит, что очень полезно для портирования изменений в linux-stable.

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

Из всех возможных вариантов они выбрали hub, ок

нет, если придерживаться правил и не оверквотить

У меня есть пара дискуссий на сотню мейлов, не рассказывай сказки, пожалуйста. Если просто дискуссия еще хоть как-то воспринимаема, то с вложенным кодом всё очень плохо.

утром получил свежую почту и дальше кодь хоть в самолёте, хоть на берегу моря под пальмой

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

дискуссии в емейлах древовидные в отличие от комментариев в PR. вы можете фокусироваться только на том, что вам реально нужно.

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

PR можно мержить только целиком

Фиксится требованием «одна фича - один PR».

набор патчей в патчсете можно менять

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

в случае PR правка истории изменений это цирк с конями

Не надо править историю изменений. Докатываешь PR до апстрима - всё, точка, он в коде, следующие изменения накладываются выше. Иначе вот именно это превращается в цирк с конями: херова гора патчсетов, и концов не найти.

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

Ну нет. Вообще не влияет.

Детально объяснять свои изменения, что часто помогает в поиске источника проблем

Это как раз и решается в первом коммит еи обсуждении PR.

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

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

Не срать в историю фиксами фиксов, которые ещё даже не попали в апстрим.

Не понял, о чем речь.

И всё-таки если это фикс, то можно тегом пометить что конкретно он фиксит, что очень полезно для портирования изменений в linux-stable.

Прямо в коммите делаешь ссылку на issue, типа org/repo#n, и всё становится ясно. По гитхабу очень удобно ходить и искать связанные коммиты. Особенно здорово бывает, когда на твои issue и патчи ссылуются вообще из другого проекта, о котором ты знать не знаешь, это показывается в issue и ты можешь посмотреть, как там решают твою проблему или с чем она может быть связана. Вот этот социальный аспект часто помогает в работе.