Re: Linux 2.4.21-rc8

From: John Bradford (
Date: Thu Jun 12 2003 - 03:59:56 EST

> Saying it is a bad idea to release a kernel with known bugs
> is like saying it is a bad idea to buy a computer when the
> price will be going down soon. Would you care to delay
> 2.4.21 until next spring or would you rather get the fixes
> it contains today and have 2.4.22 with your pet fix on
> (hopefully) a scale of weeks?

A lot of the known bugs have fixes which appear to be OK, but haven't
really had enough testing to go in to a -final tree. A lot of them
won't have been tested on SMP boxes for example.

What _would_ be nice would be to have a -$firstinitial$lastinitial
tree that opens up once we get in to the -rc phase - a kind of
'alternative rc' if you like, which collects all the patches that are
rejected for the official -rc tree. That gives the maintainers one
last chance to prove the validity of their patch :-).

Or, to look at it other way, it would be effectively carrying on the
-pre phase during the -rc phase:

E.G. 2.4.22 development could look like this:

                 | All potential patches are declared
                 V / here.
         | |
         V V
     2.4.22-rc2 2.4.22-jb2<-Absolutely nothing new goes in from
         | | here on, just fixes. If it breaks
         V V for more than 1 release, it's
       [snip] [snip] permenantly deleted from this -jb
         | | tree.
         V V
     2.4.22-rc5 2.4.22-jb7
         | |
         V V
         | ^
         V \--------------- Merge of whatever has survived
     2.4.22-rc7<-\ -jb
         | ---Delete
         V anything that's broken in any way, I.E. it has
     2.4.22-final to be perfect.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

This archive was generated by hypermail 2b29 : Sun Jun 15 2003 - 22:00:31 EST