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=a8eb5b1d4572af81d4032326937d7ad2f96b64bd;hb=7ec99366f11ebbba12919979d3ada164594b4674;hpb=c755d20562708fe99969d9d5e4b985c370d28140
diff --git a/developer-duties.dbk b/developer-duties.dbk
index a8eb5b1..6b60b65 100644
--- a/developer-duties.dbk
+++ b/developer-duties.dbk
@@ -12,6 +12,107 @@
high-quality packages that are well integrated
in the system and that adhere to the Debian Policy.
+
+Work towards the next stable 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 stable
+
+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.
+
+
+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 his 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.
+
+
@@ -144,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
@@ -229,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.
+