<!--
TODO:
- bugs in upstream versions should be reported upstream!
- - porter instructions - - volunteers needed for this x86-centric
- maintainer!
- add information on how to get accounts on different architectures
- talk about CVS access
-->
<p>
Debian GNU/Linux 1.3 is only available as <em>i386</em>. Debian 2.0
supports <em>i386</em> and <em>m68k</em> architectures. The next
-version of Debian is likely to also support all these, in addition to
-<em>alpha</em>, <em>ppc</em>, and <em>sparc</em> architectures.
+version of Debian is likely to support <em>i386</em>, <em>m68k</em>,
+<em>alpha</em>, and possibly <em>ppc</em> and <em>sparc</em>
+architectures.
<sect>Subsections
The sections <em/main/, <em/contrib/, and <em/non-free/ are split into
<em/subsections/ to simplify the installation process and the
maintainance of the archive. Subsections are not formally defined,
-excepting perhaps for the `base' subsection. Subsections exist simply
+excepting perhaps the `base' subsection. Subsections exist simply
to simplify the organization and browsing of available packages.
Please check the current Debian distribution to see which sections are
available.
-
+<p>
<sect>Packages
the keys of the developers key-ring.
- <sect>Announcing package uploads
+ <sect id="upload-announce">Announcing package uploads
<p>
When a package is uploaded an announcement should be posted to one of
the ``debian-changes'' lists. The announcement should give the (source)
<package/ftp.debian.org/.
<p>
For more information about <em/override files/, see
-<manref name="dpkg-scanpackages" section="8">,
+<manref name="dpkg-scanpackages" section="8"/>,
<tt>/usr/doc/debian/bug-log-mailserver.txt</tt>, and
<tt>/usr/doc/debian/bug-maint-info.txt</tt>.
- <sect id="nmu">Interim releases
- <p>
+
+ <chapt id="nmu">Non-Maintainer Uploads (NMUs) and Porters
+
+ <p>
Under certain circumstances it is necessary for someone other than the
-usual package maintainer to make a release of a package. For example,
-a porter for another architecture may have to make some small changes
-to the source package and does not wish to wait with uploading their
-release until the main maintainer has incorporated the patch, or a
-serious security problem or bug may have come to light requiring
-immediate attention.
+usual package maintainer to make a release of a package. This is
+called a non-maintainer upload, or NMU.
+ <p>
+Debian porters, who compile packages for different architectures, do
+binary NMUs as part of their normal porting activity. Sometimes,
+Debian developers do NMUs in order to fix a serious security problem
+or a crippling bug, especially when the package maintainer is unable
+to release a fix in a timely fashion.
+ <p>
+This chapter contains information providing guidelines for when and
+how NMUs should be done.
+
+
+<sect id="nmu-who">Who can do an NMU
+ <p>
+Only an official Debian developers can do an NMU.
+<!-- TODO: link to section talking about how non-maintainers can still
+contribute -->
+
+<sect id="nmu-when">When to do an NMU
<p>
When a security bug is detected a fixed package should be uploaded as
soon as possible. In this case, the Debian Security Managers should
if he/she cannot be reached in time, the Security Manager may upload a
fixed package.
<p>
-When someone other than the usual maintainer releases a package they
-should add a new component to the <var/debian-revision/ component of
-the version number--that is, the portion after the (last) hyphen.
-This extra component will start at `1'. This is to avoid
-`stealing' one of the usual maintainer's version numbers, possibly
-disrupting their work. If there is no <var/debian-revision/ component
-in the version number then one should be created, starting at `1'.
+During the release freeze (see <ref id="upload-frozen">), NMUs which
+fix important or higher severity bugs are encouraged and accepted.
+Even during this window, however, you should endeavor to reach the
+current maintainer of the package; they might be just about to upload
+a fix for the problem.
<p>
+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'.
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/
switch to force the build system to pick up the new source package
(normally it only looks for Debian revisions of '0' or '1').
<p>
+<!--- HERE --->
Maintainers other than the usual package maintainer should make as few
changes to the package as possible, and they should always send a
unified context diff (<tt/diff -u/) detailing their changes to the bug
-tracking system properly flagged with the correct package so that the
+tracking system. properly flagged with the correct package so that the
usual maintainer is kept aware of the situation.
<p>
If the non-maintainer upload (as known as an ``NMU'') fixes some
in the changelog file documenting the non-maintainer upload.
- <sect>Maintainer changes
- <p>
-Periodically, a listing of packages in need of new maintainers will be
-sent to <email/debian-devel@lists.debian.org</email> list. This list
-is also available at in the Work-Needing and Prospective Packages
-document (WNPP), <url
-id="ftp://ftp.debian.org/debian/doc/package-developer/prospective-packages.html">
-and at <url id="http://www.debian.org/doc/prospective-packages.html">.
-If you wish to take over maintenance of any of the packages listed in
-the WNPP, or if you can no longer maintain a packages you have, or you
-simply want to know if any one is working on a new package, send a
-message to <email/wnpp@debian.org/.
-
- <p>
-If you take over an old package, you probably want to be listed as the
-package's official maintainer in the bug system. This will happen
-automatically once you upload a new version with an updated
-<tt/Maintainer:/ field. If you do not expect to upload a new version
-for a while, send an email to <email/override-change@debian.org/ so
-that bug reports will go to you.
-
-
-
- <chapt id="archive-manip">Moving, Removing, Renaming, and Orphaning Packages
+ <chapt id="archive-manip">Moving, Removing, Renaming, Adopting, and Orphaning Packages
<p>
Some archive manipulation operation are not automated in the Debian
upload process. This chapter gives guidelines in what to do in these
obsolete name.
+
<sect>Orphaning a package
<p>
If you can no longer maintain a package, then you should set the
maintainer.
+ <sect>Adopting a package
+ <p>
+Periodically, a listing of packages in need of new maintainers will be
+sent to <email/debian-devel@lists.debian.org</email> list. This list
+is also available at in the Work-Needing and Prospective Packages
+document (WNPP), <url
+id="ftp://ftp.debian.org/debian/doc/package-developer/prospective-packages.html">
+and at <url id="http://www.debian.org/doc/prospective-packages.html">.
+If you wish to take over maintenance of any of the packages listed in
+the WNPP, or if you can no longer maintain a packages you have, or you
+simply want to know if any one is working on a new package, send a
+message to <email/wnpp@debian.org/.
+
+ <p>
+If you take over an old package, you probably want to be listed as the
+package's official maintainer in the bug system. This will happen
+automatically once you upload a new version with an updated
+<tt/Maintainer:/ field. If you do not expect to upload a new version
+for a while, send an email to <email/override-change@debian.org/ so
+that bug reports will go to you.
+
+
+
+
<chapt id="bug-handling">Handling Bug Reports
<sect>Monitoring bugs
~ianmdlvl / developers-reference.git / commitdiff