Folks,
Can we celebrate getting to 2.4.20 with a really super-stable version of
the kernel, by only admitting patches that fix known and significant bugs
(that is, no new features, no more optimisations, no backports, no "it's
only a line" fixes)?
It would help 2.4 a lot, I think.
Ruth
On Fri, 29 Mar 2002, Ruth Ivimey-Cook wrote:
> Folks,
>
> Can we celebrate getting to 2.4.20 with a really super-stable version of
> the kernel, by only admitting patches that fix known and significant bugs
> (that is, no new features, no more optimisations, no backports, no "it's
> only a line" fixes)?
>
> It would help 2.4 a lot, I think.
>
I'd prefer that too! We've always cheered these x.y.20 versions for being
so stable (2.2.20 comes to mind). I hope we can keep up the tradition *g*
> > It would help 2.4 a lot, I think.
>
> I'd prefer that too! We've always cheered these x.y.20 versions for being
> so stable (2.2.20 comes to mind). I hope we can keep up the tradition *g*
Its somewhat naiive. If you have a hole in a bridge and someone tells you
that for stability you can only paint the bridge and tighten bolts you will
still have a very broke bridge. Ditto with software.
2.2.20 is stable because its been slowly refined to that and is now at the
point where on the hole the painting and bolt tightening is all that needs
doing. The 2.4 tree suffered serious earthquake damage in 2.4.10 which
hasn't entirely been fixed yet.
> [Alan:]
> 2.2.20 is stable because its been slowly refined to that and is now at the
> point where on the hole the painting and bolt tightening is all that needs
> doing. The 2.4 tree suffered serious earthquake damage in 2.4.10 which
> hasn't entirely been fixed yet.
>
Okay...ah...in this case: What, precisely, *is* the problem since 2.4.10 ?
Yours, MT
> > point where on the hole the painting and bolt tightening is all that needs
> > doing. The 2.4 tree suffered serious earthquake damage in 2.4.10 which
> > hasn't entirely been fixed yet.
>
> Okay...ah...in this case: What, precisely, *is* the problem since 2.4.10 ?
Linus changed the VM and chunks of the block layer in 2.4.10, that set back
stability work very seriously. It was a mistake but it happened, and most
of the repair work is done now. Not all of it. We've also gained things like
file system direct I/O as a result, so long term it may pay off, even
though it should have gone into 2.5 for stabilizing first
On Fri, 29 Mar 2002, Ruth Ivimey-Cook wrote:
> Can we celebrate getting to 2.4.20 with a really super-stable version of
> the kernel, by only admitting patches that fix known and significant
> bugs (that is, no new features, no more optimisations, no backports, no
> "it's only a line" fixes)?
>
> It would help 2.4 a lot, I think.
Not correct, you cannot have bugfixes-only if there are still
large structural things which need changes to work right on
some machines, eg. the VM.
regards,
Rik
--
Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/ http://distro.conectiva.com/
At 16:27 29/03/2002 +0000, Alan Cox wrote:
>Its somewhat naiive. If you have a hole in a bridge and someone tells you
>that for stability you can only paint the bridge and tighten bolts you will
>still have a very broke bridge. Ditto with software.
>
>2.2.20 is stable because its been slowly refined to that and is now at the
>point where on the hole the painting and bolt tightening is all that needs
>doing. The 2.4 tree suffered serious earthquake damage in 2.4.10 which
>hasn't entirely been fixed yet.
Please note I didn't say .20 *and all future versions*. I asked because it
just seems to me that while kernel 2.4 is definitely improving, it is being
pulled hard in 2 directions -- towards stability and towards 2.5.
I was hoping that, if we had a release that was focused on stability, the
current code base might get a longer testing phase, resulting in a better
code base overall.
I have been involved in professional software engineering for many years --
I know how things go and how basic structure affects things. However, I
also know (from my own experience) that bug fixing is not nearly as
exciting as developing some new feature, or getting a chunk of code "just
right", when it worked ok to begin with. My commercial experience is that,
at the end of a project, introducing significant changes of any type is
something you do rarely and with great care; even the best engineer
sometimes misses an important side-issue and messes up.
I guess I might be digging a hole here, but I'm trying hard to make Linux
better for us all.
Ruth
> Please note I didn't say .20 *and all future versions*. I asked because it
> just seems to me that while kernel 2.4 is definitely improving, it is being
> pulled hard in 2 directions -- towards stability and towards 2.5.
In a lot of cases like the USB stuff they are both the same thing. The
stuff filtering back is bug fixes found in the development tree and tested
by the lunatic fringe. The 2.4 -ac tree doesn't quite obey the rules but
the fun stuff like the O(1) scheduler code is stuff I don't intend to
push to Marcelo.
> I was hoping that, if we had a release that was focused on stability, the
> current code base might get a longer testing phase, resulting in a better
> code base overall.
That release is 2.4.* (or should be)
Alan