+real distribution directories use the <em>code names</em>, while
+symbolic links for <em>stable</em>, <em>testing</em>, and
+<em>unstable</em> point to the appropriate release directories.
+
+
+ <sect id="mirrors">Debian mirrors
+ <p>
+The various download archives and the web site have several mirrors
+available in order to relieve our canonical servers from heavy load.
+In fact, some of the canonical servers aren't public, and instead a
+first tier of mirrors balances the load. That way, users always access
+the mirrors and get used to using them, which allows Debian to better
+spread its bandwidth requirements over several servers and networks,
+and basically makes users avoid hammering on one primary location.
+Note that the first tier of mirrors is as up-to-date as it can be since
+they update when triggered from the internal sites (we call this
+"push mirroring").
+ <p>
+All the information on Debian mirrors, including a list of the available
+public FTP/HTTP servers, can be found at <url id="&url-debian-mirrors;">.
+This useful page also includes information and tools which can be helpful if
+you are interested in setting up your own mirror, either for internal or
+public access.
+ <p>
+Note that mirrors are generally run by third-parties who are
+interested in helping Debian. As such, developers generally do not
+have accounts on these machines.
+
+
+ <sect id="incoming-system">
+ <heading>The Incoming system
+ <p>
+The Incoming system is responsible of collecting updated packages and
+installing them in the Debian archive. It consists of a set of
+directories and scripts that are installed both on <tt>&ftp-master-host;</tt>
+and <tt>&non-us-host;</tt>.
+ <p>
+Packages are uploaded by all the maintainers into a directory called
+<file>unchecked</file>. This directory is scanned every 15 minutes by
+the <prgn>katie</prgn> script, which verifies the integrity of the uploaded packages and the cryptographic
+signatures. If the package is considered ready to be installed, it
+is moved into the <file>accepted</file> directory. If this is the first upload of
+the package, it is moved in the <file>new</file> directory, where it waits
+for an approval of the ftpmasters. If the package contains files to be installed
+"by-hand" it is moved in the <file>byhand</file> directory, where it waits
+for a manual installation by the ftpmasters. Otherwise, if any error has been detected,
+the package is refused and is moved in the <file>reject</file> directory.
+ <p>
+Once the package is accepted the system sends a confirmation
+mail to the maintainer, closes all the bugs marked as fixed by the upload
+and the auto-builders may start recompiling it. The package is now publicly
+accessible at <url id="&url-incoming;"> (there is no
+such URL for packages in the non-US archive) until it is really installed
+in the Debian archive. This happens only once a day, the package
+is then removed from incoming and installed in the pool along with all
+the other packages. Once all the other updates (generating new
+<file>Packages</file> and <file>Sources</file> index files for example) have been
+made, a special script is called to ask all the primary mirrors to update
+themselves.
+ <p>
+The archive maintenance software will also send the OpenPGP/GnuPG signed
+<file>.changes</file> file that you uploaded to the appropriate mailing
+lists. If a package is released with the <tt>Distribution:</tt> set to
+`stable', the announcement is sent to &email-debian-changes;.
+If a package is released with <tt>Distribution:</tt> set to `unstable'
+or `experimental', the announcement will be posted to
+&email-debian-devel-changes; instead.
+ <p>
+All Debian developers have write access to the <file>unchecked</file>
+directory in order to upload their packages, they also have that access
+to the <file>reject</file> directory in order to remove their bad uploads
+or to move some files back in the <file>unchecked</file> directory. But
+all the other directories are only writable by the ftpmasters, that is
+why you can not remove an upload once it has been accepted.
+
+ <sect1 id="delayed-incoming">Delayed incoming
+ <p>
+The <file>unchecked</file> directory has a special <file>DELAYED</file>
+subdirectory. It is itself subdivided in nine directories
+called <file>1-day</file> to <file>9-day</file>. Packages which are uploaded in
+one of those directories will be moved in the real unchecked
+directory after the corresponding number of days.
+This is done by a script that is run each day and which moves the
+packages between the directories. Those which are in "1-day" are
+installed in <file>unchecked</file> while the others are moved in the
+adjacent directory (for example, a package in <file>5-day</file> will
+be moved in <file>4-day</file>). This feature is particularly useful
+for people who are doing non-maintainer uploads. Instead of
+waiting before uploading a NMU, it is uploaded as soon as it is
+ready but in one of those <file>DELAYED/<var>x</var>-day</file> directories.
+That leaves the corresponding number of days for the maintainer
+to react and upload another fix themselves if they are not
+completely satisfied with the NMU. Alternatively they can remove
+the NMU.
+ <p>
+The use of that delayed feature can be simplified with a bit
+of integration with your upload tool. For instance, if you use
+<prgn>dupload</prgn> (see <ref id="dupload">), you can add this
+snippet to your configuration file:
+<example>
+$delay = ($ENV{DELAY} || 7);
+$cfg{'delayed'} = {
+ fqdn => "&ftp-master-host;",
+ login => "yourdebianlogin",
+ incoming => "/org/ftp.debian.org/incoming/DELAYED/$delay-day/",
+ dinstall_runs => 1,
+ method => "scpb"
+};
+</example>
+Once you've made that change, <prgn>dupload</prgn> can be used to
+easily upload a package in one of the delayed directories:
+<example>DELAY=5 dupload --to delayed <changes-file></example>
+
+
+
+ <sect id="pkg-info">Package information
+ <p>
+
+ <sect1 id="pkg-info-web">On the web
+ <p>
+Each package has several dedicated web pages.
+<tt>http://&packages-host;/<var>package-name</var></tt>
+displays each version of the package
+available in the various distributions. Each version links to a page
+which provides information, including the package description,
+the dependencies and package download links.
+ <p>
+The bug tracking system track bugs for each package. You can
+view the bugs of a given package at the URL
+<tt>http://&bugs-host;/<var>package-name</var></tt>.
+
+ <sect1 id="madison">The <prgn>madison</prgn> 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 <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.
+
+ <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 as 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. This can be done by sending mail
+to <tt><var>srcpackage</var>@&pts-host;</tt>. In order to prevent spam,
+mails sent to these addresses must contain the header "X-PTS-Approved"
+with a non-empty string.
+
+
+ <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 <em>testing</em>, ...).
+</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.
+
+ <tag><tt>ddtp</tt>
+ <item>
+Translations of descriptions or debconf templates
+submitted to the Debian Description Translation Project.
+</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-bts-control;
+ <item><tt>summary</tt>: automatic summary mails about the state of a package
+ <item><tt>cvs</tt>: notification of CVS commits
+ <item><tt>ddtp</tt>: translations of descriptions and debconf templates
+ <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 publicly 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.
+
+ <sect1 id="pts-web">The PTS web interface
+ <p>
+The PTS has been extended with a web interface that puts together
+many information about each source package. It features many useful
+links (BTS, QA stats, contact information, DDTP translation status,
+buildd logs) and gathers many more information from various places
+(30 latest changelog entries, testing status, ...). It's a very useful
+tool if you want to know what's going on with a specific source
+package. Furthermore there's a form that let you easily subscribe to
+the mail service offered by the PTS.
+ <p>
+You can jump directly to the web page concerning a specific source package
+with an url like <tt>http://&pts-host;/<var>srcpackage</var></tt>. Otherwise
+you can go through the <url id="http://&pts-host;" name="main page">.
+ <p>
+This web interface has been designed like a portal for the development of
+packages: you can add custom content on the pages of your packages. You can
+add "static information" (news item that are meant to stay available
+indefinitely) and news items in the "latest news" section.
+ <p>
+Static news can be used to indicate:
+<list>
+<item>the availability of a project hosted on alioth.debian.org for co-maintaining the package
+<item>a link to the upstream website
+<item>a link to the upstream bugtracker
+<item>the existence of an IRC channel dedicated to the software
+<item>any other available resource that could be useful in the maintenance of the package
+</list>
+Usual news item may be used to announce that:
+<list>
+<item>beta packages are available for test
+<item>final packages are expected for next week
+<item>the packaging is about to be redone from scratch
+<item>backports are available
+<item>the maintainer is on vacation (if he wishes to publish this information)
+<item>a NMU is being worked on
+<item>something important will affect the package
+</list>
+ <p>
+Both kind of news are generated in a similar manner: you just have to send a mail
+either to <email>pts-static-news@qa.debian.org</email> or to
+<email>pts-news@qa.debian.org</email>. The mail should indicate which package is
+concerned by the news by giving the name of the source package in a
+<tt>X-PTS-Package</tt> mail header or in a <tt>Package</tt> pseudo-header (like the
+BTS reports). If an URL is available in the <tt>X-PTS-Url</tt> mail header or in
+the <tt>Url</tt> pseudo-header, then the result is a link to that URL instead
+of a complete news item.
+ <p>
+Some examples of valid mails used to generate news item in the PTS are following. The first one
+adds a link to the cvsweb interface of debian-cd in the "Static information" section.
+<example>
+From: Raphael Hertzog <hertzog@debian.org>
+To: pts-static-news@qa.debian.org
+Subject: Browse debian-cd CVS repository with cvsweb
+
+Package: debian-cd
+Url: http://cvs.debian.org/debian-cd/
+</example>
+The second one is an announce sent to a mailing list which is also sent
+to the PTS so that it is published on the PTS web page of the package. Note the
+use of the BCC field to avoid answers sent to the PTS by mistake ...
+<example>
+From: Raphael Hertzog <hertzog@debian.org>
+To: debian-gtk-gnome@lists.debian.org
+Bcc: pts-news@qa.debian.org
+Subject: Galeon 2.0 backported for woody
+X-PTS-Package: galeon
+
+Hello gnomers !
+
+I'm glad to announce that galeon has been backported for woody. You'll find
+everything here:
+...
+</example>
+ <p>
+Think twice before adding a news to the PTS because you won't be able to
+remove it later and you wan't be able to edit it either. The only thing that you
+can do is send a second news that will deprecate the information contained in
+the first news.
+
+ <sect id="ddpo">Developer's packages overview
+ <p>
+A QA (quality assurance) web portal is available at <url
+ id="&url-ddpo;"> which displays a table listing all the packages
+of a single developer (including those where the party is listed as
+a co-maintainer). The table gives a good summary about the developer's
+packages: number of bugs by severity, list of available versions in each
+distribution, testing status and much more including links to any other
+useful information.
+ <p>
+It is a good idea to look up your own data regularly so that
+you don't forget any open bug, and so that you don't forget which
+packages are under your responsibility.
+