Branch Policy

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

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

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

Каковы приоритеты характеристик?

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

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

• Релиз-менеджер (RM)
• мейнтейнеры пакетов (не Sisyphus! см. ниже)
• кто-то ещё? qa?

RM

RM поддерживает в актуальном состоянии roadmap бранча. Под roadmap подразумевается публично доступный документ, содержащий информацию о планируемых крупных изменениях в бранче по сравнению с предыдущим. Roadmap создаётся путём каким?.

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

Мейнтейнеры

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

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

NMU

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

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

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

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

Administrativia

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