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 address, your country, the latitude and longitude
of 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 at 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 signatures to your public key, or add user identities, you can
update the debian keyring 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, send mail 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 developers take vacations, and 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 (see Non-Maintainer Uploads (NMUs), Chapter 7) 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. Be aware that some
people don't care for vacation notices and don't want to read them; you should
prepend "[VAC] " to the subject of your message so that it can be
easily filtered.
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. Debian users will sometimes report bugs to the Bug Tracking System that are not specific to Debian. You must forward these bug reports to the upstream developers so that they can be fixed in a future release. It's not your job to fix non-Debian specific bugs. However, if you are able to do so, you are encouraged to contribute to upstream development of the package by providing a fix for the bug. Debian users and developers will often submit patches to fix upstream bugs, and you should evaluate and forward these patches upstream.
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 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.
Release Critical Bugs (RCB) are all bugs that have severity critical,
grave or serious. Those 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. 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 whenever they are able. 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 explain your difficulties and present a plan to fix them by sending a mail
to the proper bug report. Otherwise, people from the QA group may want to do a
Non-Maintainer Upload (see Non-Maintainer Uploads
(NMUs), Chapter 7) 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).
Even though there is a dedicated group of people for Quality Assurance, QA
duties are not reserved solely for them. You can participate in this effort by
keeping your packages as bug-free as possible, and as lintian-clean (see Lintian reports, Section
10.5) as possible. If you do not find that possible, then you should
consider orphaning some of your packages (see Orphaning a package, Section
9.4). 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 notice that a package is lacking maintenance, you should make sure the maintainer is active and will continue to work on his packages. Try contacting him yourself.
If you do not get a reply after a few weeks you should collect all useful
information about this maintainer. Start by logging into the Debian Developer's Database
and doing
a full search to check whether the maintainer is on vacation and when he was
last seen. Collect any important package names he maintains and any Release
Critical bugs filled against them.
Send all this information to debian-qa@lists.debian.org
,
in order to let the QA people do whatever is needed.
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
.
Debian Developer's Reference
ver. 2.11, 08 April, 2002aph@debian.org
schwarz@debian.org
ijackson@gnu.ai.mit.edu