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

Материал из ALT Linux Wiki
(Import from freesource.info)
 
м (+заголовок Примечания)
 
(не показано 70 промежуточных версий 12 участников)
Строка 1: Строка 1:
[[Category:Policy]]
{{Policy
{{MovedFromFreesourceInfo|AltLinux/Policy/drafts/NMU}}
|responsible=Антон Фарыгин (rider)
|since=01.05.2009
}}
__NOTOC__
Версия 1.1.


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


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


=== Правила обновления пакета без уведомления мантейнера ===
Данное Policy регламентирует взаимоотношения между мейнтейнерами. Для правил выполнения массовых NMU роботами см. [[MassNMU|полиси по массовым NMU]].


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


При выполнении NMU должны обязательно быть выполнены следующие условия:
== Условия выдачи NMU ==
* при увеличении релиза пакета необходимо прибавить к существующему релизу 0.1 (например исходный пакет alt3, результирующий - alt3.1)
* при сборке новой версии пакета необходимо уведомить мантейнера через список рассылки devel@ о факте сборки новой версии, по запросу - предоставить spec и патчи
* в случае наличия репозитария, в котором мантейнер хранит (разрабатывает) пакет - необходимо при наличии доступа внести изменения в используемый репозитарий


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


# Без предварительного оповещения мейнтейнера NMU может выполняться при подготовке security-исправлений, требующих приватной подготовки согласно Security Policy (до того момента, как Security Policy принята, такими считаются только исправления, для которых организуется Coordinated Release Date (CRD)). В этом случае мейнтейнер должен быть извещён не позднее, чем пакет будет отправлен в репозиторий.
# Отсутствие реакции мейнтейнера на ошибки с серьёзностью [[BugSeverityPolicy|Critical]] в {{altbug}} в течение двух недель.
# Отсутствие реакции мейнтейнера на ошибки с серьёзностью [[BugSeverityPolicy|Blocker]] в {{altbug}} в течение 12 часов


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


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


Если возможно, подготовьте, проверьте и предложите в bugzilla патч, исправляющий проблему -- это облегчит работу майнтейнеру.  В любом случае '''настоятельно''' рекомендуется прислать майнтейнеру изменения в спеке и патчах, поскольку забыв про NMU -- он может забыть и применить изменения к своей сборке, из которой будет исходить при составлении следующего пакета.  В результате исправления могут быть откаченными, а то и вовсе потерянными.
Одновременно с заливкой NMU рекомендуется указать мейнтейнеру на git с исправлением (если мейнтейнер использует gear) либо приложить к ошибке в {{altbug}} патч.


