On Fri, Jul 12, 2013 at 10:50 AM, Steven Rostedt <rostedt@xxxxxxxxxxx> wrote: > > Perhaps just make a separate stable branch, where you cherry-pick the > specific patch using the -x option. Adds a "(cherry picked from > commit ...)". Then you could have some filter that monitors Linus > commits and when a commit matches one of these patches, have it > automatically sent to the stable list. Actually, please don't use -x very much. It doesn't much help, and it can get very confusing before things are merged, and people who are on one branch don't even see the other "identical" commit. But cherry-picking patches is fine, if they really are stable material. Feel free to send me a patch during -rc4 that ends up *also* being in your tree for the next merge window, and don't worry too much about it. It will cause merge problems if you then have other patches on top of it that touch the same code, but for stable-quality patches those tend to be really easy to fix up ("Oh, both branches already have this patch, I should obviously take the version from the branch that has five other patches on top too"), and most of the time it merges cleanly anyway because there isn't anything else right there on top of it anyway. In fact, I'd *much* rather see the same fix committed twice in two different maintainer trees than see cross-maintainership merges, which is what some people do in order to pick up some trivial fix. The cross-maintainership merges are much more painful, and tend to result in "Oh, I didn't send in this pull request in a timely manner in the merge window, because I was waiting for that *other* pull request to go through first". If it's that kind of a critical patch, it really probably *should* go in twice. Of course, if it gets more complicated and bigger, then duplicating the fix is a bad idea, and then you might want to have a separate branch just for that particular fix. Linus -- 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