Despite everything that's been said, I strongly support the idea of
'slowing down' a little, and having an -rc release before -final.
Perhaps things will now slow down anyway, since 2.4.x has hopefully
"made it" and won't be seeing radical changes under Marcelo's
stewardship.
But like it or not, 3 of the last 5 releases from 2.4.x have had
significantly embarrassing bugs / compilation issues, and I would hate
for this sort of thing to start tarnishing the reputation of Linux in
the media....
I have tended to track 2.4.x since the start, because it's been changing
and improving so rapidly. I know I *should* wait a few days before
building each new -final release, but let's be honest, lots of people
don't or won't, so it's important that they be of good quality.
Recently, I've started to run -pre kernels on production machines, like
some others by the sound of it. Let's slow down, consider an -rc
release and nail this little recurring problem!
Cheers
Alastair
(off to see if his 'greased-turkey' machine has safely got over the
filesystem corruption problem...)
o o o o o o o o o o o o o o o o o o o o o o o o o o o o
Alastair Stevens \ \
MRC Biostatistics Unit \ \___________ 01223 330383
Cambridge UK \___ http://www.mrc-bsu.cam.ac.uk
On Mon, 26 Nov 2001, Alastair Stevens wrote:
> I have tended to track 2.4.x since the start, because it's been changing
> and improving so rapidly. I know I *should* wait a few days before
> building each new -final release, but let's be honest, lots of people
> don't or won't, so it's important that they be of good quality.
Or maybe can't, as the new release may address problems that they've been
having with previous kernel revisions.
--
-- John E. Jasen ([email protected])
-- In theory, theory and practise are the same. In practise, they aren't.