linux-next: manual merge of the rdma tree with the nfsd tree

linux-next: manual merge of the rdma tree with the nfsd tree

[Stephen Rothwell]

Hi Doug,

Today's linux-next merge of the rdma tree got conflicts in a quite a
few files between (mostly, I think) commit:

  6c7b6d2d442c ("IB: merge struct ib_device_attr into struct ib_device")

from the nfsd tree and various commits from the rdma tree.

It would have taken me considerable time to fix the conflicts up, so I
have dropped teh rdma tree for today (just because it was merged second).
Please have a conversation and figure out how you are going to cooperate
and get these conflicts fixed e.g. set up a stable branch with Christoph's
commit (and any other conflicting commits) in it and merge that into
both trees.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

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

[Stephen Rothwell]

Hi all,

On Thu, 31 Dec 2015 13:30:22 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi Doug,
> 
> Today's linux-next merge of the rdma tree got conflicts in a quite a
> few files between (mostly, I think) commit:
> 
>   6c7b6d2d442c ("IB: merge struct ib_device_attr into struct ib_device")
> 
> from the nfsd tree and various commits from the rdma tree.
> 
> It would have taken me considerable time to fix the conflicts up, so I
> have dropped teh rdma tree for today (just because it was merged second).
> Please have a conversation and figure out how you are going to cooperate
> and get these conflicts fixed e.g. set up a stable branch with Christoph's
> commit (and any other conflicting commits) in it and merge that into
> both trees.

So, on further inspection, it appears that there is a series of commits
in the rdma tree that does basically the same as that nfsd tree commit
above.  So I have dropped the rdma tree again today.  Please have a
conversation guys ...

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

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

[Doug Ledford]

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

On 01/03/2016 08:44 PM, Stephen Rothwell wrote:
> Hi all,
> 
> On Thu, 31 Dec 2015 13:30:22 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>
>> Hi Doug,
>>
>> Today's linux-next merge of the rdma tree got conflicts in a quite a
>> few files between (mostly, I think) commit:
>>
>>   6c7b6d2d442c ("IB: merge struct ib_device_attr into struct ib_device")
>>
>> from the nfsd tree and various commits from the rdma tree.
>>
>> It would have taken me considerable time to fix the conflicts up, so I
>> have dropped teh rdma tree for today (just because it was merged second).
>> Please have a conversation and figure out how you are going to cooperate
>> and get these conflicts fixed e.g. set up a stable branch with Christoph's
>> commit (and any other conflicting commits) in it and merge that into
>> both trees.
> 
> So, on further inspection, it appears that there is a series of commits
> in the rdma tree that does basically the same as that nfsd tree commit
> above.  So I have dropped the rdma tree again today.  Please have a
> conversation guys ...
> 

The initial patchset was Christoph's.  It was later replaced with a
different patchset from Or Gerlitz.  Bruce picked up some changes from
Chuck Lever that were originally based on Christoph's work but now need
to be rebased off of the current RDMA tree.

-- 
Doug Ledford <dledford@redhat.com>
              GPG KeyID: 0E572FDD



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]

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

[J. Bruce Fields]

On Sun, Jan 03, 2016 at 09:53:20PM -0500, Doug Ledford wrote:
> On 01/03/2016 08:44 PM, Stephen Rothwell wrote:
> > Hi all,
> > 
> > On Thu, 31 Dec 2015 13:30:22 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >>
> >> Hi Doug,
> >>
> >> Today's linux-next merge of the rdma tree got conflicts in a quite a
> >> few files between (mostly, I think) commit:
> >>
> >>   6c7b6d2d442c ("IB: merge struct ib_device_attr into struct ib_device")
> >>
> >> from the nfsd tree and various commits from the rdma tree.
> >>
> >> It would have taken me considerable time to fix the conflicts up, so I
> >> have dropped teh rdma tree for today (just because it was merged second).
> >> Please have a conversation and figure out how you are going to cooperate
> >> and get these conflicts fixed e.g. set up a stable branch with Christoph's
> >> commit (and any other conflicting commits) in it and merge that into
> >> both trees.
> > 
> > So, on further inspection, it appears that there is a series of commits
> > in the rdma tree that does basically the same as that nfsd tree commit
> > above.  So I have dropped the rdma tree again today.  Please have a
> > conversation guys ...
> > 
> 
> The initial patchset was Christoph's.  It was later replaced with a
> different patchset from Or Gerlitz.  Bruce picked up some changes from
> Chuck Lever that were originally based on Christoph's work but now need
> to be rebased off of the current RDMA tree.

