There's a LDAP database containing many informations concerning all developers,
you can access it at https://db.debian.org/
. You can
update your password (this password is propagated to most of the machines that
are accessible to you), your adress, your country, the latitude and longitude
from the point where you live, phone and fax numbers, your preferred shell,
your IRC nickname, your web page and the email that you're using as alias for
your debian.org email. Most of the information is not accessible to the
public, for more details about this database, please read its online
documentation that you can find here : http://db.debian.org/doc-general.html
.
You have to keep the information available there up to date.
Be very careful with your private keys. Do not place them on any public
servers or multiuser machines, such as master.debian.org. Back
your keys up; keep a copy offline. Read the documentation that comes with your
software; read the PGP FAQ
.
If you add or remove signatures from your public key, or add or remove user
identities, you need to update the key servers and mail your public key to
keyring-maint@debian.org
.
The same key extraction routines discussed in Registering as a Debian developer,
Section 2.2 apply.
You can find a more in-depth discussion of Debian key maintenance in the
documentation for the debian-keyring
package.
Most of the developers take vacation, usually this means that they can't work for Debian and they can't be reached by email if any problem occurs. The other developers need to know that you're on vacation so that they'll do whatever is needed when such a problem occurs. Usually this means that other developers are allowed to NMU your package if a big problem (release critical bugs, security update, ...) occurs while you're on vacation.
In order to inform the other developers, there's two things that you should do.
First send a mail to debian-private@lists.debian.org
giving the period of time when you will be on vacation, you can also give some
special instructions on what to do if any problem occurs. Next you should
update your information available in the Debian LDAP database and mark yourself
as « on vacation » (this information is only accessible to debian developers).
Don't forget to remove the « on vacation » flag when you come back.
A big part of your job as Debian maintainer will be to stay in contact with the upstream developers since you'll have to share information that you get from the Bug Tracking System. It's not your job to fix non-Debian specific bugs so you have to forward the bugs to the upstream developers (of course, if you are able to fix them, you can ...). This way the bug may be corrected when the next upstream version comes out. From time to time, you may get a patch attached to a bug report, you have to send the patch upstream and make sure that it gets included (if the authors accept the proposed fix). If you need to modify the upstream sources in order to build a policy conformant package, then you should propose a nice fix to the upstream developers which can be included 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.
Release Critical Bugs (RCB) are the bugs of severity « critical »,
« grave » and « important ». Those bugs can delay the
Debian release and/or can justify the removal of a package at freeze time.
That's why those bugs needs to be corrected as fast as possible. You must be
aware that some developers who are part of the Debian Quality Assurance
effort are
following those bugs and try to help you each time they can. But if you can't
fix such bugs 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 justify yourself and gives your plan to fix it by sending a mail to the
concerned bug report. Otherwise people from the QA group may want to do a Non
Maintainer Upload (NMU) after trying to contact you (they might wait not as
long as usually before they do their NMU if they have seen no recent activity
from you on the BTS).
Even if there is a dedicated group of people for Quality Assurance, QA is not
reserved to them. You can participate to this effort by keeping your packages
as bug free as possible, as lintian-clean (see Lintian reports, Section
10.5) as possible. If you think that it's quite impossible, then you
should consider orphaning (see Orphaning a package, Section 9.4)
some of your packages so that you can do a good job with the other packages
that you maintain. Alternatively you may ask the help of other people in order
to catch up the backlog of bugs that you have (you can ask for help on debian-qa@lists.debian.org
or debian-devel@lists.debian.org
).
If you choose to leave the Debian project, you should make sure you do the following steps:
debian-private@lists.debian.org
.
keyring-maint@debian.org
.
aph@debian.org
schwarz@debian.org
ijackson@gnu.ai.mit.edu