Re: Debian reliability growth
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.
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.
>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.
(Quoted from <http://www.debian.org/security/faq#oldversion>)
Our users and developers are relying on the exact behaviour of a
release once it is made, so any change we make can possibly break
someone's system. This is especially true in case of libraries: make
sure you never change the Application Program Interface (API) or
Application Binary Interface (ABI), no matter how small the change is.
This means that moving to a new upstream version is not a good
solution, instead the relevant changes should be backported. Generally
upstream maintainers are willing to help if needed, if not the Debian
security team might be able to help.
> 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.
Debian stable is like a Cisco machine. You install/purchase it, you
configure it, you put it into a corner and forget about it (in case
for Debian except for security updates). You don't have to maintain
it too actively and can concentrate on the things that are important
to you or your business.
> 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.
Hmm. Did I read this correct as "Hey, since we can't improve the
future, let's fiddle with the past."? That's quite a disturbing
thought for me. This way, there's not going to be any new releases
any time. Hmm, I agree, in such a case something needs to be done
with stable, but only in 1-2 years.
> 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.
You are free to fix the problem and provide fixed packages, even if
they won't end up in the stable release. If some people want to use
your fixed packages, that's fine. There are backports of KDE, Snort,
Apache and Samba as well. The users who would like to use them, are
free to use them. They are even maintained since they are maintained
by the person who maintains these packages in unstable.
This is a great service to our users in addition to the regular
release, for those who would like to use them.
> 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.
> Reliability growth has a meaning only if we stay in feature freeze, so
> we should not change anything about "no new feature" policy.
Reliability also means that the behaviour doesn't change, so people
can base their tools and work on it. A constantly changing target
like unstable won't be able to provide this.
Regards,
Joey
--
Have you ever noticed that "General Public Licence" contains the word "Pub"?
Reply to: