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

Материал из ALT Linux Wiki
Нет описания правки
Строка 8: Строка 8:
'''Следует различать NMU и запрос на добавление в список мейнтейнеров! (acl пакета) '''
'''Следует различать NMU и запрос на добавление в список мейнтейнеров! (acl пакета) '''


''' Данное Policy регламентирует взаимоотношения между мантейнерами и не имеет отношения к взаимоотношению роботов и мантейнеров. См. [[MassNMU|Массовое NMU]] '''
''' Данное Policy регламентирует взаимоотношения между мейнтейнерами и не имеет отношения к взаимоотношению роботов и мейнтейнеров. См. [[MassNMU|Массовое NMU]] '''
 
 
После введения сборки из git-репозиториев условия NMU существенно упростились: если ваше изменение простое, то вы просто формируете задание на сборку и даёте на него ссылку мейнтейнерам, которые могут посмотреть и дать подтверждение.  Получив подтверждение, вы отправляете это же задание на повторную сборку. В случае крупных изменений действуют обычные правила NMU.
 
Помните, что NMU — это акт помощи, мейнтейнер может быть благодарен за неё. При этом ответственность за судьбу пакета несёт мейнтейнер и поэтому он вправе в дальнейших сборках пакета делать то, что сочтёт нужным.
 
Стоит приложить разумные усилия к тому, чтобы облегчить мейнтейнеру принятие решения — приложением к письму или багрепорту патча, ссылкой на конкретный коммит или репозиторий в git.alt, наконец, доброжелательным отношением.


== Условия, требующие подготовки NMU ==
== Условия, требующие подготовки NMU ==
Строка 48: Строка 41:


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


== Ссылки ==
== Ссылки ==
* [http://www.debian.org/doc/developers-reference/ch-pkgs.en.html#s-nmu Debian NMU Policy]
[[BugSeverityPolicy|Уровни серьёзности ошибок]]
[[MassNMU|Массовый NMU]]


[[Категория:Sisyphus]]
[[Категория:Sisyphus]]

Версия от 15:31, 17 апреля 2009

Stub.png
Черновик политики Sisyphus
Автор(ы) — rider@
Обсуждение в devel@
Обсуждается с 02.04.2009


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

Следует различать NMU и запрос на добавление в список мейнтейнеров! (acl пакета)

Данное Policy регламентирует взаимоотношения между мейнтейнерами и не имеет отношения к взаимоотношению роботов и мейнтейнеров. См. Массовое NMU

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

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

  1. Отсутствие реакции мейнтейнера на ошибки с Серьёзностью Critical или Blocker в bugzilla.altlinux.org в течение двух недель.
  2. Наличие проблем с безопасностью или наличие фатальных ошибок в пакете. Представитель security team или администратор репозитория (а также любой член команды на усмотрение администратора репозитория) имеет право сделать NMU немедленно после публикации информации о проблеме с безопасностью в пакете или обнаружения в нём фатальной ошибки. Фатальной считается ошибка, приводящая к неработоспособности существенной части репозитория. Автор NMU в случае экстренного изменения пакета обязан проинформировать мантейнера пакета не позднее, чем данный пакет будет отправлен на сборку в репозиторий.

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

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

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

Одновременно с заливкой NMU настойчиво рекомендуется указать мейнтейнеру на git с исправлением (если мейнтейнер использует gear), либо приложить к багам патч (в противном случае).

Правила подготовки NMU

  • Изменения должны быть минимальными и настолько неинтрузивными, насколько это возможно (не следует «зачищать» спек, передвигать модули или файлы и вообще чинить то, что не сломано — этим следует заниматься мейнтейнерам).
  • К NMU предъявляются обычные требования попадания пакета в репозиторий (в частности, наследование по коммитам при использовании gear).
  • Если в spec-файле отсутствует поле Packager, то его необходимо добавить и указать в нём мейнтейнера пакета.
  • Строка в changelog пакета должна содержать слово «NMU», а также ссылки на номера багрепортов. Мейнтейнеру следует сохранить или импортировать эту запись при дальнейшем сопровождении пакета.

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

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

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

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

Если для исправления необходимо обновление версии в репозитории, то NMU выполняется с нормальной нумерацией.

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

Мейнтейнер предоставляет или изымает возможность NMU на ведомые им пакеты при помощи git.alt.

В случае отсутствия реакции мейнтейнера на запросы по предоставлению доступа, право на NMU предоставляет один из администраторов репозитория.

Дополнительная информация

Эта секция не является нормативной

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

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

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


Ссылки

Уровни серьёзности ошибок Массовый NMU