"stable-test"? (WAS: Re: Danger Will Robinson! Danger!)
At the place where I work they still have a number of machines running
an ancient Linux distribution called "FT" with the 1.2.13 kernel. The
machines work perfectly. In fact, they work a lot better than the Red
Hat 6.0 machines in some respects: there are a number of things (xfs,
lpr with Netware printer, ...) which seem to be broken in Red Hat 6.0,
but they work fine on the old "FT" 1.2.13 machines.
Generally I prefer a high-quality and well-tested distribution to one
that has the very latest version of everything. If there's a
particular program that I need the latest version of, then I build
that program from source.
How many people will actually need a feature from the 2.4 kernel when
it appears? Not many, I would guess. It's very easy to build the
kernel from source, so let those people do it.
At the same time, I can't say I'm totally happy with the Debian
release policy. Perhaps there should be some kind of non-security
upgrades to stable.
The concept of a Debian release is really only important where complex
dependencies between packages are concerned. Packages on which no
other package depends could be upgraded independently of each other
while the packages they depend on remain unchanged or receive only
minor, security updates. To implement this you might have a separate
Debian version called "stable-test" where such packages go for
testing. When the package maintainer is confident that the version in
stable-test is in every way superior to the version in stable, he asks
the release manager to move it from stable-test into stable. Many
users would dist-upgrade to "stable" from time to time and upgrade
particular packages they are interesed in from stable-test. For real
hackers there would still be "unstable" and "frozen", too.
Edmund
Reply to: