[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

DEP1: Non Maintainer Uploads (final call for review)


After a long delay, here is a final call for reviews and comments for
DEP1. I've wrote it as a patch to developers-reference, and extracted
the relevant part on:
If you prefer to read the diff, go to:

Also, I've included a text dump of the full section at the end of this
mail, but please review the html version if possible, as the text
version won't show problems in the markup that was used, for example.

You might also want to have a look at the archives of
debian-{devel,project} in april, may and june.

I'm interested both in ACKs and suggestions for changes.

Thank you,

- Lucas
5.11. Non-Maintainer Uploads (NMUs)

   Every package has one or more maintainers. Normally, these are
   the people who work on and upload new versions of the package.
   In some situations, it is useful that other developers can
   upload a new version as well, for example if they want to fix a
   bug in a package they don't maintain, when the maintainer fails
   to respond to issues. Such uploads are called Non-Maintainer
   Uploads (NMU).

  5.11.1. When and how to do an NMU

   Before doing an NMU, consider the following questions:

     o Do you really fix bugs in your NMU? Fixing cosmetic issues,
       or changing the packaging style in NMUs is discouraged,
       unless it is required to fix bugs.

     o Did you give enough time to the maintainer? When was the bug
       reported to the BTS? Being busy for a week or two isn't
       unusual. Is the bug so severe that it needs to be fixed
       right now, or can it wait a few more days?

     o How confident are you about your changes? Please remember
       the Hippocratic Oath: "Above all, do no harm." It is better
       to leave a package with an open grave bug than applying a
       non-functional patch, or one that hides the bug instead of
       resolving it. If you are not 100% sure of what you did, it
       might be a good idea to seek advice from others. Remember
       that if you break something in your NMU, many people will be
       very unhappy about it.

     o Have you clearly expressed your intention to NMU, at least
       on the BTS? Has the maintainer been notified of it? It is
       also a good idea to try to contact the maintainer by other
       means (private email, IRC).

     o If the maintainer is usually active and responsive, have you
       tried to contact him? In general it should be considered
       preferable that a maintainer takes care of an issue himself
       and that he is given the chance to review and correct your
       patch, because he can be expected to be more aware of
       potential issues which an NMUer might miss.

   When doing an NMU, you must first make sure that your intention
   to NMU is really clear. Then, you must send a patch with the
   differences between the current package and your proposed NMU to
   the BTS (the nmudiff script in the devscripts package might be

   Unless you have an excellent reason not to do so, you must then
   give some time to the maintainer to react (for example, by
   uploading to the DELAYED queue). Here are some delays that you
   could use as default values:

     o Upload fixing only release-critical bugs older than 7 days:
       2 days

     o Upload fixing only release-critical and important bugs: 5

     o Other NMUs: 10 days

   Those delays are only examples. In some cases (uploads fixing
   security issues, trivial bugfixes blocking a transition, ...),
   it is desirable that the fixed package reaches unstable sooner.

   Sometimes, release managers decide to allow NMUs with shorter
   delays for a subset of bugs (e.g release critical bugs older
   than 7 days). Also, some maintainers listed themselves in the
   Low Threshold NMU list, and accept that NMUs are uploaded
   without delay. But even in those cases, it's still a good idea
   to give the maintainer a few days to react before you upload,
   especially if the patch wasn't available on the BTS before, or
   if you know that the maintainer is generally active.

   After you upload an NMU, you are responsible for the possible
   problems that you might have introduced. You must keep an eye on
   the package (subscribing to the package on the PTS is a good

   This is not a license to perform NMUs thoughtlessly. If you NMU
   when it is clear that the maintainers are active and would have
   acknowledged a patch in a timely manner, or if you ignore the
   recommendations of this document, be warned, there is no
   protection for you here. You should always be prepared to defend
   the wisdom of any NMU you perform on its own merits.

  5.11.2. 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

   The version must be the version of the last upload, plus +nmuX,
   where X is a counter starting at 1. If the last upload was also
   an NMU, the counter should be increased. For example, if the
   current version is 1.5-1, then an NMU would get version
   1.5-1+nmu1. If the current version is 1.5+nmu3 (a native package
   which has already been NMUd), the NMU would get version
   1.5+nmu4. If a new upstream version is packaged in the NMU, the
   debian revision is set to 0, for example 1.6-0+nmu1.

   This special versioning is needed to avoid stealing one of the
   package maintainer's version numbers, which might disrupt their
   work. It also has the benefit of making it visually clear that a
   package in the archive was not made by the official maintainer.

   If you upload a package to testing or stable, you sometimes need
   to "fork" the version number tree. This is the case for security
   uploads, for example. For this, a version of the form +debXYuZ
   should be used, where X is the current stable major release
   number, and Y is the current minor release number for a stable
   upload, or one higher than that for a testing upload. Z is a
   counter starting at 1. For example, while Etch (Debian 4.0) is
   stable, a security NMU to stable for a package at version 1.5-3
   would have version 1.5-3+deb40u1, while a security NMU to Lenny
   would get version 1.5-3+deb41u1. This is the case even when it
   is already known that the next release will be a new major
   version ; for instance, Lenny will be released as Debian 5.0.

  5.11.3. Using the DELAYED/ queue

   After asking the maintainer for the permission to upload your
   NMU, it is annoying to have to wait for some time before you
   actually make the upload.

   The DELAYED queue (see Section 5.6.2, "Delayed uploads") allows
   the developer doing the NMU to perform all the necessary tasks
   at the same time. Instead of telling the maintainer that you
   will upload the updated package in (for example) 7 days, you
   should upload the package to DELAYED/7 and tell the maintainer
   that he has 7 days to react. During this time, the maintainer
   can ask you to delay the upload some more, or cancel your

   The DELAYED queue should not be used to put additional pressure
   on the maintainer. In particular, it's important that you are
   available to cancel or delay the upload before the delay expires
   (the maintainer cannot cancel the upload himself).

   If you make an NMU to DELAYED, and the maintainer updates his
   package before the delay expires, your upload will be rejected,
   because a newer version (the maintainer's one) is already
   available in the archive. Normally, the maintainer should take
   care to include your proposed changes (or at least a solution
   for the problems they address) in that upload.

  5.11.4. NMUs from the maintainer's 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.

   When a package has been NMUed, the maintainer should acknowledge
   it in the next upload. This makes clear that the changes were
   accepted in the maintainer's packaging, and that they aren't
   lost again. For this, you must first incorporate the changes
   into your package, as far as you want to keep them. Make sure to
   include the NMU's changelog entry (not just the line describing
   the changes) in your own changelog. This is important to allow
   the BTS version tracking to work.

  5.11.5. Source NMUs vs Binary-only NMUs (binNMUs)

   The full name of an NMU is source NMU. There is also another
   type, namely the binary-only NMU, or binNMU. A binNMU is also a
   package upload by someone other than the package's maintainer.
   However, it is a binary-only upload.

   When a library (or other dependency) is updated, the packages
   using it may need to be rebuilt. Since no changes to the source
   are needed, the same source package is used.

   BinNMUs are usually done by porters. They add an entry to
   debian/changelog, explaining why the upload was needed and
   increasing the version number as described in Section,
   "Recompilation or binary-only NMU". This entry should not be
   included in the next upload.

   Buildds upload packages for their architecture to the archive as
   binary-only uploads. Strictly speaking, these are binNMUs.
   However, they are not normally called NMU, and they don't add an
   entry to debian/changelog.

  5.11.6. NMUs vs QA uploads

   NMUs are uploads of packages which are owned by another
   maintainer. There is another type of upload where the uploaded
   package is not yours: QA uploads. QA uploads are uploads of
   orphaned packages.

   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 that 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

   Instead of doing a QA upload, you can also consider adopting the
   package by making yourself the maintainer. You don't need
   permission from anybody to adopt an orphaned package, you can
   just set yourself as maintainer and upload the new version (see
   Section 5.9.5, "Adopting a package").

| Lucas Nussbaum
| lucas@lucas-nussbaum.net   http://www.lucas-nussbaum.net/ |
| jabber: lucas@nussbaum.fr             GPG: 1024D/023B3F4F |

Reply to: