Document the existence of "hints" that release managers can use

Mention how they use hints to tweak the conditions of testing migration.
Drop some outdated/uninteresting information at the same time.

Closes: #679562
Based-on-patch-by: Paul Gevers <paul@climbing.nl>
git-svn-id: svn://anonscm.debian.org/ddp/manuals/trunk/developers-reference@9255 313b444b-1b9f-4f58-a734-7bb04f332e8d

diff --git a/debian/changelog b/debian/changelog
index 7c16abdadfb27a5edea6f2970c9d80fd75bbfb21..4b0ee6ce0e71d5cbf51d0ca15e12a9c1096f0121 100644 (file)
--- a/debian/changelog
+++ b/debian/changelog
@@ -7,8 +7,11 @@ developers-reference (3.4.9) UNRELEASED; urgency=low
     Thanks to Per Andersson and Steve Langasek for the patch.
   * Recommend usage of gender-neutral formulations in README-contrib.
   * Fix Vcs-Browser URL. Thanks to Charles Plessy who spotted it.
+  * Document the existence of "hints" that release managers can
+    use to tweak the conditions of testing migration. Closes: #679562
+    Thanks to Paul Gevers <paul@climbing.nl> for the patch.
 
-  * Translation updates (complete)
+  [ Translation updates ]
     - Japanese by Hideki Yamane.
     - French by David Prévot.
 

diff --git a/pkgs.dbk b/pkgs.dbk
index 3ce0bee233e232f7cf885803f653de9916e43363..88bb6d807340e27ca7079d619c11977bbade4870 100644 (file)
--- a/pkgs.dbk
+++ b/pkgs.dbk
@@ -2386,9 +2386,7 @@ the following:
 The package must have been available in <literal>unstable</literal> for 2, 5
 or 10 days, depending on the urgency (high, medium or low).  Please note that
 the urgency is sticky, meaning that the highest urgency uploaded since the
-previous <literal>testing</literal> transition is taken into account.  Those
-delays may be doubled during a freeze, or <literal>testing</literal>
-transitions may be switched off altogether;
+previous <literal>testing</literal> transition is taken into account;
 </para>
 </listitem>
 <listitem>
@@ -2416,7 +2414,13 @@ It must not break any dependency of a package which is already available in
 The packages on which it depends must either be available in
 <literal>testing</literal> or they must be accepted into
 <literal>testing</literal> at the same time (and they will be if they fulfill
-all the necessary criteria).
+all the necessary criteria);
+</para>
+</listitem>
+<listitem>
+<para>
+The phase of the project.  I.e. automatic transitions are turned off during
+the <emphasis>freeze</emphasis> of the <literal>testing</literal> distribution.
 </para>
 </listitem>
 </itemizedlist>
@@ -2628,10 +2632,8 @@ If you are interested in details, this is how britney works:
 The packages are looked at to determine whether they are valid candidates.
 This gives the update excuses.  The most common reasons why a package is not
 considered are too young, RC-bugginess, and out of date on some arches.  For
-this part of britney, the release managers have hammers of various sizes to
-force britney to consider a package.  (Also, the base freeze is coded in that
-part of britney.) (There is a similar thing for binary-only updates, but this
-is not described here.  If you're interested in that, please peruse the code.)
+this part of britney, the release managers have hammers of various sizes,
+called hints (see below), to force britney to consider a package.
 </para>
 <para>
 Now, the more complex part happens: Britney tries to update <literal>testing</literal>
@@ -2649,7 +2651,13 @@ url="http://&ftp-master-host;/testing/update_output/"></ulink>.
 </para>
 <para>
 The hints are available via <ulink
-url="http://&ftp-master-host;/testing/hints/"></ulink>.
+url="http://&ftp-master-host;/testing/hints/"></ulink>, where you can find
+the
+<ulink url="http://&ftp-master-host;/testing/hints/README">description</ulink>
+as well.  With the hints, the Debian Release team can block or unblock
+packages, ease or force packages into <literal>testing</literal>, remove
+packages from <literal>testing</literal>, approve uploads to
+<xref linkend="t-p-u">testing-proposed-updates</link> or override the urgency.
 </para>
 </section>