On Tue, 16 Jul 2013, Greg KH wrote: > > > > 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 am still continuing with my pushback against the /dev/random revamp that > > happened in -stable; at least in the form it happened. I still strongly > > believe it's something that's not a stable material. But that's happening > > in parallel in a different thread already. > > > > Okay, if you want another example: > > > > commit a6aa749906b92eaec6ca0469f90f35de26044d90 > > Author: Zhenzhong Duan <zhenzhong.duan@xxxxxxxxxx> > > Date: Thu Dec 20 15:05:14 2012 -0800 > > > > drivers/firmware/dmi_scan.c: fetch dmi version from SMBIOS if it exists > > > > While this is a correct fix for major kernel release, as it achieves > > correctness by checking SMBIOS version properly and behaving according to > > the spec, it actually causes an userspace ABI regression in some sense, as > > it just changes byte order of /sys/class/dmi/id/product_uuid on certain > > systems. > > > > Which is something I absolutely *do not* expect from a minor release of > > branch which is called "stable". > > As you pointed out, your definition of "stable" is one that the > enterprise distros have created, and might be totally different from my > view of what "stable" is :) Absolutely, this is why I think discussing this would be very healthy. - first to clarify what the consumers of your branch are expecting it to be - then making clear what your understanding of "stable" is - then clarifying whether the stable branch is there for you or for its consumers :) - finally finding some intersection (some time in the future :) ) that'll suit all parties > And also, as Ben pointed out, this was probably wrong, and someone > should have told me about this, so I could have reverted it. Please do > so the next time. I thought that one of your golas was to improve scalability. "Everyone is reviewing everything" is not my understanding of scalability; hence my proposals. Thanks, Greg. -- Jiri Kosina SUSE Labs -- 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