%commondata; ]> Debian Developer's Duties
Work towards the next <literal>stable</literal> release Providing high-quality packages in unstable is not enough, most users will only benefit from your packages when they are released as part of the next stable release. You are thus expected to collaborate with the release team to ensure your packages get included. More concretely, you should monitor whether your packages are migrating to testing (see ). When the migration doesn't happen after the test period, you should analyze why and work towards fixing this. It might mean fixing your package (in the case of release-critical bugs or failures to build on some architecture) but it can also mean updating (or fixing, or removing from testing) other packages to help complete a transition in which your package is entangled due to its dependencies. The release team might provide you some input on the current blockers of a given transition if you are not able to identify them.
Maintain packages in <literal>stable</literal> Most of the package maintainer's work goes into providing updated versions of packages in unstable, but his job also entails taking care of the packages in the current stable release. While changes in stable are discouraged, they are possible. Whenever a security problem is reported, you should collaborate with the security team to provide a fixed version (see ). When bugs of severity important (or more) are reported against the stable version of your packages, you should consider providing a targeted fix. You can ask the stable release team whether they would accept such an update and then prepare a stable upload (see ).
Manage release-critical bugs 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 make the package unsuitable for inclusion in the next stable release. They can thus delay the Debian release (when they affect a package in testing) or block migrations to testing (when they only affect the package in unstable). In the worst scenario, they will lead to the package's removal. That's why these bugs need to be corrected as quickly as possible. If, for any reason, you aren't able fix an RC bug in a package of yours within 2 weeks (for example due to time constraints, or because it's difficult to fix), you should mention it clearly in the bug report and you should tag the bug help to invite other volunteers to chime in. Be aware that RC bugs are frequently the targets of Non-Maintainer Uploads (see ) because they can block the testing migration of many packages. Lack of attention to RC bugs is often interpreted by the QA team as a sign that the maintainer has disappeared without properly orphaning his package. The MIA team might also get involved, which could result in your packages being orphaned (see ).
Maintaining your Debian information There's a LDAP database containing information about Debian developers at . 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 choose to subscribe there. For more information about the database, please see .
Maintaining your public key 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. You need to ensure not only that your key is secure against being stolen, but also that it is secure against being lost. Generate and make a copy (best also in paper form) of your revocation certificate; this is needed if your key is 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 &keyserver-host;. If you need to add a completely new key or remove an old key, you need to get 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 . The same key extraction routines discussed in apply. You can find a more in-depth discussion of Debian key maintenance in the documentation of the debian-keyring package.
Voting 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 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 &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 &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 with information on how to make, second and vote on proposals.
Going on vacation gracefully It is common for developers to have periods of absence, whether those are planned vacations or simply being buried in other work. The important thing to notice is that other developers need to know that you're on vacation so that they can do whatever is needed if a problem occurs with your packages or other duties in the project. Usually this means that other developers are allowed to NMU (see ) 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. In order to inform the other developers, there are two things that you should 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 vacation. You can also give some special instructions on what to do if a problem occurs. The other thing to do is to mark yourself as on vacation in the Debian developers' LDAP database (this information is only accessible to Debian developers). Don't forget to remove the on vacation flag when you come back! Ideally, you should sign up at the GPG coordination pages 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.
Retiring If you choose to leave the Debian project, you should make sure you do the following steps: Orphan all your packages, as described in . Send an gpg-signed email about why you are leaving the project to debian-private@&lists-host;. Notify the Debian key ring maintainers that you are leaving by opening a ticket in Debian RT by sending a mail to &email-keyring; with the words 'Debian RT' somewhere in the subject line (case doesn't matter). It is important that the above process is followed, because finding inactive developers and orphaning their packages takes significant time and effort.
Returning after retirement A retired developer's account is marked as "emeritus" when the process in is followed, and "disabled" otherwise. Retired developers with an "emeritus" account can get their account re-activated as follows: Contact &email-debian-account-manager;. Go through a shortened NM process (to ensure that the returning developer still knows important parts of P&P and T&S). Prove that they still control the GPG key associated with the account, or provide proof of identify on a new GPG key, with at least two signatures from other developers. Retired developers with a "disabled" account need to go through NM again.