chiark / gitweb /
Proofread
[developers-reference.git] / developer-duties.dbk
index 5b7f73d..b753160 100644 (file)
@@ -26,7 +26,7 @@ For more information about the database, please see <xref linkend="devel-db"/>
 <para>
 Be very careful with your private keys.  Do not place them on any public
 servers or multiuser machines, such as the Debian servers (see <xref
-linkend="server-machines"/> ).  Back your keys up; keep a copy offline.  Read
+linkend="server-machines"/>).  Back your keys up; keep a copy offline.  Read
 the documentation that comes with your software; read the <ulink
 url="&url-pgp-faq;">PGP FAQ</ulink>.
 </para>
@@ -100,7 +100,7 @@ duties in the project.
 </para>
 <para>
 Usually this means that other developers are allowed to NMU (see <xref
-linkend="nmu"/> ) your package if a big problem (release critical bug, security
+linkend="nmu"/>) your package if a big problem (release critical bug, security
 update, etc.) occurs while you're on vacation.  Sometimes it's nothing as
 critical as that, but it's still appropriate to let others know that you're
 unavailable.
@@ -122,7 +122,7 @@ the on vacation flag when you come back!
 </para>
 <para>
 Ideally, you should sign up at the <ulink
-url="&url-newmaint-db;gpg.php">GPG coordination site</ulink> when booking a
+url="&url-gpg-coord;">GPG coordination pages</ulink> when booking a
 holiday and check if anyone there is looking for signing.  This is especially
 important when people go to exotic places where we don't have any developers
 yet but where there are people who are interested in applying.
@@ -152,13 +152,19 @@ 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
+<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
@@ -176,7 +182,7 @@ 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
+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>
@@ -191,7 +197,7 @@ following steps:
 <orderedlist numeration="arabic">
 <listitem>
 <para>
-Orphan all your packages, as described in <xref linkend="orphaning"/> .
+Orphan all your packages, as described in <xref linkend="orphaning"/>.
 </para>
 </listitem>
 <listitem>
@@ -203,7 +209,7 @@ Send an gpg-signed email about why you are leaving the project to
 <listitem>
 <para>
 Notify the Debian key ring maintainers that you are leaving by opening a ticket
-in Debian RT by sending a mail to keyring@rt.debian.org with the words 'Debian
+in Debian RT by sending a mail to &email-keyring; with the words 'Debian
 RT' somewhere in the subject line (case doesn't matter).
 </para>
 </listitem>