Re: New stable version after Sarge
Paul van der Vlis(paul@vandervlis.nl)@2005-01-04 14:40:
> Hello,
>
> One of the biggest disadvantages of Debian for me is the long time it
> takes for a new stable version.
I guess one man's meat is another man's poison.
Since I administer a large number of distant computers I view the long
time between stable releases as a feature not a bug.
> What about saying something like: the next stable release comes in the
> beginning of 2006?
Once a year works for me, but any more frequent would be a pain in the
neck. Frankly a release every 18 months seems about right.
> I can understand something like "Debian releases when it's ready", but
> many people have to work together. Maybe it's better to say: "a package
> releases when it's ready, but the deadline for the next Debian release
> is a fixed date".
Also the concept of "releases when it's ready" seems to be a little
contrived. When *what* is ready exactly? The current system of
defining a release seems to involve identifying a number is arbitrarily
characteristics that will define the new version. The release occurs
when they are complete and the RC bug list is low.
Perhaps a date based release mechanism could be built using a new
distribution, call it prestable.
Packages qualify to be enter prestable after residing in testing for
ten days and having NO RC BUGS. The idea is to keep prestable in a
highly stable state at all times, a rolling stable if you will.
So a package follows the following path:
unstable --> testing --> prestable --(approx. 12 months)--> stable
People running servers (like myself) will stick with stable. Those
wanting a reasonably stable system but want the latest features run
prestable. Those wanting the very latest but don't care about RC bugs
run testing. Developers normally run unstable.
In some ways prestable would resemble the current stable when the
release manager has begun freezing it.
Of course one would not want prestable to be released with critical
components missing. To prevent such a thing a number of packages are
identified as release essential (RE). Every RE package
has to have migrated from testing to prestable for the annual release
to take place.
Any non-RE packages with RC bugs at release time simply do not make it
into the stable release for that year. If it looks like a critical
package will be ommited the release manager can always make that
package RE.
Although the target is for an annual release to occur, the proposed
mechanism also permits the project to identify a set of features for
the new release. For example, had prestable existed for 3.1 the new
installer would have been listed as RE.
So ... Debian would still release "when its ready" but everyone has a
better idea of what "ready" means simply by looking at the RE package
list.
Steve
Reply to: