<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
"http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" [
- <!ENTITY % commondata SYSTEM "common.ent" > %commondata;
+ <!ENTITY % commondata SYSTEM "common.ent" > %commondata;
]>
<chapter id="developer-duties">
<title>Debian Developer's Duties</title>
servers or multiuser machines, such as the Debian servers (see <xref
linkend="server-machines"/> ). Back your keys up; keep a copy offline. Read
the documentation that comes with your software; read the <ulink
-url="http://www.cam.ac.uk.pgp.net/pgpnet/pgp-faq/">PGP FAQ</ulink>.
+url="&url-pgp-faq;">PGP FAQ</ulink>.
</para>
<para>
You need to ensure not only that your key is secure against being stolen, but
<para>
Other than the yearly leader election, votes are not routinely held, and they
are not undertaken lightly. Each proposal is first discussed on the
-<email>debian-vote@&lists-host;</email> mailing list and it requires
-several endorsements before the project secretary starts the voting procedure.
+&email-debian-vote; mailing list and it requires several
+endorsements before the project secretary starts the voting procedure.
</para>
<para>
You don't have to track the pre-vote discussions, as the secretary will issue
-several calls for votes on
-<email>debian-devel-announce@&lists-host;</email> (and all developers are
-expected to be subscribed to that list). Democracy doesn't work well if people
-don't take part in the vote, which is why we encourage all developers to vote.
-Voting is conducted via GPG-signed/encrypted email messages.
+several calls for votes on &email-debian-devel-announce; (and
+all developers are expected to be subscribed to that list). Democracy doesn't
+work well if people don't take part in the vote, which is why we encourage all
+developers to vote. Voting is conducted via GPG-signed/encrypted email
+messages.
</para>
<para>
The list of all proposals (past and current) is available on the <ulink
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">
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 <emphasis>critical</emphasis>,
-<emphasis>grave</emphasis> or <emphasis>serious</emphasis> are considered to
+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