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

Версия от 10:42, 5 февраля 2009

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

Автор(ы) — {{{responsible}}}

NMU (Non-Maintainer Upload) — обновление пакета не сопровождающим его.

Следует различать NMU и запрос на добавление в группу майнтэйнеров!

После введения сборки из git-репозиториев условия NMU существенно упроситились: если ваше изменение простое, то вы просто формируете задание на сборку и даёте на него ссылку мантейнерам, которые могут посмотреть и дать подтверждение. Получив подтверждение, вы отправляете это же задание на повторную сборку. В случае крупных изменений действуют обычные правила NMU.

Помните, что NMU — это акт помощи, мейнтейнер может быть благодарен за неё. При этом ответственность за судьбу пакета несёт мейнтайнер и поэтому он вправе в дальнейших сборках пакета делать то, что сочтёт нужным.

Стоит приложить разумные усилия к тому, чтобы облегчить мейнтейнеру принятие решения — приложением к письму или багрепорту патча, ссылкой на конкретный коммит или репозиторий в git.alt, наконец, доброжелательным отношением.

Условия, требующие подготовки NMU

NMU выполняется в случае выполнения одного из нижеследующих условий:

Наличие серьёзных ошибок в пакете (major и выше), висящих на нем в системе отслеживания ошибок bugzilla.altlinux.org.
Отсутствие реакции мейнтейнера на запросы от любого из участников ALT Linux Team, выполненные через систему отслеживания ошибок bugzilla.altlinux.org, в течение двух недель.
Наличие проблем с безопасностью в пакете.
Несобираемость пакета в изменённой сборочной среде (например при обновлении gcc, glibc и т. д.).

Общие соображения

Перед тем, как делать NMU, следует постараться найти контакт с текущим мейнтейнером — обязательно при помощи отчёта об ошибке в bugzilla, электронной почты, IM, телефона или прямого обращения по мере возможности и уместности.

Если в течение срока от суток до двух недель, в зависимости от срочности проблемы (серьёзная с безопасностью или разваливающая существенную часть репозитория, мешающая не единицам пакетов и/или пользователей), положительный ответ не поступил или проблема не исправлена — следует написать в devel@ запрос и готовить обновление, если оно ещё не собрано для своих нужд.

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

Подготовка

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

Не забывайте и Гиппократа: «превыше всего, не навреди». Лучше на пакете будет висеть открытый багрепорт по серьёзной проблеме, чем она будет «разрешена» нерабочим патчем или даже исправлена, но сломано ещё что-нибудь.

Указание Packager

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

Версионирование

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

Например, пакет, собранный мейнтейнером с релизом alt3, автоматически пересобранный QA Team Robot с релизом alt3.1 — при NMU должен получить релиз alt3.1.1.

Соответствующая строка в changelog пакета должна содержать слово «NMU», а также ссылки на номера багрепортов. Мейнтейнеру следует сохранить или импортировать эту запись при дальнейшем сопровождении пакета.

Управление доступом

Мейнтейнер в данное время может предоставлять или изымать возможность публикации ведомого им пакета другими участниками команды, передавать им пакет или объявлять его бесхозным при помощи управления ACL пакетов через git.alt.

Ссылки

Debian NMU Policy

@@ Строка 2: / Строка 2: @@
 '''NMU''' (Non-Maintainer Upload) — обновление пакета не сопровождающим его.
-Экстренное обновление пакета в репозитории кем-либо, кроме сопровождающих пакет. Предпринимается в случае наличия серьёзных проблем в пакете и недоступности сопровождающего или отсутствия у него возможности эти проблемы исправить.
+'''Следует различать NMU и запрос на добавление в группу майнтэйнеров!'''
+После введения сборки из git-репозиториев условия NMU существенно упроситились: если ваше изменение простое, то вы просто формируете задание на сборку и даёте на него ссылку мантейнерам, которые могут посмотреть и дать подтверждение.  Получив подтверждение, вы отправляете это же задание на повторную сборку. В случае крупных изменений действуют обычные правила NMU.
 Помните, что NMU — это акт помощи, мейнтейнер может быть благодарен за неё. При этом ответственность за судьбу пакета несёт мейнтайнер и поэтому он вправе в дальнейших сборках пакета делать то, что сочтёт нужным.
@@ Строка 12: / Строка 14: @@
 NMU выполняется в случае выполнения одного из нижеследующих условий:
 # Наличие серьёзных ошибок в пакете (major и выше), висящих на нем в системе отслеживания ошибок {{altbug|}}.
-# Отсутствие реакции мейнтейнера на запросы от любого из участников ALT Linux Team, выполненные через список рассылки {{lists|devel}}, в течение двух недель.
+# Отсутствие реакции мейнтейнера на запросы от любого из участников ALT Linux Team, выполненные через систему отслеживания ошибок {{altbug|}}, в течение двух недель.
 # Наличие проблем с безопасностью в пакете.
 # Несобираемость пакета в изменённой сборочной среде (например при обновлении gcc, glibc и т. д.).
 == Общие соображения ==
-Перед тем, как делать NMU, следует постараться найти контакт с текущим мейнтейнером — обязательно при помощи отчёта об ошибке в [https://bugzilla.altlinux.org bugzilla], а также электронной почты, IM, телефона или прямого обращения по мере возможности и уместности.
+Перед тем, как делать NMU, следует постараться найти контакт с текущим мейнтейнером — обязательно при помощи отчёта об ошибке в [https://bugzilla.altlinux.org bugzilla], электронной почты, IM, телефона или прямого обращения по мере возможности и уместности.
-Если в течение срока от суток до месяца, в зависимости от срочности проблемы (серьёзная с безопасностью или разваливающая существенную часть репозитория, мешающая не единицам пакетов и/или пользователей), положительный ответ не поступил или проблема не исправлена — следует написать в <tt>devel@</tt> запрос и готовить обновление, если оно ещё не собрано для своих нужд.
+Если в течение срока от суток до двух недель, в зависимости от срочности проблемы (серьёзная с безопасностью или разваливающая существенную часть репозитория, мешающая не единицам пакетов и/или пользователей), положительный ответ не поступил или проблема не исправлена — следует написать в <tt>devel@</tt> запрос и готовить обновление, если оно ещё не собрано для своих нужд.
-Если возможно, подготовьте, проверьте и предложите в bugzilla патч, исправляющий проблему — это облегчит работу мейнтейнеру. В любом случае '''настоятельно''' рекомендуется прислать мейнтейнеру изменения в спеке и патчах, поскольку забыв про NMU — он может забыть и применить изменения к своей сборке, из которой будет исходить при составлении следующего пакета. В результате исправления могут быть откаченными, а то и вовсе потерянными.
+Лучше всего использовать git для подготовки изменений, исправляющих проблему. Следует обязательно прислать майнтейнеру ссылку на git-репозиторий с исправлениями.
 == Подготовка ==
@@ Строка 31: / Строка 33: @@
 == Указание Packager ==
-При отсутствии поля Packager в пакете его необходимо добавить, указав в нём реального мейнтейнера, чтобы пакет не перешёл к вам (со всеми своими багами).
+При отсутствии поля Packager в пакете его необходимо добавить, указав в нём реального мейнтейнера, чтобы пакет случайно не перешёл к вам (со всеми своими багами).
 == Версионирование ==