fix FTBFS

[developers-reference.git] / developers-reference.sgml

diff --git a/developers-reference.sgml b/developers-reference.sgml
index f792bccdd50ef0272a240bab660f980eca646811..94dda5c3513282613b7fc34f49953c2d57c0293c 100644 (file)
--- a/developers-reference.sgml
+++ b/developers-reference.sgml
@@ -6,7 +6,7 @@
   <!ENTITY % commondata  SYSTEM "common.ent" > %commondata;
 
   <!-- CVS revision of this document -->
-  <!ENTITY cvs-rev "$Revision: 1.248 $">
+  <!ENTITY cvs-rev "$Revision: 1.253 $">
 
   <!-- if you are translating this document, please notate the CVS
        revision of the original developer's reference in cvs-en-rev -->
@@ -692,7 +692,7 @@ aforementioned <tt>non-us.debian.org</tt>.
 Send mail to &email-debian-devel; if you have any questions.
 
       <sect1 id="servers-cvs">The CVS server
-<!-- TODO: document svn.debian.org also -->
+<!-- TODO: document svn.debian.org, arch.debian.org also -->
        <p>
 Our CVS server is located on <tt>cvs.debian.org</tt>.
        <p>
@@ -1206,7 +1206,8 @@ You can view the bugs of a given package at the URL
       <sect1 id="madison">The <prgn>madison</prgn> utility
         <p>
 <prgn>madison</prgn> is a command-line utility that is available
-on both <tt>&ftp-master-host;</tt> and <tt>&non-us-host;</tt>. It
+on both <tt>&ftp-master-host;</tt> and <tt>&non-us-host;</tt>, and on
+the mirror on <tt>&ftp-master-mirror;</tt>. It
 uses a single argument corresponding to a package name. In result
 it displays which version of the package is available for each
 architecture and distribution combination. An example will explain
@@ -2100,6 +2101,17 @@ We prefer the <tt>closes: #<var>XXX</var></tt> syntax, as it is the
 most concise entry and the easiest to integrate with the text of the
 <file>changelog</file>.
        <p>
+If an upload is identified as <qref id="nmu">Non-maintainer upload (NMU)</qref>
+(and that is the case if the name of the person who commits this change
+is not exactly the same as any one of Maintainer or Uploader,
+except if the maintainer is the qa group),
+than the bug is only tagged <tt>fixed</tt> instead of being closed.
+If a maintainer upload is targetted to experimental,
+than the tag <tt>fixed-in-experimental</tt> is added to the bug;
+for NMUs, the tag <tt>fixed</tt> is used.
+(The special rule for experimental is expected to change
+as soon as version-tracking is added to the bug tracking system.)
+       <p>
 If you happen to mistype a bug number or forget a bug in the changelog
 entries, don't hesitate to undo any damage the error caused. To reopen
 wrongly closed bugs, send an <tt>reopen <var>XXX</var></tt> command to
@@ -2825,7 +2837,7 @@ 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 technical speaking a binary NMU.
+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
@@ -3399,7 +3411,9 @@ Such bugs are presumed to have an impact on the chances that the package will be
 The unstable bug count are all release-critical bugs
 without either any release-tag (such as potato, woody) or with release-tag sid;
 also, only if they are neither fixed nor set to sarge-ignore.
-The "testing" bug count for a package is considered to be roughly the bug of unstable count at the last point when the "testing" version equalled the "unstable" version.
+The "testing" bug count for a package is considered to be roughly
+the bug count of unstable count at the last point
+when the "testing" version equalled the "unstable" version.
        <p>
 This will change post-sarge, as soon as we have versions in the bug tracking system.