a bit of a stylistic clarification -- forwarding is primary, the rest is secondary

[developers-reference.git] / developers-reference.sgml

diff --git a/developers-reference.sgml b/developers-reference.sgml
index a86386ec698e921b12591d62fe783296e22639e7..774f6ad9e31ca6697bb2a61d171e0bd5bea68030 100644 (file)
--- a/developers-reference.sgml
+++ b/developers-reference.sgml
@@ -1,20 +1,20 @@
 <!DOCTYPE debiandoc PUBLIC "-//DebianDoc//DTD DebianDoc//EN" [
   <!-- include version information so we don't have to hard code it
        within the document -->
 <!DOCTYPE debiandoc PUBLIC "-//DebianDoc//DTD DebianDoc//EN" [
   <!-- include version information so we don't have to hard code it
        within the document -->

-  <!entity % versiondata SYSTEM "version.ent"> %versiondata;
+  <!ENTITY % versiondata SYSTEM "version.ent"> %versiondata;

   <!-- common, language independant entities -->
   <!-- common, language independant entities -->

-  <!entity % commondata  SYSTEM "common.ent" > %commondata;
+  <!ENTITY % commondata  SYSTEM "common.ent" > %commondata;

 
   <!-- CVS revision of this document -->
 
   <!-- CVS revision of this document -->

-  <!entity cvs-rev "$Revision: 1.205 $">
+  <!ENTITY cvs-rev "$Revision: 1.209 $">

   <!-- if you are translating this document, please notate the CVS
        revision of the developers reference here -->
   <!--
   <!-- if you are translating this document, please notate the CVS
        revision of the developers reference here -->
   <!--

-    <!entity cvs-en-rev "X.YY">
+  <!ENTITY cvs-en-rev "X.YY">

     -->
 
     -->
 

-  <!--  -->
-  <!entity FIXME "<em>FIXME:</em>&nbsp;">
+  <!-- how to mark a section that needs more work -->
+  <!ENTITY FIXME "<em>FIXME:</em>&nbsp;">

 
 ]>
 <debiandoc>
 
 ]>
 <debiandoc>


@@ -350,14 +350,15 @@ Don't forget to remove the "on vacation" flag when you come back!
        <p>
 A big part of your job as Debian maintainer will be to stay in contact
 with the upstream developers.  Debian users will sometimes report bugs
        <p>
 A big part of your job as Debian maintainer will be to stay in contact
 with the upstream developers.  Debian users will sometimes report bugs

-to the Bug Tracking System that are not specific to Debian.  You
-must forward these bug reports to the upstream developers so that
-they can be fixed in a future release.  It's not your job to fix
-non-Debian specific bugs.  However, if you are able to do so, you are
-encouraged to contribute to upstream development of the package by
-providing a fix for the bug.  Debian users and developers will often
-submit patches to fix upstream bugs, and you should evaluate and
-forward these patches upstream.
+that are not specific to Debian to our bug tracking system.  You
+have to forward these bug reports to the upstream developers so that
+they can be fixed in a future upstream release.
+       <p>
+While it's not your job to fix non-Debian specific bugs, you may freely
+do so if you're able. When you make such fixes, be sure to pass them on
+to the upstream maintainers as well. Debian users and developers will
+sometimes submit patches to fix upstream bugs -- you should evaluate
+and forward these patches upstream.

         <p>
 If you need to modify the upstream sources in order to build a policy
 compliant package, then you should propose a nice fix to the upstream
         <p>
 If you need to modify the upstream sources in order to build a policy
 compliant package, then you should propose a nice fix to the upstream


@@ -1735,6 +1736,10 @@ to transfer the files, place them into &us-upload-dir;;
 if you use anonymous FTP to upload, place them into
 &upload-queue;.
          <p>
 if you use anonymous FTP to upload, place them into
 &upload-queue;.
          <p>

+If you want to use feature described in <ref id="delayed-incoming">,
+you'll have to upload to <tt>ftp-master</tt>.  It is the only upload
+point that supported delayed incoming.
+         <p>

 Please note that you should transfer
 the changes file last.  Otherwise, your upload may be rejected because the
 archive maintenance software will parse the changes file and see that not
 Please note that you should transfer
 the changes file last.  Otherwise, your upload may be rejected because the
 archive maintenance software will parse the changes file and see that not


@@ -1974,7 +1979,8 @@ maintainer address.
 
       <sect1 id="bug-answering">Responding to bugs
        <p>
 
       <sect1 id="bug-answering">Responding to bugs
        <p>

-Make sure that any discussion you have about bugs are sent both to
+When responding to bugs, make sure that any discussion you have about
+bugs are sent both to

 the original submitter of the bug, and the bug itself (e.g.,
 <email>123@&bugs-host;</email>). If you're writing a new
 mail and you don't remember the submitter email address, you can
 the original submitter of the bug, and the bug itself (e.g.,
 <email>123@&bugs-host;</email>). If you're writing a new
 mail and you don't remember the submitter email address, you can


@@ -1983,6 +1989,9 @@ contact the submitter <em>and</em> to record your mail within the
 bug log (that means you don't need to send a copy of the mail to
 <email>123@&bugs-host;</email>).
        <p>
 bug log (that means you don't need to send a copy of the mail to
 <email>123@&bugs-host;</email>).
        <p>

+If you get a bug which mentions "FTBFS", that means "Fails to build
+from source".  Porters frequently use this acronym.
+       <p>

 Once you've dealt with a bug report (e.g. fixed it), mark it as
 <em>done</em> (close it) by sending an explanation message to
 <email>123-done@&bugs-host;</email>. If you're fixing a bug by
 Once you've dealt with a bug report (e.g. fixed it), mark it as
 <em>done</em> (close it) by sending an explanation message to
 <email>123-done@&bugs-host;</email>. If you're fixing a bug by