On Fri, 2013-07-12 at 10:50 -0700, Linus Torvalds wrote: > You cut out the important part: > > - It must fix a problem that causes a build error (but not for things > marked CONFIG_BROKEN), an oops, a hang, data corruption, a real > security issue, or some "oh, that's not good" issue. In short, something > critical. > > That list is not a "or" list, it's an "and" list - it needs to follow > *all* the rules. The exception is the "New device IDs and quirks are > also accepted", which maybe should be made more clearly separate. So if I read this (and stable_kernel_rules.txt) correctly, that means that for example, let's say, we find in RHEL66 or SLES42 (possibly following a user report), for example, that PCI hotplug is broken with some category of devices on some machines. We do a fix, it's roughtly 4 or 5 lines, pretty self contained. We get it into the distro. That still doesn't qualify for stable right ? We have to start shooting at every distro around separately or wait for users of those other distros to also hit it ? Where is the line when something "Doesn't work" (without crashing/oops'ing or being a security issue) ? My personal line so far has been to take it and send it to -stable if the patch is simple enough and self contained (little risk of side effects). But I can stop if that's indeed the accepted rule. Cheers, Ben. -- 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