Debian reliability growth
I want, with this mail, to start a campaign on improving Debian
reliability.
Policy on improving stable release are, in my humble opinion, too
restrictive and don't give the opportunity to improve Debian quality out
of security fix. I think that as release cycle is very long we have to
accept fix on all bugs in Stable.
I know of two reasons why we are not doing this:
The first one is that when we are working on Stable, we are not working
on Unstable/Testing and this way we make the release cycle longer.
Of course I don't agree, as unfortunately few of us do work on Release
Critical Bugs of other packages and even fewer can work on
debian-installer. As they are the most critical issues we need to solve
for a new release, improving stable will not slow so much Sarge release.
The second reason is that it may result more damage than improvement
from changing something in Stable. Saying it like this is right, as many
things may happen, but by using a good process we may reduce the risk.
In the other hand being to much restrictive on improving Stable means
that we don't trust ourselves and that there is no alternative between
no change at all and being out off control.
Can we continue to tell Debian users "thanks for reporting bug on Woody
but even if this bug is annoying and fixable it will never be fixed
before the next stable release" ? Can we continue to say that the bug
is fix in Unstable/Testing but of course theses distribution are known
to be less stable than Stable so use it with care ? You also know that
back porting package from Unstable becomes harder when Unstable
progresses.
We also need some collaboration from the BTS and katie/dinstall,
to not get a bug closed when a fixed version is uploaded into
Unstable, but only marked as being fixed there, so that users can know
the bug has already been reported and does impact Stable.
Having open bugs on Woody also gives me some bad feelings, as some users
trust us to provide them a quality product, but from the moment we
switch into deep freeze state only critical or security fixes can be
done, so we can roughly say that quality is also freeze.
The only help we can provide to users is ad-hoc help, or in other
words, maintain unofficial packages. This can now be done by using
Alioth, but this stays unofficial and for that to work the user has to
trust maintainer instead of trusting the Debian group, and this is
weaker.
I think we shouldn't provide a new release for this as it will be very
hard for most of us to maintain up to 3 releases (Stable, Frozen and
Unstable) so fixes on stable should stay in proposed-updates and then
migrate smoothly into Stable if they are not known to cause more trouble
than improvement.
Reliability growth has a meaning only if we stay in feature freeze, so
we should not change anything about "no new feature" policy.
The next, harder thing to do is to find a way to deal with regressions
and their consequences. Maybe we will have to look how deep the changed
packages are in the dependency tree. We may also let maintainers
quantify the confidence they have on their fixes. I other words, we will
have to think about impact analysis.
But whatever we choose, staying so rigid on Stable is more and more
difficult to justify, so we need to think on how to change this.
Regards,
Rémi Perrot
Reply to: