NMU
NMU (Non-Maintainer Upload) — обновление пакета не сопровождающим его.
Следует различать NMU и запрос на добавление в группу майнтэйнеров!
После введения сборки из git-репозиториев условия NMU существенно упроситились: если ваше изменение простое, то вы просто формируете задание на сборку и даёте на него ссылку мантейнерам, которые могут посмотреть и дать подтверждение. Получив подтверждение, вы отправляете это же задание на повторную сборку. В случае крупных изменений действуют обычные правила NMU.
Помните, что NMU — это акт помощи, мейнтейнер может быть благодарен за неё. При этом ответственность за судьбу пакета несёт мейнтайнер и поэтому он вправе в дальнейших сборках пакета делать то, что сочтёт нужным.
Стоит приложить разумные усилия к тому, чтобы облегчить мейнтейнеру принятие решения — приложением к письму или багрепорту патча, ссылкой на конкретный коммит или репозиторий в git.alt, наконец, доброжелательным отношением.
Условия, требующие подготовки NMU
NMU выполняется в случае выполнения одного из нижеследующих условий:
- Отсутствие реакции мейнтейнера на серьёзные (major и выше) ошибки в bugzilla.altlinux.org в течение двух недель.
- Наличие проблем с безопасностью в пакете.
- Несобираемость пакета в изменённой сборочной среде (например при обновлении gcc, glibc и т. д.).
Общие соображения
Перед тем, как делать NMU, следует постараться найти контакт с текущим мейнтейнером — обязательно при помощи отчёта об ошибке в bugzilla.altlinux.org, электронной почты, IM, телефона или прямого обращения по мере возможности и уместности.
Если в течение срока от суток до двух недель, в зависимости от срочности проблемы (серьёзная с безопасностью или разваливающая существенную часть репозитория, мешающая не единицам пакетов и/или пользователей), положительный ответ не поступил или проблема не исправлена — следует известить devel@, добавить соответствующий комментарий к багам в 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 предоставляет один из администраторов репозитория.