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

Материал из ALT Linux Wiki
Нет описания правки
Нет описания правки
Строка 1: Строка 1:
[[Category:Policy]]
[[Category:Sisyphus]]
{{Merge|NMU}}
Обновление пакета не сопровождающим (Non-Maintainer Upload, далее — NMU) — экстренное обновление пакета в репозитории кем-либо, кроме сопровождающих пакет. Предпринимается в случае наличия серьёзных проблем в пакете и недоступности сопровождающего или отсутствия у него возможности эти проблемы исправить.
{{MovedFromFreesourceInfo|AltLinux/Policy/drafts/NMU}}
== NMU ==
Закачка не сопровождающим (Non-Maintainer Upload) -- действие скорее чрезвычайного, хотя порой делегируемого характера, обычно имеющее место при необходимости безотлагательного решения срочной проблемы и затруднений со временем или возможностью у человека, ведущего пакет.


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


=== Правила обновления пакета без уведомления мантейнера ===
== Условия, требующие подготовки NMU ==


Обновление пакета без ожидания реакции мантейнера (далее - NMU) выполняется в случае выполнения одного из нижеследующих условий:
NMU выполняется в случае выполнения одного из нижеследующих условий:
# наличие ошибок в пакете, висящих на нем в системе отслеживания ошибок [http://bugzilla.altlinux.org http://bugzilla.altlinux.org]
# наличие серьёзных ошибок в пакете (major и выше), висящих на нем в системе отслеживания ошибок [http://bugzilla.altlinux.org http://bugzilla.altlinux.org],
# отсутствие реакции мантейнера на запросы от любого из участников ALT Linux Team, выполненные через список рассылки devel@, в течении двух недель
# отсутствие реакции мантейнера на запросы от любого из участников ALT Linux Team, выполненные через список рассылки devel@, в течении двух недель,
# наличие проблем с безопасностью в пакете
# наличие проблем с безопасностью в пакете,
# не собираемость пакета в изменённой сборочной среде (например при обновлении gcc, glibc и т.д.)
# несобираемость пакета в изменённой сборочной среде (например при обновлении gcc, glibc и т. д.).


