Re: New stable version after Sarge
Jose Carlos Garcia Sogo wrote:
Which will mean that people will skip at least one distribution if we
released each 6 months, even two. That would put the burden on us of
needing to have security support for even 2 more distributions older
than current stable, which could not be possible.
ACK to this (and most other things you wrote).
Most software projects and distributions - commercial and OSS/GPL -
typically have only 2-3 versions under active development or
maintainance. More is not possible.
That's why I think that a 18 months release is the best compromise
between server and desktop users.
This can be too long for both - servers and desktop. On servers it is
IMHO a less important problem, as mostly only a few packages with newest
features are needed.
Other option could be make a splitted release. For example, release
base+server each 18 months and make a debian-desktop release each 6, but
this has also other side effects and implications which are not easily
handled.
This would mean, that the 3 archives (stable, testing, unstable) move to
4 archives.
Instead of an extra desktop release I would like an idea like this:
- unstable
- testing
- pre-stable
- stable
For unstable the role is the same: a kind of sanity check, and a package
moves to testing after 10-20 days, if no critical or important bugs known.
For the move from testing to pre-stable different rules can apply. E.g.
for new major (=redesign) releases of server/essential/important
packages the minimum testing time should be 3 months (or more - to be
defined). Typical examples are Apache 1.x -> 2.x, kernel 2.4 -> 2.6,
DRBD 0.6 -> 0.7, or the upcoming release of heartbeat 2.0.
Desktop or utilty packages, where a crash would be less important, can
have softer quality rules. E.g. I always experienced crashes with
Netscape/Mozilla/Thunderbird, independant if they where included in
stable, testing or whatelse - who cares.
Pre-stable would be nearly the same, what Sarge now _temporarly_ is -
the place for preparation of a stable release.
To avoid the split into 4 archives, the only alternative seems IMHO
stronger rules for the move from unstable to testing. The rules could be
like these rules, which apply for Sarge now in pre-release state.
- A well known date for the freeze. About a year from Sarge release
if we want to release in 18 months.
ACK.
The installer should be ready when the
freeze, having some months then to check and polish.
[...]
- "Release essential" packages should be kept mostly free of RC
bugs.
[...]
- For other packages, discourage maintainers to make hughe changes
if not needed, but evolve them.
[...]
Of course I know that all we are voluteers, and that it is a bit
difficult to enforce a calendar as if we were a corporation,
Major releases (=redesigns) of complex software need a minimum of time
to develop (~1 year), test and polish (~6 months and more). Knowing both
cultures there is IMHO no essential difference between volunteers and
corporations in the minimum time to reach stable quality.
Helmut Wollmersdorfer
Reply to: