Bug#548867: Proposed patch to update Debian Developer's Duties chapter
On Sat, 12 Mar 2011, Charles Plessy wrote:
> I do not like for instance, the way you write:
>
> Lack of attention to RC bugs is grounds for the QA team to orphan the package.
>
> In the pledge that inspired your patch, you present orphaning by the QA as a
> sanction:
>
> [I will] not complain if the quality assurance team decides to orphan the package
>
> I do not think that this reflects reality. Perhaps I did not find the words,
> but for me, it sounds like a morale lesson: « If you do not maintain your
> package well, the QA team will take it from your hands and it will be your
> fault ».
Can you concentrate on the submitted patch and not on my initial pledge?
I agree my pledge sounds like a morale lesson, and Manoj Srivastava also
found it patronizing. That's why he rewrote it and he came up
with the wording "Lack of attention to RC bugs is grounds for the QA team
to orphan the package.".
See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=548867#10
That said I'm certainly open to rewrite it further. What about this:
---
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.
Don't be surprised if the MIA team enters in action and ends up orphaning
your packages (see <xref linkend="mia-qa" />). But you should really avoid
that situation in the first place and ensure that your packages get the attention
that they deserve.
---
> This is probably the last comment I send. For the moment you got one negative
> appreciation, and zero positive appreciation. Please focus on gathering
> positive appreciations, instead of sending your buddies explaining that the
> person giving the negative appreciation is wrong. Because even if my negative
> comments were wrong, you still have zero positive comments.
Stefano is the DPL, someone elected that is supposed to represent us all... not
my "buddy". Your tone in the end of the message is highly displeasing and not
at all constructive.
I have spent several hours drafting this in a way that ought to be acceptable by
the project at large. I hope some other people will comment and help get this
improved. But the way you framed this initial discussion doesn't make it
welcoming for other people to chime in...
I have attached the latest draft of my patch.
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Follow my Debian News ▶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)
commit 18db2dc72dcb1275ed868e6fb7ba941d9d09cae9
Author: Raphaël Hertzog <hertzog@debian.org>
Date: Mon Feb 28 23:02:46 2011 +0100
Document duties to wort towards the next stable release and to maintain the stable package
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 <hertzog@debian.org> Wed, 24 Nov 2010 23:54:39 +0100
diff --git a/developer-duties.dbk b/developer-duties.dbk
index f240890..e77519c 100644
--- a/developer-duties.dbk
+++ b/developer-duties.dbk
@@ -12,31 +12,76 @@
Social Contract by providing 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.
+Don't be surprised if the MIA team enters in action and ends up orphaning
+your packages (see <xref linkend="mia-qa" />). But you should really avoid
+that situation in the first place and ensure that your packages get the attention
+that they deserve.
</para>
</section>
Reply to: