<?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>
choose to subscribe there.
</para>
<para>
-For more information about the database, please see <xref linkend="devel-db"/>
-.
+For more information about the database, please see <xref linkend="devel-db"/>.
</para>
</section>
<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="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
</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.
</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.
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 <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
<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>
<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>
<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>
~ianmdlvl / developers-reference.git / blobdiff