5.11.1. When and how to do an NMU

Before doing an NMU, consider the following questions:

  • Have you geared the NMU towards helping the maintainer? As there might be disagreement on the notion of whether the maintainer actually needs help on not, the DELAYED queue exists to give time to the maintainer to react and has the beneficial side-effect of allowing for independent reviews of the NMU diff.

  • Does your NMU really fix bugs? (“Bugs” means any kind of bugs, e.g. wishlist bugs for packaging a new upstream version, but care should be taken to minimize the impact to the maintainer.) Fixing cosmetic issues or changing the packaging style (e.g. switching from cdbs to dh) in NMUs is discouraged.

  • 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?

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

  • Have you clearly expressed your intention to NMU, at least in the BTS? If that didn’t generate any feedback, it might also be a good idea to try to contact the maintainer by other means (email to the maintainer addresses or private email, IRC).

  • If the maintainer is usually active and responsive, have you tried to contact them? In general it should be considered preferable that maintainers take care of an issue themselves and that they are given the chance to review and correct your patch, because they can be expected to be more aware of potential issues which an NMUer might miss. It is often a better use of everyone’s time if the maintainer is given an opportunity to upload a fix on their own.

When doing an NMU, you must first make sure that your intention to NMU is 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 helpful.

While preparing the patch, you had better be aware of any package-specific practices that the maintainer might be using. Taking them into account reduces the burden of integrating your changes into the normal package workflow and thus increases the chances that integration will happen. A good place to look for possible package-specific practices is `debian/README.source <https://www.debian.org/doc/debian-policy/ch-source.html#s-readmesource>`__.

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 recommended values to use for delays:

  • Upload fixing only release-critical bugs older than 7 days, with no maintainer activity on the bug for 7 days and no indication that a fix is in progress: 0 days

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

  • Upload fixing only release-critical and important bugs: 5 days

  • Other NMUs: 10 days

Those delays are only examples. In some cases, such as uploads fixing security issues, or fixes for trivial bugs that block a transition, it is desirable that the fixed package reaches unstable sooner.

Sometimes, release managers decide to encourage NMUs with shorter delays for a subset of bugs (e.g release-critical bugs older than 7 days). Also, some maintainers list 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 in 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 way to achieve this).

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, your upload might be a cause of conflict with the maintainer. You should always be prepared to defend the wisdom of any NMU you perform on its own merits.