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
- 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/
This archive was generated by hypermail 2b29 : Fri Nov 30 2001 - 21:00:19 EST