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=f09e3cf09ab1002607f9813a2cd312c55a79f16d;hb=refs%2Fheads%2Fmaster;hpb=39f9d44a972a229e8d148d5bc9adc5210e5c7c60 diff --git a/developer-duties.dbk b/developer-duties.dbk index f09e3cf..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 @@ -128,65 +245,6 @@ yet but where there are people who are interested in applying.
-
-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. - -
- -
-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). - -
-
Retiring @@ -212,7 +270,55 @@ in Debian RT by sending a mail to &email-keyring; with the words 'Debian RT' somewhere in the subject line (case doesn't matter). + + +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. + +
+ +
+Returning after retirement + +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: + + + + + +Contact &email-debian-account-manager;. + + + + +Go through a shortened NM process (to ensure that the returning developer +still knows important parts of P&P and T&S). + + + + +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. + +