+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="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 an <file>unchecked</file>
+directory. This directory is scanned every 15 minutes by the katie script
+that verifies the integrity of the package and the cryptographic
+signature. If the package is considered ready to be installed, it
+is moved into an <file>accepted</file> directory. If it is the first upload of
+the package then it is moved in a <file>new</file> directory waiting an
+approval of the ftpmasters. If the package contains files to be installed
+"by-hand" is is moved in the <file>byhand</file> directory waiting 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>
+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 to the maintainer
+in order to react and upload himself another fix if he is not
+completely satisfied with the NMU. Alternatively he can remove
+the NMU by himself.
+ <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/",
+ visibleuser => "yourdebianlogin",
+ visiblename => "debian.org",
+ fullname => "Your Full Name",
+ 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="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 conditional on the following:
+<list>
+ <item>
+The package must have been available in <em>unstable</em> for several days;
+the precise number depends on the upload's urgency field. 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 <file>update_excuses</file> 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. <tt>http://&packages-host;/<var>package-name</var></tt>
+will display each version of the package
+available in the various distributions. The per-version detailed
+information includes the package description,
+the dependencies and 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;/<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 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.