adjust information about distributions with reality

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

diff --git a/developers-reference.sgml b/developers-reference.sgml
index e53978ee45927464b5c4f535d2d0b344a9643ccb..95f5bc35f33b2e9689aa592fdbde4b46a412ac26 100644 (file)
--- a/developers-reference.sgml
+++ b/developers-reference.sgml
@@ -7,7 +7,7 @@
   <!ENTITY % dynamicdata  SYSTEM "dynamic.ent" > %dynamicdata;
 
   <!-- CVS revision of this document -->
-  <!ENTITY cvs-rev "$Revision: 1.260 $">
+  <!ENTITY cvs-rev "$Revision: 1.264 $">
 
   <!-- if you are translating this document, please notate the CVS
        revision of the original developer's reference in cvs-en-rev -->
@@ -969,14 +969,17 @@ which control how packages move from <em>unstable</em> to <em>testing</em> are
 tightened.  Packages which are too buggy are removed.  No changes are
 allowed into <em>testing</em> except for bug fixes.  After some time
 has elapsed, depending on progress, the <em>testing</em> distribution
-goes into a `deep freeze', when no changes are made to it except those
-needed for the installation system.  This is called a &ldquo;test cycle&rdquo;,
-and it can last up to two weeks. There can be several test cycles,
-until the distribution is prepared for release, as decided by the
-release manager.  At the end of the last test cycle, the
-<em>testing</em> distribution is renamed to <em>stable</em>,
-overriding the old <em>stable</em> distribution, which is removed at
-that time (although it can be found at <tt>&archive-host;</tt>).
+is frozen even further.
+Details of the handling of the testing distribution are published
+by the Release Team on debian-devel-announce.
+After the open issues are solved to the satisfaction of the Release Team,
+the distribution is released.
+Releasing means
+that <em>testing</em> is renamed to <em>stable</em>,
+and a new copy is created for the new <em>testing</em>,
+and the previous <em>stable</em> is renamed to <em>oldstable</em>
+and stays there until it is finally archived.
+On archiving, the contents are moved to <tt>&archive-host;</tt>).
        <p>
 This development cycle is based on the assumption that the
 <em>unstable</em> distribution becomes <em>stable</em> after passing a
@@ -992,6 +995,9 @@ batch into the stable distribution and the revision level of the
 stable distribution is incremented (e.g., &lsquo;3.0&rsquo; becomes
 &lsquo;3.0r1&rsquo;, &lsquo;2.2r4&rsquo; becomes &lsquo;2.2r5&rsquo;, and
 so forth).
+Please refer to
+<qref="upload-stable">uploads to the <em>stable</em> distribution</qref>
+for details.
        <p>
 Note that development under <em>unstable</em> continues during the
 freeze period, since the <em>unstable</em> distribution remains in
@@ -1506,7 +1512,7 @@ everything here:
 </example>
        <p>
 Think twice before adding a news item to the PTS because you won't be able
-to remove it later and you wan't be able to edit it either. The only thing
+to remove it later and you won't be able to edit it either. The only thing
 that you can do is send a second news item that will deprecate the
 information contained in the previous one.
 
@@ -2069,6 +2075,9 @@ If the bug is real but it's caused by another package, just reassign
 the bug to the right package. If you don't know which package it should
 be reassigned to, you should ask for help on
 <qref id="irc-channels">IRC</qref> or on &email-debian-devel;.
+Please make sure that the maintainer(s) of the package
+the bug is reassigned to
+know why you reassigned it.
     <p>
 Sometimes you also have to adjust the severity of the bug so that it
 matches our definition of the severity. That's because people tend to
@@ -3095,7 +3104,7 @@ to apply the patch that has been sent to you. Once this is done, you
 have to close the bugs that have been tagged fixed by the NMU. The easiest
 way is to use the <tt>-v</tt> option of <prgn>dpkg-buildpackage</prgn>,
 as this allows you to include just all changes since your last maintainer
-upload. Alternativly, you
+upload. Alternatively, you
 can close them manually by sending the required mails to the
 BTS or by adding the required <tt>closes: #nnnn</tt> in the changelog
 entry of your next upload.
@@ -3238,7 +3247,9 @@ Please see below for details.
        <heading>Updates from unstable</heading>
        <p>
 The scripts that update the <em>testing</em> distribution are run each
-day after the installation of the updated packages. They generate the
+day after the installation of the updated packages;
+these scripts are called <em>britney</em>.
+They generate the
 <file>Packages</file> files for the <em>testing</em> distribution, but
 they do so in an intelligent manner; they try to avoid any inconsistency
 and to use only non-buggy packages.
@@ -4134,7 +4145,7 @@ Just give facts.
        <sect2>Do not use first person
        <p>
 You should avoid the use of first person ("I will do this..." or "We
-recommend..."). The computer is not a person and the Debconf tempaltes
+recommend..."). The computer is not a person and the Debconf templates
 do not speak for the Debian developers. You should use neutral
 construction and often the passive form. Those of you who already
 wrote scientific publications, just write your templates like you