On Tue, Oct 14, 2014 at 10:58:41AM +0200, Luis Henriques wrote: > On Tue, Oct 14, 2014 at 03:52:33AM +0200, Greg Kroah-Hartman wrote: > > On Mon, Oct 13, 2014 at 10:31:03AM -0700, Kamal Mostafa wrote: > > > On Fri, 2014-10-10 at 07:30 +0200, Willy Tarreau wrote: > > > > Hi Kamal, > > > > > > > > [ removed Don Bailey from the CC who's certainly not interested in this ] > > > > > > > > On Thu, Oct 09, 2014 at 02:03:08PM -0700, Kamal Mostafa wrote: > > > > > 3.13.11.9 -stable review patch. If anyone has any objections, please let me know. > > > > > > > > > > ------------------ > > > > > > > > > > From: Willy Tarreau <w@xxxxxx> > > > > > > > > > > commit 72cf90124e87d975d0b2114d930808c58b4c05e4 upstream. > > > > > > > > (...) > > > > > > Hi Willy- > > > > > > Thanks very much for reviewing this. > > > > > > > This one (and the accompanying revert) are still not present in more > > > > recent stable kernels, so I find it surprizing that you're proposing > > > > to integrate them now. > > > > > > I can hold out those lzo fixes until the next 3.13-stable if you prefer. > > > > Please do so. > > > > > But fwiw... > > > > > > > If someone upgrades from 3.13.11.9 to 3.14.21 > > > > or 3.16.5, they'd expect to keep all fixes but will lose this one, so > > > > this is a bit confusing. > > > > > > I think those sorts of scheduling mismatches and discrepancies between > > > stable versions are pretty common. Examples: The top 11 commits in > > > v3.12.30 have not yet been applied[0] to any of the newer stable > > > branches; > > > > Those -mm patches from Mel are "special", I'm taking it slow in merging > > them, doing lots of local testing and code review, and not all of them > > even are relevant for 3.14, so don't take the acceptance / > > non-acceptance of them as any kind of "proof" of anything at all. > > > > > Many of the commits in v3.10.57 have not yet been applied[1] > > > to linux-3.12.y but have been released in other newer stables. > > > > That's because I am ahead of Jiri, which will almost always happen due > > to our different workflows and time available to spend on stable > > kernels. > > > > > > Is there any reason you're not tracking fixes > > > > from more recent versions like Jiri, Li, Ben and I are doing ? > > > > > > We (the Canonical stable maintainers) have always tracked the "cc: > > > stable" fixes directly from mainline, not from the more-recent-version > > > branches. Given the examples above, it seems that the kernel.org > > > maintainers are doing that too, yes? > > > > You have included patches in your release that are not in _any_ public > > release on kernel.org yet. Which is fine, you are allowed to do > > whatever you want, but that goes against the existing rules of stable > > patches that we have been following for well over the past year for when > > it is acceptable to add a patch to a stable release. > > > > Could you please provide us with examples of commits in one of our > extended stable trees that is not on any other public release at > kernel.org? We really try hard to follow the process defined for the > official stable kernels, so if this has happen in the past it was > definitely a mistake from our side, and we would love to get your > feedback during the review cycles. I don't really know, and honestly, don't care to spend the time and energy to dig through to find this out. The lzo ones jumped out at me as I know the history behind them, and if you note, _I_ even didn't put them in a stable kernel yet, as they have not shown up in a release from Linus. As the maintainer involved didn't ask you to go against the well-known stable tree rules, that's a warning to others that perhaps something is wrong here... best of luck, greg k-h -- 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