Differences between revisions 1 and 2
Revision 1 as of 2008-02-12 09:52:21
Size: 2919
Comment:
Revision 2 as of 2008-02-13 13:47:16
Size: 6853
Editor: ?BasWijnen
Comment: Fill in some parts
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
{{{Title: Clarifying policies and workflows for Non Maintainer Uploads (NMUs) {{{
Title: Clarifying policies and workflows for Non Maintainer Uploads (NMUs)
Line 12: Line 13:
Line 14: Line 14:

In Debian, each package is "owned" by its maintainer, or by a small group of
maintainers, in the case of team maintenance. Modifying the package requires
going through those developers, which sometimes add a long, unecessary delay,
especially in the case of inactive or busy maintainers.
In Debian, each package is "owned" by its maintainer, or by a small group of maintainers, in the case of team maintenance. Modifying the package requires going through those developers, which sometimes add a long, unnecessary delay, especially in the case of inactive or busy maintainers.
Line 21: Line 17:
Line 23: Line 20:
This Debian Enhancement Proposal has two goals:
Line 24: Line 22:
This Debian Enhancement Proposal has two goals:
Line 27: Line 24:
= Proposed section 5.11: Non-Maintainer Uploads (NMUs) =
Every package has one or more maintainers. Normally, these are the people who upload new versions of the package. In some situations, it is useful that other developers can upload a new version as well. Such an upload is called a Non-Maintainer Upload (NMU).
Line 28: Line 27:
= Proposed section 5.11: Non-Maintainer Uploads (NMUs) =

short intro, describing what NMUs are, and in which case people do that.
We should mention that it's possible to do NMUs for all bugs (you just
have to follow to normal NMU rules). People often think that NMUs are
only for RC bugs.
NMUs can happen for various reasons, the most usual one being to fix bugs. There are some rules to follow when doing an NMU. These are explained below. An NMU is allowed for any reason, as long as those rules are followed.
Line 36: Line 30:
Often, there is contact with the package maintainer before an NMU is done. When this is the case, anything is allowed as long as the maintainer agrees with it.
Line 37: Line 32:
Describe the general process for NMU, without going into technical
details (such as DELAYED/, versioning, etc)
The main rules to follow when doing an NMU without prior agreement from the maintainer are:
Line 40: Line 34:
 * The NMU must fix bugs of severity at least important. All bugs which implement release goals and release blockers fall in this category.
 * The bugs that are fixed must be filed in the BTS.
 * It must only fix bugs, and do this as non-intrusive as possible. The upload must not make other minor improvements, such as updating the standards version. It certainly must not change the way the packaging is done.
 * The maintainer must be given time to fix things differently if he or she would disagree with the solution.
Line 41: Line 39:
Just like any other (source) upload, NMUs must add an entry to debian/changelog, telling what has changed with this upload. The first line of this entry is special, it must be
Line 42: Line 41:
Mention the versioning issue (there's an open bug against devref about
that, but the discussion is inconclusive. Do we want to address that as
well?)
 * Non-maintainer upload.
Line 46: Line 43:
Mention the specific changelog entry For non-native packages, the version of the changelog entry must be the upstream version, plus a Debian revision, just as in a normal upload. However, the debian revision should be of the form '''x.y''', where '''x''' is one less than the next to be released normal Debian revision number for this upstream version, and '''y''' is a counter starting at 1. For example, if the current version is '''1.5-3''', then an NMU would get '''1.5-3.1''' for the version. If a new upstream version is packaged in the NMU, the version would become '''1.6-0.1'''.

FIXME: Add something about native package NMU versioning. See bug #437392.
Line 49: Line 48:
When an NMU is done without contact with the maintainer first, there are several ways to allow the maintainer to do things differently. First of all, if the bug that is fixed has not had any activity for 7 days, and there is no indication that it is being worked on, NMUs are allowed without any delay (as long as they follow the other rules).
In some situations, such as bug squashing parties, it is not desirable to have to wait 7 days and do the upload after that. It is then possible to schedule an upload for some time in the future. That way, the maintainer has some time to fix it differently (and cancel the upload). But when nothing is done (because the maintainer agrees with the upload, or is unavailable), the upload happens at the scheduled time without any action from the NMUer.
Line 50: Line 51:
explain how to use the DELAYED/ queue to make it easier to do NMUs. FIXME: explain how to use the DELAYED/ queue.
Line 53: Line 54:

describe what they are, and how to apply them. We should have a list of
things to consider when deciding between DELAYED/2,7,etc...)
FIXME: describe what they are, and how to apply them. We should have a list of things to consider when deciding between DELAYED/2,7,etc...)
Line 58: Line 57:
When someone NMUs your package, this means they want to help you to keep it in good shape. This saves you work, and gives users fixed packages faster. You can consider asking the NMUer to become a co-maintainer of the package.
Line 59: Line 59:
blurb about how NMUs are nice, and you shouldn't complain If someone suggests that they could do an NMU on your package, you should be thankful that they want to put time into this, while it is really your responsibility to fix the bug. Receiving an NMU on a package is not a bad thing; it just means that the package is interesting enough for other people to work on it.
FIXME: describe how to ACK an NMU (include the relevant changelog entry so BTS versioning gets it right)
Line 61: Line 62:
describe how to ACK an NMU (include the relevant changelog entry so BTS versioning gets it right)

describe how the BTS reacts to NMUs (and compare with how it reacted in the past)
FIXME: describe how the BTS reacts to NMUs (and perhaps compare with how it reacted in the past? Bas: not sure about this, I think the devref should not contain statements about how things are not done, even if many people currently still remember that)
Line 66: Line 65:
FIXME: explain the difference.
Line 67: Line 67:
explain the difference. == 5.11.4 NMUs vs QA uploads ==
NMUs are uploads of packages which are owned by another maintainer. There is another type of uploading a package which is not yours: a QA upload. This is an upload of an orphaned package.
Line 69: Line 70:
== 5.11.4 NMus vs QA uploads == QA uploads are very much like normal maintainer uploads: they may fix anything, even minor issues; the version numbering is normal, and there is no need to use a delayed upload. The difference is that you are not listed as the Maintainer or Uploader for the package. Also, the changelog entry of a QA upload has a special first line:
Line 71: Line 72:
very short blurb about how to do QA uploads.  * QA upload.

If you want to do an NMU, and it seems the maintainer is not active, it is wise to check if the package is orphaned. When doing the first QA upload to an orphaned package, the maintainer should be set to ''Debian QA Group <packages@qa.debian.org>''. Orphaned packages which did not have a QA upload yet still have their old maintainer set. There is a list of them at http://qa.debian.org/orphaned.html.
Line 74: Line 77:

propose new wording for the default template to make it more friendly
FIXME: propose new wording for the default template to make it more friendly

Title: Clarifying policies and workflows for Non Maintainer Uploads (NMUs)
DEP: FIXME
State: DRAFT
Date: 2008-02-12
Drivers: Lucas Nussbaum <lucas@debian.org>,
 Bas Wijnen <wijnen@debian.org>
URL: http://wiki.debian.org/NmuDep
Abstract:
 This document aims at clarifying the policies and workflows used for NMUs
 inside Debian. Its main goal is to provide a patch to section 5.11 of the
 Debian Developer's Reference, adressing the current issues regarding NMUs.

Introduction and Motivation

In Debian, each package is "owned" by its maintainer, or by a small group of maintainers, in the case of team maintenance. Modifying the package requires going through those developers, which sometimes add a long, unnecessary delay, especially in the case of inactive or busy maintainers.

Non-maintainer uploads (NMUs) alleviate this problem, by allowing any developer to upload a new version of another maintainer's package. However:

  1. NMUs are often received with angry comments from maintainers
  2. Rules that have to be followed for NMUs are not very clear, so many developers prefer not to do NMUs.

This Debian Enhancement Proposal has two goals:

  1. improve section 5.11 of the Developer's Reference, to clarify it and address the current issues about NMUs
  2. improve related tools, like the nmudiff script in the devscripts package.

Proposed section 5.11: Non-Maintainer Uploads (NMUs)

Every package has one or more maintainers. Normally, these are the people who upload new versions of the package. In some situations, it is useful that other developers can upload a new version as well. Such an upload is called a Non-Maintainer Upload (NMU).

NMUs can happen for various reasons, the most usual one being to fix bugs. There are some rules to follow when doing an NMU. These are explained below. An NMU is allowed for any reason, as long as those rules are followed.

5.11.1 How to do an NMU

Often, there is contact with the package maintainer before an NMU is done. When this is the case, anything is allowed as long as the maintainer agrees with it.

The main rules to follow when doing an NMU without prior agreement from the maintainer are:

  • The NMU must fix bugs of severity at least important. All bugs which implement release goals and release blockers fall in this category.
  • The bugs that are fixed must be filed in the BTS.
  • It must only fix bugs, and do this as non-intrusive as possible. The upload must not make other minor improvements, such as updating the standards version. It certainly must not change the way the packaging is done.
  • The maintainer must be given time to fix things differently if he or she would disagree with the solution.

5.11.1.1 NMUs and debian/changelog

Just like any other (source) upload, NMUs must add an entry to debian/changelog, telling what has changed with this upload. The first line of this entry is special, it must be

  • Non-maintainer upload.

For non-native packages, the version of the changelog entry must be the upstream version, plus a Debian revision, just as in a normal upload. However, the debian revision should be of the form x.y, where x is one less than the next to be released normal Debian revision number for this upstream version, and y is a counter starting at 1. For example, if the current version is 1.5-3, then an NMU would get 1.5-3.1 for the version. If a new upstream version is packaged in the NMU, the version would become 1.6-0.1.

FIXME: Add something about native package NMU versioning. See bug #437392.

5.11.1.2 Using the DELAYED/ queue

When an NMU is done without contact with the maintainer first, there are several ways to allow the maintainer to do things differently. First of all, if the bug that is fixed has not had any activity for 7 days, and there is no indication that it is being worked on, NMUs are allowed without any delay (as long as they follow the other rules). In some situations, such as bug squashing parties, it is not desirable to have to wait 7 days and do the upload after that. It is then possible to schedule an upload for some time in the future. That way, the maintainer has some time to fix it differently (and cancel the upload). But when nothing is done (because the maintainer agrees with the upload, or is unavailable), the upload happens at the scheduled time without any action from the NMUer.

FIXME: explain how to use the DELAYED/ queue.

5.11.1.3 Relaxed NMU policy

FIXME: describe what they are, and how to apply them. We should have a list of things to consider when deciding between DELAYED/2,7,etc...)

5.11.2 NMUs, from the maintainer point of view

When someone NMUs your package, this means they want to help you to keep it in good shape. This saves you work, and gives users fixed packages faster. You can consider asking the NMUer to become a co-maintainer of the package.

If someone suggests that they could do an NMU on your package, you should be thankful that they want to put time into this, while it is really your responsibility to fix the bug. Receiving an NMU on a package is not a bad thing; it just means that the package is interesting enough for other people to work on it. FIXME: describe how to ACK an NMU (include the relevant changelog entry so BTS versioning gets it right)

FIXME: describe how the BTS reacts to NMUs (and perhaps compare with how it reacted in the past? Bas: not sure about this, I think the devref should not contain statements about how things are not done, even if many people currently still remember that)

5.11.3 Source NMUs vs Binary NMUs (binNMUs)

FIXME: explain the difference.

5.11.4 NMUs vs QA uploads

NMUs are uploads of packages which are owned by another maintainer. There is another type of uploading a package which is not yours: a QA upload. This is an upload of an orphaned package.

QA uploads are very much like normal maintainer uploads: they may fix anything, even minor issues; the version numbering is normal, and there is no need to use a delayed upload. The difference is that you are not listed as the Maintainer or Uploader for the package. Also, the changelog entry of a QA upload has a special first line:

  • QA upload.

If you want to do an NMU, and it seems the maintainer is not active, it is wise to check if the package is orphaned. When doing the first QA upload to an orphaned package, the maintainer should be set to Debian QA Group <packages@qa.debian.org>. Orphaned packages which did not have a QA upload yet still have their old maintainer set. There is a list of them at http://qa.debian.org/orphaned.html.

nmudiff improvements

FIXME: propose new wording for the default template to make it more friendly