fixed/updated/extended stuff about bugs. this should probably address the issue of...

git-svn-id: svn://anonscm.debian.org/ddp/manuals/trunk/developers-reference@1846 313b444b-1b9f-4f58-a734-7bb04f332e8d

diff --git a/common.ent b/common.ent
index d43ac1ecc9eabfbd0e15750ec43b17e7dd68026d..05427a3877f809162772c9e377400d6a0ae70818 100644 (file)
--- a/common.ent
+++ b/common.ent
@@ -52,7 +52,8 @@
 <!entity url-debian-lists-subscribe "http://&www-debian-org;/MailingLists/subscribe">
 <!entity url-lists-archives "http://&lists-host;/">
 <!entity url-bts "http://&www-debian-org;/Bugs/">
-<!entity url-bts-control "&url-bts;server-control.html">
+<!entity url-bts-devel "&url-bts;Developer">
+<!entity url-bts-control "&url-bts;server-control">
 <!entity url-debian-mirrors "http://&www-debian-org;/distrib/ftplist">
 <!entity url-debian-mirroring "http://&www-debian-org;/mirror/">
 <!entity url-debian-ports "http://&www-debian-org;/ports/">

diff --git a/developers-reference.sgml b/developers-reference.sgml
index e7a4eb2fd7b44e6dd1de746f345d5d5797948e43..a7251ba95e79ba971daaf67343a0afce7b9394d1 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.134 $">
+  <!entity cvs-rev "$Revision: 1.135 $">
   <!-- if you are translating this document, please notate the CVS
        revision of the developers reference here -->
   <!--
@@ -366,18 +366,23 @@ need, always try not to fork from the upstream sources.
 
       <sect id="rc-bugs">Managing release-critical bugs
         <p>
-Release-critical bugs (RCB) are all bugs that have severity
-<em>critical</em>, <em>grave</em> or <em>serious</em>.
+Generally you should deal with bug reports on your packages as described in
+<ref id="bug-handling">. However, there's a special category of bugs that
+you need to take care of -- the so-called release-critical bugs (RC bugs).
+All bug reports that have severity <em>critical</em>, <em>grave</em> or
+<em>serious</em> are considered to have an impact on whether the package can
+be released in the next stable release of Debian.
 Those bugs can delay the Debian release
 and/or can justify the removal of a package at freeze time. That's why
-these bugs need to be corrected as quickly as possible.  You must be
-aware that some developers who are part of the <url
-id="&url-debian-qa;" name="Debian Quality Assurance"> effort are
-following those bugs and try to help you whenever they are able. But if
-you can't fix such bugs within 2 weeks, you should either ask for help
+these bugs need to be corrected as quickly as possible.
+       <p>
+Developers who are part of the <url id="&url-debian-qa;"
+name="Quality Assurance"> group are following all such bugs, and trying
+to help whenever possible. If, for any reason, you aren't able fix an
+RC bug in a package of yours within 2 weeks, you should either ask for help
 by sending a mail to the Quality Assurance (QA) group
 &email-debian-qa;, or explain your difficulties and present a plan to fix
-them by sending a mail to the proper bug report. Otherwise, people
+them by sending a mail to the bug report. Otherwise, people
 from the QA group may want to do a Non-Maintainer Upload (see
 <ref id="nmu">) after trying to contact you (they might not wait as long as
 usual before they do their NMU if they have seen no recent activity from you
@@ -2526,6 +2531,12 @@ contact the submitter <em>and</em> to record your mail within the
 bug log (that means you don't need to send a copy of the mail to
 <email>123@bugs.debian.org</email>).
        <p>
+Once you've dealt with a bug report (e.g. fixed it), mark it as
+<em>done</em> (close it) by sending an explanation message to
+<email>123-done@bugs.debian.org</email>. If you're fixing a bug by
+changing and uploading the package, you can automate bug closing as
+described in <ref id="upload-bugfix">.
+       <p>
 You should <em>never</em> close bugs via the bug server <tt>close</tt>
 command sent to &email-bts-control;.  If you do so, the original
 submitter will not receive any information about why the bug was
@@ -2535,15 +2546,17 @@ closed.
        <p>
 As a package maintainer, you will often find bugs in other packages or
 have bugs reported against your packages which are actually bugs in
-other packages.  The <url id="&url-bts-control;" name="BTS
-instructions"> document the technical operations of the BTS, such as
-how to file, reassign, merge, and tag bugs.  This section contains
+other packages. The bug tracking system's features interesting to developers
+are described in the <url id="&url-bts-devel;" name="BTS documentation for
+Debian developers">. Operations such as reassigning, merging, and tagging
+bug reports are described in the <url id="&url-bts-control;" name="BTS
+control bot documentation">. This section contains
 some guidelines for managing your own bugs, based on the collective
 Debian developer experience.
         <p>
 Filing bugs for problems that  you find in other packages is one of
 the "civic obligations" of maintainership, see <ref id="submit-bug">
-for details. However handling the bugs on your own packages is
+for details. However, handling the bugs in your own packages is
 even more important.
         <p>
 Here's a list of steps that you may follow to handle a bug report:
@@ -2848,10 +2861,18 @@ The author prefers the <tt>closes: #<var>XXX</var></tt> syntax, as
 one of the most concise and easiest to integrate with the text of the
 <file>changelog</file>.
        <p>
-If you want to close bugs the old fashioned, manual way, it is usually
-sufficient to mail the <file>.changes</file> file to
+If you happen to mistype a bug number or forget one in the changelog file,
+don't hesitate to undo any damage the error caused. To reopen wrongly closed
+bugs, send an <tt>reopen <var>XXX</var></tt> command in the bug tracking
+system's control bot. To close any remaining bugs that were fixed by your
+upload, email the <file>.changes</file> file to
 <email>XXX-done@bugs.debian.org</email>, where <var>XXX</var> is your
 bug number.
+       <p>
+Bear in mind that it is not obligatory to close bugs using the changelog
+like described above -- if you simply want to close bugs that don't have
+anything to do with an upload of yours, do it simply by emailing an
+explanation to <email>XXX-done@bugs.debian.org</email>.
 
 
       <sect1 id="lintian-reports">Lintian reports