Date:	Sat, 13 Jul 2013 19:52:32 +0200
From:	Geert Uytterhoeven <geert@...ux-m68k.org>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	"H. Peter Anvin" <hpa@...or.com>, stable <stable@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	ksummit-2013-discuss@...ts.linux-foundation.org
Subject: Re: [Ksummit-2013-discuss] When to push bug fixes to mainline

On Fri, Jul 12, 2013 at 8:14 PM, Steven Rostedt <rostedt@...dmis.org> wrote:
> On Fri, 2013-07-12 at 10:59 -0700, Linus Torvalds wrote:
>> On Fri, Jul 12, 2013 at 10:50 AM, Steven Rostedt <rostedt@...dmis.org> 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.

The git branch has the advantage of allowing git power tools for processing.

Say you "cherry-pick -x" all commits for stable to a private branch named
"for-stable".
Then "git cherry -v linus/master for-stable" will prefix all commits that are
already upstream with a minus sign, so you know when to ping stable.
Commits prefixed with a plus sign are still pending (or got applied with some
mutilation, i.e. you want to double-check).

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists