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

[Vitaly Lipatov]

Давние поклонники сизифова труда наблюдали появление Sisyphus, потом, в 
попытке усилить стабильность Sisyphus, а однажды даже пытался взлететь 
Daedalus, предназначенный
для крайне нестабильных версий пакетов. Чтобы создать условия для 
разработки стабильного бранча сообществом, возникали бранчи типа t7.

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

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

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

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

Возможно, что-то ещё я забыл упомянуть, поэтому и пишу сюда.

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

Это был «жёлтый» заголовок.

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

Отличия от нынешней схемы (они же — преимущества) я вижу такие:
* бранчевание репозитория происходит в момент технологической 
необходимости (когда весь мир переходит, когда отказались от xorg и 
перешли на wayland и т.п., когда перешли на php 8 или python 4 или perl 
6, или когда решили вернуться на ffmpeg);
* разработка мантейнерами ведётся в стабильном бранче, которым можно 
пользоваться (он умеренно стабилен, на его основе можно делать выпуски 
дистрибутивов community и т.п.);
* Компания сама решает, какие изменения забирать в продуктовый branch, и 
нет конфликта с мантейнерами;
* крупные нестабильные обновления можно готовить в репозитории, который 
будет являться дополнением к последнему бранчу (в чём-то это сокращение 
идеи карманов https://www.altlinux.org/Pockets, а, может быть, и 
наоборот, им приходит время, если таких нестабильных дополнений может 
быть больше одного;
* у сообщества разработчиков появляется стабильный бранч, в развитии и 
стабильности которого они заинтересованы и могут пользоваться.

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

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

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

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

Извините, что это не доклад на конференции :)

-- 
С уважением,
Виталий Липатов,
ALT Linux Team