Re: Kernel Releases

[Phil Sorber <aafes@psu.edu>]

[-- Attachment #1: Type: text/plain, Size: 2845 bytes --]

i know this is an old thread now, but i thought of something that might
be a nice feature, though it means more work for kernel maintainers.

a bug patch seperate from the new kernel patch. so you could only
upgrade from 2.4.0 with the bug fixes in 2.4.1. by the time you're at
something like 2.4.15, 2.4.0 should be rock solid. but you wouldn't have
any new funcionality.

say you wanted the new VM. you could upgrade to the first kernel with
the new VM, then get the bug patch for the latest kernel.

not a simple straigt forward idea, and it could mean a lot of work.
though maybe it is easier than i realize, or a few orders of magnitude
harder than i realize, and thus not worth it.

i've noticed that the 'aa' patch series seems to be something along
these lines.

On Sat, 2001-11-24 at 23:27, David Relson wrote:
> Greetings to All,
> 
> Over the past few months, I've been listening in on LKML, with occasional, 
> minor comments - mostly to help newbies.  Now, I think it's time for a 
> suggestion ...
> 
> As we all know, several of the recent releases have had defects that have 
> __required__ patches before they could be built (or used safely).  Problems 
> with symlinks, loopbacks, and unmount come to mind as being like 
> this.  They are all show stoppers that required immediate fixes and the 
> creation of a new release or of the next -pre1 version.
> 
> I have a tendency to tink that it's better to be running a released kernel, 
> than a pre-release kernel.  I'd much rather be running a kernel named 2.4.x 
> than a kernel named 2.4.y-pre?.  With the recent problems, the working 
> versions tend to be the -pre1 or -pre2 releases, not the released 
> one.  With a bit of QA, I think we can have 2.4.x releases be the stable 
> releases.  Here's how...
> 
> When the kernel maintainer, now Marcelo for 2.4, is ready to release the 
> next kernel, for example 2.4.16, I suggest he switch from "pre?" to "-rc1" 
> (as in release candidate).  A day or two with -rc1 will quickly show if it 
> has a show stopper.  If so, then the minor fixes (and nothing else) go into 
> -rc2.  A day or two ..., and either -rc3 appears or we have a stable 
> release and 2.4.16 is ready to be released.
> 
> Let's go the extra distance and have the releases be usable, stable 
> kernels!  It's what users want and it's within the abilities of the 
> developers to produce.  Let's do it :-)
> 
> David
> 
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 
-- 
Phil Sorber
AIM: PSUdaemon
IRC: irc.openprojects.net #psulug PSUdaemon
GnuPG: keyserver - pgp.mit.edu

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]