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. Yet another reason I _strongly_ urge you to mark your kernels with some type of "name" to help reduce the confusion of others that your kernels might be somehow associated with kernel.org releases. 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