[devel] Устаревшая концепция бранчей или стабильный бранч как основа разработки

Вт Окт 13 23:23:23 MSK 2020

вт, 13 окт. 2020 г. в 22:48, Vitaly Lipatov <lav на altlinux.ru>:
>
>
> Давние поклонники сизифова труда наблюдали появление Sisyphus, потом, в
> попытке усилить стабильность Sisyphus, а однажды даже пытался взлететь
> Daedalus, предназначенный
> для крайне нестабильных версий пакетов. Чтобы создать условия для
> разработки стабильного бранча сообществом, возникали бранчи типа t7.
>
> Мне кажется, настало время поговорить о том, чтобы и Sisyphus оставить в
> прошлом. По крайней мере, в его нынешнем виде.
>
> Первый момент. Концепция вечно нестабильного репозитория, которым нельзя
> пользоваться, не очень популярна среди пользователей. Также и несколько
> теряется смысл для мантейнеров — зачастую они собирают пакеты в этот
> репозиторий, а сами пользуются другим, более стабильным.

По моим наблюдениям, число пользователей Sisyphus растет, он повышает
стабильность.

 Например, p9.
> Который является репозиторием компании и является точкой возникновения
> конфликта интересов (на мой взгляд, тут есть проблема в публичном
> сформулированном полиси развития такого репозитория, но это отдельная
> тема).

Кто угодно может создать свой репозиторий, все открыто.
Конечно, p9 ориентирован в значительной степени на продукты "Базальт
СПО". И, что особенно важно, на их сопровождение. Для этого построена
система тестирования пакетов, которая сейчас серьезно развита и
развивается дальше. Без нее мы сейчас не могли бы обеспечить каество
продуктов для восьми аппаратных платформ.

>
> Второй момент. Понятие нестабильности сильно изменилось за прошедшие
> годы. Повысился уровень квалификации в апстримах, больше соблюдается
> семантическое версионирование в библиотеках, проекты делают стабильные
> релизы, которые тестируются через CI, причём с серьёзными тестами. То
> есть культура разработки изменилась. Тесты, Continuous Integration,
> github, более доступная возможность pull requests. Наконец, сам Open
> Source перестал быть маргинальным и стал мейнстримом. Всё это ведёт к
> тому, что свободные проекты выпускают в стабильных релизах код высокого
> качества, и даже более того, например, в wine каждый коммит вносит
> атомарные изменения, подтверждённые тестами, то есть сборка из любого
> коммита стабильна.

Это не вполне так. Посмотрите на число патчей в основных пакетах p9.
>
> Третий момент. Снижение роли мантейнера. В связи с ростом культуры
> апстрима, а также с с большим количеством дистрибутивов, ведущих свою
> сборку пакетов (что даёт некоторое количество мантейнеров, которые
> смотрят на апстрим с разных сторон) большинство апстримов стали устроены
> так, что упаковываются в пакет типовым образом и не требуют специальной
> обработки. Конечно, я не о феноменах типа ghostscript, но и тому вроде
> становится лучше. Тут я не то что констатирую факт, а настаиваю на том,
> что роль мантейнера должна быть снижена, а часть его бессмысленной
> работы — автоматизирована. Есть вещи, которые может и должен выполнять
> человек, но это не относится к преобразованию спецификаций из одного
> формата в другой. Мы всё же имеем дело не с естественным языком.

Снова не соглашусь. Наш вклад в апстрим растет и это говорит о
повышении роли  и требований к мейнтейнеру.

>
> Возможно, что-то ещё я забыл упомянуть, поэтому и пишу сюда.
>
> Если вкратце, то я предлагаю сделать p9 основным репозиторием
> разработки, автоматически портируя все изменения в Сизиф.

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

>
> Это был «жёлтый» заголовок.
>
> На самом деле предложение в том, чтобы основной веткой разработки стал
> репозиторий, который бранчуется при крупных несовместимых изменениях
> (например, критичных обновлениях тулчейна, glibc или KDE :)).
> Репозитории Компании (p9 и т.д.) при этом забирают изменения из такого
> репозитория согласно своим регламентам.

Бранчеванию предшестует концепция и всестороннее тестирование.
Конечно, любая компания может попробовать любую схему.

