Thread (15 messages) 15 messages, 5 authors, 2018-03-09

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

flat view

From: Paul Moore <paul@paul-moore.com>
Date: 2018-03-07 23:28:48
Also in: linux-next, lkml

On Wed, Mar 7, 2018 at 3:26 PM, David Miller [off-list ref] wrote:
From: Paul Moore <paul@paul-moore.com>
Date: Wed, 7 Mar 2018 15:20:33 -0500
quoted
quoted
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.
I never said you rebase anything.  I wonder where you get that from.
As I said, I was just trying to figure out what you were suggesting.
Your email was not very clear in my opinion.
I'm saying, you just defer your pull request until Linus takes my
networking tree in.

No changes or rebasing of your tree is necessary whatsoever.  You just
ask him to pull your tree as-is.

Again, this is what other smaller subsystem trees do when they have a
situation like this.
Which gets us back to what I originally suggested in my first email of
this thread: linux-next carries the fixup patch and when we send the
pull requests to Linus we mention this fixup/thread.

For what it's worth, if you mention the potential merge conflict, and
the fixup that Stephen provided, it shouldn't matter when the pull
requests are sent to Linus; he's a smart guy, he'll merge things in
the order he wants.  I've seen more than a few people get burned by
deferring pull requests, I don't intend to have SELinux, or audit for
that matter, run into the same problem.

-- 
paul moore
www.paul-moore.com
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help