Request for 2.4.20 to be a non-trivial-bugfixes-only version

Request for 2.4.20 to be a non-trivial-bugfixes-only version

[Ruth Ivimey-Cook]

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

Re: Request for 2.4.20 to be a non-trivial-bugfixes-only version

[mtopper]

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*

Re: Request for 2.4.20 to be a non-trivial-bugfixes-only version

[Alan Cox]

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

Re: Request for 2.4.20 to be a non-trivial-bugfixes-only version

[mtopper]

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

Re: Request for 2.4.20 to be a non-trivial-bugfixes-only version

[Alan Cox]

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

Re: Request for 2.4.20 to be a non-trivial-bugfixes-only version

[Rik van Riel]

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/

Re: Request for 2.4.20 to be a non-trivial-bugfixes-only version

[Ruth Ivimey-Cook]

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

Re: Request for 2.4.20 to be a non-trivial-bugfixes-only

[Alan Cox]

> 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

Re: Request for 2.4.20 to be a non-trivial-bugfixes-only

[Henning P. Schmiedehausen]

Ruth Ivimey-Cook <Ruth.Ivimey-Cook@ivimey.org> writes:

>fixed bugs I might hit next. Problem is, I have been looking for the 'good' 
>kernel for a while: trying 2.4.6, 2.4.8, 2.4.15, 2.4.17, 2.4.18rc1 -- I'm 
>starting to wonder when it might get here.

2.4.19-pre4-ac2 is the first kernel since ages that is able to boot up on
an Intel SC5x00 server with SDS2 board without either

- losing one processor
- losing one gig of RAM
- locking up in highmem
- locking up when loading the GDTH driver

2x 1,13GHz PIII Processor, 2 GB RAM, ServerWorks OSB5 chipset, GDTH
8523RZ controller driving four 36 GB U160 disks). Nice little box for
kernel compiles (actually it is a java application server running
apache / tomcat and various webapps, but until our stability issues
are ironed out I can play with it). 2.4.19pre4ac2 survived the
stress-kernel test from VA Linux for hours. Something no other kernel
in the 2.4 series was able to do. Now if I could please get a sensor
driver for the ADM1026...

	Regards
		Henning
-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen       -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH     hps@intermeta.de

Am Schwabachgrund 22  Fon.: 09131 / 50654-0   info@intermeta.de
D-91054 Buckenhof     Fax.: 09131 / 50654-20