NMU: различия между версиями
Строка 29: | Строка 29: | ||
* К NMU предъявляются обычные требования попадания пакета в репозиторий (в частности, наследование по коммитам при использовании gear). | * К NMU предъявляются обычные требования попадания пакета в репозиторий (в частности, наследование по коммитам при использовании gear). | ||
* Если в spec-файле отсутствует поле <tt>Packager</tt>, то его необходимо добавить и указать в нём мейнтейнера пакета. | * Если в spec-файле отсутствует поле <tt>Packager</tt>, то его необходимо добавить и указать в нём мейнтейнера пакета. | ||
* | * Changelog пакета должен начинаться с «NMU:». В changelog так-же должен быть указан номер ошибки в формате, допускающем [[Changelogs_guide#.D0.90.D0.B2.D1.82.D0.BE.D0.B7.D0.B0.D0.BA.D1.80.D1.8B.D1.82.D0.B8.D0.B5_.D0.B1.D0.B0.D0.B3.D0.BE.D0.B2|автоматическое закрытие ошибок]]. Мейнтейнеру следует сохранить или импортировать эту запись при дальнейшем сопровождении пакета. | ||
Не забывайте и Гиппократа: "превыше всего, не навреди". Лучше на пакете будет висеть открытый багрепорт по серьёзной проблеме, чем она будет "разрешена" нерабочим патчем или даже исправлена, но сломано ещё что-нибудь. | Не забывайте и Гиппократа: "превыше всего, не навреди". Лучше на пакете будет висеть открытый багрепорт по серьёзной проблеме, чем она будет "разрешена" нерабочим патчем или даже исправлена, но сломано ещё что-нибудь. | ||
Строка 38: | Строка 38: | ||
Таким образом, пакет, собранный мейнтейнером с релизом <tt>alt3</tt> и автоматически пересобранный QA Team Robot с релизом <tt>alt3.1</tt> при NMU должен получить релиз <tt>alt3.1.1</tt>. | Таким образом, пакет, собранный мейнтейнером с релизом <tt>alt3</tt> и автоматически пересобранный QA Team Robot с релизом <tt>alt3.1</tt> при NMU должен получить релиз <tt>alt3.1.1</tt>. | ||
Если для исправления необходимо обновление версии в репозитории, то NMU выполняется с | Если для исправления необходимо обновление версии в репозитории, то NMU выполняется с изменением версии программы и установкой релиза пакета в alt1. | ||
== Управление доступом == | == Управление доступом == |
Версия от 08:56, 24 апреля 2009
NMU (Non-Maintainer Upload) — обновление пакета не сопровождающим его.
Рамки Policy
Данное Policy регламентирует взаимоотношения между мейнтейнерами. Для правил выполнения массовых NMU роботами см. полиси по массовым NMU.
Условия, требующие подготовки NMU
NMU выполняется в случае выполнения одного из нижеследующих условий:
- Без предварительного оповещения мейнтейнера NMU может выполняться при подготовке security-исправлений, требующих приватной подготовки согласно Security Policy (до того момента, как Security Policy принята, такими считаются только исправления, для которых организуется Coordinated Release Date (CRD)). В этом случае мейнтейнер должен быть извещён не позднее, чем пакет будет отправлен в репозиторий.
- Отсутствие реакции мейнтейнера на ошибки с серьёзностью Critical в bugzilla.altlinux.org в течение двух недель.
- Отсутствие реакции мейнтейнера на ошибки с серьёзностью Blocker в bugzilla.altlinux.org в течение 12 часов
Общие соображения
Перед тем, как делать NMU, следует постараться найти контакт с текущим мейнтейнером при помощи отчёта об ошибке в bugzilla.altlinux.org. Всё общение с мейнтейнером должно быть зафиксировано в bugzilla для упрощения дальнейшей работы администратора ACL, арбитра или конфликтной комиссии.
В случае отсутствия реакции мейнтейнера на вашу ошибку в течении установленного в данном Policy времени - вы должны добавить комментарий к ошибке с запросом на NMU и подготовить обновление.
Одновременно с заливкой NMU рекомендуется указать мейнтейнеру на git с исправлением (если мейнтейнер использует gear), либо приложить к ошибке в bugzilla.altlinux.org патч.
Правила подготовки NMU
- Изменения должны быть минимальными и настолько неинтрузивными, насколько это возможно (не следует "зачищать" спек, передвигать модули или файлы и вообще чинить то, что не сломано — этим следует заниматься мейнтейнерам).
- К NMU предъявляются обычные требования попадания пакета в репозиторий (в частности, наследование по коммитам при использовании gear).
- Если в spec-файле отсутствует поле Packager, то его необходимо добавить и указать в нём мейнтейнера пакета.
- Changelog пакета должен начинаться с «NMU:». В changelog так-же должен быть указан номер ошибки в формате, допускающем автоматическое закрытие ошибок. Мейнтейнеру следует сохранить или импортировать эту запись при дальнейшем сопровождении пакета.
Не забывайте и Гиппократа: "превыше всего, не навреди". Лучше на пакете будет висеть открытый багрепорт по серьёзной проблеме, чем она будет "разрешена" нерабочим патчем или даже исправлена, но сломано ещё что-нибудь.
Версионирование
Если исправление можно сделать в рамках той же upstream-версии пакета, что находится в репозитории, то в версию (релиз) необходимо добавить дополнительное число, отделённое точкой и по нумерации начинающееся с единицы, чтобы не пересечься с нормальной нумерацией версий у основного мейнтейнера.
Таким образом, пакет, собранный мейнтейнером с релизом alt3 и автоматически пересобранный QA Team Robot с релизом alt3.1 при NMU должен получить релиз alt3.1.1.
Если для исправления необходимо обновление версии в репозитории, то NMU выполняется с изменением версии программы и установкой релиза пакета в alt1.
Управление доступом
Мейнтейнер предоставляет или изымает возможность NMU на ведомые им пакеты при помощи git.alt.
В случае отсутствия реакции мейнтейнера на запросы по предоставлению доступа, право на NMU предоставляет один из администраторов репозитория.
Дополнительная информация
Эта секция не является нормативной
NMU и запрос на добавление в список мейнтейнеров — это разные вещи. Если вам хочется принять участие в поддержке пакета — обратитесь к мейнтейнеру и попросите его добавить вас в ACL пакета или группу.
После введения сборки из git-репозиториев условия NMU существенно упростились: если ваше изменение простое, то вы просто формируете задание на сборку и даёте на него ссылку мейнтейнерам, которые могут посмотреть и дать подтверждение. Получив подтверждение, вы отправляете это же задание на повторную сборку. В случае крупных изменений действуют обычные правила NMU.
Помните, что NMU — это акт помощи, мейнтейнер может быть благодарен за неё. При этом ответственность за судьбу пакета несёт мейнтейнер и поэтому он вправе в дальнейших сборках пакета делать то, что сочтёт нужным.
Стоит приложить разумные усилия к тому, чтобы облегчить мейнтейнеру принятие решения — приложением к письму или багрепорту патча, ссылкой на конкретный коммит или репозиторий в git.alt, наконец, доброжелательным отношением.