<!ENTITY % commondata SYSTEM "common.ent" > %commondata;
<!-- CVS revision of this document -->
- <!ENTITY cvs-rev "$Revision: 1.236 $">
+ <!ENTITY cvs-rev "$Revision: 1.239 $">
<!-- if you are translating this document, please notate the CVS
revision of the original developer's reference in cvs-en-rev -->
Please see below for details.
<sect1 id="testing-unstable">
<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
<file>Packages</file> files for the <em>testing</em> distribution, but
<p>
Consider this example:
<p>
- <tt>
- foo | alpha | arm
+ <example>
+foo | alpha | arm
---------+-------+----
testing | 1 | -
unstable | 1 | 2
-</tt>
+</example>
<p>
The package is out of date on alpha in unstable, and will not go to
testing. And removing foo from testing would not help at all, the package
<p>
However, if ftp-master removes a package in unstable (here on arm):
<p>
- <tt>
+ <example>
foo | alpha | arm | hurd-i386
---------+-------+-----+----------
testing | 1 | 1 | -
unstable | 2 | - | 1
- </tt>
+ </example>
<p>
In this case, the package is up to date on all release architectures in
unstable (and the extra hurd-i386 doesn't matter, as it's not a release
<p>
<sect2 id="rc">
- <heading>What are release-critical bugs, and how do they get counted?</headin>
+ <heading>What are release-critical bugs, and how do they get counted?</heading>
<p>
All bugs of some higher severities are by default considered release-critical; currently, these are critical, grave and serious bugs.
<p>