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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 12 Jul 2013 10:59:13 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	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 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.

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 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/