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" [
 <?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>
 ]>
 <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
 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>
 <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
 <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
 </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>
 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
 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
 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