+ <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 <tt>unchecked</tt>
+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 <tt>accepted</tt> directory. If it is the first upload of
+the package then it is moved in a <tt>new</tt> directory waiting an
+approval of the ftpmasters. If the package contains files to be installed
+"by-hand" is is moved in the <tt>byhand</tt> directory waiting a manual
+installation by the ftpmasters. Otherwise, if any error has been detected,
+the package is refused and is moved in the <tt>reject</tt> 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 autobuilders may start recompiling it. The package is now publically
+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
+<tt>Packages</tt> and <tt>Sources</tt> 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 <tt>unchecked</tt>
+directory in order to upload their packages, they also have that access
+to the <tt>reject</tt> directory in order to remove their bad uploads
+or to move some files back in the <tt>unchecked</tt> 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 <tt>unchecked</tt> directory has a special <tt>DELAYED</tt>
+subdirectory. It is itself subdivised in nine directories
+called <tt>1-day</tt> to <tt>9-day</tt>. 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 <tt>unchecked</tt> while the others are moved in the
+adjacent directory (for example, a package in <tt>5-day</tt> will
+be moved in <tt>4-day</tt>). 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 <tt>DELAYED/x-day</tt> 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, the following addition to
+the <prgn>dupload</prgn> configuration file should be
+considered.
+ <p>
+<example>
+$delay = ($ENV{DELAY} || 7);
+$cfg{'delayed'} = {
+ fqdn => "ftp-master.debian.org",
+ 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>
+ <p>
+<prgn>dupload</prgn> can now 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 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>