X-Git-Url: http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?p=developers-reference.git;a=blobdiff_plain;f=developer-duties.dbk;h=27a7ff784303bcf921b588146cd7fac4e4d8c598;hp=b2d375fd00bd676f7a3b8093ee7794cbb6cb4145;hb=HEAD;hpb=eee80cde286181bc20d6f446a6cb6100027a5e53 diff --git a/developer-duties.dbk b/developer-duties.dbk index b2d375f..27a7ff7 100644 --- a/developer-duties.dbk +++ b/developer-duties.dbk @@ -5,6 +5,123 @@ ]> Debian Developer's Duties + +
+Package Maintainer's Duties +As a package maintainer, you're supposed to provide +high-quality packages that are well integrated +in the system and that adhere to the Debian Policy. + +
+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 their 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 their package. +The MIA team might also get involved, which could result in your packages +being orphaned (see ). + +
+ +
+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. + + +If you find that the upstream developers are or become hostile towards Debian +or the free software community, you may want to re-consider the need to +include the software in Debian. Sometimes the social cost to the +Debian community is not worth the benefits the software may bring. + +
+ +
+ +
+Administrative Duties +A project of the size of Debian relies on some administrative +infrastructure to keep track of everything. As a project member, you +have some duties to ensure everything keeps running smoothly. +
Maintaining your Debian information @@ -16,8 +133,7 @@ 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 -. +For more information about the database, please see .
@@ -26,7 +142,7 @@ For more information about the database, please see 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 +linkend="server-machines"/>). Back your keys up; keep a copy offline. Read the documentation that comes with your software; read the PGP FAQ. @@ -100,7 +216,7 @@ 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 +linkend="nmu"/>) 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. @@ -122,98 +238,87 @@ the on vacation flag when you come back! Ideally, you should sign up at the GPG coordination site when booking a +url="&url-gpg-coord;">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.
-
-Coordination with upstream developers +
+Retiring -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. +If you choose to leave the Debian project, you should make sure you do the +following steps: + + -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. +Orphan all your packages, as described in . + + -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. +Send an gpg-signed email about why you are leaving the project to +debian-private@&lists-host;. + + -If you find that the upstream developers are or become hostile towards Debian -or the free software community, you may want to re-consider the need to -include the software in Debian. Sometimes the social cost to the -Debian community is not worth the benefits the software may bring. +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). -
- -
-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-host;, 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). +If you received mails via a @debian.org e-mail alias (e.g. +press@debian.org) and would like to get removed, open a RT ticket for +the Debian System Administrators. Just send an e-mail to +&email-rt-dsa; with "Debian RT" somewhere in the subject stating +from which aliases you'd like to get removed. + + + + +It is important that the above process is followed, because finding inactive +developers and orphaning their packages takes significant time and effort.
-
-Retiring +
+Returning after retirement -If you choose to leave the Debian project, you should make sure you do the -following steps: +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: - + + -Orphan all your packages, as described in . +Contact &email-debian-account-manager;. -Send an gpg-signed email about why you are leaving the project to -debian-private@&lists-host;. +Go through a shortened NM process (to ensure that the returning developer +still knows important parts of P&P and T&S). -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). +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. + +