Improved text output. (Better parametrisation of XSL and w3m.)

[developers-reference.git] / pkgs.dbk

diff --git a/pkgs.dbk b/pkgs.dbk
index 1e0b29d9593b81ade4d436d9ef8540f87a748780..c6c478cea7d01c8bb7adf5de5a083b49277ea27d 100644 (file)
--- a/pkgs.dbk
+++ b/pkgs.dbk
@@ -28,14 +28,18 @@ description of the package, the license of the prospective package, and the
 current URL where it can be downloaded from.
 </para>
 <para>
-You should set the subject of the bug to ``ITP: <replaceable>foo</replaceable>
--- <replaceable>short description</replaceable>'', substituting the name of the
-new package for <replaceable>foo</replaceable>.  The severity of the bug report
-must be set to <literal>wishlist</literal>.  If you feel it's necessary, send
-a copy to &email-debian-devel; by putting the address in the
-<literal>X-Debbugs-CC:</literal> header of the message (no, don't use
-<literal>CC:</literal>, because that way the message's subject won't indicate
-the bug number).
+You should set the subject of the bug to <literal>ITP: 
+<replaceable>foo</replaceable> -- <replaceable>short
+description</replaceable></literal>, substituting the name of the new
+package for <replaceable>foo</replaceable>. 
+The severity of the bug report must be set to <literal>wishlist</literal>.
+Please send a copy to &email-debian-devel; by using the X-Debbugs-CC
+header (don't use CC:, because that way the message's subject won't
+indicate the bug number). If you are packaging so many new packages (>10)
+that notifying the mailing list in seperate messages is too disruptive,
+do send a summary after filing the bugs to the debian-devel list instead.
+This will inform the other developers about upcoming packages and will
+allow a review of your description and package name.
 </para>
 <para>
 Please include a <literal>Closes:
@@ -735,9 +739,9 @@ several developers working on the same package.
 </listitem>
 <listitem>
 <para>
-Once a corrected package is available in the <literal>unstable</literal>
-distribution, you can close the bug.  This can be done automatically, read
-<xref linkend="upload-bugfix"/> .
+Once a corrected package is available in the archive, the bug should be
+closed indicating the version in which it was fixed. This can be done
+automatically, read <xref linkend="upload-bugfix"/>.
 </para>
 </listitem>
 </orderedlist>
@@ -2281,7 +2285,7 @@ available in <literal>unstable</literal>, but not affecting the version in
 <listitem>
 <para>
 It must be available on all architectures on which it has previously been built
-in <literal>unstable</literal>.  <xref linkend="madison"/> may be of interest
+in <literal>unstable</literal>.  <xref linkend="dak ls"/> may be of interest
 to check that information;
 </para>
 </listitem>