- Don't upload security updates directly to stable

[developers-reference.git] / developers-reference.sgml

diff --git a/developers-reference.sgml b/developers-reference.sgml
index 6b2e7a8ab98a051245becb0bd7049b8b1e536d01..4d4a87b75faa281d0ef999e7fa970dc27b8c4e23 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.214 $">
+  <!ENTITY cvs-rev "$Revision: 1.217 $">
   <!-- if you are translating this document, please notate the CVS
        revision of the developers reference here -->
   <!--
@@ -1961,8 +1961,8 @@ reorder them, and how to process and close them.
        <p>
 The bug tracking system's features interesting to developers are described
 in the <url id="&url-bts-devel;" name="BTS documentation for developers">.
-This includes closing bugs, sending followup messages, assigning severities,
-tags, marking bugs as forwarded and other issues.
+This includes closing bugs, sending followup messages, assigning severities
+and tags, marking bugs as forwarded and other issues.
        <p>
 Operations such as reassigning bugs to other packages, merging separate
 bug reports about the same issue, or reopening bugs when they are
@@ -2328,17 +2328,24 @@ When packaging the fix, keep the following points in mind:
     <file>debian/changelog</file>. For stable this is <tt>stable-security</tt> and for
     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!
+    <var>distribution</var>-proposed-updates or <tt>stable</tt>!
 
     <item>Make descriptive, meaningful changelog entries.  Others will
     rely on them to determine whether a particular bug was fixed.
-    Whenever possible, include an external reference, preferably a CVE
-    identifier, so that it can be cross-referenced.
+    Always include an external reference, preferably a CVE
+    identifier, so that it can be cross-referenced.  Include the same
+    information in the changelog for unstable, so that it is clear that
+    the same bug was fixed, as this is very helpful when verifying
+    that the bug is fixed in the next stable release.  If a CVE
+    identifier has not yet been assigned, the security team will
+    request one so that it can be included in the package and in the advisory.
 
     <item>Make sure the version number is proper. It must be greater
     than the current package, but less than package versions in later
     distributions.  If in doubt, test it with <tt>dpkg
-    --compare-versions</tt>.  For <em>testing</em>, there must be
+    --compare-versions</tt>.  Be careful not to re-use a version
+    number that you have already used for a previous upload.  For
+    <em>testing</em>, there must be
     a higher version in <em>unstable</em>. If there is none yet (for example,
     if <em>testing</em> and <em>unstable</em> have the same version) you must upload a
     new version to unstable first.
@@ -3330,9 +3337,9 @@ or, if the package name itself is a plural (such as
 
 <example><var>package-name</var> are <var>synopsis</var>.</example>
 
-This way of forming a sentance from the package name and synopsis
+This way of forming a sentence from the package name and synopsis
 should be considered as a heuristic and not a strict rule.  There are
-some cases where it doesn't make sense to try to form a sentance.
+some cases where it doesn't make sense to try to form a sentence.
         </sect1>
 
        <sect1 id="bpp-pkg-desc">