Re: Debian reliability growth
On Wed, May 07, 2003 at 09:02:34PM +0300, jb@rk3-56-3.tky.hut.fi wrote:
> Very interresting...
>
> I see this as a sympton of a conflict of interrest, which I think has
> been around for some time, i.e. there are two main classes of users:
>
> 1) The conservative crowd, who are happy with the current situation.
> In fact, many of these people probably use debian precisely because of
> this hard earned reputation for quality and stability.
>
> 2) The desktop crowd, who want quicker updates (preferably without
> sacrificing quality).
I only accept this only as a rough way to depict two kind of users.
> I guess both groups have valid points and gripes. There have been
> efforts to shorten the release cycle (testing, etc.), but the steadily
> increasing number of packages and platforms have canceled benefits, so
> the 18 month release cycle still seems to be the norm.
After having thought again about that problem, I'm quite sure that it
isn't related to the time we need to make a new release. And as said
before that policy change on Stable shouldn't change the release cycle
time.
Reliability of a release grows slowly when RC and security bugs are
fixed in it, but when a new release comes out the reliability regresses
due to new added features, and because upstream has been tested for a
shorter time. Of course it is quite a lie as reliability may be estimate
in regard to the number of features. But even like this the impact of a
defect on reliability depends on many other factors like use cases. But
unfortunately we are quite sure that we will have more defects in the
new release than in the older one.
I'm afraid that trying to shorten to much the release cycle will produce
releases with even more defects. I'm not saying that release cycle should
be longer, since although we have more defects we also have more features,
and, I hope, we increase the usability of Debian.
I'm closer to Joey's point of view than it seems.
First I don't want new upstream versions in Stable, so if a bug is fixed
in a new upstream version, the fix should be extracted and applied to
the Debian package. The only exception for this, and it differ from the
security point of view, is when the new upstream consist only on bug
fixes which impacts Debian.
Bug fixes shouldn't change the package behavior and no new feature would
be allowed. If the package isn't a leaf in the Debian dependency tree,
all maintainer on which the fixed package depend directly or not would
have to approve the fix. Of course this will slower the acceptance of
the package, but remember there is no urgency. We may also think about
a committee-based decision process.
Unfortunately we lack user feedback and by the way don't know how are
used each Debian package. With better information on usage we would be
able to do some risk/impact analysis. Well, it doesn't matter, it's just
an idea thrown in the wild ?
> Release: Fully supported release with security AND bug fixes, like
> Remi suggested. Depending on upstream policy, why not new minor
> versions of packages instead of backporting fixes (perhaps this would
> reduce the burden on maintainers?)? And also, why not allow new
> packages to be added as long as they don't conflict with existing
> packages. Perhaps bugfixes and new packages could be added via point
> releases if continous addition is a bad idea?
I'm not for this in a first approach, as I think it may result on a
global quality downgrade. It would be easy to loose user trust on the
Debian project even if it affect a non essential part of the project.
I'm not sure we don't care. This is why I would only focus on bug fix.
> Stable: As a new release branch is made, the current release branch is
> renamed stable (and packages with RC bugs dropped?). Same policy as
> the current stable branch, but as the release branch has been in
> widespread use for quite some time most bugs and security issues have
> (hopefully) been corrected, so it would be of even higher quality than
> the current stable.
On second thought it looks better. And it is much simpler than what I
have in mind, but the result is more or less what I'm looking for. That
is to have opportunity to continue to improve stable reliability after
the deep freeze of testing and being able to answer user "a fixed Debian
package is provided under the umbrella of the Debian project".
> So what do you think of this? I think a scheme like this could fulfill the
> wishes of both groups. Desktop users could find somewhat newer software in
> the release branch, and conservative users could stay with stable.
> Additionally, upgrade-shy people could skip every other version. :)
That's fine.
> The big ifs, as I see it, are:
>
> 1) Does it increase the burden on developers too much? At least
> regarding security updates, it shouldn't, as security updates are
> still being done for potato.
I think we will continue to have old-stable in addition to this
> 2) How to achieve a faster relase of the release branch? AT has flamed
> many people to a crisp for making unsubstantiated suggestion re.
> testing, so maybe I'll pass and let other more knowledgeable people
> comment, if they wish..
We should go farther into automating test procedures. But this is an
other story.
Regards,
Remi Perrot
Reply to: