Re: [GIT PULL] Audit patches for 4.5

[Stephen Rothwell]

Hi Paul,

On Wed, 13 Jan 2016 11:24:29 -0500 Paul Moore <pmoore@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxx