Linux-Next Archive on lore.kernel.org
 help / color / Atom feed
From: Leon Romanovsky <leon@kernel.org>
To: Doug Ledford <dledford@redhat.com>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>,
	Linux-Next Mailing List <linux-next@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Daniel Jurgens <danielj@mellanox.com>,
	Paul Moore <paul@paul-moore.com>,
	Parav Pandit <parav@mellanox.com>, Eli Cohen <eli@mellanox.com>
Subject: Re: linux-next: manual merge of the rdma tree with Linus' tree
Date: Fri, 14 Jul 2017 07:54:17 +0300
Message-ID: <20170714045417.GU1528@mtr-leonro.local> (raw)
In-Reply-To: <1500005553.2936.14.camel@redhat.com>

[-- 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 --]

  reply index

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-14  1:14 Stephen Rothwell
2017-07-14  1:17 ` Doug Ledford
2017-07-14  3:34   ` Leon Romanovsky
2017-07-14  3:50     ` Stephen Rothwell
2017-07-14  4:55       ` Leon Romanovsky
2017-07-14 12:03         ` Doug Ledford
2017-07-14 13:46           ` Leon Romanovsky
2017-07-14  4:12     ` Doug Ledford
2017-07-14  4:54       ` Leon Romanovsky [this message]
2017-07-14 14:33         ` Doug Ledford
2017-07-14 15:10           ` Leon Romanovsky
  -- strict thread matches above, loose matches on Subject: below --
2019-11-05  1:17 Stephen Rothwell
2019-11-05  2:21 ` Jason Gunthorpe
2019-11-05  2:28   ` Stephen Rothwell
2019-10-24  0:01 Stephen Rothwell
2019-10-28 19:30 ` Jason Gunthorpe
2019-06-20  2:10 Stephen Rothwell
2019-06-20  3:25 ` Doug Ledford
2019-06-20  2:06 Stephen Rothwell
2019-06-20  3:24 ` Doug Ledford
2019-06-14  3:00 Stephen Rothwell
2019-06-14 13:11 ` Doug Ledford
2018-09-28  0:01 Stephen Rothwell
2018-09-29  2:57 ` Parav Pandit
2018-08-06  2:01 Stephen Rothwell
2018-08-06 19:41 ` Jason Gunthorpe
2018-08-06 21:49   ` Stephen Rothwell
2017-08-08  2:11 Stephen Rothwell
2016-12-15  0:47 Stephen Rothwell
2016-10-10  0:59 Stephen Rothwell
2016-10-10  0:54 Stephen Rothwell
2016-08-05  1:05 Stephen Rothwell
2016-08-05  1:01 Stephen Rothwell
2016-08-05  0:52 Stephen Rothwell
2016-05-19  1:45 Stephen Rothwell
2016-03-22  0:33 Stephen Rothwell
2016-03-22  0:29 Stephen Rothwell
2016-03-22  0:24 Stephen Rothwell
2016-03-22  0:17 Stephen Rothwell
2015-11-01  7:48 Stephen Rothwell
2015-11-02 10:40 ` Sagi Grimberg

Reply instructions:

You may reply publically to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170714045417.GU1528@mtr-leonro.local \
    --to=leon@kernel.org \
    --cc=danielj@mellanox.com \
    --cc=dledford@redhat.com \
    --cc=eli@mellanox.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=parav@mellanox.com \
    --cc=paul@paul-moore.com \
    --cc=sfr@canb.auug.org.au \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-Next Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-next/0 linux-next/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-next linux-next/ https://lore.kernel.org/linux-next \
		linux-next@vger.kernel.org
	public-inbox-index linux-next

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-next


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git