+ <sect id="testing-scripts">
+ <heading>The testing scripts</heading>
+ <p>
+The testing scripts 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
+non-buggy packages.
+ <p>The inclusion of a package from <em>unstable</em> is conditionned:
+<list>
+ <item>
+The package must have been available in <em>unstable</em> for several days;
+the precise number depends on the urgency field's value of the upload. It
+is 10 days for low urgency, 5 days for medium urgency and 2 days for high
+urgency. Those delays may be doubled during a freeze;
+ <item>
+It must have less release-critical bugs than the version available
+in <em>testing</em>;
+ <item>
+It must be available on all architectures on which it has been
+previously built. <ref id="madison"> may be of interest to
+check that information;
+ <item>
+It must not break any dependency of a package that is already available
+in <em>testing</em>;
+ <item>
+The packages on which it depends must either be available in <em>testing</em>
+or they must be accepted into <em>testing</em> at the same time (and they will
+if they respect themselves all the criteria);
+</list>
+ <p>
+The scripts are generating some output files to explain why some packages
+are kept out of testing. They are available at <url
+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.
+ <p>
+The <tt>update_excuses</tt> file does not always give the precise reason
+why the package is refused, one may have to find it by himself by looking
+what would break with the inclusion of the package. The <url
+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
+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.
+
+ <sect id="pkg-info">Package's information
+ <p>
+
+ <sect1 id="pkg-info-web">On the web
+ <p>
+Each package has several dedicated web pages that contains many
+informations. First <tt>http://&packages-host;/<package></tt>
+will let you discover a presentation of each version of the package
+available in the various distributions. It includes its description,
+the dependencies and some links to download the package.
+ <p>
+The bug tracking system sorts the bugs by package, you can
+watch the bugs of each package at
+<tt>http://&bugs-host;/<package></tt>.
+
+ <sect1 id="madison">The madison utility
+ <p>
+<prgn>madison</prgn> is a command-line utility that is available
+on both <tt>&ftp-master-host;</tt> and <tt>&non-us-host;</tt>. It
+uses a single argument corresponding to a package name. In result
+it displays which version of the package is available for each
+architecture and distribution combination. An example will explain
+it better.
+ <p>
+<example>
+$ madison libdbd-mysql-perl
+libdbd-mysql-perl | 1.2202-4 | stable | source, alpha, arm, i386, m68k, powerpc, sparc
+libdbd-mysql-perl | 1.2216-2 | testing | source, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc
+libdbd-mysql-perl | 1.2216-2.0.1 | testing | alpha
+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
+package for the alpha architecture. Each time the package has been
+recompiled on most of the architectures.
+
+ <sect id="pkg-tracking-system">The Package Tracking System
+ <p>
+The Package Tracking System (PTS) is basically a tool to track by mail
+the activity of a source package. You just have to subscribe
+to a source package to start getting the mails related to it.
+You get the same mails than the maintainer. Each mail
+sent through the PTS is classified and associated to one of
+the keyword listed below. This will let you select the mails that
+you want to receive.
+ <p>
+By default you will get :
+<taglist>
+ <tag><tt>bts</tt>
+ <item>
+All the bug reports and following discussions.
+
+ <tag><tt>bts-control</tt>
+ <item>
+The control mails notifying a status change in one of the bugs.
+
+ <tag><tt>upload-source</tt>
+ <item>
+The confirmation mail from <prgn>katie</prgn> when an uploaded source
+package is accepted.
+
+ <tag><tt>katie-other</tt>
+ <item>
+Other warning and error mails from <prgn>katie</prgn> (like the
+override disparity for the section or priority field).
+
+ <tag><tt>default</tt>
+ <item>
+Any non-automatic mail sent to the PTS by people who wanted to
+contact the subscribers of the package.
+
+ <tag><tt>summary</tt>
+ <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, ...).
+</taglist>
+ <p>
+You can also decide to receive some more information :
+<taglist>
+ <tag><tt>upload-binary</tt>
+ <item>
+The confirmation mail from <prgn>katie</prgn> when an uploaded binary
+package is accepted (to check that your package is recompiled for all
+architectures).
+
+ <tag><tt>cvs</tt>
+ <item>
+CVS commits if the maintainer has setup a system to forward commit
+notification to the PTS.
+</taglist>
+
+ <sect1 id="pts-commands">The PTS email interface
+ <p>
+You can control your subscription(s) to the PTS by sending
+various commands to <email>pts@qa.debian.org</email>.
+
+<taglist>
+
+<tag><tt>subscribe <srcpackage> [<email>]</tt>
+<item>
+ Subscribes <var>email</var> to communications related to the source package
+ <var>srcpackage</var>. Sender address is used if the second argument is
+ not present. If <var>srcpackage</var> is not a valid source package,
+ you'll get a warning. However if it's a valid binary package, the PTS
+ will subscribe you to the corresponding source package.
+
+<tag><tt>unsubscribe <srcpackage> [<email>]</tt>
+<item>
+ Removes a previous subscription to the source package <var>srcpackage</var>
+ using the specified email address or the sender address if the second
+ argument is left out.
+
+<tag><tt>which [<email>]</tt>
+<item>
+ Lists all subscriptions for the sender or the email address optionally
+ specified.
+
+<tag><tt>keyword [<email>]</tt>
+<item>
+ Tells you the keywords that you are accepting. Each mail sent through
+ the Package Tracking System is associated to a keyword and you receive
+ only the mails associated to keywords that you are accepting. Here is
+ the list of available keywords :
+ <list>
+ <item><tt>bts</tt> : mails coming from the Debian Bug Tracking System
+ <item><tt>bts-control</tt> : reply to mails sent to
+ <email>control@bugs.debian.org</email>
+ <item><tt>summary</tt> : automatic summary mails about the state of a package
+ <item><tt>cvs</tt> : notification of cvs commits
+ <item><tt>upload-source</tt> : announce of a new source upload that
+ has been accepted
+ <item><tt>upload-binary</tt> : announce of a new binary-only upload (porting)
+ <item><tt>katie-other</tt> : other mails from ftpmasters
+ (override disparity, etc.)
+ <item><tt>default</tt> : all the other mails (those which aren't "automatic")
+ </list>
+
+<tag><tt>keyword <srcpackage> [<email>]</tt>
+<item>
+ Same as previous item but for the given source package since
+ you may select a different set of keywords for each source package.
+
+<tag><tt>keyword [<email>] {+|-|=} <list of keywords></tt>
+<item>
+ Accept (+) or refuse (-) mails associated to the given keyword(s).
+ Define the list (=) of accepted keywords.
+
+<tag><tt>keyword <srcpackage> [<email>] {+|-|=} <list of keywords></tt>
+<item>
+ Same as previous item but overrides the keywords list for the
+ indicated source package.
+
+<tag><tt>quit | thanks | --</tt>
+<item>
+ Stops processing commands. All following lines are ignored by
+ the bot.
+</taglist>
+
+ <sect1 id="pts-mail-filtering">Filtering PTS mails
+ <p>
+Once you are subscribed to a package, you will get the mails sent to
+<tt><var>srcpackage</var>@packages.qa.debian.org</tt>. Those mails
+have special headers appended to let you filter them in a special
+mailbox with <prgn>procmail</prgn>. The added headers are
+<tt>X-Loop</tt>, <tt>X-PTS-Package</tt>, <tt>X-PTS-Keyword</tt> and
+<tt>X-Unsubscribe</tt>.
+ <p>
+Here is an example of added headers for a source upload notification
+on the <package>dpkg</package> package :
+<example>
+X-Loop: dpkg@&pts-host;
+X-PTS-Package: dpkg
+X-PTS-Keyword: upload-source
+X-Unsubscribe: echo 'unsubscribe dpkg' | mail pts@qa.debian.org
+</example>
+
+ <sect1 id="pts-cvs-commit">Forwarding CVS commits in the PTS
+ <p>
+If you use a publically accessible CVS repository for maintaining
+your Debian package you may want to forward the commit notification
+to the PTS so that the subscribers (possible co-maintainers) can
+closely follow the package's evolution.
+ <p>
+It's very easy to setup. Once your cvs repository generates commit
+notifications, you just have to make sure it sends a copy of those mails
+to <tt><var>srcpackage</var>_cvs@&pts-host;</tt>. Only people who
+accepts the <em>cvs</em> keyword will receive the notifications.
+
+
+ <chapt id="pkgs">Managing Packages
+ <p>
+This chapter contains information related to creating, uploading,
+maintaining, and porting packages.