<!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.204 $">
+ <!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> ">
+ <!-- how to mark a section that needs more work -->
+ <!ENTITY FIXME "<em>FIXME:</em> ">
]>
<debiandoc>
<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
In particular, it never makes sense to combine the <em>experimental</em>
distribution with anything else (see <ref id="experimental">).
- <sect1 id="upload-stable">Uploads to <em>stable</em>
+ <sect1 id="upload-stable">
+ <heading>Special case: uploads to the <em>stable</em> distribution</heading>
<p>
Uploading to <em>stable</em> means that the package will be placed into the
<file>stable-proposed-updates</file> directory of the Debian archive for further
<em>stable</em>, because otherwise the package won't be considered for
inclusion.
- <sect1 id="upload-t-p-u">Uploads to <em>testing-proposed-updates</em>
+ <sect1 id="upload-t-p-u">
+ <heading>Special case: uploads to <em>testing-proposed-updates</em></heading>
<p>
The testing distribution is fed with packages from unstable according to the rules
explained in <ref id="testing">. However, the release manager may stop the testing
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
<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
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