Bug#548867: Proposed patch to update Debian Developer's Duties chapter
tag 548867 + patch
thanks
Hello,
please find attatched 3 patches that try to update the Debian Developer's
Duties chapter to make it more clear that package maintainers have
responsibilities in making the next stable release happen and in
maintaining their packages in stable (and not only in unstable).
I have split it in two, one for duties related to package's maintainance
one for administrative duties.
The most interesting patch to review is the third one and it's this one
where I would like to have some feedback. In the absence of objections, I
will commit this sometimes next week.
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Follow my Debian News ▶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)
>From 514e0bcff568d1da5faa997125535adcf102927e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Rapha=C3=ABl=20Hertzog?= <hertzog@debian.org>
Date: Mon, 28 Feb 2011 21:41:35 +0100
Subject: [PATCH 1/3] Split the Developer's Duties chapter in two
One part on the technical work and one part on the administrative side.
Put the technical work first because that's the most interesting part
for the reader.
---
developer-duties.dbk | 17 +++++++++++++++++
1 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/developer-duties.dbk b/developer-duties.dbk
index f09e3cf..005350a 100644
--- a/developer-duties.dbk
+++ b/developer-duties.dbk
@@ -5,6 +5,22 @@
]>
<chapter id="developer-duties">
<title>Debian Developer's Duties</title>
+
+<section id="package-maintainer-duties">
+<title>Package Maintainer's Duties</title>
+<para>As a package maintainer, you're supposed to fulfill the Debian
+Social Contract by providing high-quality packages that are well integrated
+in the system and that adhere to the Debian Policy.</para>
+
+
+</section>
+
+<section id="administrative-duties">
+<title>Administrative Duties</title>
+<para>A project of the size of Debian relies on some administrative
+infrastructure to keep track of everything. As a project member, you
+have some duties to ensure everything keeps running smoothly.</para>
+
<section id="user-maint">
<title>Maintaining your Debian information</title>
<para>
@@ -214,6 +230,7 @@ RT' somewhere in the subject line (case doesn't matter).
</listitem>
</orderedlist>
</section>
+</section>
</chapter>
--
1.7.4.1
>From 069ef1ea0955c94111ff07adcaf89f5faa8a2ed0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Rapha=C3=ABl=20Hertzog?= <hertzog@debian.org>
Date: Mon, 28 Feb 2011 21:55:19 +0100
Subject: [PATCH 2/3] Move some sections around
Include the "Managing RC bugs" and "Coordinate with upstream" in the
"Package Maintainer's Duties" section.
---
developer-duties.dbk | 117 +++++++++++++++++++++++++-------------------------
1 files changed, 58 insertions(+), 59 deletions(-)
diff --git a/developer-duties.dbk b/developer-duties.dbk
index 005350a..f240890 100644
--- a/developer-duties.dbk
+++ b/developer-duties.dbk
@@ -12,6 +12,64 @@
Social Contract by providing high-quality packages that are well integrated
in the system and that adhere to the Debian Policy.</para>
+<section id="rc-bugs">
+<title>Managing 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).
+</para>
+</section>
+
+<section id="upstream-coordination">
+<title>Coordination with upstream developers</title>
+<para>
+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.
+</para>
+<para>
+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.
+</para>
+<para>
+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.
+</para>
+<para>
+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.
+</para>
+</section>
</section>
@@ -144,65 +202,6 @@ yet but where there are people who are interested in applying.
</para>
</section>
-<section id="upstream-coordination">
-<title>Coordination with upstream developers</title>
-<para>
-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.
-</para>
-<para>
-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.
-</para>
-<para>
-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.
-</para>
-<para>
-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.
-</para>
-</section>
-
-<section id="rc-bugs">
-<title>Managing 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).
-</para>
-</section>
-
<section id="s3.7">
<title>Retiring</title>
<para>
--
1.7.4.1
>From b8fd85287fd1f0b8cfd2f0f71564f28ed12d1449 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Rapha=C3=ABl=20Hertzog?= <hertzog@debian.org>
Date: Mon, 28 Feb 2011 23:02:46 +0100
Subject: [PATCH 3/3] Document duties to wort towards the next stable release and to maintain the stable package
---
developer-duties.dbk | 80 +++++++++++++++++++++++++++++++++++++------------
1 files changed, 60 insertions(+), 20 deletions(-)
diff --git a/developer-duties.dbk b/developer-duties.dbk
index f240890..81c538d 100644
--- a/developer-duties.dbk
+++ b/developer-duties.dbk
@@ -12,31 +12,71 @@
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) 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. 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 grounds for the QA team to orphan the
+package.
</para>
</section>
--
1.7.4.1
Reply to: