On Thu, Apr 12, 2012 at 2:44 PM, Linus Torvalds <[email protected]> wrote: > On Thu, Apr 12, 2012 at 2:34 PM, Linus Torvalds > <[email protected]> wrote: >> >> So just reverting it from stable, *WITHOUT LEARNING THE LESSON*, is >> not a no-op at all, it's a sign of being a f*cking moron. > > Btw, the revert is now in my tree (commit 011afa1ed8c4), and marked > for stable. So *now* Greg can revert it from stable too. > > But the important lesson to everybody should be that "we don't lose > fixes from -stable". If a problem was found in stable, it needs to be > fixed upstream. In fact, quite often people *do* find problems in > stable, because it tends to have more users more quickly than > mainline. That makes it really really important to make sure that > those problems get fixed upstream, and not hidden in stable due to > some kind of dieseased "it's a no-op to revert it" thinking. > > End of story.
FWIW if people want stable fixes propagated faster (before Linus sucks it in or Greg sucks it in after Linus) things like compat-wireless (to be renamed to compat-drivers) allows us to get these out, but we label them properly [0]. We in fact have a place holder for even other type of non-upstream patches that any PHB may come up with as required but -- the key is to 1) help categorize these properly 2) keep metrics of them 3) prioritize upstream first The pending-stable/ patches get patches out to the community faster than Linus / Greg can apply them or before we even get the community to test them. We get these sucked out by looking for the Cc: [email protected] The linux-next-cherry-pick/ allows you suck out non-stable patches and I gladly accept such patches so long as they are in linux-next and I can suck them out automatically if you Cc: [email protected]. There are similar tricks for the other types of patches. [0] http://wireless.kernel.org/en/users/Download/stable/#Additional_patches_to_stable_releases Luis -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
