Move some sections around

Include the "Managing RC bugs" and "Coordinate with upstream" in the
"Package Maintainer's Duties" section.

git-svn-id: svn://anonscm.debian.org/ddp/manuals/trunk/developers-reference@8578 313b444b-1b9f-4f58-a734-7bb04f332e8d

diff --git a/developer-duties.dbk b/developer-duties.dbk
index a8eb5b1d4572af81d4032326937d7ad2f96b64bd..cf85ffef13f23d073a0678c4e96fa4bc5d703c47 100644 (file)
--- a/developer-duties.dbk
+++ b/developer-duties.dbk
@@ -12,6 +12,64 @@
 high-quality packages that are well integrated
 in the system and that adhere to the Debian Policy.</para>
 
 high-quality packages that are well integrated
 in the system and that adhere to the Debian Policy.</para>
 

+<section id="rc-bugs">
+<title>Managing release-critical bugs</title>
+<para>
+Generally you should deal with bug reports on your packages as described in
+<xref linkend="bug-handling"/>.  However, there's a special category of bugs
+that you need to take care of — the so-called release-critical bugs (RC
+bugs).  All bug reports that have severity <literal>critical</literal>,
+<literal>grave</literal> or <literal>serious</literal> are considered to
+have an impact on whether the package can be released in the next stable
+release of Debian.  These bugs can delay the Debian release and/or can justify
+the removal of a package at freeze time.  That's why these bugs need to be
+corrected as quickly as possible.
+</para>
+<para>
+Developers who are part of the <ulink url="&url-debian-qa;">Quality
+Assurance</ulink> group are following all such bugs, and trying to help
+whenever possible.  If, for any reason, you aren't able fix an RC bug in a
+package of yours within 2 weeks, you should either ask for help by sending a
+mail to the Quality Assurance (QA) group
+<email>debian-qa@&lists-host;</email>, or explain your difficulties and
+present a plan to fix them by sending a mail to the bug report.  Otherwise,
+people from the QA group may want to do a Non-Maintainer Upload (see <xref
+linkend="nmu"/>) after trying to contact you (they might not wait as long as
+usual before they do their NMU if they have seen no recent activity from you in
+the BTS).
+</para>
+</section>
+
+<section id="upstream-coordination">
+<title>Coordination with upstream developers</title>
+<para>
+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 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.
+</para>
+<para>
+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.
+</para>
+<para>
+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 developers which
+can be included there, so that you won't have to modify the sources of the next
+upstream version.  Whatever changes you need, always try not to fork from the
+upstream sources.
+</para>
+<para>
+If you find that the upstream developers are or become hostile towards Debian
+or the free software community, you may want to re-consider the need to
+include the software in Debian. Sometimes the social cost to the
+Debian community is not worth the benefits the software may bring.
+</para>
+</section>

 
 </section>
 
 
 </section>
 


@@ -144,65 +202,6 @@ yet but where there are people who are interested in applying.
 </para>
 </section>
 
 </para>
 </section>
 

-<section id="upstream-coordination">
-<title>Coordination with upstream developers</title>
-<para>
-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 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.
-</para>
-<para>
-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.
-</para>
-<para>
-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 developers which
-can be included there, so that you won't have to modify the sources of the next
-upstream version.  Whatever changes you need, always try not to fork from the
-upstream sources.
-</para>
-<para>
-If you find that the upstream developers are or become hostile towards Debian
-or the free software community, you may want to re-consider the need to
-include the software in Debian. Sometimes the social cost to the
-Debian community is not worth the benefits the software may bring.
-</para>
-</section>
-
-<section id="rc-bugs">
-<title>Managing release-critical bugs</title>
-<para>
-Generally you should deal with bug reports on your packages as described in
-<xref linkend="bug-handling"/>.  However, there's a special category of bugs
-that you need to take care of — the so-called release-critical bugs (RC
-bugs).  All bug reports that have severity <literal>critical</literal>,
-<literal>grave</literal> or <literal>serious</literal> are considered to
-have an impact on whether the package can be released in the next stable
-release of Debian.  These bugs can delay the Debian release and/or can justify
-the removal of a package at freeze time.  That's why these bugs need to be
-corrected as quickly as possible.
-</para>
-<para>
-Developers who are part of the <ulink url="&url-debian-qa;">Quality
-Assurance</ulink> group are following all such bugs, and trying to help
-whenever possible.  If, for any reason, you aren't able fix an RC bug in a
-package of yours within 2 weeks, you should either ask for help by sending a
-mail to the Quality Assurance (QA) group
-<email>debian-qa@&lists-host;</email>, or explain your difficulties and
-present a plan to fix them by sending a mail to the bug report.  Otherwise,
-people from the QA group may want to do a Non-Maintainer Upload (see <xref
-linkend="nmu"/>) after trying to contact you (they might not wait as long as
-usual before they do their NMU if they have seen no recent activity from you in
-the BTS).
-</para>
-</section>
-

 <section id="s3.7">
 <title>Retiring</title>
 <para>
 <section id="s3.7">
 <title>Retiring</title>
 <para>