Create a publish target in the Makefile to reenable builds on the

[developers-reference.git] / developer-duties.dbk

diff --git a/developer-duties.dbk b/developer-duties.dbk
index 5a444e76a034e9fc0898f94fb958b7421ca3b710..5b7f73d5501be4cf0aa9c9afa419373e2a6c8a99 100644 (file)
--- a/developer-duties.dbk
+++ b/developer-duties.dbk
@@ -1,7 +1,7 @@
 <?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>
@@ -28,7 +28,7 @@ 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
 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
@@ -71,16 +71,16 @@ Constitution</ulink>.
 <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
@@ -160,8 +160,8 @@ upstream sources.
 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