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. 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 don't like this at all, just for the simple reason that it will push > > the majority of the work of stable kernel development on to the > > subsystem maintainers, who have enough work to do as it is. > > Well, I think of this as a feature not a bug because it enables scaling, > but we can certainly debate the topic; it's probably one of the more > important things that should be discussed. How does this scale? It makes the maintainers do more work, which does not scale at all. > > Stable tree stuff should cause almost _no_ extra burden on the kernel > > developers, because it is something that I, and a few other people, have > > agreed to do with our time. It has taken me 8 _years_ to finally get > > maintainers to agree to mark stuff for the stable tree, and fine-tune a > > development process that makes it easy for us to do this backport work. > > > > I _want_ the exact same commit that is in Linus's tree for the backport > > because if I have to rely on a maintainer to do the backport and resend > > it, I _know_ it will usually be a changed patch, and the git commit id > > will be lost. > > This is fixable with process and tools, surely. That's crazy, and it implies that there is a problem today with the Cc: tag. Is there? What is the problem that you are seeing that you wish to help resolve? I don't think it's the same problem that I am seeing, as adding more tools and processes sure isn't going to fix that. > > Have I missed anything else that the distros are objecting to? The > > "smaller" distros (i.e. ones without lots of kernel developers) have > > been giving me nothing but _thanks_ and appreciation with the way that > > I've been sucking in all of the different fixes. Do we want to mess > > with a process that is really working out well for them, and only causes > > annoyance at times by the larger ones? > > I still think the scaling problem remains plus, if you push back more, > it's going to increase friction: you aren't necessarily in the best > position to know what should be a stable fix for a given subsystem, and > if you push back incorrectly it's going to annoy the maintainer. Making a subsystem maintainer answer "why is this needed" is really going to annoy people? Seriously? Let's try it out, and see what happens. I think the real stable issue that _everyone_ keeps ignoring, is my original complaint, in that people are using the -rc1 merge window to get fixes in they should have sent to Linus for .0. I don't see anything you have written so far that will help resolve that issue, which is not good, as that needs to be taken care of. 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