[sisyphus] Предложения по формированию бранчей

[Андрей Черепанов]

В данном письме я попробую проанализировать ситуацию со стабильными срезами 
Сизифа (бранчами) и предложить стратегию их жизненного цикла. Буду рад любым 
конструктивным предложениям и дополнениям.

Текущая ситуация
----------------
Существует вечно развивающаяся пакетная база Sisyphus, активно поддерживаемая 
сопровождающими (мейнтейнерами). В определённое время (обычно раз в полгода) 
при достаточно стабильном качестве репозитория из него форкается копия, 
называемая бранчем (branch), получающая собственный incoming и ACL на пакеты. 
Развитие Sisyphus продолжается безотносительно от бранча.

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

Однако такая стабилизация в силу своей природы имеет ряд неприятных моментов:
1. Дополнительные усилия от сопровождающего пакет по бэкпортированию 
(адаптации новой версии пакета под старую пакетную базу) и тестированию помимо 
Sisyphus ещё и в бранч (один или несколько).
2. Как следствие п. 1 в бранче остаются старые версии пакетов, в том числе и 
без необходимых обновлений по безопасности. На огромной пакетной базе бранча 
поддержка полной проверки и бэкпортирования потребует больших трудозатрат (а с 
учётом частого выпуска бранчей - просто колоссальных).
3. Отсутствующая или плохая поддержка нового оборудования.

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

Бранч и задачи целевых групп
----------------------------
Рассматриваемые целевые группы:
а) сопровождающие (мейнтейнеры);
б) создатели дистрибутивов (release managers);
в) продвинутые пользователи (целью которых является постоянное обновление);
г) обычные пользователи;
д) техническая поддержка и сторонние разработчики;

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

Создатели дистрибутивов заинтересованы в бранче только в подмножестве пакетов, 
необходимых для сборки дистрибутива. При этом стабилизация важна лишь на этапе 
тестирования дистрибутива, а пакетная база должна быть как можно новее (для 
поддержки новейшего оборудования и для новых фич).

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

Обычные пользователи обычно используют пакетную базу дистрибутивов и им 
достаточно обновлений только этой пакетной базы.

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

Итоги
-----

Итак, существующая политика создания бранчей (форк бранча и через много 
месяцев создание дистрибутивов на его основе) приводит к "протуханию" пакетной 
базы уже к созданию дистрибутивов (что нежелательно для создателей 
дистрибутивов). Кроме того, полная копия Sisyphus приводит к практически 
отсутствующей практике выпуска обновлений для этого бранча. Попытка участить 
выпуск бранчей проблему не решает, а усугубляет нарастающей массой кода, 
требующего качественной поддержки. Единственные люди, которые радуются новым 
бранчам - это продвинутые пользователи, которые апгрейдятся на новый бранч. 
Однако никакой пользы ни сопровождающим, ни дистрибуторам они не приносят.

Предложения
-----------
1. Бранч создаётся непосредственно перед выпуском дистрибутива (примерно за 
месяц, на этапе тестирования) и служит источником стабильного кода для 
дистрибутива. Это служит гарантией, что пакетная база дистрибутива будет 
стабильна.
2. Бранч создаётся _только_ в объёме пакетной базы дистрибутива (то есть бранч 
- это обновляемая пакетная база дистрибутива). При необходимости, в него 
добавляются пакеты, необходимые сторонним разработчикам. Под такую базу 
гораздо проще выпускать обновления и поддерживать её.


-- 
Андрей Черепанов
ALT Linux
cas на altlinux.ru