<!entity % commondata SYSTEM "common.ent" > %commondata;
<!-- CVS revision of this document -->
- <!entity cvs-rev "$Revision: 1.123 $">
+ <!entity cvs-rev "$Revision: 1.124 $">
<!-- if you are translating this document, please notate the CVS
revision of the developers reference here -->
<!--
to make sure everything in this distribution is working properly, it is
sometimes literally unstable.
<p>
-The testing distribution is generated automatically by taking
+<ref id="testing"> is generated automatically by taking
packages from unstable if they satisfy certain criteria. Those
criteria should ensure a good quality for packages within testing.
-<ref id="testing-scripts"> are launched each day after the
+The update to testing is launched each day after the
new packages have been installed.
<p>
After a period of development, once the release manager deems fit, the
<em>testing</em> distribution is frozen, meaning that the policies
-which control how packages move from <em>unstable</em> to testing are
+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
easily upload a package in one of the delayed directories:
<example>DELAY=5 dupload --to delayed <changes-file></example>
- <sect id="testing-scripts">
- <heading>The testing scripts</heading>
+ <sect id="testing">
+ <heading>The "testing" distribution</heading>
<p>
-The testing scripts are run each day after the installation of the
+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 they do so in an intelligent manner
trying to avoid any inconsistency and trying to use only
id="&url-testing-maint;">. Alternatively, it is possible to use
the <prgn>grep-excuses</prgn> program part of the
<package>devscripts</package> package. It can be easily put in a crontab
-to keep someone informed of the progression of his packages in testing.
+to keep someone informed of the progression of his packages in <em>testing</em>.
<p>
The <file>update_excuses</file> file does not always give the precise reason
why the package is refused, one may have to find it on their own by looking
id="&url-testing-faq;" name="testing FAQ"> gives some more information
about the usual problems which may be causing such troubles.
<p>
-Sometimes, some packages never enter testing because the set of
+Sometimes, some packages never enter <em>testing</em> because the set of
inter-relationship is too complicated and can not be sorted out
by the scripts. In that case, the release manager must be
contacted, and he will force the inclusion of the packages.
libdbd-mysql-perl | 1.2219-1 | unstable | source, alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc
</example>
<p>
-In this example, you can see that the version in unstable differs from
-the version in testing and that there has been a binary-only NMU of the
+In this example, you can see that the version in <em>unstable</em> differs from
+the version in <em>testing</em> and that there has been a binary-only NMU of the
package for the alpha architecture. Each time the package has been
recompiled on most of the architectures.
<item>
In the future, you may receive regular summary mails to keep you
informed of the package's status (bug statistics, porting overview,
-progression in testing, ...).
+progression in <em>testing</em>, ...).
</taglist>
<p>
You can also decide to receive some more information: