Re: [ 00/19] 3.10.1-stable review

[Benjamin Herrenschmidt]

On Fri, 2013-07-12 at 10:05 -0700, Greg Kroah-Hartman wrote:
> Specific example is, again, the powerpc patches.  Out of 21 patches
> marked for stable that showed up in the -rc1 merge, at least 7 of them
> had _plenty_ of time to get into 3.10.0 as they are weeks, and sometimes
> months, old.  Some of the other ones seem _very_ new, being only days
> old before they hit Linus's tree, which makes me worry about them for
> totally different reasons (i.e. not tested in linux-next at all.)

So for the old ones that's me not actively sending you stuff that has a
CC stable tag when I merge it. I should probably fix that indeed. This
is especially true of (but not exclusively) stuff that I don't apply
myself but merge via somebody else branch.

For the new stuff, this is a combinations of some last minute fuckups
which are pretty specific to 3.10 and for which I'm in part responsible,
and in part due to us basically ramping up testing on Power8 and getting
ready for the next RHEL & SLES at the same time, thus doing more testing
internally.

You'll notice that a lot of that stuff is P8 support so testing in
"next" isn't going to help much since nobody outside of IBM has access
to these guys yet. We are getting the stuff out there due to distro
unrealistic expectations of having upstream code for new machines years
before a release.

Also keep in mind that sometimes, that stuff has been around on
patchwork for a while and got tested by various people, but the patch
got a last minute rev of improved changeset comment or cosmetic polish.

> I can put a "delay" on patches to not hit a stable release for a few
> weeks until they get some testing in Linus's tree, but in reality,
> what's that going to help with?

Depends. In some of the patches I put in for stable, they fix something
that 3.10 broke and the fixes are quite self-contained, waiting makes no
sense.

At some stage I make a judgement call on a given patch, how "obvious"
the fix is (I know they never are completely ... well most of the time),
how invasive it is, what risk it represents outside of the are that it
"fixes". I do mistakes, but generally I am fairly conservative in that
area.

> I guess I can just not apply them at all, tough-love and all that, but
> that just puts an extra burden on the distro kernel maintainers to have
> to go dig up the fixes for their users.

You know how the distro can be about that... especially when they invent
idiotic junk such as kABI which prevents you from fixing things properly
for the sake of [probably illegal] binary drivers, and so on... Distro
seem to enjoy establishing a process that guarantee that an "enterprise
release" is entirely comprise of utter junk (not even talking about all
the in-house untested broken stupid crap they add to their kernels while
at the same time being hard-ass with fixes coming from the vendors).

> Although really, who cares about powerpc anymore :)

That was unfair :-)

Cheers,
Ben.


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