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

[Matthias Andree <matthias.andree@gmx.de>]

On Mon, 05 Dec 2005, Lee Revell wrote:

> On Mon, 2005-12-05 at 17:44 +0100, Matthias Andree wrote:
> > This constant shifting the blame on someone else is becoming
> > offensive.
> > 
> > Diligent maintainers put "INCOMPATIBLE CHANGES" sections up front in
> > their release announcements or notes, that is the upstream
> > maintainer's chance to state "wpa_supplicant version >= 1.2.3
> > required" and really pass the buck on to the distros. Without such
> > upgrade-required-for: notes, it's just rude. "We break everything but
> > you need to find out for
> > yourself which..."
> > 
> 
> I'm not trying to shift blame, I am just saying that with their access
> to a larger hardware and user base the distros are in a much better
> position to regression test changes than the kernel developers.

You just described what shifting burden or blame means.

Are you seriously saying it's the distributors' fault for not trying the
random monkey patch on end users machines?

Heck, SUSE 9.2 ate a complete server because SUSE (they take the blame)
didn't manage to (1) notice in time, (2) therefore package a CRITICAL
(as in causes data corruption) MegaRAID bugfix. Do you really want such
things to happen as intrinsic part of the kernel development? Do the
upstream gurus such as Linus and Andrew want that? If so, they can say
so and we'll see the companies running for their sheer lives and putting
their money into other kernels.

BSD makes it only easier to provide binary modules, because you don't
even have to discuss with anyone if it's derived work or not, you can
just embrace, extend and lock the beast up and everyone in.

> And I didn't even mention the cases where the distros just don't do
> their homework.  For example in order to insulate users from internal
> changes ALSA has a kernel and userspace (alsa-lib) component and both
> must be upgraded in sync to properly support new hardware.  This is
> common knowledge.  But many distros keep shipping kernel upgrades that
> introduce new ALSA drivers but don't bother to make the kernel upgrade
> depend on an alsa-lib upgrade, or even to make a newer alsa-lib
> available.

Major distros usually aim for small and well-audited changes in order
not to make things worse, at least where end-user support is concerned.

Given the development pace and the ridiculous policy which is
effectively "you may break everything in the two weeks after release,
and we'll collect those fixes that come in until Linus's machine works
and ship without the rest".

Basically, no-one should have permission to touch any core parts, except
for fixes, until 2.7. Yes, that means going back to older models. Yes,
that means that the discussions will start all over. And yes, that means
that the cool stuff has to wait. Solution: release more often.

I'm so bold as to claim that a new minor release every 6 months with a
tight "only fixes allowed as core changes" policy would satisfy many. Of
course you cannot break the binary driver of the day that way, but it
also means fewer chances to break NFS, XFS, MegaRAID and whatnot.

-- 
Matthias Andree
-
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/