Date:	Sun, 12 Oct 2014 11:04:08 -0400
From:	Paul Moore <pmoore@...hat.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	James Morris <jmorris@...ei.org>,
	LSM List <linux-security-module@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Stephen Rothwell <sfr@...b.auug.org.au>
Subject: Re: [GIT] Security subsystem upate for 3.18

On Sunday, October 12, 2014 10:12:28 AM Linus Torvalds wrote:
> On Fri, Oct 10, 2014 at 4:23 AM, James Morris <jmorris@...ei.org> wrote:
> > One of these is from merging with your v3.16, and the other from a merge
> > of the keys tree.  That's about all I understand of it.
> 
> Please don't do back-merges. What was the reason for that v3.16 merge?
> It only caused problems, and the merge message is this worthless
> oneliner:
> 
>   "Merge commit 'v3.16' into next"
> 
> that's it. No reason why, and there doesn't seem to be any merge
> conflicts fixed up either, so why was that merge done? The commit
> message sure as hell doesn't explain it.
> 
> There's another one, by Paul Moore:
> 
>    "Merge tag 'v3.16' into next
> 
>     Linux 3.16"
> 
> and please tell me what that (now two-line) merge message adds to the
> world ...

Nothing other than that a merge was done.  To be honest I wasn't sure any 
additional comment was needed since it was a clean merge without any conflict; 
my process has only been to add commentary when there were conflicts that 
needed to be resolved by hand.

As far as the one vs two line commit message goes, the two line message was 
just the default message generated by git when I did the 'git merge v3.16' 
command.  I didn't realize two lines were worse than one.

> ... and why those merges were done at all?

When I took over the care and feeding of the SELinux tree I talked with Eric, 
the previous maintainer, read some of your mail on the subject, and came to 
the conclusion that the proper tree process should be something like the 
following:

 1. Start with the latest stable release, e.g. v3.15
 2. Apply patches as necessary
 3. Send pull request upstream
 4. Merge latest stable release with 'git merge v3.16'
 5. Jump to step #2

Once again, I honestly thought this was the "Right Way".  The result was a 
current, reasonably stable tree, that was easy to patch and merged easily 
upstream.

However, despite my best intentions, it sounds like I'm doing it wrong.  Okay, 
I'll accept that, I can change my process to whatever you want; just help me 
out a little bit and explain, like I'm a distracted four year old if 
necessary, what process you would like me to use.  I appreciate that you 
probably feel like you've repeated yourself a thousand times on this topic, so 
if a pointer to a previous thread works, that's fine too.

Is the core issue that I'm merging each release into the SELinux tree?  Do you 
only want to see merges in the tree when there is a merge conflict or some 
logic change that would require a merge?

> People, stop doing these back-merges. You are doing them wrong, and
> they cause problems. Just stop it. And if you have some seriously good
> reason for why you are doing them, you should damn well *document*
> that reason, rather than say "Merge v3.16" and leave it at that. If
> you *don't* have a good reason for doing them, don't do them!

-- 
paul moore
security and virtualization @ redhat

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