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

Текущая версия от 22:02, 28 июня 2015

Черновик политики Sisyphus

Автор(ы) — dottedmag@, cas@, mike@

Обсуждение в devel@

Обсуждается с 2009

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

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

ориентация на выпуск минимум одного поддерживаемого дистрибутива;
отсутствие регрессий по функциональности в течение жизни бранча;
устранение серьёзных функциональных ошибок по мере возможности в течение жизни бранча;
стабильный 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.

Черновики нормативных документов

ACL Policy • Ada Policy • Backports Policy • Branch Policy • Desktop Environment Policy • DistroReleasePolicy • Fortune Policy • Gtk Gnome Themes Policy • Index.html Policy • Jabber Policy • JavaScript Policy • License Tag Policy • Lua Policy • Maintainer Change Policy • Mass NMU • MediaWiki Policy • Mono Policy • Node.js Policy • NonFree • OCaml Policy • Package Splitting • Packager Teams • Pear Policy • Pecl Policy • Pseudo User Policy • Python Policy • Ruby Policy 2.0 • SbindirPolicy • Security Policy • Services Policy • Shared Libs Policy • Sound Policy • Tcl Policy • TLS • TmpDir • Web Policy

@@ Строка 1: / Строка 1: @@
-{{Stub}}
+{{DraftPolicy
+|responsible=dottedmag@, cas@, mike@
+|discussion_link=http://lists.altlinux.org/pipermail/sisyphus/2009-May/339144.html
+|discussion_since=2009
+}}<!-- NB: черновик политики _не_ Sisyphus, и обсуждение _не_ в devel@, но ладно -->
 == Общие положения ==
 Стабильный бранч создаётся для получения пакетной базы, обладающей следующими характеристиками:
-* стабильный API/ABI (''как определяется?'')
+* ориентация на выпуск минимум одного поддерживаемого дистрибутива;
-* отсутствие регрессий по функциональности в течение жизни бранча
+* отсутствие регрессий по функциональности в течение жизни бранча;
-* устранение серьёзных функциональных ошибок по мере возможности в течение жизни бранча
+* устранение серьёзных функциональных ошибок по мере возможности в течение жизни бранча;
-* ''что-то ещё? roadmap?''
+* стабильный API/ABI.
-''Каковы приоритеты характеристик?''
 Участие в создании стабильного бранча является добровольным.
@@ Строка 14: / Строка 17: @@
 == Роли в создании стабильного бранча ==
-* Релиз-менеджер (RM)
+* релиз-менеджеры (RM, обычно также выпускающие дистрибутивы);
-* мейнтейнеры пакетов (не Sisyphus! см. ниже)
+* мейнтейнеры пакетов (необязательно совпадающие с таковыми в Sisyphus, см. ниже).
-* ''кто-то ещё? qa?''
 == RM ==
-RM поддерживает в актуальном состоянии roadmap бранча. Под roadmap подразумевается публично доступный документ, содержащий информацию о планируемых крупных изменениях в бранче по сравнению с предыдущим. Roadmap создаётся путём ''каким?''.
+Поскольку бранчи на данный момент (конец весны 2011) не рассматриваются как подлежащие глубокой разработке, но скорее фиксирующие состояние разработки Sisyphus в момент ответвления с целью устранения недостатков и мелкой доработки — основная деятельность RM сводится к помощи мейнтейнерам в разрешении технических вопросов по бранчу (как правило, ACL).
-RM по мере нахождения регрессий (см. выше) извещает мейнтейнеров и при необходимости совместно подготавливает исправление.
+RM по мере нахождения регрессий (см. выше) извещают мейнтейнеров и при необходимости совместно подготавливают исправление.
+Если не находится решение какой-либо проблемы силами мейнтейнеров — ожидается решение силами RM, хотя оно также не всегда может быть возможно.
 == Мейнтейнеры ==
-Мейнтейнеры обещают не допускать регрессий по мере возможности и исправлять их как можно скорее.
+Мейнтейнеры обещают не допускать заведомых регрессий и исправлять обнаруженные как можно скорее.
-Мейнтейнеры обещают по мере взможности исправлять функциональные ошибки в пакетах.
+Мейнтейнеры обещают по мере возможности исправлять функциональные ошибки в пакетах.
 == NMU ==
-Поддержание функциональности бранча приоритетной задачей, поэтому для бранча действуют более мягкие правила NMU (в частности, при отсутствии реакции мейнтейнера на серьёзную ошибку, NMU подготавливается даже при активности мейнтейнера), при этом правила подготвки самого NMU (неинтрузивность изменений) остаются в силе.
+Поддержание функциональности бранча считается приоритетной задачей, поэтому для бранча действуют более мягкие правила [[NMU]] (в частности, при отсутствии реакции мейнтейнера на серьёзную ошибку, NMU подготавливается даже при активности мейнтейнера), при этом правила подготовки самого NMU (неинтрузивность изменений) остаются '''в силе'''.
 == Связь с проектом Sisyphus ==
-Если Сизифный пакет, требующий исправления в бранче, принадлежит мейнтейнеру, не высказавшему желания участвовать в разработке бранча, его следует спросить, не хочет ли он принять участия.
+Если сизифный пакет, требующий исправления в бранче, принадлежит мейнтейнеру, не высказавшему желания участвовать в разработке бранча, его следует спросить, не хочет ли он принять участия.
-Пакеты, сизифные мейнтейнеры которых отказались принимать участие в разработке бранчей, и для которых не нашлось мейнтейнера в бранче, может забрать любой желающий.
+Пакеты, сизифные мейнтейнеры которых [[Обсуждение:Branches|не желают]] принимать участие в разработке бранчей и для которых не нашлось мейнтейнера в бранче, может забрать любой желающий.  При формировании бранча такие майнтейнеры исключаются из ACL всех пакетов и групп бранча с тем, чтобы не беспокоить их понапрасну сообщениями от bugzilla и сборочницы.
+== Требования к пакетам ==
+Если протестировано точечное обновление из иного бранча или Sisyphus, можно попытаться скопировать пакет «как есть» ({{cmd|ssh git.alt copy ...}}, см. [[Справочник по git.alt]]); если при работоспособном результате такого обновления копирование приводит к получению сообщения об ошибке выполнения задания либо есть основания сразу обеспечивать сборку в бинарном окружении бранча, следует обратиться к [[Backports Policy#Требования к пакетам|Backports Policy]] в части «Требования к пакетам», поскольку технические требования к нумерации релизов совпадают.
 == Administrativia ==
-При систематическом нарушении этих правил кем-либо из мейнтейнеров, взявшимся за подготовку пакетов в бранчи, RM разъясняет правила и, в особо плохих случаях (к примеру, вливании перманентно глючного чего-нибудь, взятого из upstream git раз в день и игнорировании всех увещеваний) - отстраняет от работы над бранчем.
+При систематическом нарушении этих правил кем-либо из мейнтейнеров, взявшимся за подготовку пакетов в бранчи, RM разъясняют правила и в особо плохих случаях (к примеру, вливании перманентно глючного чего-нибудь, взятого из upstream git раз в день, и игнорировании всех увещеваний) — отстраняют от работы над бранчем посредством ACL.
+{{Category navigation|title=Черновики нормативных документов|category=Черновики нормативных документов|sortkey={{SUBPAGENAME}}}}