Update several bits about release management/testing transitions.

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

diff --git a/debian/changelog b/debian/changelog
index fa8d821c802e777c07072888f18c716e5a3ae117..fb6a3b3dc75aacffeba12bc2a8863f6f920f37af 100644 (file)
--- a/debian/changelog
+++ b/debian/changelog
@@ -21,6 +21,7 @@ developers-reference (3.4.0) UNRELEASED; urgency=low
     doesn't exist anymore.
   * Fix several typesetting errors and typos noticed by Sandro Tosi,
     thanks for the notes! Closes: #483223
     doesn't exist anymore.
   * Fix several typesetting errors and typos noticed by Sandro Tosi,
     thanks for the notes! Closes: #483223

+  * Update several bits about release management/testing transitions.

 
  -- Marc 'HE' Brockschmidt <he@debian.org>  Sun, 01 Jun 2008 16:26:33 +0200
 
 
  -- Marc 'HE' Brockschmidt <he@debian.org>  Sun, 01 Jun 2008 16:26:33 +0200
 

diff --git a/pkgs.dbk b/pkgs.dbk
index 1f35c35c7d058731e412b3199290d5aa8d1ddb08..5494ef6c80e8649b98e4a8eb20e3f5405b14800b 100644 (file)
--- a/pkgs.dbk
+++ b/pkgs.dbk
@@ -2193,8 +2193,8 @@ being a release candidate.  Please see below for details.
 <title>Updates from unstable</title>
 <para>
 The scripts that update the <literal>testing</literal> distribution are run
 <title>Updates from unstable</title>
 <para>
 The scripts that update the <literal>testing</literal> distribution are run

-each day after the installation of the updated packages; these scripts are
-called <literal>britney</literal>.  They generate the
+twice each day, right after the installation of the updated packages; these
+scripts are called <literal>britney</literal>.  They generate the

 <filename>Packages</filename> files for the <literal>testing</literal>
 distribution, but they do so in an intelligent manner; they try to avoid any
 inconsistency and to use only non-buggy packages.
 <filename>Packages</filename> files for the <literal>testing</literal>
 distribution, but they do so in an intelligent manner; they try to avoid any
 inconsistency and to use only non-buggy packages.


@@ -2268,7 +2268,7 @@ scripts.  See below for details.
 </para>
 <para>
 Some further dependency analysis is shown on <ulink
 </para>
 <para>
 Some further dependency analysis is shown on <ulink

-url="http://bjorn.haxx.se/debian/"></ulink> — but be warned, this page also
+url="http://release.debian.org/migration/"></ulink> — but be warned, this page also

 shows build dependencies which are not considered by britney.
 </para>
 <section id="outdated">
 shows build dependencies which are not considered by britney.
 </para>
 <section id="outdated">


@@ -2458,11 +2458,13 @@ is not described here.  If you're interested in that, please peruse the code.)
 </para>
 <para>
 Now, the more complex part happens: Britney tries to update <literal>testing
 </para>
 <para>
 Now, the more complex part happens: Britney tries to update <literal>testing

-</literal> with the valid candidates; first, each package alone, and then 
-larger and even larger sets of packages together.  Each try is accepted if 
-<literal>testing</literal> is not more uninstallable after the update than
-before.  (Before and after this part, some hints are processed; but as only
-release masters can hint, this is probably not so important for you.)
+</literal> with the valid candidates. For that, britney tries to add each
+valid candidate to the testing distribution. If the number of uninstallable
+packages in <literal>testing</literal> doesn't increase, the package is
+accepted. From that point on, the accepted package is considered to be part
+of <literal>testing</literal>, such that all subsequent installability
+tests include this package.  Hints from the release team are processed
+before or after this main run, depending on the exact type.

 </para>
 <para>
 If you want to see more details, you can look it up on
 </para>
 <para>
 If you want to see more details, you can look it up on


@@ -2566,7 +2568,8 @@ at &email-debian-release; and ask them to approve your upload.
 <title>What are release-critical bugs, and how do they get counted?</title>
 <para>
 All bugs of some higher severities are by default considered release-critical;
 <title>What are release-critical bugs, and how do they get counted?</title>
 <para>
 All bugs of some higher severities are by default considered release-critical;

-currently, these are critical, grave, and serious bugs.
+currently, these are <literal>critical</literal>, <literal>grave</literal> and
+<literal>serious</literal> bugs.

 </para>
 <para>
 Such bugs are presumed to have an impact on the chances that the package will
 </para>
 <para>
 Such bugs are presumed to have an impact on the chances that the package will


@@ -2576,16 +2579,10 @@ if a package has open release-critical bugs filed on it, it won't get into
 stable</literal>.
 </para>
 <para>
 stable</literal>.
 </para>
 <para>

-The <literal>unstable</literal> 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 <literal>testing
-</literal> bug count for a package is considered to be roughly the bug count of
-<literal>unstable</literal> count at the last point when the <literal>testing
-</literal>version equalled the <literal>unstable</literal> version.
-</para>
-<para>
-This will change post-sarge, as soon as we have versions in the bug tracking
-system.
+The <literal>unstable</literal> bug count are all release-critical bugs which
+are marked to apply to <replaceable>package</replaceable>/<replaceable>version
+</replaceable> combinations that are available in unstable for a release
+architecture. The <literal>testing</literal> bug count is defined analogously.

 </para>
 </section>
 
 </para>
 </section>