Re: stable cc's in linux -next was Re: [BUG] x86: bootmem brokenon SGI UV

From: Greg KH
Date: Mon Oct 11 2010 - 13:40:48 EST


On Mon, Oct 11, 2010 at 10:18:34AM -0700, Linus Torvalds wrote:
> And I suspect that from a social standpoint, if we delay the stable
> queue auto-patch-sending, it will just lead to people trying to bypass
> that delay by sending things directly to stable rather than depending
> on the "stable@xxxxxxxxxx" tag on the commit itself. Or if the delay
> is implemented on the stable email address itself, then people would
> try to just send it directly to you instead.

I agree, that would just get messier.

> It doesn't help that the number of patches in a stable release is much
> bigger than at least I personally envisioned. Yes, many of them are
> things like adding device ID's etc, but I do suspect that it just then
> makes it much harder to try to delay things by a week or something.
> Plus some problems probably wouldn't even be noticed in a week in the
> development kernel, and they'd _still_ be found only once it hits
> stable just because lots of people will obviously never test the
> development kernel.

The "largeness" of recent stable kernel releases (i.e. for the past
year) seem more to be a factor of the subsystem maintainers finally
realizing that they should be sending their bugfixes to me (thanks a
large part to Andrew's constant badgering about this), combined with the
distros sending me their bugfixes that they have found that are already
included upstream.

> So I have no solution to it. I just don't think stable has been quite
> as stable as people would wish for.

It hasn't? I haven't heard people saying anything about this before, in
fact, people seem to get upset at me when I reject the stuff they are
sending me for inclusion which don't meet the stable criteria.

Not that I'm trying to say, "it could be worse", just that, "what could
be done better?"

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/