При выполнении NMU должны обязательно быть выполнены следующие условия:
== Общие соображения ==
* при увеличении релиза пакета необходимо прибавить к существующему релизу 0.1 (например исходный пакет alt3, результирующий - alt3.1)
Перед тем, как делать NMU, следует постараться найти контакт с текущим майнтейнером — обязательно при помощи отчёта об ошибке в [https://bugzilla.altlinux.org bugzilla], а также электронной почты, IM, телефона или прямого обращения по мере возможности и уместности.
* при сборке новой версии пакета необходимо уведомить мантейнера через список рассылки devel@ о факте сборки новой версии, по запросу - предоставить spec и патчи
* в случае наличия репозитария, в котором мантейнер хранит (разрабатывает) пакет - необходимо при наличии доступа внести изменения в используемый репозитарий


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


Если возможно, подготовьте, проверьте и предложите в bugzilla патч, исправляющий проблему — это облегчит работу майнтейнеру. В любом случае '''настоятельно''' рекомендуется прислать майнтейнеру изменения в спеке и патчах, поскольку забыв про NMU — он может забыть и применить изменения к своей сборке, из которой будет исходить при составлении следующего пакета. В результате исправления могут быть откаченными, а то и вовсе потерянными.


=== Общие соображения ===
== Подготовка ==
Перед тем, как делать NMU, следует постараться найти контакт с текущим майнтейнером -- обязательно при помощи отчёта об ошибке в [https://bugzilla.altlinux.org bugzilla], а также электронной почты, IM, телефона или прямого обращения по мере возможности и уместности.


Если в течение срока от суток до месяца, в зависимости от срочности проблемы (серьёзная с безопасностью или разваливающая существенную часть репозитория, мешающая, не единицам пакетов и/или пользователей), положительный ответ не поступил или проблема не исправлена -- следует написать в <tt>devel@altlinux</tt> запрос и готовить обновление, если оно ещё не собрано для своих нужд.  
При исправлении следует учесть, что изменения должны быть минимальными и настолько неинтрузивными, насколько это возможно. Не следует «зачищать» спек, передвигать модули или файлы и вообще чинить то, что не сломано — этим следует заниматься майнтейнеру или [[Drafts/PackagerTeams|команде сопровождающих]].


Если возможно, подготовьте, проверьте и предложите в bugzilla патч, исправляющий проблему -- это облегчит работу майнтейнеру. В любом случае '''настоятельно''' рекомендуется прислать майнтейнеру изменения в спеке и патчах, поскольку забыв про NMU -- он может забыть и применить изменения к своей сборке, из которой будет исходить при составлении следующего пакета.  В результате исправления могут быть откаченными, а то и вовсе потерянными.
Не забывайте и Гиппократа: «превыше всего, не навреди». Лучше на пакете будет висеть открытый багрепорт по серьёзной проблеме, чем она будет «разрешена» нерабочим патчем или даже исправлена, но сломано ещё что-нибудь.


=== Подготовка ===
== Указание Packager ==
В любом случае при исправлении следует учесть, что изменения должны быть минимальными и настолько неинтрузивными, насколько это возможно.  Не следует "зачищать" спек, передвигать модули или файлы и вообще чинить то, что не сломано -- этим следует заниматься майнтейнеру или [[Drafts/PackagerTeams|команде сопровождающих]].


Не забывайте и Гиппократа: "превыше всего, не навреди". Лучше на пакете будет висеть открытый багрепорт по серьёзной проблеме, чем она будет "разрешена" нерабочим патчем или даже исправлена, но сломано ещё что-нибудь.
При отсутствии поля Packager в пакете его необходимо добавить, указав в нём реального майнтейнера, чтобы пакет не перешёл к вам (со всеми своими багами).
 
== Версионирование ==
 
Зачастую исправление можно сделать в рамках той же базовой версии пакета; при этом стоит добавить дополнительное число, отделённое точкой и начинающееся с «1» к содержимому тега <tt>Release</tt>, чтобы не пересечься с нормальной нумерацией версий у основного майнтейнера.


=== Указание Packager ===
Например, пакет, собранный майнтейнером с релизом <tt>alt3</tt>, автоматически пересобранный QA Team Robot с релизом <tt>alt3.1</tt> — при NMU должен получить релиз <tt>alt3.1.1</tt>.
При отсутствии поля Packager в пакете его необходимо добавить, указав в нём реального майнтейнера, чтобы пакет не перешёл к вам (со всеми своими багами).


==== Версионирование ====
Соответствующая строка в changelog пакета должна содержать слово «NMU», а также ссылки на номера багрепортов. Майнтейнеру следует сохранить или импортировать эту запись при дальнейшем сопровождении пакета.
Зачастую исправление можно сделать в рамках той же базовой версии пакета; при этом стоит добавить дополнительное число, отделённое точкой и начинающееся с "1", к содержимому тега <tt>Release</tt>, чтобы не пересечься с нормальной нумерацией версий у основного майнтейнера.


Например, пакет, собранный майнтейнером с релизом <tt>alt3</tt>, автоматически пересобранный QA Team Robot с релизом <tt>alt3.1</tt> -- при NMU должен получить релиз <tt>alt3.1.1</tt>.
== Управление доступом ==


Соответствующая строка в changelog пакета должна содержать слово "NMU", а также ссылки на номера багрепортов.  Майнтейнеру следует сохранить или импортировать эту запись при дальнейшем сопровождении пакета.
Майнтейнер в данное время может предоставлять или изымать возможность публикации ведомого им пакета другими участниками команды, передавать им пакет или объявлять его бесхозным при помощи [[Incoming#ACL|ACL на пакет]].


=== Ссылки ===
== Ссылки ==
* [http://www.debian.org/doc/developers-reference/ch-pkgs.en.html#s-nmu Debian NMU Policy]
* [http://www.debian.org/doc/developers-reference/ch-pkgs.en.html#s-nmu Debian NMU Policy]
* [[Drafts/PackagerTeams|Команды ведущих пакет]]

Версия от 08:24, 17 августа 2008

Обновление пакета не сопровождающим (Non-Maintainer Upload, далее — NMU) — экстренное обновление пакета в репозитории кем-либо, кроме сопровождающих пакет. Предпринимается в случае наличия серьёзных проблем в пакете и недоступности сопровождающего или отсутствия у него возможности эти проблемы исправить.

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

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

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

  1. наличие серьёзных ошибок в пакете (major и выше), висящих на нем в системе отслеживания ошибок http://bugzilla.altlinux.org,
  2. отсутствие реакции мантейнера на запросы от любого из участников ALT Linux Team, выполненные через список рассылки devel@, в течении двух недель,
  3. наличие проблем с безопасностью в пакете,
  4. несобираемость пакета в изменённой сборочной среде (например при обновлении gcc, glibc и т. д.).

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

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

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

Если возможно, подготовьте, проверьте и предложите в bugzilla патч, исправляющий проблему — это облегчит работу майнтейнеру. В любом случае настоятельно рекомендуется прислать майнтейнеру изменения в спеке и патчах, поскольку забыв про NMU — он может забыть и применить изменения к своей сборке, из которой будет исходить при составлении следующего пакета. В результате исправления могут быть откаченными, а то и вовсе потерянными.

Подготовка

При исправлении следует учесть, что изменения должны быть минимальными и настолько неинтрузивными, насколько это возможно. Не следует «зачищать» спек, передвигать модули или файлы и вообще чинить то, что не сломано — этим следует заниматься майнтейнеру или команде сопровождающих.

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

Указание Packager

При отсутствии поля Packager в пакете его необходимо добавить, указав в нём реального майнтейнера, чтобы пакет не перешёл к вам (со всеми своими багами).

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

Зачастую исправление можно сделать в рамках той же базовой версии пакета; при этом стоит добавить дополнительное число, отделённое точкой и начинающееся с «1» к содержимому тега Release, чтобы не пересечься с нормальной нумерацией версий у основного майнтейнера.

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

Соответствующая строка в changelog пакета должна содержать слово «NMU», а также ссылки на номера багрепортов. Майнтейнеру следует сохранить или импортировать эту запись при дальнейшем сопровождении пакета.

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

Майнтейнер в данное время может предоставлять или изымать возможность публикации ведомого им пакета другими участниками команды, передавать им пакет или объявлять его бесхозным при помощи ACL на пакет.

Ссылки