On Sat, Apr 14, 2012 at 06:29:54PM +0300, Felipe Contreras wrote: > So, the hypothetical patch that was dropped in the stable review queue > yesterday has to be fixed in mainline too, just like the hypothetical > patch that made it to stable and was found problematic today has to be > fixed in mainline. Patches are not always dropped from the stable queue if we know they're causing issues, sometimes they're left pending in the queue. This is how Greg is able to ping developers from time to time. > Again, what makes a released patch undroppable? Being applied, in other words, having a commit ID in the branch. (...) > Just by going through the stable review process the patch already > received more eyes to make the bugs more shallow. There might be a lot > of trees out there where people pick patches from mainline, and they > don't *need* to follow the "upstream first" rule, by reviewing the > patch, and maybe even testing it, and then reporting the problem, they > are helping getting it fixed for v3.4. They do what they want with their trees. I have a number of patches in my trees that are not worth pushing to mainline and that's fine. However the rule is that the official stable tree has to hold patches that come from mainline. > You don't *need* to keep the patch in the stable review queue, you > don't *need* to make a stable release with it in order to ensure that > it will fixed in mainline, the information about the patch problems is > not lost. It's lost since nobody cares once their kernel is fixed. For instance, I have an issue with 3.0.x on my netbook which I haven't had time to bisect (no resume from s2r). But 3.2 works. If I find that the issue was introduced in any stable backport, we'll have to ensure that mainline has the fix, because the bug might simply be hidden in 3.2 but still present. If we'd just revert the fix from 3.0, what would motivate anyone to fix mainline if it appears to work ? > Seems to me you are abusing the 'stable' branch as a bug tracking > system for certain patches for the next release. The most reliable bug tracking system are the end users. They're the only one who remind you to get their fix merged. And you did this yourself, quite louder than the average I'd say, but it worked perfectly again. Willy -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
