chiark / gitweb /
Re-applied comments from SGML source to the DocBook files.
[developers-reference.git] / resources.dbk
index a1679154178c1919efa0328c09673b21dacaa3e3..cc04f3d268b8e8b116e10ec10f58351134f3f70d 100644 (file)
@@ -337,6 +337,7 @@ questions.
 
 <section id="servers-cvs">
 <title>The CVS server</title>
+<!-- TODO: document svn.debian.org, arch.debian.org also -->
 <para>
 Our CVS server is located on <literal>cvs.debian.org</literal>.
 </para>
@@ -950,6 +951,63 @@ announcement will be posted to
 Though ftp-master is restricted, a copy of the installation is available to all
 developers on <literal>merkel.debian.org</literal>.
 </para>
+<!-- FIXME: delete it or keep it for historical purposes?
+<para>
+All Debian developers have write access to the <filename>unchecked</filename>
+directory in order to upload their packages; they also have that access
+to the <filename>reject</filename> directory in order to remove their bad uploads
+or to move some files back to the <filename>unchecked</filename> directory. But
+all the other directories are only writable by the ftpmasters, which is
+why you cannot remove an upload once it has been accepted.
+</para>
+
+<section id="delayed-incoming-broken">
+<title>Delayed incoming</title>
+<para>
+<emphasis>Note:</emphasis> This description here is currently not working, because
+ftp-master is restricted. Please see <xref linkend="delayed-incoming"/> for
+the currently working way.
+</para>
+<para>
+The <filename>unchecked</filename> directory has a special <filename>DELAYED</filename>
+subdirectory. It is itself subdivided in nine directories
+called <filename>1-day</filename> to <filename>9-day</filename>. Packages which are uploaded to
+one of those directories will be moved to the real unchecked
+directory after the corresponding number of days.
+This is done by a script which is run each day and which moves the
+packages between the directories. Those which are in "1-day" are
+installed in <filename>unchecked</filename> while the others are moved to the 
+adjacent directory (for example, a package in <filename>5-day</filename> will
+be moved to <filename>4-day</filename>). 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 to one of those <filename>DELAYED/<varname>x</varname>-day</filename> 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.
+</para>
+<para>
+The use of that delayed feature can be simplified with a bit
+of integration with your upload tool.  For instance, if you use 
+<command>dupload</command> (see <xref linkend="dupload"/>), you can add this
+snippet to your configuration file:
+<screen>
+$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"
+};
+</screen>
+Once you've made that change, <command>dupload</command> can be used to
+easily upload a package in one of the delayed directories:
+<literal>DELAY=5 dupload -X-to delayed &lt;changes-file&gt;</literal>
+</para>
+</section>
+-->
 </section>
 
 <section id="pkg-info">