Bug#548867: Proposed patch to update Debian Developer's Duties chapter
Le Tue, Mar 01, 2011 at 10:14:19AM +0100, Raphael Hertzog a écrit :
>
> 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).
Bonjour Raphaël,
I have to admit that I have mixed feelings with your patch. This is why I
waited a week to let others give more positive comments first. But since there
are no comments, I will give mine.
I checked our Social Contract and Constitution, and did not find a special
emphasis on the stable release. In particular, the Constitution defines
developers as people producing packages or making useful work according to the
Delegates in charge of the new members.
We had the case two years ago that it was announced abruptly (but reversed
later) that the next freeze would take place only 6 monthes after the release.
We are a do-o-craty, and I think that it is important that following such
decisions is an opt-in process, where developers who disagree can simply focus
on other useful work instead of being bound to the new strategy. More in
general, I have seen people (including myself) using the proximity of a release
as an argument to delay or cancel unrelated works. Making a duty of supporting
the release process may give more grounds to that kind of argument.
More in general, since some of your additions are naming some teams that we
need to support, I think that it would be necessary that they give their
opinion on how it is formulated.
Since the take home message of your patch is to not be a burden to others,
I propose to refocus on this.
> +<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.
My experience is rather the contrary: I am more often asking the RT to include
my packages in stable than the RT is asking me to make sure that my package
will be part of Stable. Perhaps we should recommend to not harrass the release
team for including the latest versions of our packages ?
> +<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.
I have a long-standing disagreement that when a package has build problem on an
achitecture where there is no evidence for users of that package, the
responsibilities are reversed and it should be to the porters to demonstrate
that it is necessary to build the package on their favorite architecture. (It
happens from time to time that a package starts to FTBFS, not for a new bug,
but because of an improvement of its regression tests, which demonstrate that
on the arch where it fails to build, it was already unusable in the previous
versions).
> +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.
I agree that we should give a particular care to the packages on which our own
packages depend. But for the transitions, the blockers may be collaterals. In
some cases, from the point of view of the blocked packages, it may be
equivalent to fix or remove the blocker packages.
> +<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"/>).
Perhaps members of the Stable and Security teams can comment if they would like
to add more details to this ?
> -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.
> +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.
I do not think that a removal is the worst scenario, since if it is done early
enough it means that the bug does not delay the release, nor takes the time
of other people.
> +Lack of attention to RC bugs is grounds for the QA team to orphan the
> +package.
I think that we need the input of the QA team there. Orphaning a package does
not fix its bugs. If a package is buggy, abandonned and not essential, will the
QA team orphan it or remove it ?
I do not have time to propose a wording this morning, but if for some part you
agree with my comments, please do not hesitate to ask me for some more
formatted input.
Have a nice day,
--
Charles Plessy
Tsurumi, Kanagawa, Japan
Reply to: