NMU: различия между версиями
Нет описания правки |
Нет описания правки |
||
Строка 4: | Строка 4: | ||
|discussion_since=02.04.2009 | |discussion_since=02.04.2009 | ||
}} | }} | ||
'''NMU''' (Non-Maintainer Upload) | __NOTOC__ | ||
'''NMU''' (Non-Maintainer Upload) — обновление пакета не сопровождающим его. | |||
== Рамки Policy == | |||
Данное Policy регламентирует взаимоотношения между мейнтейнерами. Для правил выполнения массовых NMU роботами см. [[MassNMU|полиси по массовым NMU]]. | |||
== Условия, требующие подготовки NMU == | == Условия, требующие подготовки NMU == | ||
Строка 16: | Строка 17: | ||
== Общие соображения == | == Общие соображения == | ||
Перед тем, как делать NMU, следует постараться найти контакт с текущим | Перед тем, как делать NMU, следует постараться найти контакт с текущим мейнтейнером — обязательно при помощи отчёта об ошибке в {{altbug|}}. Разумеется, никто не запрещает пообщаться с мейнтейнером по электронной почте, IM, телефону или лично, по мере возможности и уместности. Формально всё общение с мейнтейнером должно быть зафиксировано в bugzilla для упрощения дальнейшей работы арбитра или конфликтной комиссии, если такая понадобится. | ||
Если в течение срока от суток до двух недель, в зависимости от срочности проблемы (серьёзная с безопасностью или разваливающая существенную часть репозитория, мешающая не единицам пакетов и/или пользователей), положительный ответ в bugzilla не поступил или проблема не | Если в течение срока от суток до двух недель, в зависимости от срочности проблемы (серьёзная с безопасностью или разваливающая существенную часть репозитория, мешающая не единицам пакетов и/или пользователей), положительный ответ в bugzilla не поступил или проблема не исправлена — следует добавить комментарий с запросом на NMU к багам в {{altbug|}} и готовить обновление, если оно ещё не собрано для своих нужд. | ||
Одновременно с заливкой NMU настойчиво рекомендуется указать мейнтейнеру на git с исправлением (если мейнтейнер использует gear), либо приложить к багам патч (в противном случае). | Одновременно с заливкой NMU настойчиво рекомендуется указать мейнтейнеру на git с исправлением (если мейнтейнер использует gear), либо приложить к багам патч (в противном случае). | ||
== Правила подготовки NMU == | == Правила подготовки NMU == | ||
* Изменения должны быть минимальными и настолько неинтрузивными, насколько это возможно (не следует | * Изменения должны быть минимальными и настолько неинтрузивными, насколько это возможно (не следует "зачищать" спек, передвигать модули или файлы и вообще чинить то, что не сломано — этим следует заниматься мейнтейнерам). | ||
* К NMU предъявляются обычные требования попадания пакета в репозиторий (в частности, наследование по коммитам при использовании gear). | * К NMU предъявляются обычные требования попадания пакета в репозиторий (в частности, наследование по коммитам при использовании gear). | ||
* Если в spec-файле отсутствует поле <tt>Packager</tt>, то его необходимо добавить и указать в нём мейнтейнера пакета. | * Если в spec-файле отсутствует поле <tt>Packager</tt>, то его необходимо добавить и указать в нём мейнтейнера пакета. | ||
* Строка в changelog пакета должна содержать слово «NMU», а также ссылки на номера багрепортов. Мейнтейнеру следует сохранить или импортировать эту запись при дальнейшем сопровождении пакета. | * Строка в changelog пакета должна содержать слово «NMU», а также ссылки на номера багрепортов. Мейнтейнеру следует сохранить или импортировать эту запись при дальнейшем сопровождении пакета. | ||
Не забывайте и Гиппократа: | Не забывайте и Гиппократа: "превыше всего, не навреди". Лучше на пакете будет висеть открытый багрепорт по серьёзной проблеме, чем она будет "разрешена" нерабочим патчем или даже исправлена, но сломано ещё что-нибудь. | ||
=== Версионирование === | === Версионирование === | ||
Строка 42: | Строка 43: | ||
В случае отсутствия реакции мейнтейнера на запросы по предоставлению доступа, право на NMU предоставляет один из администраторов репозитория. | В случае отсутствия реакции мейнтейнера на запросы по предоставлению доступа, право на NMU предоставляет один из администраторов репозитория. | ||
== Дополнительная информация == | == Дополнительная информация == | ||
''Эта секция не является нормативной'' | ''Эта секция не является нормативной'' | ||
NMU и запрос на добавление в список мейнтейнеров — это разные вещи. Если вам хочется принять участие в поддержке пакета — обратитесь к мейнтейнеру и попросите его добавить вас в ACL пакета или группу. | |||
После введения сборки из git-репозиториев условия NMU существенно упростились: если ваше изменение простое, то вы просто формируете задание на сборку и даёте на него ссылку мейнтейнерам, которые могут посмотреть и дать подтверждение. Получив подтверждение, вы отправляете это же задание на повторную сборку. В случае крупных изменений действуют обычные правила NMU. | |||
Помните, что NMU — это акт помощи, мейнтейнер может быть благодарен за неё. При этом ответственность за судьбу пакета несёт мейнтейнер и поэтому он вправе в дальнейших сборках пакета делать то, что сочтёт нужным. | |||
Стоит приложить разумные усилия к тому, чтобы облегчить мейнтейнеру принятие решения — приложением к письму или багрепорту патча, ссылкой на конкретный коммит или репозиторий в git.alt, наконец, доброжелательным отношением. | |||
== Ссылки == | == Ссылки == | ||
[[BugSeverityPolicy|Уровни серьёзности ошибок]] | [[BugSeverityPolicy|Уровни серьёзности ошибок]] | ||
[[Категория:Sisyphus]] | [[Категория:Sisyphus]] |
Версия от 16:46, 17 апреля 2009
NMU (Non-Maintainer Upload) — обновление пакета не сопровождающим его.
Рамки Policy
Данное Policy регламентирует взаимоотношения между мейнтейнерами. Для правил выполнения массовых NMU роботами см. полиси по массовым NMU.
Условия, требующие подготовки NMU
NMU выполняется в случае выполнения одного из нижеследующих условий:
- Отсутствие реакции мейнтейнера на ошибки с Серьёзностью Critical или Blocker в bugzilla.altlinux.org в течение двух недель.
- Наличие проблем с безопасностью или наличие фатальных ошибок в пакете. Представитель 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 предоставляет один из администраторов репозитория.
Дополнительная информация
Эта секция не является нормативной
NMU и запрос на добавление в список мейнтейнеров — это разные вещи. Если вам хочется принять участие в поддержке пакета — обратитесь к мейнтейнеру и попросите его добавить вас в ACL пакета или группу.
После введения сборки из git-репозиториев условия NMU существенно упростились: если ваше изменение простое, то вы просто формируете задание на сборку и даёте на него ссылку мейнтейнерам, которые могут посмотреть и дать подтверждение. Получив подтверждение, вы отправляете это же задание на повторную сборку. В случае крупных изменений действуют обычные правила NMU.
Помните, что NMU — это акт помощи, мейнтейнер может быть благодарен за неё. При этом ответственность за судьбу пакета несёт мейнтейнер и поэтому он вправе в дальнейших сборках пакета делать то, что сочтёт нужным.
Стоит приложить разумные усилия к тому, чтобы облегчить мейнтейнеру принятие решения — приложением к письму или багрепорту патча, ссылкой на конкретный коммит или репозиторий в git.alt, наконец, доброжелательным отношением.