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 -->
-  <!entity % versiondata SYSTEM "version.ent"> %versiondata;
+  <!ENTITY % versiondata SYSTEM "version.ent"> %versiondata;
   <!-- common, language independant entities -->
-  <!entity % commondata  SYSTEM "common.ent" > %commondata;
+  <!ENTITY % commondata  SYSTEM "common.ent" > %commondata;
 
   <!-- 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 -->
   <!--
-    <!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>
@@ -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
-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
@@ -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 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
@@ -1974,7 +1979,8 @@ maintainer address.
 
       <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
@@ -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>
+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