Branch Policy: различия между версиями

Материал из ALT Linux Wiki
Нет описания правки
Нет описания правки
Строка 15: Строка 15:


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


Строка 33: Строка 33:


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


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

Версия от 17:57, 15 мая 2009

Stub.png
Данная страница находится в разработке.
Эта страница ещё не закончена. Информация, представленная здесь, может оказаться неполной или неверной.


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

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

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

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

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

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

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

RM

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

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

Мейнтейнеры

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

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

NMU

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

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

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

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

Administrativia

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