OK.  I'm assuming Chuck will want to do any necessary rebasing and
retesting himself, so for now I've just dropped those patches, and
expect to pick up new versions when Chuck gets back from the holidays.

--b.

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

[Chuck Lever]

> On Jan 4, 2016, at 2:36 PM, J. Bruce Fields <bfields@fieldses.org> wrote:
> 
> On Sun, Jan 03, 2016 at 09:53:20PM -0500, Doug Ledford wrote:
>> On 01/03/2016 08:44 PM, Stephen Rothwell wrote:
>>> Hi all,
>>> 
>>> On Thu, 31 Dec 2015 13:30:22 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>>> 
>>>> Hi Doug,
>>>> 
>>>> Today's linux-next merge of the rdma tree got conflicts in a quite a
>>>> few files between (mostly, I think) commit:
>>>> 
>>>>  6c7b6d2d442c ("IB: merge struct ib_device_attr into struct ib_device")
>>>> 
>>>> from the nfsd tree and various commits from the rdma tree.
>>>> 
>>>> It would have taken me considerable time to fix the conflicts up, so I
>>>> have dropped teh rdma tree for today (just because it was merged second).
>>>> Please have a conversation and figure out how you are going to cooperate
>>>> and get these conflicts fixed e.g. set up a stable branch with Christoph's
>>>> commit (and any other conflicting commits) in it and merge that into
>>>> both trees.
>>> 
>>> So, on further inspection, it appears that there is a series of commits
>>> in the rdma tree that does basically the same as that nfsd tree commit
>>> above.  So I have dropped the rdma tree again today.  Please have a
>>> conversation guys ...
>>> 
>> 
>> The initial patchset was Christoph's.  It was later replaced with a
>> different patchset from Or Gerlitz.  Bruce picked up some changes from
>> Chuck Lever that were originally based on Christoph's work but now need
>> to be rebased off of the current RDMA tree.
> 
> OK.  I'm assuming Chuck will want to do any necessary rebasing and
> retesting himself, so for now I've just dropped those patches, and
> expect to pick up new versions when Chuck gets back from the holidays.

Part of the plan was that Doug's tree would be merged before
Bruce's. But the above problem description looks like the
maintainer trees were merged into linux-next in the other order.

I'd like to make this simpler for everyone. Bruce, may I send
my for-4.5 NFS/RDMA server patches to Doug with your Acked-by?
That way, merge order won't matter.

Doug, what is the URL for the branch I should rebase on?


--
Chuck Lever

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

[Or Gerlitz]

On 1/6/2016 2:01 PM, Chuck Lever wrote:
> what is the URL for the branch I should rebase on?

k.o/for-4.5 on Doug's kernel.org tree

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

[Christoph Hellwig]

On Wed, Jan 06, 2016 at 07:01:14AM -0500, Chuck Lever wrote:
> Part of the plan was that Doug's tree would be merged before
> Bruce's. But the above problem description looks like the
> maintainer trees were merged into linux-next in the other order.
> 
> I'd like to make this simpler for everyone. Bruce, may I send
> my for-4.5 NFS/RDMA server patches to Doug with your Acked-by?
> That way, merge order won't matter.
> 
> Doug, what is the URL for the branch I should rebase on?

I'm not Doug, but all the recent for 4.5 work is in Dougs tree
at

	https://github.com/dledford/linux rdma/k.o/for-4.5

Bruce, can you ACK me local_dma_lkey patch as well which needs
the same treatment as Chuck's patches?  I have some RDMA work
in that area planned for the nxt merge window, so it would be
really helpful to get it in for 4.5.

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

