Re: [GIT] Security subsystem upate for 3.18

From: Paul Moore
Date: Sun Oct 12 2014 - 11:04:37 EST


On Sunday, October 12, 2014 10:12:28 AM Linus Torvalds wrote:
> On Fri, Oct 10, 2014 at 4:23 AM, James Morris <jmorris@xxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/