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
-- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
