On 02-07-12 02:52, Charles Plessy wrote:
> I just read through the section 5.13 again ("The testing distribution"). I
> see
> that details about britney are given in 5.13.2.5.I agree that this is a better place. > Also, it would not be completely > consistent to describe in 5.13.2 how to use the hints to override the default > time needed for a transition, but to not describe the other hints related with > the other bullet points. I have changed the description such that it states the other possibilities as well. > Lastly, I do not remember having seen migration delays doubling during a > freeze > since I am DD, so I think that this sentence is misleading in the sense that > there is nothing special about double delays, and would be better removed by > your patch. Although now this change could have it's own patch (as the original issue is in a different part of the text), I have taken the liberty to include something in this patch as well. I moved the statement about the freeze to a separate condition for the migration, which I think hi-lights better that in the current situation the migration is not automatic during a freeze. Please let me know if a separate patch is more appropriate. Paul
Index: pkgs.dbk =================================================================== --- pkgs.dbk (revision 9236) +++ pkgs.dbk (working copy) @@ -2386,9 +2386,7 @@ 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> @@ -2419,6 +2417,12 @@ all the necessary criteria). </para> </listitem> +<listitem> +<para> +The phase of the project. I.e. automatic transitions are turned off during +the <literal>freeze</literal> of the <literal>testing</literal> distribution; +</para> +</listitem> </itemizedlist> <para> To find out whether a package is progressing into <literal>testing</literal> @@ -2628,10 +2632,11 @@ 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. (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.) </para> <para> Now, the more complex part happens: Britney tries to update <literal>testing</literal> @@ -2649,7 +2654,13 @@ </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 +<link linkend="t-p-u">testing-proposed-updates</link> or override the urgency. </para> </section>
signature.asc
Description: OpenPGP digital signature
