+Bug fixes to unstable by non-maintainers are also acceptable, but only
+as a last resort. Try the following steps first, and if they don't
+work, it is ok to do an NMU:
+ <p>
+<list>
+ <item>
+Make sure that the package bug is in the Debian BTS. If not, submit a
+bug.
+ <item>
+Email the maintainer, and offer to help fix the package bug. Give it a
+few days.
+ <item>
+Go ahead and fix the bug, submitting a patch to the right bug in
+the Bug Tracking System.
+ <item>
+Wait a couple of weeks for a response.
+ <item>
+Email the maintainer, asking if it is ok to do an NMU.
+ <item>
+Wait a couple of weeks for a response.
+ <item>
+Double check that your patch doesn't have any unexpected side effects.
+Build the package and test it as discussed in <ref id="upload-checking">.
+ </list>
+
+ <sect1>When to do an NMU if you are a porter
+ <p>
+Porters who have to patch the source package in order to get the
+package to compile need to follow these steps as well, although their
+window of time that they should wait is smaller, since they deal with
+a high quantity of packages.
+ <p>
+Again, the situation will vary depending on the distribution they are
+uploading to. Crucial fixes (i.e., changes need to get a source package
+to compile) can be uploaded with <em/no/ waiting period for the `frozen'
+distribution.
+ <p>
+However, if you are a porter doing an NMU for `unstable', the above
+guidelines for porting should be followed, with one variation.
+If you need to alter the source of a package in order to get a
+released port of Debian to compile, the bug you submit to the BTS
+should be of severity `important' or greater. This ensures that a
+single source package can be used to compile every supported Debian
+architecture.
+ <p>
+An acceptable waiting period -- the time between when the bug is
+submitted to the BTS and when it is ok to do an NMU -- is ten days
+for porters working on the unstable distribution.
+ <p>
+Try to avoid patches which simply kluge around bugs in the current
+version of the compile environment, kernel, or libc. Sometimes
+that can't be helped. If you have to kluge around compilers bugs and
+the like, make sure you <tt>#ifdef</tt> your work properly; also,
+document your kluge so that people know to remove it once the external
+problems have been fixed.
+ <p>
+Porters may also have an unofficial location where they can put the results
+of their work during the waiting period. This helps others running
+the port have the benefit of the porter's work, even during the waiting
+period.
+
+
+<sect id="nmu-guidelines">How to do an NMU
+ <p>
+When someone other than the usual maintainer releases a package they
+should add a new minor version number to the <var/debian-revision/ part of
+the version number (the portion after the last hyphen).
+This extra minor number will start at `1'. For example, consider
+the package `foo', which is at version 1.1-3. In the archive, the source
+package control file would be <tt>foo_1.1-3.dsc</tt>. The upstream
+version is `1.1' and the Debian revision is `3'. The next NMU would
+add a new minor number `.1' to the Debian revision; the new source
+control file would be <tt>foo_1.1-3.1.dsc</tt>.
+ <p>
+The Debian revision minor number 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 made by an NMU.
+ <p>
+If there is no <var/debian-revision/ component
+in the version number then one should be created, starting at `0.1'.
~ianmdlvl / developers-reference.git / blobdiff