Branch Policy

Общие положения

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

• ориентация на выпуск минимум одного поддерживаемого дистрибутива;
• отсутствие регрессий по функциональности в течение жизни бранча;
• устранение серьёзных функциональных ошибок по мере возможности в течение жизни бранча;
• стабильный API/ABI.

Участие в создании стабильного бранча является добровольным.

Роли в создании стабильного бранча

• релиз-менеджеры (RM, обычно также выпускающие дистрибутивы);
• мейнтейнеры пакетов (необязательно совпадающие с таковыми в Sisyphus, см. ниже).

RM

Поскольку бранчи на данный момент (конец весны 2011) не рассматриваются как подлежащие глубокой разработке, но скорее фиксирующие состояние разработки Sisyphus в момент ответвления с целью устранения недостатков и мелкой доработки — основная деятельность RM сводится к помощи мейнтейнерам в разрешении технических вопросов по бранчу (как правило, ACL).

RM по мере нахождения регрессий (см. выше) извещают мейнтейнеров и при необходимости совместно подготавливают исправление.

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

Мейнтейнеры

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

Мейнтейнеры обещают по мере возможности исправлять функциональные ошибки в пакетах.

NMU

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

Связь с проектом Sisyphus

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

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

Требования к пакетам

Если протестировано точечное обновление из иного бранча или Sisyphus, можно попытаться скопировать пакет «как есть» (ssh git.alt copy ..., см. Справочник по git.alt); если при работоспособном результате такого обновления копирование приводит к получению сообщения об ошибке выполнения задания либо есть основания сразу обеспечивать сборку в бинарном окружении бранча, следует обратиться к Backports Policy в части «Требования к пакетам», поскольку технические требования к нумерации релизов совпадают.

Administrativia

При систематическом нарушении этих правил кем-либо из мейнтейнеров, взявшимся за подготовку пакетов в бранчи, RM разъясняют правила и в особо плохих случаях (к примеру, вливании перманентно глючного чего-нибудь, взятого из upstream git раз в день, и игнорировании всех увещеваний) — отстраняют от работы над бранчем посредством ACL.