On Fri, 2013-07-12 at 10:59 -0700, Linus Torvalds wrote: > 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. > Actually I was trying to answer HPA's question about how to notify stable of a patch that wasn't tagged for stable, and one that you need to remember when its committed by you. Say I get a bunch of patches and add them to a branch queued for an -rc (all fixes for the current release). Then I notice that one of the patches is a fix for older kernels as well, but it has already been made public. As to tag it for stable would require a rebase, but its still in a queue to be sent to you, and others may have based their work on it. The question now is, how do I remember to notify stable of this patch when its part of a queue going to you already? Is it OK to cherry pick the patch separately, and add the stable tag, and queue that up to you first? That way the stable automated process will trigger when you take it. Basically, there's been times when branches have been made public before it is realized that a commit in that branch should go back to older trees, not just a fix for the current -rc release. Thus, this is not a question of sending a stable fix to you, but a fix that is already queued to go to you and later realize it needs to go to older trees as well. Greg likes it when you send that patch after it is in mainline. But remembering which patch to send isn't always trivial, and can be forgotten about. I was giving an answer to that question. Having the separate stable branch that will never be pushed to you and only used as a database of what needs to go to stable for older kernels is what I was going for. It doesn't need to be a git branch at all. It could just be a directory of files that was created via a git format-patch. -- Steve -- 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