+The following applies to porters insofar as they are playing the dual
+role of being both package bug-fixers and package porters. If a
+porter has to change the Debian source archive, automatically their
+upload is a source NMU and is subject to its rules. If a porter is
+simply uploading a recompiled binary package, the rules are different;
+see <ref id="porter-guidelines">.
+ <p>
+First and foremost, it is critical that NMU patches to source should
+be as non-disruptive as possible. Do not do housekeeping tasks, do
+not change the name of modules or files, do not move directories; in
+general, do not fix things which are not broken. Keep the patch as
+small as possible. If things bother you aesthetically, talk to the
+Debian maintainer, talk to the upstream maintainer, or submit a bug.
+However, aesthetic changes must <em/not/ be made in a non-maintainer
+upload.
+
+
+ <sect1 id="nmu-version">Source NMU version numbering
+ <p>
+Whenever you have made a change to a package, no matter how trivial,
+the version number needs to change. This enables our packing system
+to function.
+ <p>
+If you are doing a non-maintainer upload (NMU), you 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 <file>foo_1.1-3.dsc</file>. 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
+<file>foo_1.1-3.1.dsc</file>.
+ <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 not made by the official maintainer.
+ <p>
+If there is no <var/debian-revision/ component in the version number
+then one should be created, starting at `0.1'. If it is absolutely
+necessary for someone other than the usual maintainer to make a
+release based on a new upstream version then the person making the
+release should start with the <var/debian-revision/ value `0.1'. The
+usual maintainer of a package should start their <var/debian-revision/
+numbering at `1'. Note that if you do this, you'll have to invoke
+<prgn>dpkg-buildpackage</prgn> with the <tt/-sa/ switch to force the
+build system to pick up the new source package (normally it only looks
+for Debian revisions of '0' or '1' -- it's not yet clever enough to
+know about `0.1').
+ <p>
+Remember, porters who are simply recompiling a package for a different
+architecture do not need to renumber. Porters should use new version
+numbers if and only if they actually have to modify the source package
+in some way, i.e., if they are doing a source NMU and not a binary
+NMU.
+
+
+ <sect1 id="nmu-changelog">Source NMUs must have a new changelog entry
+ <p>
+A non-maintainer doing a source NMU must create a changelog entry,
+describing which bugs are fixed by the NMU, and generally why the NMU
+was required and what it fixed. The changelog entry will have the
+non-maintainer's email address in the log entry and the NMU version
+number in it.
+ <p>
+By convention, source NMU changelog entries start with the line
+<example>
+ * Non-maintainer upload
+</example>
+
+
+ <sect1 id="nmu-patch">Source NMUs and the Bug Tracking System
+ <p>
+Maintainers other than the official package maintainer should make as
+few changes to the package as possible, and they should always send a
+patch as a unified context diff (<tt/diff -u/) detailing their
+changes to the Bug Tracking System.
+ <p>
+What if you are simply recompiling the package? In this case, the
+process is different for porters than it is for non-porters, as
+mentioned above. If you are not a porter and are doing an NMU that
+simply requires a recompile (i.e., a new shared library is available
+to be linked against, a bug was fixed in <package/debhelper/), there
+must still be a changelog entry; therefore, there will be a patch. If
+you are a porter, you are probably just doing a binary NMU. (Note:
+this leaves out in the cold porters who have to do recompiles -- chalk
+it up as a weakness in how we maintain our archive.)
+ <p>
+If the source NMU (non-maintainer upload) fixes some existing bugs,
+the bugs in the Bug Tracking System which are fixed need to be
+<em/notified/ but not actually <em/closed/ by the non-maintainer.
+Technically, only the official package maintainer or the original bug
+submitter are allowed to close bugs. However, the person making the
+non-maintainer release must send a short message to the relevant bugs
+explaining that the bugs have been
+fixed by the NMU. Using <email/control@bugs.debian.org/, the party
+doing the NMU should also set the severity of the bugs fixed in the
+NMU to `fixed'. This ensures that everyone knows that the bug was
+fixed in an NMU; however the bug is left open until the changes in the
+NMU are incorporated officially into the package by the official
+package maintainer. Also, open a bug with the patches needed to
+fix the problem, or make sure that one of the other (already open) bugs
+has the patches.
+ <p>
+The normal maintainer will either apply the patch or employ an
+alternate method of fixing the problem. Sometimes bugs are fixed
+independently upstream, which is another good reason to back out an
+NMU's patch. If the maintainer decides not to apply the NMU's patch
+but to release a new version, the maintainer needs to ensure that the
+new upstream version really fixes each problem that was fixed in the
+non-maintainer release.
+ <p>
+In addition, the normal maintainer should <em/always/ retain the entry