NMU
Материал из ALT Linux Wiki
| Строка 29: | Строка 29: | ||
Лучше всего использовать git для подготовки изменений, исправляющих проблему. Следует обязательно прислать майнтейнеру ссылку на git-репозиторий с исправлениями. | Лучше всего использовать git для подготовки изменений, исправляющих проблему. Следует обязательно прислать майнтейнеру ссылку на git-репозиторий с исправлениями. | ||
| - | == | + | == Правила подготовки NMU == |
| - | + | * Изменения должны быть минимальными и настолько неинтрузивными, насколько это возможно (не следует «зачищать» спек, передвигать модули или файлы и вообще чинить то, что не сломано — этим следует заниматься мейнтейнерам). | |
| + | * К NMU предъявляются обычные требования попадания пакета в репозиторий (в частности, наследование по коммитам при использовании gear). | ||
| + | * Если в spec-файле отсутствует поле <tt>Packager</tt>, то его необходимо добавить и указать в нём мейнтейнера пакета. | ||
| + | * Строка в changelog пакета должна содержать слово «NMU», а также ссылки на номера багрепортов. Мейнтейнеру следует сохранить или импортировать эту запись при дальнейшем сопровождении пакета. | ||
Не забывайте и Гиппократа: «превыше всего, не навреди». Лучше на пакете будет висеть открытый багрепорт по серьёзной проблеме, чем она будет «разрешена» нерабочим патчем или даже исправлена, но сломано ещё что-нибудь. | Не забывайте и Гиппократа: «превыше всего, не навреди». Лучше на пакете будет висеть открытый багрепорт по серьёзной проблеме, чем она будет «разрешена» нерабочим патчем или даже исправлена, но сломано ещё что-нибудь. | ||
| - | == | + | === Версионирование === |
| - | + | Если исправление можно сделать в рамках той же upstream-версии пакета, что находится в репозитории, то в версию (релиз) необходимо добавить дополнительное число, отделённое точкой и по нумерации начинающееся с единицы, чтобы не пересечься с нормальной нумерацией версий у основного мейнтейнера. | |
| - | + | Таким образом, пакет, собранный мейнтейнером с релизом <tt>alt3</tt> и автоматически пересобранный QA Team Robot с релизом <tt>alt3.1</tt> при NMU должен получить релиз <tt>alt3.1.1</tt>. | |
| - | + | FIXME: а если нельзя? | |
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
== Управление доступом == | == Управление доступом == | ||
Версия 07:35, 2 апреля 2009
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-репозиторий с исправлениями.
Правила подготовки NMU
- Изменения должны быть минимальными и настолько неинтрузивными, насколько это возможно (не следует «зачищать» спек, передвигать модули или файлы и вообще чинить то, что не сломано — этим следует заниматься мейнтейнерам).
- К NMU предъявляются обычные требования попадания пакета в репозиторий (в частности, наследование по коммитам при использовании gear).
- Если в spec-файле отсутствует поле Packager, то его необходимо добавить и указать в нём мейнтейнера пакета.
- Строка в changelog пакета должна содержать слово «NMU», а также ссылки на номера багрепортов. Мейнтейнеру следует сохранить или импортировать эту запись при дальнейшем сопровождении пакета.
Не забывайте и Гиппократа: «превыше всего, не навреди». Лучше на пакете будет висеть открытый багрепорт по серьёзной проблеме, чем она будет «разрешена» нерабочим патчем или даже исправлена, но сломано ещё что-нибудь.
Версионирование
Если исправление можно сделать в рамках той же upstream-версии пакета, что находится в репозитории, то в версию (релиз) необходимо добавить дополнительное число, отделённое точкой и по нумерации начинающееся с единицы, чтобы не пересечься с нормальной нумерацией версий у основного мейнтейнера.
Таким образом, пакет, собранный мейнтейнером с релизом alt3 и автоматически пересобранный QA Team Robot с релизом alt3.1 при NMU должен получить релиз alt3.1.1.
FIXME: а если нельзя?
Управление доступом
Мейнтейнер в данное время может предоставлять или изымать возможность публикации ведомого им пакета другими участниками команды, передавать им пакет или объявлять его бесхозным при помощи управления ACL пакетов через git.alt.
В случае отсутствия реакции мантейнера на запросы по предоставлению доступа, согласно условиям предоставления NMU, право на NMU предоставляет один из администраторов репозитария.
