Re: Debian reliability growth
On Fri, May 02, 2003 at 07:46:08AM +0200, Martin Schulze wrote:
> Remi Perrot wrote:
> > 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 when I say feature I mean more or less behavior. Do you mean that
abnormal behaviors should stay as is. I can see some rare cases when this
should be, but I think theres cases are so special that they shouldn't
block us on improving our processes. I also want to add that the severity
of a problem is very relative, so a 'Normal' bug for us can make the
package completely uninstalable or unusable for some body who haven't
our skill on Debian.
> > 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.
I agree this is very important, and I really would like to makes Debian
behaves as it should, but currently it still behaves has it does even if
it is a buggy behavior.
> > 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 agree that it would become very hard to follow changes without breaking
my previous assertion on not creating a new release. At now we have
Stable Stable-proposed-update, and Stable-security-update release. So if
a non security fix is done the package is uploaded in
Stable-proposed-update, then if security fix come there is now two
packages to fix, the Stable one and the Stable-proposed-update.
Maybe I misunderstanding something, but it looks like that we ever
work like this.
> > 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.
Infrastructure problem are always the easiest problem to resolve,
the harder to resolve is human resources lacks. Whatever, we have to
work out theres two problem if we want to progress.
> (Quoted from <http://www.debian.org/security/faq#oldversion>)
> 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 agree this is the right way to change things in stable, but this
shouldn't be restrict to security, but only security related problem
may justify to move a new upstream version in stable if backport of
security fix is not possible.
Maybe you think that today somebody ask to have all bug fixable in
stable, and if we go for this tomorrow somebody will ask to have new
upstream 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.
>
> 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.
I'm in strong disagree with this and I hope that am not contributing to
a project for which its only ambition is to become covered in dust.
I'm quite sure that this isn't the case as for this you may use other
distributions that gives lower assistance to users on packages
configuration. The value added on Debian became obvious if you do
many change on you system. Well I also know that the easy update
mechanism is a great thing for sensible machine and that must continue.
> > 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."?
Don't forget between past and future there is present and in my opinion
Woody is the present not the past. It's very uncomfortable to answer
this to you, Joey, with the great work you do every day for Woody (thanks
to you and to security team for this).
> That's quite a disturbing thought for me. This way, there's not going
> to be any new releases any time.
I pretend that if a Debian maintainer hasn't the skill, the time or the
material to work on the install process, as me, blocking bug fix on
stable will not makes Sarge release cycle shorter. This is the same with
fixing RC bugs of other packages than one's own. But of course I hope
that maintainers and other will continue to work on unstable. What I
want to demonstrate is that improving Stable will not slower the release
process.
> Hmm, I agree, in such a case
> something needs to be done with stable, but only in 1-2 years.
So lets say if Sarge isn't release in 2004 or before, all bug fix will
be accepted in stable-proposed-update ;-)
Even if we would have a consensus on my proposition now, I think that
building team, policy, processes and tools will take a least a Debian
year.
> > 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.
Thanks :-)
> If some people want to use your fixed packages, that's fine.
I have had 2 download on my package on Alioth but how many user of my
package know that bug fix are available on Alioth even if I had reported
it in the DBTS.
> 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.
Let's say backporting from unstable is off topic, I only mention it case
of a user who wants to get a bug fixed in stable by backporting himself
the package from Unstable. And no this is not the same to have an
official package and an unofficial one even if it is done by same
maintainer, as for example there will be no more update, even for
security on theres packages if the maintainer doesn't maintain it
anymore. The second major differences is there is no unified mirror, BTS
or mailing list, so I can say that is very far to be the same.
> This is a great service to our users in addition to the regular
> release, for those who would like to use them.
So let's institutionalize it.
> > 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)
I see no offense on this. The question is why users has started
reporting bugs only when the stable release was out. In my case this the
answerer is easy to find but off topic.
Sorry but I never had the idea to ask you why security bugs are not
fixed before Stable is out?
> 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.
I would never imagine how bugs could be a stretch in Debian. For a
commercial product I would understand it (of course it is never a stretch
for user). The sole plus I have on getting bug is that it is the only
feedback from user I have on my package.
> > 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.
So let's say that we are targeting to fix abnormal behavior, so Stable
will converge to a very reliable release.
Regards,
Rémi Perrot
Reply to: