X-Git-Url: http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?p=developers-reference.git;a=blobdiff_plain;f=developers-reference.sgml;h=f792bccdd50ef0272a240bab660f980eca646811;hp=a08ed3bf5517a2306e65b7c98f53ce4d236d84fc;hb=0108f286a50871243923c0a231222cecf05f7553;hpb=da69deb12a47c0b55cb0f2b18fcfd5f52323a410

diff --git a/developers-reference.sgml b/developers-reference.sgml
index a08ed3b..f792bcc 100644
--- 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.247 $">
+  <!ENTITY cvs-rev "$Revision: 1.248 $">
 
   <!-- if you are translating this document, please notate the CVS
        revision of the original developer's reference in cvs-en-rev -->
@@ -2824,8 +2824,9 @@ called a non-maintainer upload, or NMU.
 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">.
-For buildd uploads (which are strictly speaking also NMUs), please see <ref
-id="buildd">.
+If a buildd builds and uploads a package,
+that too is strictly technical 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
@@ -3349,9 +3350,8 @@ upload to <em>testing-proposed-updates</em>.
 Keep in mind that packages uploaded there are not automatically processed, they
 have to go through the hands of the release manager. So you'd better have a good
 reason to upload there. In order to know what a good reason is in the
-release manager's eyes, you should read the instructions that he regularly
-gives on &email-debian-devel-announce;.
-<!-- FIXME: gender-specific; fix when RM is female at the very latest -->
+release managers' eyes, you should read the instructions that they regularly
+give on &email-debian-devel-announce;.
 	  <p>
 You should not upload to <em>testing-proposed-updates</em> when you can update your
 packages through <em>unstable</em>. If you can't (for example because you have a
@@ -3396,7 +3396,12 @@ All bugs of some higher severities are by default considered release-critical; c
 	  <p>
 Such bugs are presumed to have an impact on the chances that the package will be released with the stable release of Debian: in general, if a package has open release-critical bugs filed on it, it won't get into "testing", and consequently won't be released in "stable".
 	  <p>
-The "testing" bug count for a package is considered to be roughly the bug count at the last point when the "testing" version equalled the "unstable" version. The bugs tagged woody or sarge will not be counted. Bugs with the sid tag will be counted, though.
+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.
+	<p>
+This will change post-sarge, as soon as we have versions in the bug tracking system.
 
 
 	<sect2>
@@ -3681,8 +3686,11 @@ used instead, it should be here as well.
 	<item>
 How is this package different from the competition? Is it a better
 implementation? more features? different features? Why should I
-choose this package (the second questions is about the class of packages, and
+choose this package.
+<!-- FIXME: what's this?
+(the second questions is about the class of packages, and
 this about this particular package, if you have information related to both).
+-->
 	</list>
 
         </sect1>