=== Подготовка ===
=== Управление доступом ===
В любом случае при исправлении следует учесть, что изменения должны быть минимальными и настолько неинтрузивными, насколько это возможно. Не следует "зачищать" спек, передвигать модули или файлы и вообще чинить то, что не сломано -- этим следует заниматься майнтейнеру или [[Drafts/PackagerTeams|команде сопровождающих]].
Мейнтейнер предоставляет или изымает возможность NMU на ведомые им пакеты при помощи [[Git.alt/Справочник#acl|git.alt acl]] и [[Git.alt/Справочник#task_approve|git.alt task approve]].


Не забывайте и Гиппократа: "превыше всего, не навреди".  Лучше на пакете будет висеть открытый багрепорт по серьёзной проблеме, чем она будет "разрешена" нерабочим патчем или даже исправлена, но сломано ещё что-нибудь.
В случае отсутствия реакции мейнтейнера на запросы по предоставлению доступа, право на NMU предоставляет один из [[ACLAdmin|администраторов ACL]].


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


==== Версионирование ====
* Изменения должны быть минимальными и настолько неинтрузивными, насколько это возможно (не следует «зачищать» спек, передвигать модули или файлы, и вообще, чинить то, что не сломано — этим следует заниматься мейнтейнерам).
Зачастую исправление можно сделать в рамках той же базовой версии пакета; при этом стоит добавить дополнительное число, отделённое точкой и начинающееся с "1", к содержимому тега <tt>Release</tt>, чтобы не пересечься с нормальной нумерацией версий у основного майнтейнера.
* К NMU предъявляются обычные требования попадания пакета в репозиторий (в частности, наследование по коммитам при использовании gear).
* Если в spec-файле отсутствует поле <tt>Packager</tt>, то его необходимо добавить и указать в нём мейнтейнера пакета.<ref>Однако, ср. [[ACL#@everybody|текущее поведение acl для заливок через @everybody]]: "Принадлежность пакета при таких заливках не меняется." Т.е. в таком случае на самом деле в нынешней ситуации принадлежность не должна поменяться и при отсутствии поля <tt>Packager</tt>.</ref>
* 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|автоматическое закрытие ошибок]]. Мейнтейнеру следует сохранить или импортировать эту запись при дальнейшем сопровождении пакета.


Например, пакет, собранный майнтейнером с релизом <tt>alt3</tt>, автоматически пересобранный QA Team Robot с релизом <tt>alt3.1</tt> -- при NMU должен получить релиз <tt>alt3.1.1</tt>.
Не забывайте и Гиппократа: «превыше всего, не навреди». Пусть лучше на пакете будет висеть открытый багрепорт по серьёзной проблеме, чем она будет «разрешена» нерабочим патчем или даже исправлена, но при этом будет сломано ещё что-нибудь.


Соответствующая строка в changelog пакета должна содержать слово "NMU", а также ссылки на номера багрепортов.  Майнтейнеру следует сохранить или импортировать эту запись при дальнейшем сопровождении пакета.
=== Версионирование ===
Если исправление можно сделать в рамках той же upstream-версии пакета, что находится в репозитории, то в значение тэга Release пакета необходимо добавить дополнительное число, отделённое точкой и по нумерации начинающееся с единицы, чтобы не пересечься с обычной нумерацией версий и релизов у основного мейнтейнера.


=== Ссылки ===
Например, пакет, собранный ранее мейнтейнером с релизом <tt>alt3</tt> и автоматически пересобранный ранее QA Team Robot с релизом <tt>alt3.1</tt>, при NMU должен получить релиз <tt>alt3.1.1</tt>.
* [http://www.debian.org/doc/developers-reference/ch-pkgs.en.html#s-nmu Debian NMU Policy]
 
* [[Drafts/PackagerTeams|Команды ведущих пакет]]
Если для исправления необходимо обновление версии в репозитории, то NMU выполняется с изменением версии программы и установкой релиза пакета в <tt>alt1</tt>.
 
Также, во избежание появления в релизе расчесок вида <tt>alt3.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1</tt>
допускаются суффиксы вида <tt>alt<M>{,.n}</tt>, где <M> релиз выставленный мантейнером, а n -- цифра инкрементируемая при NMU.
 
Также, как исключение, сборки в рамках @qa team могут иметь суффикс <tt>alt<M>{,.qaN}</tt>,
где <M> релиз выставленный мантейнером, а N -- цифра, инкрементируемая при NMU.
 
== Дополнительная информация ==
 
''Эта секция не является нормативной''
 
NMU и запрос на добавление в список мейнтейнеров — это разные вещи. Если вам хочется принять участие в поддержке пакета — обратитесь к мейнтейнеру и попросите его добавить вас в ACL пакета или группу. Если мейнтейнер не отзывается — имеет смысл [[ACLPolicy|забрать пакет себе]].
 
После введения в строй сборки из git-репозиториев стала доступной следующая простая форма реализации NMU:
вы формируете обычное задание на сборку и даёте на него ссылку мейнтейнерам, которые могут её посмотреть и дать подтверждение.
Получив подтверждение, вы просто отправляете это же задание на повторную сборку.
 
Помните, что NMU — это акт помощи, мейнтейнер может быть благодарен за неё. При этом ответственность за судьбу пакета несёт мейнтейнер, и поэтому он вправе в дальнейших сборках пакета делать то, что сочтёт нужным.
 
Стоит приложить разумные усилия к тому, чтобы облегчить мейнтейнеру принятие решения — приложением к письму или багрепорту патча, ссылкой на конкретный коммит или репозиторий в git.alt, наконец, доброжелательным отношением.
 
== Ссылки ==
* [[BugSeverityPolicy|Уровни серьёзности ошибок]]
* [[ACL|Общая информация об ACL]]
* [[Git.alt/Справочник#.D0.A3.D0.BF.D1.80.D0.B0.D0.B2.D0.BB.D0.B5.D0.BD.D0.B8.D0.B5_ACL_.D0.BF.D0.B0.D0.BA.D0.B5.D1.82.D0.BE.D0.B2|Справочник по управлению ACL в git.alt]]
 
== Примечания ==
<references />
 
[[Категория:Sisyphus]]

Текущая версия от 19:27, 14 ноября 2015

Stamp90cw.png
Действующая политика Sisyphus

Политика действует с 01.05.2009.

Ответственный за проведение политики в жизнь — Антон Фарыгин (rider).


Версия 1.1.

NMU (Non-Maintainer Upload) — обновление пакета не сопровождающим его.

Рамки Policy

Данное Policy регламентирует взаимоотношения между мейнтейнерами. Для правил выполнения массовых NMU роботами см. полиси по массовым NMU.

В данном Policy регулируются два вопроса:

  • Условия выдачи NMU
  • Технологические требования к NMU

Условия выдачи NMU

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

  1. Без предварительного оповещения мейнтейнера NMU может выполняться при подготовке security-исправлений, требующих приватной подготовки согласно Security Policy (до того момента, как Security Policy принята, такими считаются только исправления, для которых организуется Coordinated Release Date (CRD)). В этом случае мейнтейнер должен быть извещён не позднее, чем пакет будет отправлен в репозиторий.
  2. Отсутствие реакции мейнтейнера на ошибки с серьёзностью Critical в bugzilla.altlinux.org в течение двух недель.
  3. Отсутствие реакции мейнтейнера на ошибки с серьёзностью Blocker в bugzilla.altlinux.org в течение 12 часов

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

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

В случае отсутствия реакции мейнтейнера на ошибку в течении установленного в данном Policy времени следует добавить комментарий к ошибке с запросом на NMU и подготовить обновление.

Одновременно с заливкой NMU рекомендуется указать мейнтейнеру на git с исправлением (если мейнтейнер использует gear) либо приложить к ошибке в bugzilla.altlinux.org патч.

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

Мейнтейнер предоставляет или изымает возможность NMU на ведомые им пакеты при помощи git.alt acl и git.alt task approve.

В случае отсутствия реакции мейнтейнера на запросы по предоставлению доступа, право на NMU предоставляет один из администраторов ACL.

Технологические требования к NMU

  • Изменения должны быть минимальными и настолько неинтрузивными, насколько это возможно (не следует «зачищать» спек, передвигать модули или файлы, и вообще, чинить то, что не сломано — этим следует заниматься мейнтейнерам).
  • К NMU предъявляются обычные требования попадания пакета в репозиторий (в частности, наследование по коммитам при использовании gear).
  • Если в spec-файле отсутствует поле Packager, то его необходимо добавить и указать в нём мейнтейнера пакета.[1]
  • Changelog пакета должен начинаться с «NMU:». В changelog так же должен быть указан номер ошибки в формате, допускающем автоматическое закрытие ошибок. Мейнтейнеру следует сохранить или импортировать эту запись при дальнейшем сопровождении пакета.

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

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

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

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

Если для исправления необходимо обновление версии в репозитории, то NMU выполняется с изменением версии программы и установкой релиза пакета в alt1.

Также, во избежание появления в релизе расчесок вида alt3.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1 допускаются суффиксы вида alt<M>{,.n}, где <M> релиз выставленный мантейнером, а n -- цифра инкрементируемая при NMU.

Также, как исключение, сборки в рамках @qa team могут иметь суффикс alt<M>{,.qaN}, где <M> релиз выставленный мантейнером, а N -- цифра, инкрементируемая при NMU.

Дополнительная информация

Эта секция не является нормативной

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

После введения в строй сборки из git-репозиториев стала доступной следующая простая форма реализации NMU: вы формируете обычное задание на сборку и даёте на него ссылку мейнтейнерам, которые могут её посмотреть и дать подтверждение. Получив подтверждение, вы просто отправляете это же задание на повторную сборку.

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

Стоит приложить разумные усилия к тому, чтобы облегчить мейнтейнеру принятие решения — приложением к письму или багрепорту патча, ссылкой на конкретный коммит или репозиторий в git.alt, наконец, доброжелательным отношением.

Ссылки

Примечания

  1. Однако, ср. текущее поведение acl для заливок через @everybody: "Принадлежность пакета при таких заливках не меняется." Т.е. в таком случае на самом деле в нынешней ситуации принадлежность не должна поменяться и при отсутствии поля Packager.