Re: [Ksummit-2013-discuss] When to push bug fixes to mainline

[Steven Rostedt]

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 linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/