Re: Debian reliability growth
On Fri, May 02, 2003 at 07:46:08AM +0200, Martin Schulze wrote:
> Remi Perrot wrote:
> > 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.
>
> If you install a Debian stable system, you are (more or less)
> guaranteed the system doesn't change its behaviour during its
> lifetime, except for security updates, corrections for severe problems
> and license violations.
Well, that is the aim. IMHO the version of Samba distributed with woody
is buggy to the point of being unsuitable for professional use. In that
particular case the maintainers have backported the latest releases to
woody -- these are essential, particularly in view of the fact that the
only other "official" package is the pre-release of Samba 3.0.
The problem as I see it is that users installing Debian have to find the
appropriate backports. They cannot simply install, update with the
security fixes and leave it. woody does not work "out of the box" as a
Samba server, and never will. And there are disadvantages to going down
the "unofficial backport" path, because the usual support mechanisms
(security fixes and bug reporting) are not available. And the risk of
the backport failing is perhaps greater than if the package had been
updated in stable, due to a smaller set of users (because some users
will not find the backports or will decide they do not need them, or
not even realise they might need them).
As for the example of a Cisco box, I would hope that if it were
corrupting data, Cisco would release a firmware update to address the
problem!
> This is quite important if you want to use a system or base a project
> on it, but don't want to check every month if the system, after an
> update, still behaves as it should. Even worse, if you have to expect
> that the system changes, people may not install security updates since
> this would retroactively creep in other changes that they would not
> want, hence, leaving their system vulnerable to more problems than it
> should.
I certainly appreciate this. People can get used to working round a
known set of bugs. It is embarrassing, though, if a supported fix is not
made available. Again, the user's choice is to sit tight and wait up to
2 years for the next full release (and I do not have a problem with the
long cycle for the full releases) or to try and find an unofficial
fixed/updated package for stable (or make their own fixed package). None
of the user's options strike me as ways that are at all likely to avoid
further problems.
> >>From a technical point, we don't have the infrastructure to build and
> largely test updates for stable as we have for unstable. Sometimes
> this badly affects security as well, unfortunately.
OK. There may be other ways of addressing the problem -- e.g. an
official list of the maintained backports on the web site.
[snip]
> > 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 question is, if the bug is so important for you, why didn't you
> fix it a couple of days before? Before the deep freeze? (this is
> plural you, not only addressed to you, Rémi) Also acknowledging that a
> stable release contains bugs, is strength not weakness. The
> particular bug report could even contain instructions on how to fix
> it or how to work around it.
Bugs may be discovered *after* the stable release, of course.
[snip]
Rob.
Reply to: