Bug#548867: Proposed patch to update Debian Developer's Duties chapter
Hi,
On Tue, 08 Mar 2011, Charles Plessy wrote:
> > +<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 ?
When I say "collaborate with the release team" it does not imply who is
contacting who. Arguably I have seen both happening: RT contacting
maintainers and maintainers contacting RT.
This is also only an introduction, the next paragaph goes into more
"concrete" details and it's clearer that we refer that the maintainer
should take the initiatives...
> > +<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).
I'm not digging in that level of details... and I'm pretty confident you are
not in-line with the consensus on that topic.
If I were to describe the case you mention, I would say that the duty of
the maintainer is to try to get the problem fixed either with the help of
upstream or with the help of Debian porters. I.e. at least seek for help
before deciding that you can't support it on a given architecture. That's
"work" too, "work towards" doesn't mean "fixing yourself".
> > +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.
I will add "or removing from testing", it's indeed a way to get a
problematic package out of the equation.
> > +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 ?
I don't think it's needed, the developers reference already has dedicated
sections for security updates and stable updates.
> > -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.
It's the worst scenario from the maintainer's point of view and it's the
one that I take when I write for maintainers. It's probably not the worst
scenario from the point of view of Debian as a whole, true.
> > +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 ?
Orphan it for a start. Removal will come later if no new maintainer is
found. Removal from testing might happen in the mean time.
> 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.
I have not seen major objections in your comments except that you don't
want to put "support the release team" as a duty but leave it up to each
maintainer.
Of course I don't support that point of view, but I shall add that the
developers-reference is not binding, it's "only" a set of best-practices
to ensure the project runs smoothly and in my opinion, supporting the
release team is part of this.
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Follow my Debian News ▶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)
Reply to: