X-Git-Url: http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?a=blobdiff_plain;f=pkgs.dbk;h=3ce0bee233e232f7cf885803f653de9916e43363;hb=f5304146298bee2c1dd27d5acb52c6fd319ada62;hp=af8bcf072d20967664854fee780ef36ae61f2f02;hpb=0b16e655d73fddaea09dbbd0eea262378fc4d358;p=developers-reference.git

diff --git a/pkgs.dbk b/pkgs.dbk
index af8bcf0..3ce0bee 100644
--- a/pkgs.dbk
+++ b/pkgs.dbk
@@ -429,7 +429,8 @@ When the specified waiting time is over, the package is moved into
 the regular incoming directory for processing.
 This is done through automatic uploading to
 <literal>&ftp-upload-host;</literal> in upload-directory
-<literal>DELAYED/[012345678]-day</literal>. 0-day is uploaded
+<literal>DELAYED/<replaceable>X</replaceable>-day</literal>
+(<replaceable>X</replaceable> between 0 and 15). 0-day is uploaded
 multiple times per day to <literal>&ftp-upload-host;</literal>.
 </para>
 <para>
@@ -1308,7 +1309,10 @@ distribution.  Packages are not removed from
 <literal>testing</literal> directly.  Rather, they will be removed
 automatically after the package has been removed from
 <literal>unstable</literal> and no package in
-<literal>testing</literal> depends on it.
+<literal>testing</literal> depends on it. (Removals from
+<literal>testing</literal> are possible though by filing a removal bug report
+against the <systemitem role="package">&release-debian-org;</systemitem>
+pseudo-package. See the section <xref linkend="removals"/>.)
 </para>
 <para>
 There is one exception when an explicit removal request is not necessary: If a
@@ -1954,11 +1958,11 @@ maintainer by other means (private email, IRC).
 <listitem>
 <para>
 If the maintainer is usually active and responsive, have you tried to contact
-him? In general it should be considered preferable that a maintainer takes care
-of an issue himself and that he is given the chance to review and correct your
-patch, because he can be expected to be more aware of potential issues which an
-NMUer might miss. It is often a better use of everyone's time if the maintainer
-is given an opportunity to upload a fix on their own.
+them? In general it should be considered preferable that maintainers take care
+of an issue themselves and that they are given the chance to review and
+correct your patch, because they can be expected to be more aware of potential
+issues which an NMUer might miss. It is often a better use of everyone's time
+if the maintainer is given an opportunity to upload a fix on their own.
 </para>
 </listitem>
 </itemizedlist>
@@ -2120,7 +2124,7 @@ allows the developer doing the NMU to perform all the necessary tasks at the
 same time. For instance, instead of telling the maintainer that you will
 upload the updated
 package in 7 days, you should upload the package to
-<literal>DELAYED/7</literal> and tell the maintainer that he has 7 days to
+<literal>DELAYED/7</literal> and tell the maintainer that they have 7 days to
 react.  During this time, the maintainer can ask you to delay the upload some
 more, or cancel your upload.
 </para>
@@ -2129,12 +2133,12 @@ more, or cancel your upload.
 The <literal>DELAYED</literal> queue should not be used to put additional
 pressure on the maintainer. In particular, it's important that you are
 available to cancel or delay the upload before the delay expires since the
-maintainer cannot cancel the upload himself.
+maintainer cannot cancel the upload themselves.
 </para>
 
 <para>
 If you make an NMU to <literal>DELAYED</literal> and the maintainer updates
-his package before the delay expires, your upload will be rejected because a
+the package before the delay expires, your upload will be rejected because a
 newer version is already available in the archive.
 Ideally, the maintainer will take care to include your proposed changes (or
 at least a solution for the problems they address) in that upload.