Unneeded RFC: Starting a stable kernel series off the 2.6 kernel

Unneeded RFC: Starting a stable kernel series off the 2.6 kernel

[Jonathan A. George]

This is really a silly discussion:

2.6.x release is the initial base for each stable release
    !with absolutely no intention of stalling non-useland API's!

2.6.x.y releases are the stability updates to the base release
    and in kernel API's will usually stay stable

If you want an ultra stable kernel you should start with the last stable 
release and start tracking what you consider critical fixes from the 
next base kernel (2.6.x) forward (essentially creating your own vendor 
branch).  Alternatively you should use a vendor branch which already 
does this for you with the addition of back porting important new device 
drivers (Debian Stable, RHEL, SLES, ...).

The 2.6 development model finally gives developers the ability to dump 
cruft, fix broken architecture, and add performance enhancements in a 
timely manor.  Linux development hasn't worked this well since 1.2 was 
small enough to test and release quickly.


OTOH it would be nice if core userland (libc, udev, binutils, 
shellutils) were managed as a single project (as with OpenBSD) so that 
userland breakage would be better managed. :-)

Re: Unneeded RFC: Starting a stable kernel series off the 2.6 kernel

[Rob Landley]

On Sunday 04 December 2005 10:24, Jonathan A. George wrote:
> OTOH it would be nice if core userland (libc, udev, binutils,
> shellutils) were managed as a single project (as with OpenBSD) so that
> userland breakage would be better managed. :-)

Well, there's always the combination of busybox and uClibc. :)

But we don't do gcc, binutils, and make.  (There's tcc, but it doesn't quite 
build the unmodified kernel yet, doesn't do make, and its optimizer still 
sucks pretty badly...)

Rob
-- 
Steve Ballmer: Innovation!  Inigo Montoya: You keep using that word.
I do not think it means what you think it means.