X-Git-Url: http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?p=developers-reference.git;a=blobdiff_plain;f=developer-duties.dbk;h=5b7f73d5501be4cf0aa9c9afa419373e2a6c8a99;hp=899b56732486efd83e5574897c2b39090717a07f;hb=430f868ef5cabbf6539d3051966de888d14277be;hpb=8a77d09ebb4f5b985db6da174892a3a66d5aa272 diff --git a/developer-duties.dbk b/developer-duties.dbk index 899b567..5b7f73d 100644 --- a/developer-duties.dbk +++ b/developer-duties.dbk @@ -1,13 +1,15 @@ + "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" [ + %commondata; +]> Debian Developer's Duties
Maintaining your Debian information There's a LDAP database containing information about Debian developers at -. You should enter your +. 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 @@ -26,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 ). Back your keys up; keep a copy offline. Read the documentation that comes with your software; read the PGP FAQ. +url="&url-pgp-faq;">PGP FAQ. You need to ensure not only that your key is secure against being stolen, but @@ -37,7 +39,7 @@ lost. 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 -keyring.debian.org. +&keyserver-host;. 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 . +url="http://&keyserver-host;/replacing_keys.html">. The same key extraction routines discussed in @@ -63,26 +65,26 @@ package. 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 Debian +defined by the Debian Constitution. Other than the yearly leader election, votes are not routinely held, and they are not undertaken lightly. Each proposal is first discussed on the -debian-vote@lists.debian.org 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. You don't have to track the pre-vote discussions, as the secretary will issue -several calls for votes on -debian-devel-announce@lists.debian.org (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. The list of all proposals (past and current) is available on the Debian Voting Information page, along +url="&url-vote;">Debian Voting Information page, along with information on how to make, second and vote on proposals.
@@ -105,7 +107,7 @@ unavailable. In order to inform the other developers, there are two things that you should -do. First send a mail to debian-private@lists.debian.org with +do. First send a mail to debian-private@&lists-host; with [VAC] prepended to the subject of your message This is so that the message can be easily filtered by people who don't want to read vacation notices. and state the period of time when you will be on @@ -120,7 +122,7 @@ the on vacation flag when you come back! Ideally, you should sign up at the GPG coordination site when booking a +url="&url-newmaint-db;gpg.php">GPG coordination site 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. @@ -158,20 +160,20 @@ upstream sources. Generally you should deal with bug reports on your packages as described in . 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 critical, -grave or serious are considered to +bugs). All bug reports that have severity critical, +grave or serious 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 corrected as quickly as possible. -Developers who are part of the Quality +Developers who are part of the Quality Assurance 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 -debian-qa@lists.debian.org, or explain your difficulties and +debian-qa@&lists-host;, 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 ) after trying to contact you (they might not wait as long as @@ -195,7 +197,7 @@ Orphan all your packages, as described in . Send an gpg-signed email about why you are leaving the project to -debian-private@lists.debian.org. +debian-private@&lists-host;.