[Or Gerlitz]

On 1/6/2016 2:15 PM, Christoph Hellwig wrote:
> I'm not Doug, but all the recent for 4.5 work is in Dougs tree
> at
>
> 	https://github.com/dledford/linux  rdma/k.o/for-4.5

Christoph,

As I wrote here, the bits are already @ kernel.org

git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma.git k.o/for-4.5

Or.

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

[Christoph Hellwig]

On Wed, Jan 06, 2016 at 02:22:41PM +0200, Or Gerlitz wrote:
> As I wrote here, the bits are already @ kernel.org
>
> git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma.git k.o/for-4.5

Ok, that's a little confusing.

Doug, any chance you could settle on one tree? I don't really care
which one.

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

[Doug Ledford]

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


> On Jan 6, 2016, at 7:28 AM, Christoph Hellwig <hch@lst.de> wrote:
> 
> On Wed, Jan 06, 2016 at 02:22:41PM +0200, Or Gerlitz wrote:
>> As I wrote here, the bits are already @ kernel.org
>> 
>> git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma.git k.o/for-4.5
> 
> Ok, that's a little confusing.
> 
> Doug, any chance you could settle on one tree? I don't really care
> which one.

I use both, but for different things.  For instance, when I had 9 out of 10 of Sagi’s patches for iSER applied and was waiting on the 10th patch to complete the set, I was willing to push that to my github tree so Sagi could check out how the first 9 had gone and double check my merge fixups while he rebased the 10th patch, but I didn’t want to push it to k.o.  I don’t rebase on k.o, ever (something Linus was adamant about when I started doing this).  But the github repo is released earlier and may be rebased.  If it is a smooth merge window, there is little, if any, difference between the two.  Only during merge windows when I am looking at different alternatives of controversial stuff does this seem to be an issue.

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]

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

[Chuck Lever]

> On Jan 6, 2016, at 7:15 AM, Christoph Hellwig <hch@lst.de> wrote:
> 
> On Wed, Jan 06, 2016 at 07:01:14AM -0500, Chuck Lever wrote:
>> Part of the plan was that Doug's tree would be merged before
>> Bruce's. But the above problem description looks like the
>> maintainer trees were merged into linux-next in the other order.
>> 
>> I'd like to make this simpler for everyone. Bruce, may I send
>> my for-4.5 NFS/RDMA server patches to Doug with your Acked-by?
>> That way, merge order won't matter.
>> 
>> Doug, what is the URL for the branch I should rebase on?
> 
> I'm not Doug, but all the recent for 4.5 work is in Dougs tree
> at
> 
> 	https://github.com/dledford/linux rdma/k.o/for-4.5
> 
> Bruce, can you ACK me local_dma_lkey patch as well which needs
> the same treatment as Chuck's patches?  I have some RDMA work
> in that area planned for the nxt merge window, so it would be
> really helpful to get it in for 4.5.

Actually, one of Or's for-4.5 devattr patches doesn't
appear to have the proper Ack's for the changes under
net/sunrpc/xprtrdma either.


--
Chuck Lever

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

[Or Gerlitz]

On 1/6/2016 4:24 PM, Chuck Lever wrote:
> Actually, one of Or's for-4.5 devattr patches doesn't appear to have the proper Ack's for the changes under net/sunrpc/xprtrdma either.

Chuck,

Lets be concrete... anything wrong with patch [1]?

Or.

[1]  commit e3e45b1 "xprtrdma: Avoid calling ib_query_device"

in git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma.git 
k.o/for-4.5

http://git.kernel.org/cgit/linux/kernel/git/dledford/rdma.git/commit/?h=k.o/for-4.5&id=e3e45b1b43988b99007a9908ca0ba738b3fbd0ff

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

[Chuck Lever]

> On Jan 6, 2016, at 9:46 AM, Or Gerlitz <ogerlitz@mellanox.com> wrote:
> 
> On 1/6/2016 4:24 PM, Chuck Lever wrote:
>> Actually, one of Or's for-4.5 devattr patches doesn't appear to have the proper Ack's for the changes under net/sunrpc/xprtrdma either.
> 
> Chuck,
> 
> Lets be concrete... anything wrong with patch [1]?

