linux-kernel - Re: linux-next: manual merge of the selinux tree with the net-next tree

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHC9VhRQb50EYD6BVTxNv2x=S_tTLq57OZBsWbXFdfJEunNUiA@mail.gmail.com>
Date:   Wed, 7 Mar 2018 15:20:33 -0500
From:   Paul Moore <paul@...l-moore.com>
To:     David Miller <davem@...emloft.net>
Cc:     lucien.xin@...il.com, sfr@...b.auug.org.au, netdev@...r.kernel.org,
        linux-next@...r.kernel.org, linux-kernel@...r.kernel.org,
        richard_c_haines@...nternet.com
Subject: Re: linux-next: manual merge of the selinux tree with the net-next tree

On Wed, Mar 7, 2018 at 12:45 PM, David Miller <davem@...emloft.net> wrote:
> From: Paul Moore <paul@...l-moore.com>
> Date: Wed, 7 Mar 2018 12:27:52 -0500
>
>> I'm not sure we could have cleanly separated the core network stack
>> changes from the rest of the SELinux/SCTP enablement, regardless it's
>> a bit late at this point.  The only other thought would have been to
>> simply push Xin Long's cleanup patches until after the next merge
>> window, but that would only be worth considering if they truly were
>> just cleanup patches, and even then it doesn't seem very fair to Xin
>> Long to have to wait.
>
> I think you wanted to have more integration, rather than less.

I'm not quite sure where you are going here, I think we *all* want
integration - subtrees merge patches/trees, Linus merges subtrees,
etc. - and I don't believe I've said anything to the contrary.

> What others have done in the past, is they simply pull my networking
> tree into their's.

I only base the SELinux and audit trees on Linus' tree.  Perhaps I'm
wrong, but a quick look at net-next makes me believe you do the same.

I think it is also worth mentioning that the SELinux/SCTP patches have
been in the selinux/next branch for several days now; from what I can
tell they predate these net-next cleanup patches.  Not that it
matters, I just don't believe that pulling net-next would have solved
this problem; I suppose the right thing would have been for net-next
to pull selinux/next, yes?

> I never rebase, ever.

I've learned that saying "never" (or "never X, ever" in this case) is
a recipe for disaster, but if it works for you, go for it.

FWIW, I try to avoid rebases as much as possible; it's the nuclear
option as far as I'm concerned and the only time I regularly rebase
the SELinux and audit trees is after the merge window (e.g. we need
something in -rc1, or we are simply too far out of date).

Looking quickly at net-next, it looks like net-next/master is
refreshed/rebased on a regular basis too (it contains the
selinux-pr-20180130 tag)... and perhaps rebase is a term you don't
want to use, but I think we are on the same page here.

> My tree often goes in reasonable early in the merge window.

Generally speaking I send my pull request to Linus early in the merge
window too.  It obviously tends to vary on when he does the pull, but
we generally haven't had any major problems.

> So you would only have to wait until my tree went in before
> sending your pull request.

So you would want me to rebase selinux/next on top of Linus' tree in
the middle of the merge window?  I'm sure that isn't what you meant,
but that's how I keep reading the above ... which can't be right,
because in my experience that's one way to piss off Linus.  Help me
understand what you are saying.

> That's really the way to handle something like this.

-- 
paul moore
www.paul-moore.com