From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Rothwell Subject: Re: [GIT PULL] Audit patches for 4.5 Date: Thu, 14 Jan 2016 11:28:47 +1100 Message-ID: <20160114112847.54f02a4f@canb.auug.org.au> References: <1490560.yARnk4QFpi@sifl> <20160114020325.7f778cda@canb.auug.org.au> <1633246.WIdWYpcqb3@sifl> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1633246.WIdWYpcqb3@sifl> Sender: linux-kernel-owner@vger.kernel.org To: Paul Moore Cc: Linus Torvalds , linux-audit@redhat.com, linux-kernel@vger.kernel.org List-Id: linux-audit@redhat.com Hi Paul, On Wed, 13 Jan 2016 11:24:29 -0500 Paul Moore wrote: > > In December I made some changes to how I manage the SELinux and audit trees: > > * https://www.redhat.com/archives/linux-audit/2015-December/msg00019.html You may have a problem here, you start with: "1. When a new kernel is released, rebase the repository's upstream branch to the tagged kernel release (or the latest LSM upstream branch in the case of SELinux) and apply the next branch on top of the upstream branch. Send a pull request for the upstream branch to the next level maintainer." Linus has repeatedly said to not rebase just before sending a pull request unless you hava a good reason - and even then you should let the result be tested for a few days before sending a pull request. He also says that published trees (that people could be developing against) should not be rebased (except for exceptional circumstances). Instead you could do 1. When a new kernel is released (i.e. the merge window opens), send a pull request for the upstream branch to the next level maintainer. After it is merged, then do a fast forward bask merge merge of the upstream tree (if necessary). > ... I will readily admit it isn't a perfect system, in fact it is a > step back in some areas, but the changes make it easier for me to get > pre-built kernel packages to users who are interested in testing the > bleeding edge (the Fedora COPR repository, see below) and it helps me > keep up with weekly testing of both the -rcX kernel releases and the > changes in the SELinux and audit trees. One of the things I've been > trying to work on lately is better, more automated, testing of the > SELinux and audit bits in the Linux kernel; unfortunately, some > things have had to change a little to help make this happen, but I > think the more frequent testing outweighs any disadvantages. I don't understand why this testing would require any rebasing. You can just crate a test branch that is Linus' tree and then merge in your tree and test that. > The date change is likely a result of moving the patches from > audit#next to audit#upstream as part of the process mentioned above. I wasn't aware that "git rebase" would change the author dates by default (in fact I don;t think it does). Or do you use some other method to move the patches. In any case, why aren't you just submitting the next branch upstream? > I haven't updated audit#next yet because I know you try to keep > linux-next quiet until -rc1 is released; if that has changed let me > know and I'll be happy to update audit#next. It hasn't changed, but this is part of what I tell everyone who adds a branch to linux-next: "Basically, this should be just what you would send to Linus (or ask him to fetch)." So by "quiet" I mean not adding stuff for the next release and not changing stuff around too much. If you *must* rebase you tree for some reason, you should let it simmer in linux-next for a few days before asking Linus to pull it. That way, at least Linus and I will end up with the same *commits* and I (and others) won't have to cope with unnecessary conflicts caused by different versions of the same *patches* (or even just further changes to teh same files in other commits. > For reference, the Fedora COPR repository can be found below, it was > announced back in November, but only to the relevant lists. Anyone > is welcome to give the kernels a try (instructions are provided) and > report any problems they find. I tend to push out an update at least > once a week to coincide with the new -rcX release, although the exact > day varies due to merge conflicts, build problems, etc. > > * https://copr.fedoraproject.org/coprs/pcmoore/kernel-secnext So, I don't see why that requires you to rebase your tree. That kernel source is separate from Linus' in any case (since I assume it contains all manner of not-yet-upstreamed or back ported patches). -- Cheers, Stephen Rothwell sfr@canb.auug.org.au