Re: Question for all candidates: Release process
Le Sun, Mar 14, 2010 at 02:44:15PM -0700, Russ Allbery a écrit :
>
> Releasing is regularly the hardest thing that Debian does, not just
> technically but also socially. Apart from the standard issues of setting
> deadlines, RC bug counts being high, and similar difficult technical
> issues, the process seems to eat volunteers.
Dear Russ and everybody,
I think that our release process is manpower-hungry by design, and that the
more packages and architectures we have, the harder the release is. I propose
to refocus our efforts.
Solving a thousand of RC bugs is a herculean task for a small group of persons.
But why should they do that in the first place? Most of these bugs are the
responsibility of the package maintainers. If they can not make their package
ready for the release, will they be able to help for stable support? Who will
do that work?
I propose that we reshape the sections and priorities of our archive, so that
it is easy to remove from Testing any RC bug that is not in a core pakcage,
and is old and not tagged RFH. In parallel, I propose that the definition
of what the ‘core’ is can vary between architectures.
The goal is not only to reduce the workload of the release team and the
porters. It is also to give some meaning to the presence of a package in a
stable release. These packages must be there because there is agreement that
enough users are insterested in it, and are comfortable with the idea to keep it
at the same version for a long time.
For many peripheral leafs and branches of our dependancy tree, let's innovate
and distribute them through other channels, like official backports and even
the new snapshot system that is being set up. When all of this is aptable from
the official Debian mirrors, it will open great opportunities to build tailored
Debian systems, for instance with the ‘blends’ framework.
Debian is volunteer-driven, so the release can only happen by coordination.
Acutally, it is a coordination process by nature: a release is a moment in the
development where all the core components work well together. If these
components evolve independantly, it will hardly happen by chance. Motivation
must be there on both ends. This is why I propose to limit the release to
the packages where there is a real motivation for it. When maintainers feel the
need for a release, they will have to talk to the others and eventually make
concessions on their timeline. Not to mention that for many of our packages,
there is actualy nobody who regularly cares for them anymore. In that sense, I
think that membership issues are one of the roots of our difficulties to
release.
As a DPL I will help the Project to evolve its release and membership process
through my constitutional roles: leadership in discussions, GRs, and
delegations. I expect as a result that the release work will become much more
social than technical, with all participants doing their part of the
housekeeping work.
Have a nice day,
--
Charles Plessy
Tsurumi, Kanagawa, Japan
Reply to: