Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752231AbaJLPEU (ORCPT ); Sun, 12 Oct 2014 11:04:20 -0400 Received: from mx1.redhat.com ([209.132.183.28]:47200 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751115AbaJLPES (ORCPT ); Sun, 12 Oct 2014 11:04:18 -0400 From: Paul Moore To: Linus Torvalds Cc: James Morris , LSM List , Linux Kernel Mailing List , Stephen Rothwell Subject: Re: [GIT] Security subsystem upate for 3.18 Date: Sun, 12 Oct 2014 11:04:08 -0400 Message-ID: <18599898.QtEUVscf6i@sifl> Organization: Red Hat User-Agent: KMail/4.14.1 (Linux/3.16.1-gentoo; KDE/4.14.1; x86_64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sunday, October 12, 2014 10:12:28 AM Linus Torvalds wrote: > On Fri, Oct 10, 2014 at 4:23 AM, James Morris 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/