On Tue, Jul 16, 2013 at 3:43 AM, James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote: > On Mon, 2013-07-15 at 23:20 -0700, Greg KH wrote: >> On Tue, Jul 16, 2013 at 09:17:32AM +0400, James Bottomley wrote: >> > On Mon, 2013-07-15 at 14:44 -0700, Greg KH wrote: >> > > On Mon, Jul 15, 2013 at 11:27:56PM +0400, James Bottomley wrote: >> > > > Before the "3.10.1-stable review" thread degenerated into a disagreement >> > > > about habits of politeness, there were some solid points being made >> > > > which, I think, bear consideration and which may now be lost. >> > > > >> > > > The problem, as Ji???? Kosina put is succinctly is that the distributions >> > > > are finding stable less useful because it contains to much stuff they'd >> > > > classify as not stable material. >> >> And I'm going to be working on that. > > OK, I accept that. > >> But I need, from the distros, specific examples of what they object to. >> So far all I've gotten is one security patch (that was needed), and one >> patch for sysfs that I backported too far in the version numbers (my >> fault.) >> >> Given the huge number of stable patches over the past few years, only >> having 2 patches be an issue sounds like things are working well for >> people here. >> >> If I don't get pushback, with specifics, from the distros, I will not >> know what to change, so if people can provide me that, it will help out >> a lot. > > I agree ... I think Jiří and his Red Hat equivalent need to pipe up and > give us more examples of the problems they've been having. I'm actually more concerned about the glut of patches showing up in the .1 releases because people didn't bother to send fixes to Linus for the .0 release. I think it is a clear sign that the stable tree is working fairly well when we don't bother to push out a rebase to a new release until the .1 or .2 stable tree is out there. It's a warning sign for the actual .0 release though. Now, that being said, there are cases where .1 can be broken too. There have been a couple of changes that showed up during a merge window that were sucked into -stable through the CC tag, and then later found to be broken. Those resulted in reverts or significant fixes that then took a while to get reverted in -stable or required different temporary fixes because the upstream fix was too invasive. That's mainly a problem of them not getting enough testing before hitting Linus' tree I suppose, but the CC: stable tag being on them doesn't help. Forgive me for not having immediate concrete examples here. I'm sitting in the middle of nowhere on a lake using tethering for internet and hiding from my wife so she doesn't catch me doing "work". Crap, I think she's coming... josh -- 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