Yes. It is missing Acked-by: lines from the maintainers of
those files.

All changes to files under net/sunrpc need an Ack from one
of the maintainers listed in MAINTAINERS for that directory,
if the changes are going through another maintainer's tree.

I have been personally asked to remind folks that the
nfs-sunrpc maintainers do not read linux-rdma, so they
must be contacted directly (and cc: linux-nfs) as part of
proposing finished patches in that area.

Unfortunately I have not been able to review every patch
that has come by on linux-rdma in the past 9 months to
ensure the eyes are dotted and tees crossed. More than
a few commits in the tree are missing the proper tags.


> Or.
> 
> [1]  commit e3e45b1 "xprtrdma: Avoid calling ib_query_device"
> 
> in git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma.git k.o/for-4.5
> 
> http://git.kernel.org/cgit/linux/kernel/git/dledford/rdma.git/commit/?h=k.o/for-4.5&id=e3e45b1b43988b99007a9908ca0ba738b3fbd0ff
> 

--
Chuck Lever

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

[Or Gerlitz]

On 1/6/2016 5:20 PM, Chuck Lever wrote:
>> Chuck,
>> >
>> >Lets be concrete... anything wrong with patch [1]?
> Yes. It is missing Acked-by: lines from the maintainers of
> those files.
>
> All changes to files under net/sunrpc need an Ack from one
> of the maintainers listed in MAINTAINERS for that directory,
> if the changes are going through another maintainer's tree.
>
> I have been personally asked to remind folks that the
> nfs-sunrpc maintainers do not read linux-rdma, so they
> must be contacted directly (and cc: linux-nfs) as part of
> proposing finished patches in that area.

I did that!!

I copied you and Anna on the patch [1].

Again, lets be concrete, this very small cleanup was picked and merged, 
anything there
need to be fixed?

Or.

[1] http://marc.info/?l=linux-rdma&m=145042924110411&w=2


> Unfortunately I have not been able to review every patch
> that has come by on linux-rdma in the past 9 months to
> ensure the eyes are dotted and tees crossed. More than
> a few commits in the tree are missing the proper tags.
>
>
> >[1]  commit e3e45b1 "xprtrdma: Avoid calling ib_query_device"
> >
> >in git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma.git k.o/for-4.5
> >
> >http://git.kernel.org/cgit/linux/kernel/git/dledford/rdma.git/commit/?h=k.o/for-4.5&id=e3e45b1b43988b99007a9908ca0ba738b3fbd0ff
> >

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

[Chuck Lever]

> On Jan 6, 2016, at 10:52 AM, Or Gerlitz <ogerlitz@mellanox.com> wrote:
> 
> On 1/6/2016 5:20 PM, Chuck Lever wrote:
>>> Chuck,
>>> >
>>> >Lets be concrete... anything wrong with patch [1]?
>> Yes. It is missing Acked-by: lines from the maintainers of
>> those files.
>> 
>> All changes to files under net/sunrpc need an Ack from one
>> of the maintainers listed in MAINTAINERS for that directory,
>> if the changes are going through another maintainer's tree.
>> 
>> I have been personally asked to remind folks that the
>> nfs-sunrpc maintainers do not read linux-rdma, so they
>> must be contacted directly (and cc: linux-nfs) as part of
>> proposing finished patches in that area.
> 
> I did that!!
> 
> I copied you and Anna on the patch [1].

The marc.info archive does not preserve To: or Cc:
fields on e-mail. I had to look in my own inbox to
confirm who the recipients were.

Anna was the only NFS maintainer listed, and
linux-nfs was not included on that e-mail at all.
Did Anna ever reply with an Acked-by ? I don't see
that in either the archive or my own inbox.

Bruce needs to Ack the svc_rdma_transport.c hunks.


> Again, lets be concrete, this very small cleanup was picked and merged, anything there
> need to be fixed?

