Debian Developer's Duties
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
keyring.debian.org.
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
debian-vote@lists.debian.org 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.
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.
Coordination with upstream developers
A big part of your job as Debian maintainer will be to stay in contact with the
upstream developers. Debian users will sometimes report bugs that are not
specific to Debian to our bug tracking system. You have to forward these bug
reports to the upstream developers so that they can be fixed in a future
upstream release.
While it's not your job to fix non-Debian specific bugs, you may freely do so
if you're able. When you make such fixes, be sure to pass them on to the
upstream maintainers as well. Debian users and developers will sometimes
submit patches to fix upstream bugs — you should evaluate and forward these
patches upstream.
If you need to modify the upstream sources in order to build a policy compliant
package, then you should propose a nice fix to the upstream developers which
can be included there, so that you won't have to modify the sources of the next
upstream version. Whatever changes you need, always try not to fork from the
upstream sources.
Managing 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 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
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
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
usual before they do their NMU if they have seen no recent activity from you in
the BTS).
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.debian.org.
Notify the Debian key ring maintainers that you are leaving by opening a ticket
in Debian RT by sending a mail to keyring@rt.debian.org with the words 'Debian
RT' somewhere in the subject line (case doesn't matter).