X-Git-Url: http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?a=blobdiff_plain;f=developers-reference.sgml;h=6402964d2700c8b7e29ed94ec01c8603b0e583b0;hb=ff9d221294cb704230148c5e9b2084bbdea7f336;hp=e7a4eb2fd7b44e6dd1de746f345d5d5797948e43;hpb=c0019387ff81023dfee67f09bcb2f0f5106629a6;p=developers-reference.git

diff --git a/developers-reference.sgml b/developers-reference.sgml
index e7a4eb2..6402964 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.134 $">
+  <!entity cvs-rev "$Revision: 1.139 $">
   <!-- 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
@@ -1115,14 +1120,15 @@ if they respect themselves all the criteria);
 The scripts are generating some output files to explain why some packages
 are kept out of testing. They are available at <url
 id="&url-testing-maint;">. Alternatively, it is possible to use
-the <prgn>grep-excuses</prgn> program part of the
-<package>devscripts</package> package. It can be easily put in a crontab
+the <prgn>grep-excuses</prgn> program which is in the
+<package>devscripts</package> package. It can be easily put in a
+<manref name="crontab" section="5">
 to keep someone informed of the progression of his packages in <em>testing</em>.
 	<p>
 The <file>update_excuses</file> file does not always give the precise reason
 why the package is refused, one may have to find it on their own by looking
 what would break with the inclusion of the package. The <url
-id="&url-testing-faq;" name="testing FAQ"> gives some more information
+id="&url-testing-maint;" name="testing overview"> gives some more information
 about the usual problems which may be causing such troubles.
 	<p>
 Sometimes, some packages never enter <em>testing</em> because the set of
@@ -2526,6 +2532,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 +2547,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:
@@ -2634,13 +2648,18 @@ Useful information includes, for example:
 
 <list compact>
   <item>What versions of the package are known to be affected by the
-  bug.
-
-  <item>The nature of the exposure (root compromise, user compromise,
-  remote/local attack)
+  bug.  Check each version that is present in a supported Debian
+  release, as well as testing and unstable.
 
   <item>The nature of the fix, if any is available (patches are
   especially helpful)
+
+  <item>Any fixed packages that you have prepared yourself (send only
+  the <tt>.diff.gz</tt> and <tt>.dsc</tt> files)
+
+  <item>Any information needed for the advisory (see <ref
+  id="bug-security-advisories">)
+
 </list>
 
         <sect2 id="bug-security-confidentiality">Confidentiality
@@ -2715,6 +2734,9 @@ text. Information that should be in an advisory includes:
   <item>Version numbers of affected packages
   <item>Version numbers of fixed packages
   <item>Information on where to obtain the updated packages
+  <item>References to upstream advisories, <url
+  id="http://cve.mitre.org" name="CVE"> identifiers, and any other
+  information useful in cross-referencing the vulnerability
 </list>
 
          <sect2 id="bug-security-building">
@@ -2749,13 +2771,19 @@ changes.  If you have an exploit available, try it and see if it
 indeed succeeds on the unpatched package and fails on the fixed
 package.  Test other, normal actions as well, as sometimes a security
 fix can break seemingly unrelated features in subtle ways.
+<p>
+Review and test your changes as much as possible.  Check the
+differences from the previous version repeatedly
+(<prgn>interdiff</prgn> and <prgn>debdiff</prgn> are useful tools for
+this).
 
 When packaging the fix, keep the following points in mind:
 
 <list>
     <item>Make sure you target the right distribution in your
     <file>debian/changelog</file>. For stable this is <tt>stable-security</tt> and for
-    testing this is <tt>testing-security</tt>. Do not target
+    testing this is <tt>testing-security</tt>, and for the previous
+    stable release, this is <tt>oldstable-security</tt>. Do not target
     <var>distribution</var>-proposed-updates!
 
     <item>Make sure the version number is proper. It must be greater
@@ -2772,8 +2800,11 @@ When packaging the fix, keep the following points in mind:
     not build those. This point applies to normal package uploads as
     well.
 
-    <item>Always build with full source (use the <tt>-sa</tt> option
-    for <prgn>dpkg-buildpackage</prgn>).
+    <item>If the upstream source has been uploaded to
+    security.debian.org before (by a previous security update), build
+    the upload without the upstream source (<tt>dpkg-buildpackage
+    -sd</tt>).  Otherwise, build with full source
+    (<tt>dpkg-buildpackage -sa</tt>).
 
     <item>Be sure to use the exact same <file>*.orig.tar.gz</file> as used in the
     normal archive, otherwise it is not possible to move the security
@@ -2794,6 +2825,14 @@ prior authorization from the security team.  If the package does not
 exactly meet the team's requirements, it will cause many problems and
 delays in dealing with the unwanted upload.
 <p>
+<em>DO NOT</em> upload your fix to proposed-updates without
+coordinating with the security team.  Packages from
+security.debian.org will be copied into the proposed-updates directory
+automatically.  If a package with the same or a higher version number
+is already installed into the archive, the security update will be
+rejected by the archive system.  That way, the stable distribution
+will end up without a security update for this package instead.
+<p>
 Once you have created and tested the new package and it has been
 approved by the security team, it needs to be uploaded so that it can
 be installed in the archives. For security uploads, the place to
@@ -2825,10 +2864,11 @@ been accepted into the Debian archive.  Therefore, once you get
 notification that your updated package has been installed into the
 archive, you can and should close the bug in the BTS.
 	<p>
-If you are using a new version of <package>dpkg-dev</package> and you do
-your changelog entry properly, the archive maintenance software will close
-the bugs automatically.  All you have to do is follow a certain syntax in
-your <file>debian/changelog</file> file:
+However, it's possible to avoid having to manually close bugs after the
+upload -- just list the fixed bugs in your <file>debian/changelog</file>
+file, following a certain syntax, and the archive maintenance software
+will close the bugs for you. For example:
+
 <example>
 acme-cannon (3.1415) unstable; urgency=low
 
@@ -2848,10 +2888,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
@@ -3285,7 +3333,7 @@ the package meets minimum Debian standards.  That implies that you
 must build and test the package on your own system before uploading.
 	<p>
 You can not simply upload a binary <file>.deb</file> from the sponsoree. In
-theory, you should only ask only for the diff file and the location of the
+theory, you should only ask for the diff file and the location of the
 original source tarball, and then you should download the source and apply
 the diff yourself. In practice, you may want to use the source package
 built by your sponsoree. In that case, you have to check that they haven't