I have rebased on Doug's current for-4.5, and will
be testing today before submitting my for-4.5 patches
again. Your changes are mechanical, so I don't expect
to encounter a technical problem.

However, I would be more comfortable if the missing
Acks were fixed in Doug's tree (with Anna and Bruce's
permission, of course) before Linus pulls.


> Or.
> 
> [1] http://marc.info/?l=linux-rdma&m=145042924110411&w=2
> 
> 
>> Unfortunately I have not been able to review every patch
>> that has come by on linux-rdma in the past 9 months to
>> ensure the eyes are dotted and tees crossed. More than
>> a few commits in the tree are missing the proper tags.
>> 
>> 
>> >[1]  commit e3e45b1 "xprtrdma: Avoid calling ib_query_device"
>> >
>> >in git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma.git k.o/for-4.5
>> >
>> >http://git.kernel.org/cgit/linux/kernel/git/dledford/rdma.git/commit/?h=k.o/for-4.5&id=e3e45b1b43988b99007a9908ca0ba738b3fbd0ff
>> >
> 

--
Chuck Lever

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

[Or Gerlitz]

On 1/6/2016 6:33 PM, Chuck Lever wrote:
> Anna was the only NFS maintainer listed, and linux-nfs was not included on that e-mail at all.

OK, will do better next time.

> Did Anna ever reply with an Acked-by ? I don't see that in either the archive or my own inbox.

as you wrote, the patch is mechanical, I didn't think there's a deep 
need to desperately chase people for that ack

Or.

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

[Anna Schumaker]

On 01/06/2016 11:33 AM, Chuck Lever wrote:
> 
>> On Jan 6, 2016, at 10:52 AM, Or Gerlitz <ogerlitz@mellanox.com> wrote:
>>
>> On 1/6/2016 5:20 PM, Chuck Lever wrote:
>>>> Chuck,
>>>>>
>>>>> Lets be concrete... anything wrong with patch [1]?
>>> Yes. It is missing Acked-by: lines from the maintainers of
>>> those files.
>>>
>>> All changes to files under net/sunrpc need an Ack from one
>>> of the maintainers listed in MAINTAINERS for that directory,
>>> if the changes are going through another maintainer's tree.
>>>
>>> I have been personally asked to remind folks that the
>>> nfs-sunrpc maintainers do not read linux-rdma, so they
>>> must be contacted directly (and cc: linux-nfs) as part of
>>> proposing finished patches in that area.
>>
>> I did that!!
>>
>> I copied you and Anna on the patch [1].
> 
> The marc.info archive does not preserve To: or Cc:
> fields on e-mail. I had to look in my own inbox to
> confirm who the recipients were.
> 
> Anna was the only NFS maintainer listed, and
> linux-nfs was not included on that e-mail at all.
> Did Anna ever reply with an Acked-by ? I don't see
> that in either the archive or my own inbox.

I'm not sure if I ever replied to that one.  This patch was part of an alternative to Christoph's deviceattr cleanup, right?  The NFS client bits looked okay to me, but I held off on replying to see which version was accepted.  Feel free to add my:

Acked-by: Anna Schumaker <Anna.Schumaker@netapp.com>

Anna

> 
> Bruce needs to Ack the svc_rdma_transport.c hunks.
> 
> 
>> Again, lets be concrete, this very small cleanup was picked and merged, anything there
>> need to be fixed?
> 
> I have rebased on Doug's current for-4.5, and will
> be testing today before submitting my for-4.5 patches
> again. Your changes are mechanical, so I don't expect
> to encounter a technical problem.
> 
> However, I would be more comfortable if the missing
> Acks were fixed in Doug's tree (with Anna and Bruce's
> permission, of course) before Linus pulls.
> 
> 
>> Or.
>>
>> [1] http://marc.info/?l=linux-rdma&m=145042924110411&w=2
>>
>>
>>> Unfortunately I have not been able to review every patch
>>> that has come by on linux-rdma in the past 9 months to
>>> ensure the eyes are dotted and tees crossed. More than
>>> a few commits in the tree are missing the proper tags.
>>>
>>>
>>>> [1]  commit e3e45b1 "xprtrdma: Avoid calling ib_query_device"
>>>>
>>>> in git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma.git k.o/for-4.5
>>>>
>>>> http://git.kernel.org/cgit/linux/kernel/git/dledford/rdma.git/commit/?h=k.o/for-4.5&id=e3e45b1b43988b99007a9908ca0ba738b3fbd0ff
>>>>
>>
> 
> --
> Chuck Lever
> 
> 
> 
> 

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

