X-Git-Url: http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?p=developers-reference.git;a=blobdiff_plain;f=developer-duties.dbk;h=6b60b6554c68cd364f0652cb1b170fc129970fda;hp=c8300f7e52019f4332b05a47acf03716cddb540a;hb=7ec99366f11ebbba12919979d3ada164594b4674;hpb=604900e856cb82e4b8e31ee2c21d652958c5444d diff --git a/developer-duties.dbk b/developer-duties.dbk index c8300f7..6b60b65 100644 --- a/developer-duties.dbk +++ b/developer-duties.dbk @@ -13,20 +13,20 @@ high-quality packages that are well integrated in the system and that adhere to the Debian Policy.
-Work towards the next stable release +Work towards the next <literal>stable</literal> release -Providing high-quality packages in unstable is not enough, most users will +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 +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 +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 +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. @@ -34,20 +34,20 @@ given transition if you are not able to identify them.
-Maintain packages in stable +Maintain packages in <literal>stable</literal> Most of the package maintainer's work goes into providing updated -versions of packages in unstable, but his job also entails taking care -of the packages in the current stable release. +versions of packages in unstable, but his job also entails taking care +of the packages in the current stable release. -While changes in stable are discouraged, they are possible. Whenever a +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 +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 stable release team whether they would accept such an +update and then prepare a stable upload (see ).
@@ -60,20 +60,20 @@ Generally you should deal with bug reports on your packages as described in 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. +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 +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 +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. +can block the testing migration of many packages. Lack of attention to RC bugs is often interpreted by the QA team as a sign @@ -271,6 +271,44 @@ RT' somewhere in the subject line (case doesn't matter). + +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. +