Re: Debian reliability growth
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 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.
Also, some in group #1 are apparently not entirely happy with the release
cycle, they want an even longer lifespan of a release. As I understand it,
debian got some amount of flack because security updates for slink were
stopped quite soon after potato released, and currently the situation is
that potato security updates are to be done at least until August 2003 (?),
about a year after the woody release.
Could the wishes of both these groups be satisfied with two supported
releases? Let me explain. Debian would then have four branches:
Unstable: No change from the current situation
Testing: As currently, but with relaxed requirements/more manual
intervention/something else so that a release can be made faster
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?
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.
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. :)
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.
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..
--
Janne
Reply to: