From 604900e856cb82e4b8e31ee2c21d652958c5444d Mon Sep 17 00:00:00 2001 From: hertzog Date: Fri, 18 Mar 2011 11:18:02 +0000 Subject: [PATCH] Document duties to wort towards the next stable release and to maintain the stable package git-svn-id: svn://anonscm.debian.org/ddp/manuals/trunk/developers-reference@8579 313b444b-1b9f-4f58-a734-7bb04f332e8d --- debian/changelog | 2 ++ developer-duties.dbk | 83 +++++++++++++++++++++++++++++++++----------- 2 files changed, 65 insertions(+), 20 deletions(-) diff --git a/debian/changelog b/debian/changelog index 4b520bc..041b479 100644 --- a/debian/changelog +++ b/debian/changelog @@ -7,6 +7,8 @@ developers-reference (3.4.5) UNRELEASED; urgency=low [ Raphaël Hertzog ] * Rework section on "sponsoring packages" and include a basic checklist for the sponsor. Closes: #453313 + * Update the "Debian Developer's Duties" chapter to be more explicit + about duties of package maintainers. Closes: #548867 -- Raphaël Hertzog Wed, 24 Nov 2010 23:54:39 +0100 diff --git a/developer-duties.dbk b/developer-duties.dbk index cf85ffe..c8300f7 100644 --- a/developer-duties.dbk +++ b/developer-duties.dbk @@ -12,31 +12,74 @@ 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 ). + +
+
-Managing release-critical bugs +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 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). +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 ).
-- 2.30.2