+Porters doing a source NMU generally follow the guidelines found in
+<ref id="nmu">, just like non-porters. However, it is expected that
+the wait cycle for a porter's source NMU is smaller than for a
+non-porter, since porters have to cope with a large quantity of
+packages.
+Again, the situation varies depending on the distribution they are
+uploading to. It also varies whether the architecture is a candidate
+for inclusion into the next stable release; the release managers
+decide and announce which architectures are candidates.
+ <p>
+If you are a porter doing an NMU for `unstable', the above
+guidelines for porting should be followed, with two variations.
+Firstly, the acceptable waiting period — the time between when the
+bug is submitted to the BTS and when it is OK to do an NMU — is seven
+days for porters working on the unstable distribution. This period
+can be shortened if the problem is critical and imposes hardship on
+the porting effort, at the discretion of the porter group. (Remember,
+none of this is Policy, just mutually agreed upon guidelines.)
+For uploads to stable or testing, please coordinate with the appropriate
+release team first.
+ <p>
+Secondly, porters doing source NMUs should make sure that the bug they
+submit to the BTS should be of severity `serious' or greater. This
+ensures that a single source package can be used to compile every
+supported Debian architecture by release time. It is very important
+that we have one version of the binary and source package for all
+architecture in order to comply with many licenses.
+ <p>
+Porters should try to avoid patches which simply kludge around bugs in
+the current version of the compile environment, kernel, or libc.
+Sometimes such kludges can't be helped. If you have to kludge around
+compiler bugs and the like, make sure you <tt>#ifdef</tt> your work
+properly; also, document your kludge 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. Of course, such locations have no official
+blessing or status, so buyer beware.
+
+
+ <sect1 id="porter-automation">
+ <heading>Porting infrastructure and automation</heading>
+ <p>
+There is infrastructure and several tools to help automate the package
+porting. This section contains a brief overview of this automation and
+porting to these tools; see the package documentation or references for
+full information.</p>
+
+ <sect2>
+ <heading>Mailing lists and web pages</heading>
+ <p>
+Web pages containing the status of each port can be found at <url
+id="&url-debian-ports;">.
+ <p>
+Each port of Debian has a mailing list. The list of porting mailing
+lists can be found at <url id="&url-debian-port-lists;">. These lists
+are used to coordinate porters, and to connect the users of a given
+port with the porters.</p>
+ </sect2>
+
+ <sect2>
+ <heading>Porter tools</heading>
+ <p>
+Descriptions of several porting tools can be found in <ref
+id="tools-porting">.</p>
+ </sect2>
+
+ <sect2 id="buildd">
+ <heading><package>buildd</package></heading>
+ <p>
+The <package>buildd</package> system is used as a distributed,
+client-server build distribution system. It is usually used in
+conjunction with <em>auto-builders</em>, which are ``slave'' hosts
+which simply check out and attempt to auto-build packages which need
+to be ported. There is also an email interface to the system, which
+allows porters to ``check out'' a source package (usually one which
+cannot yet be auto-built) and work on it.
+ <p>
+<package>buildd</package> is not yet available as a package; however,
+most porting efforts are either using it currently or planning to use
+it in the near future. The actual automated builder is packaged as
+<package>sbuild</package>, see its description in <ref id="sbuild">.
+The complete <package>buildd</package> system also collects a number of as yet unpackaged
+components which are currently very useful and in use continually,
+such as <prgn>andrea</prgn> and
+<prgn>wanna-build</prgn>.
+ <p>
+Some of the data produced by <package>buildd</package> which is
+generally useful to porters is available on the web at <url
+id="&url-buildd;">. This data includes nightly updated information
+from <prgn>andrea</prgn> (source dependencies) and
+<package>quinn-diff</package> (packages needing recompilation).
+ <p>
+We are quite proud of this system, since it has so
+many possible uses. Independent development groups can use the system for
+different sub-flavors of Debian, which may or may not really be of
+general interest (for instance, a flavor of Debian built with <prgn>gcc</prgn>
+bounds checking). It will also enable Debian to recompile entire
+distributions quickly.
+ <p>
+The buildds admins of each arch can be contacted by the mail address
+$arch@buildd.debian.org.
+
+ <sect1 id="packages-arch-specific">When your package is <em>not</em> portable
+ <p>
+Some packages still have issues with building and/or working on some
+of the architectures supported by Debian, and cannot be ported at all,
+or not with a reasonable amount of time. An example is a package that
+is SVGA-specific (only i386), or uses other hardware-specific features
+not supported on all architectures.
+ <p>
+In order to prevent broken packages from being uploaded to the archive, and
+wasting buildd time, you need to do a few things:
+ <p>
+ <list>
+ <item>
+ <p>
+First, make sure your package <em>does</em> fail to build on
+architectures that it cannot support.
+There are a few ways to achieve this.
+The preferred way is to have a small testsuite during build time
+that will test the functionality, and fail if it doesn't work.
+This is a good idea anyway,
+as this will prevent (some) broken uploads on all architectures,
+and also will allow the package to build
+as soon as the required functionality is available.
+ <p>
+Additionally, if you believe the list of supported architectures is
+pretty constant, you should change 'any' to a list of supported
+architectures in debian/control. This way, the build will fail also,
+and indicate this to a human reader without actually trying.
+ <item>
+ <p>
+In order to prevent autobuilders from needlessly trying to build your
+package, it must be included in <file>packages-arch-specific</file>, a
+list used by the <prgn>wanna-build</prgn> script.
+The current version is available as
+<url id="http://cvs.debian.org/srcdep/Packages-arch-specific?rev=HEAD&cvsroot=dak&content-type=text/vnd.viewcvs-markup">;
+please see the top of the file for whom to contact for changes.
+ </list>
+ <p>
+Please note that it is insufficient to only add your package to
+Packages-arch-specific
+without making it fail to build on unsupported architectures:
+A porter or any other person trying to build your package might
+accidently upload it without noticing it doesn't work.
+If in the past some binary packages were uploaded on unsupported architectures,
+request there removal by filing a bug against
+<package>ftp.debian.org</package>
+
+
+ <sect id="nmu">Non-Maintainer Uploads (NMUs)
+ <p>
+Under certain circumstances it is necessary for someone other than the
+official package maintainer to make a release of a package. This is
+called a non-maintainer upload, or NMU.
+ <p>
+This section handles only source NMUs, i.e. NMUs which upload a new
+version of the package. For binary-only NMUs by porters or QA members,
+please see <ref id="binary-only-nmu">.
+If a buildd builds and uploads a package,
+that too is strictly speaking a binary NMU.
+See <ref id="buildd"> for some more information.
+ <p>
+The main reason why NMUs are done is when a
+developer needs to fix another developer's packages in order to
+address serious problems or crippling bugs
+or when the package maintainer is unable to release a fix
+in a timely fashion.
+ <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</em> be made in a non-maintainer
+upload.
+ <p>
+And please remember the Hippocratic Oath: "Above all, do no harm."
+It is better if a package has an grave bug open, than if a not working
+patch was applied, and the bug is only hidden now but not resolved.
+
+
+ <sect1 id="nmu-guidelines">How to do a NMU
+ <p>
+NMUs which fix important, serious or higher severity bugs are encouraged
+and accepted.
+You should endeavor to reach the current maintainer of the package; they
+might be just about to upload a fix for the problem, or have a better
+solution present.
+ <p>
+NMUs should be made to assist a package's maintainer in resolving bugs.
+Maintainers should be thankful for that help, and NMUers should respect
+the decisions of maintainers, and try to personally help the maintainer by
+their work.
+ <p>
+A NMU should follow all conventions, written down in this section.
+For an upload to testing or unstable, this order of steps is recommended:
+ <p>
+<list>
+ <item>
+Make sure that the package's bugs that the NMU is meant to address are all
+filed in the Debian Bug Tracking System (BTS).
+If they are not, submit them immediately.
+ <item>
+Wait a few days for the response from the maintainer. If you don't get
+any response, you may want to help them by sending the patch that fixes
+the bug. Don't forget to tag the bug with the "patch" keyword.
+ <item>
+Wait a few more days. If you still haven't got an answer from the
+maintainer, send them a mail announcing your intent to NMU the package.
+Prepare an NMU as described in this section, and test it
+carefully on your machine (cf. <ref id="sanitycheck">).
+Double check that your patch doesn't have any unexpected side effects.
+Make sure your patch is as small and as non-disruptive as it can be.
+ <item>
+Upload your package to incoming in <file>DELAYED/7-day</file> (cf.
+<ref id="delayed-incoming">), send the final patch to the maintainer via
+the BTS, and explain to them that they have 7 days to react if they want
+to cancel the NMU.
+ <item>
+Follow what happens, you're responsible for any bug that you introduced
+with your NMU. You should probably use <ref id="pkg-tracking-system"> (PTS)
+to stay informed of the state of the package after your NMU.
+</list>
+ <p>
+At times, the release manager or an organized group of developers can
+announce a certain period of time in which the NMU rules are relaxed.
+This usually involves shortening the period during which one is to wait
+before uploading the fixes, and shortening the DELAYED period. It is
+important to notice that even in these so-called "bug squashing party"
+times, the NMU'er has to file bugs and contact the developer first,
+and act later.
+Please see <ref id="qa-bsp"> for details.
+ <p>
+For the testing distribution, the rules may be changed by the release
+managers. Please take additional care, and acknowledge that the usual way
+for a package to enter testing is through unstable.
+ <p>
+For the stable distribution, please take extra care. Of course, the release
+managers may also change the rules here. Please verify before upload that
+all your changes are OK for inclusion into the next stable release by the
+release manager.
+ <p>
+When a security bug is detected, the security team may do an NMU, using
+their own rules. Please refer to <ref id="bug-security"> for more
+information.
+ <p>
+For the differences for Porters NMUs, please see
+<ref id="source-nmu-when-porter">.
+ <p>
+Of course, it is always possible to agree on special rules with a maintainer
+(like the maintainer asking "please upload this fix directly for me, and no
+diff required").
+
+
+ <sect1 id="nmu-version">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</var> 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</var> 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</var> value
+`0.1'. The usual maintainer of a package should start their
+<var>debian-revision</var> numbering at `1'.
+ <p>
+If you upload a package to testing or stable, sometimes, you need to
+"fork" the version number tree. For this, version numbers like
+1.1-3sarge0.1 could be used.
+
+
+ <sect1 id="nmu-changelog">
+ <heading>Source NMUs must have a new changelog entry</heading>
+ <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</tt>) detailing their
+changes to the Bug Tracking System.
+ <p>
+What if you are simply recompiling the package? If you just need to
+recompile it for a single architecture, then you may do a binary-only
+NMU as described in <ref id="binary-only-nmu"> which doesn't require any
+patch to be sent. If you want the package to be recompiled for all
+architectures, then you do a source NMU as usual and you will have to
+send a patch.
+ <p>
+If the source NMU (non-maintainer upload) fixes some existing bugs,
+these bugs should be tagged <em>fixed</em> in the Bug Tracking
+System rather than closed. By convention, only the official package
+maintainer or the original bug submitter close bugs.
+Fortunately, Debian's archive system recognizes NMUs and thus marks
+the bugs fixed in the NMU appropriately if the person doing the NMU
+has listed all bugs in the changelog with the <tt>Closes:
+bug#<var>nnnnn</var></tt> syntax (see <ref id="upload-bugfix"> for
+more information describing how to close bugs via the changelog).
+Tagging the bugs <em>fixed</em> 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.
+ <p>
+Also, after doing an NMU, you have to send
+that information to the existing bugs that are fixed by your NMU,
+including the unified diff.
+Alternatively you can open a new bug and include a
+patch showing all the changes you have made.
+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</em> retain the
+entry in the changelog file documenting the non-maintainer upload.