[ previous ] [ Copyright Notice ] [ Contents ] [ next ]

Debian Developer's Reference
Chapter 3 Debian Developer's Duties


3.1 Maintaining Your Debian Information

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.


3.2 Maintaining Your Public Key

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.


3.3 Going On Vacation Gracefully

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.


3.4 Coordination With Upstream Developers

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.


3.5 Managing Release Critical Bugs

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).


3.6 Quality Assurance Effort

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).


3.7 Retiring Gracefully

If you choose to leave the Debian project, you should make sure you do the following steps:

  1. Orphan all your packages, as described in Orphaning a package, Section 9.4.
  2. Send an email about how you are leaving the project to debian-private@lists.debian.org.
  3. Notify the Debian key ring maintainers that you are leaving by emailing to keyring-maint@debian.org.


[ previous ] [ Copyright Notice ] [ Contents ] [ next ]
Debian Developer's Reference
ver. 2.7.2, 16 April, 2000
Adam Di Carlo, current maintainer aph@debian.org
Christian Schwarz schwarz@debian.org
Ian Jackson ijackson@gnu.ai.mit.edu