[Chuck Lever]

> On Jan 6, 2016, at 7:01 AM, Chuck Lever <chuck.lever@oracle.com> wrote:
> 
> 
>> On Jan 4, 2016, at 2:36 PM, J. Bruce Fields <bfields@fieldses.org> wrote:
>> 
>> On Sun, Jan 03, 2016 at 09:53:20PM -0500, Doug Ledford wrote:
>>> On 01/03/2016 08:44 PM, Stephen Rothwell wrote:
>>>> Hi all,
>>>> 
>>>> On Thu, 31 Dec 2015 13:30:22 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>>>> 
>>>>> Hi Doug,
>>>>> 
>>>>> Today's linux-next merge of the rdma tree got conflicts in a quite a
>>>>> few files between (mostly, I think) commit:
>>>>> 
>>>>> 6c7b6d2d442c ("IB: merge struct ib_device_attr into struct ib_device")
>>>>> 
>>>>> from the nfsd tree and various commits from the rdma tree.
>>>>> 
>>>>> It would have taken me considerable time to fix the conflicts up, so I
>>>>> have dropped teh rdma tree for today (just because it was merged second).
>>>>> Please have a conversation and figure out how you are going to cooperate
>>>>> and get these conflicts fixed e.g. set up a stable branch with Christoph's
>>>>> commit (and any other conflicting commits) in it and merge that into
>>>>> both trees.
>>>> 
>>>> So, on further inspection, it appears that there is a series of commits
>>>> in the rdma tree that does basically the same as that nfsd tree commit
>>>> above.  So I have dropped the rdma tree again today.  Please have a
>>>> conversation guys ...
>>>> 
>>> 
>>> The initial patchset was Christoph's.  It was later replaced with a
>>> different patchset from Or Gerlitz.  Bruce picked up some changes from
>>> Chuck Lever that were originally based on Christoph's work but now need
>>> to be rebased off of the current RDMA tree.
>> 
>> OK.  I'm assuming Chuck will want to do any necessary rebasing and
>> retesting himself, so for now I've just dropped those patches, and
>> expect to pick up new versions when Chuck gets back from the holidays.
> 
> Part of the plan was that Doug's tree would be merged before
> Bruce's. But the above problem description looks like the
> maintainer trees were merged into linux-next in the other order.
> 
> I'd like to make this simpler for everyone. Bruce, may I send
> my for-4.5 NFS/RDMA server patches to Doug with your Acked-by?
> That way, merge order won't matter.

Also, I see Dan Carpenter has posted a couple of clean-ups for
this series. I can include them with my upcoming repost if you
wish.

--
Chuck Lever

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

[J. Bruce Fields]

On Wed, Jan 06, 2016 at 07:01:14AM -0500, Chuck Lever wrote:
> Part of the plan was that Doug's tree would be merged before
> Bruce's. But the above problem description looks like the
> maintainer trees were merged into linux-next in the other order.

The order makes no difference.

The problem is that we had conflicting patches: I still had Christoph's
patch, but Doug's tree did something different.

(The only reason to care about merge order is that if I sent my pull
request to Linus first, it would look like "here's the nfsd changes for
4.5.  Oh, plus a bunch of rdma changes from Doug which he can explain
later...".  So it'd be best if the rdma changes were already in before I
sent a pull request based on them.)

> I'd like to make this simpler for everyone. Bruce, may I send
> my for-4.5 NFS/RDMA server patches to Doug with your Acked-by?

Sure, I'm fine with doing it either way.  Feel free to add my Acked-by:
to the patches you sent me before if that would simplify things.

--b.