[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

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.


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
    - 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: