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 stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html