chiark / gitweb /
Document duties to wort towards the next stable release and to maintain the stable...
authorhertzog <hertzog@313b444b-1b9f-4f58-a734-7bb04f332e8d>
Fri, 18 Mar 2011 11:18:02 +0000 (11:18 +0000)
committerhertzog <hertzog@313b444b-1b9f-4f58-a734-7bb04f332e8d>
Fri, 18 Mar 2011 11:18:02 +0000 (11:18 +0000)
git-svn-id: svn://anonscm.debian.org/ddp/manuals/trunk/developers-reference@8579 313b444b-1b9f-4f58-a734-7bb04f332e8d

debian/changelog
developer-duties.dbk

index 4b520bc..041b479 100644 (file)
@@ -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 <hertzog@debian.org>  Wed, 24 Nov 2010 23:54:39 +0100
 
index cf85ffe..c8300f7 100644 (file)
 high-quality packages that are well integrated
 in the system and that adhere to the Debian Policy.</para>
 
+<section id="help-release">
+<title>Work towards the next stable release</title>
+<para>
+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.
+</para>
+<para>
+More concretely, you should monitor whether your packages are migrating
+to testing (see <xref linkend="testing"/>). 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.
+</para>
+</section>
+
+<section id="maintain-stable">
+<title>Maintain packages in stable</title>
+<para>
+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.
+</para>
+<para>
+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 <xref linkend="bug-security"/>). 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 <xref
+linkend="upload-stable"/>).
+</para>
+</section>
+
 <section id="rc-bugs">
-<title>Managing release-critical bugs</title>
+<title>Manage release-critical bugs</title>
 <para>
 Generally you should deal with bug reports on your packages as described in
 <xref linkend="bug-handling"/>.  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 <literal>critical</literal>,
-<literal>grave</literal> or <literal>serious</literal> 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.
-</para>
-<para>
-Developers who are part of the <ulink url="&url-debian-qa;">Quality
-Assurance</ulink> 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
-<email>debian-qa@&lists-host;</email>, 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 <xref
-linkend="nmu"/>) 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 <literal>critical</literal>,
+<literal>grave</literal> or <literal>serious</literal> 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.
+</para>
+<para>
+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 <xref linkend="nmu"/>) because they
+can block the testing migration of many packages.
+</para>
+<para>
+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 <xref linkend="mia-qa" />).
 </para>
 </section>