chiark / gitweb /
Fixed all examples, fixed many (not all, yet) entities.
[developers-reference.git] / developer-duties.dbk
index 899b56732486efd83e5574897c2b39090717a07f..5a444e76a034e9fc0898f94fb958b7421ca3b710 100644 (file)
@@ -1,13 +1,15 @@
 <?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">
+    "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" [
+  <!ENTITY % commondata  SYSTEM "common.ent" > %commondata;
+]>
 <chapter id="developer-duties">
 <title>Debian Developer's Duties</title>
 <section id="user-maint">
 <title>Maintaining your Debian information</title>
 <para>
 There's a LDAP database containing information about Debian developers at
-<ulink url="https://db.debian.org/"></ulink>.  You should enter your
+<ulink url="&url-debian-db;"></ulink>.  You should enter your
 information there and update it as it changes.  Most notably, make sure that
 the address where your debian.org email gets forwarded to is always up to date,
 as well as the address where you get your debian-private subscription if you
@@ -37,7 +39,7 @@ lost.
 <para>
 If you add signatures to your public key, or add user identities, you can
 update the Debian key ring by sending your key to the key server at
-<literal>keyring.debian.org</literal>.
+<literal>&keyserver-host;</literal>.
 </para>
 <para>
 If you need to add a completely new key or remove an old key, you need to get
@@ -45,7 +47,7 @@ the new key signed by another developer.  If the old key is compromised or
 invalid, you also have to add the revocation certificate.  If there is no real
 reason for a new key, the Keyring Maintainers might reject the new key.
 Details can be found at <ulink
-url="http://keyring.debian.org/replacing_keys.html"></ulink>.
+url="http://&keyserver-host;/replacing_keys.html"></ulink>.
 </para>
 <para>
 The same key extraction routines discussed in <xref linkend="registering"/>
@@ -63,26 +65,26 @@ package.
 <para>
 Even though Debian isn't really a democracy, we use a democratic process to
 elect our leaders and to approve general resolutions.  These procedures are
-defined by the <ulink url="http://www.debian.org/devel/constitution">Debian
+defined by the <ulink url="&url-constitution;">Debian
 Constitution</ulink>.
 </para>
 <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.debian.org</email> mailing list and it requires
+<email>debian-vote@&lists-host;</email> 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.debian.org</email> (and all developers are
+<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.
 </para>
 <para>
 The list of all proposals (past and current) is available on the <ulink
-url="http://www.debian.org/vote/">Debian Voting Information</ulink> page, along
+url="&url-vote;">Debian Voting Information</ulink> page, along
 with information on how to make, second and vote on proposals.
 </para>
 </section>
@@ -105,7 +107,7 @@ unavailable.
 </para>
 <para>
 In order to inform the other developers, there are two things that you should
-do.  First send a mail to <email>debian-private@lists.debian.org</email> with
+do.  First send a mail to <email>debian-private@&lists-host;</email> with
 [VAC] prepended to the subject of your message<footnote><para> This is so that
 the message can be easily filtered by people who don't want to read vacation
 notices.  </para> </footnote> and state the period of time when you will be on
@@ -120,7 +122,7 @@ the on vacation flag when you come back!
 </para>
 <para>
 Ideally, you should sign up at the <ulink
-url="http://nm.debian.org/gpg.php">GPG coordination site</ulink> when booking a
+url="&url-newmaint-db;gpg.php">GPG coordination site</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.
@@ -166,12 +168,12 @@ the removal of a package at freeze time.  That's why these bugs need to be
 corrected as quickly as possible.
 </para>
 <para>
-Developers who are part of the <ulink url="http://qa.debian.org/">Quality
+Developers who are part of the <ulink url="&url-debian-qa;">Quality
 Assurance</ulink> group are following all such bugs, and trying to help
 whenever possible.  If, for any reason, you aren't able fix an RC bug in a
 package of yours within 2 weeks, you should either ask for help by sending a
 mail to the Quality Assurance (QA) group
-<email>debian-qa@lists.debian.org</email>, or explain your difficulties and
+<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
@@ -195,7 +197,7 @@ Orphan all your packages, as described in <xref linkend="orphaning"/> .
 <listitem>
 <para>
 Send an gpg-signed email about why you are leaving the project to
-<email>debian-private@lists.debian.org</email>.
+<email>debian-private@&lists-host;</email>.
 </para>
 </listitem>
 <listitem>