<!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 -->
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>
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
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
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.