Re: linux-next: manual merge of the rdma tree with Linus' tree

[Leon Romanovsky <leon@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 4391 bytes --]

On Fri, Jul 14, 2017 at 12:12:33AM -0400, Doug Ledford wrote:
> On Fri, 2017-07-14 at 06:34 +0300, Leon Romanovsky wrote:
> > On Thu, Jul 13, 2017 at 09:17:13PM -0400, Doug Ledford wrote:
> > > On Fri, 2017-07-14 at 11:14 +1000, Stephen Rothwell wrote:
> > > > Hi Doug,
> > > >
> > > > Today's linux-next merge of the rdma tree got conflicts in:
> > > >
> > > >   drivers/infiniband/core/uverbs_cmd.c
> > > >   drivers/infiniband/core/verbs.c
> > > >
> > > > between commit:
> > > >
> > > >   d291f1a65232 ("IB/core: Enforce PKey security on QPs")
> > > >
> > > > from Linus' tree and commits:
> > > >
> > > >   c7c0fb974caa ("IB/core: Introduce modify QP operation with
> > > > udata")
> > > >   5f4bc420f35f ("IB/uverbs: Make use of ib_modify_qp variant to
> > > > avoid
> > > > resolving DMAC")
> > > >
> > > > from the rdma tree.
> > > >
> > > > I fixed it up (I used the latter version of uverbs_cmd.c and see
> > > > below)
> > > > and can carry the fix as necessary. This is now fixed as far as
> > > > linux-next
> > > > is concerned, but any non trivial conflicts should be mentioned
> > > > to
> > > > your
> > > > upstream maintainer when your tree is submitted for merging.  You
> > > > may
> > > > also want to consider cooperating with the maintainer of the
> > > > conflicting
> > > > tree to minimise any particularly complex conflicts.
> > >
> > > This was expected.  The SELinux changes went through the SELinux
> > > tree
> > > and the referenced patches touch the same code.  Your fix is
> > > correct.
> >
> > Sorry Doug, but it is not expected at all for the code which will go
> > to 4.14.
>
> Who said anything about 4.14?  The merge window is not closed, and a
> current for-next tag need not represent code intended for 4.14.  That
> switchover doesn't happen until the merge window closes (and for many
> trees, a couple rc cycles past the merge window closing).

Really, "couple"?
Your tree contains enormous amount of code, you was listed as one of top-pusher,
and you still behave like your tree has one or two patches in the cycle.

All major trees with similar volume of patches are doing incremental
development and not "one-time" shots.

>
> > Both patches in question were targeted for 4.13 and you was expected
> > to
> > see the merge conflicts during last month or so, prior to merge
> > window of 4.13.
> >
> > In 4.14, you should base your tree on Linus's tree and don't have ANY
> > conflicts in your subsystem, between ANY subsystems and especially
> > Linus, so we will be able to develop and test.
>
> I'm sure for 4.14 that will be the issue.  I didn't put this tag on my
> 4.14 intended work.  I considered this patch series suitable as
> possible -rc fixes, so it is under a for-next tag for now to get the
> for-next testing (which is not much different than a local merge test
> right now, what it does in addition to a local merge test is catch the
> situation where some other pending patches and this conflict).

I don't get it, linux-next is much more than simple merge test. The overall
goal of linux-next is to allow other people to test it BEFORE it hits Linus.

We want to run our verification on it and catch bugs BETWEEN subsystems
(RoCE, iWARP and IPoIB for netdev vs. rdma) in advance and not after.

>
> > For me, this merge conflict puts a large sign, that your tree is not
> > ready for 4.14.
> >
> > Please base your tree on Linus's tree.
>
> Two things here.  First, no one, and I mean *NO ONE*, bases their for-
> next branch on a middle of the merge window version of Linus' tree.
> Second, I would be happy to base my work on a suitable base kernel
> version from Linus' tree from now on (such as -rc2).  Please do *NOT*
> send me another patch set that requires I sync up from net-next in
> order to make things work, because, as you say, I should sync up to
> Linus' tree.

Really? Are you comparing base point of 4.14 development with your stalled
for weeks branches?

Start to work incrementally, update your branches constantly and such
requests will disappear, so we will be able to plan and not to guess.

I respect your hard work and what you are doing, but struggling to understand
why don't you want to make it more effective and less error prone.

Thanks

>
> --
> Doug Ledford <dledford@redhat.com>
>     GPG KeyID: B826A3330E572FDD
>     Key fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD
>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]