chiark / gitweb /
bugs status and NMUs/experimental
[developers-reference.git] / developers-reference.sgml
index f792bccdd50ef0272a240bab660f980eca646811..9bc69d811d8b6a14cbbf9f384d56ab98d1594c25 100644 (file)
@@ -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.251 $">
 
   <!-- 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>
@@ -2100,6 +2100,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 <ref id="nmu" name="Non-maintainer upload (NMU)">
+(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 +2836,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 +3410,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.