>
> Отличия от нынешней схемы (они же — преимущества) я вижу такие:
> * бранчевание репозитория происходит в момент технологической
> необходимости (когда весь мир переходит, когда отказались от xorg и
> перешли на wayland и т.п., когда перешли на php 8 или python 4 или perl
> 6, или когда решили вернуться на ffmpeg);

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

> * разработка мантейнерами ведётся в стабильном бранче, которым можно
> пользоваться (он умеренно стабилен, на его основе можно делать выпуски
> дистрибутивов community и т.п.);

См. выше. Это паралич или отказ от тестирования.
> * Компания сама решает, какие изменения забирать в продуктовый branch, и
> нет конфликта с мантейнерами;

Пусть решает. Но логичнее тогда забирать из нестабильного бранча,
создав свои службы тестирования и сопровождения.
> * крупные нестабильные обновления можно готовить в репозитории, который
> будет являться дополнением к последнему бранчу (в чём-то это сокращение
> идеи карманов https://www.altlinux.org/Pockets, а, может быть, и
> наоборот, им приходит время, если таких нестабильных дополнений может
> быть больше одного;

Это очень сырое предложение.
> * у сообщества разработчиков появляется стабильный бранч, в развитии и
> стабильности которого они заинтересованы и могут пользоваться.

Это ресурсы. Кто профинансирует?

>
> На самом деле, благодаря тем «гайкам», которые неустанно закручивает
> ldv@ в части контроля целостности, собираемости (я про sisyphus_check и
> другие проверки собранных заданий) целостность и стабильность
> репозитория сильно выросла, и моменты, когда репозиторий развален,
> практически исключены (об этом можно судить также по достаточно редким
> случаям откатов репозитория). И эта стабильность делает возможным
> создания транзакционно стабильного репозитория (не знаю, в рамках тех
> суток, когда он публикуется).

Да. Но 2Базальт СПО" не может такое выпускать в production

>
> Таким образом мы получим стабильный репозиторий, который дискретно
> переходит в новое стабильное состояние, исходя из технических
> требований, и не приводя к бесконечным несовместимым изменениям за время
> жизни репозитория. Это чем-то похоже на выпуски Fedora, но я не вижу
> смысла делать бранчевание регулярным (привязанным к какому-то интервалу
> времени), и нет необходимости (хотя возможно) публиковать дистрибутив на
> каждом бранче.

Нравится или нет, но такая необходимость есть. И для дистрибутивов
общего назначения и для сертифицированных, которые мы сейчас серьезно
подтягиваем к стабильному бранчу. Замечу, что финансовое благополучие
"Базальт СПО" в очень большой степени, хотя и меньше, чем раньше,
зависит от сертифицированных на конфиденциалку продуктов. Боюсь, что
тенденции сейчас таковы, что эта зависимость может усилиться. И не
только у нашей фирмы. А от финансов зависит инфраструктура разработки.

>
> Кстати, разработчикам не хватает доступного инструмента по проверке
> пересобираемости (её умеют делать при тестировании для прохождения
> пакетов в p9, но она плохо доступна мантейнерам Сизифа — мне ничего
> неизвестно о таком инструменте). Ведь на самом деле большинство
> библиотек имеет ограниченное количество «пользователей» (пакетов,
> которые требуют их при сборке), поэтому такая пересборка не тяжела,
> результат её не обязательно делать фатальным, но она точно приведёт к
> снижению числа пакетов, которые неожиданно перестают собираться. Даже
> cmake легко проверяется полной пересборкой использующих его пакетов,
> хотя это достаточно популярное сборочное средство.

Вот с этим согласен.
Вообще, продукт со средствами инфраструктуры разработки назрел.

>
> Безусловно, это просто мои мысли на тему, навеянные личным опытом,
> который заключается в том, что собираю я пакеты в Сизиф, а рабочие
> системы на p9, и это усложняет цепочку проверки того, что собрано, а
> иногда и мотивирует отправлять пакет без проверки.
>
> Извините, что это не доклад на конференции :)

Готовьте доклад в конце января в Переславле. Надеюсь, что обстановка
позволит встретиться.

Спасибо!

Rgrds, Алексей

>
> --
> С уважением,
> Виталий Липатов,
> ALT Linux Team
> _______________________________________________
> Devel mailing list
> Devel на lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel