rdma kernel tree

rdma kernel tree

[Hefty, Sean]

Doug,

Do you plan on only using your kernel.org tree going forward, or will you maintain your github tree as well?

- Sean
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: rdma kernel tree

[Doug Ledford]

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

On Tue, 2015-05-12 at 21:31 +0000, Hefty, Sean wrote:
> Doug,
> 
> Do you plan on only using your kernel.org tree going forward, or will you maintain your github tree as well?

I plan to keep both repos.  The one on github will have stuff sooner,
but it is likely that portions of it will see rebases.  I've taken to a
very obvious branch naming scheme if I think that I'm going to rebase a
branch.  I'm also keeping the github repo as the one I have in the 0day
testing framework so that more of the stuff gets tested sooner.

When I'm satisfied that a branch has passed all of the 0day testing and
I'm no longer going to consider any changes to the patches in that
branch, then I'll make a k.o/<branchname> branch and I only push those
branches to the kernel.org repo.  Once a branch lands there, it is a
fast-forward only branch and will not see any rebases or edits of
patches.

I'm doing this because of the large number of interrelated patches that
different people are working on right now.  This makes it easier for
people to be able to base their work off of the latest interrelated
patches from other people.  Once this backlog clears out, it might be
possible for me to drop the github repo.  Right now it's the only way I
have to provide the sort of early access sandbox that people need to get
their patches in without taking too many consecutive release cycles.

-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
              GPG KeyID: 0E572FDD


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: rdma kernel tree

[Or Gerlitz]

On Wed, May 13, 2015 at 5:52 AM, Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> On Tue, 2015-05-12 at 21:31 +0000, Hefty, Sean wrote:
>> Doug,
>>
>> Do you plan on only using your kernel.org tree going forward, or will you maintain your github tree as well?
>
> I plan to keep both repos.  The one on github will have stuff sooner,
> but it is likely that portions of it will see rebases.  I've taken to a
> very obvious branch naming scheme if I think that I'm going to rebase a
> branch.  I'm also keeping the github repo as the one I have in the 0day
> testing framework so that more of the stuff gets tested sooner.
>
> When I'm satisfied that a branch has passed all of the 0day testing and
> I'm no longer going to consider any changes to the patches in that
> branch, then I'll make a k.o/<branchname> branch and I only push those
> branches to the kernel.org repo.  Once a branch lands there, it is a
> fast-forward only branch and will not see any rebases or edits of
> patches.
>
> I'm doing this because of the large number of interrelated patches that
> different people are working on right now.  This makes it easier for
> people to be able to base their work off of the latest interrelated
> patches from other people.  Once this backlog clears out, it might be
> possible for me to drop the github repo.  Right now it's the only way I
> have to provide the sort of early access sandbox that people need to get
> their patches in without taking too many consecutive release cycles.

Doug,

Still, as things are now, you've already accepted patches for 4.2
which are dependent on other patches which you've accepted too (e.g
Ira's patches on top of Michael's patches) --> @ this point (post
4.1-rc3) **something** has to be in your kernel.org branch for 4.2 --
else the chain of dependencies can become really non-traceable.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: rdma kernel tree

[Doug Ledford]

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

On Wed, 2015-05-13 at 17:46 +0300, Or Gerlitz wrote:
> On Wed, May 13, 2015 at 5:52 AM, Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> > On Tue, 2015-05-12 at 21:31 +0000, Hefty, Sean wrote:
> >> Doug,
> >>
> >> Do you plan on only using your kernel.org tree going forward, or will you maintain your github tree as well?
> >
> > I plan to keep both repos.  The one on github will have stuff sooner,
> > but it is likely that portions of it will see rebases.  I've taken to a
> > very obvious branch naming scheme if I think that I'm going to rebase a
> > branch.  I'm also keeping the github repo as the one I have in the 0day
> > testing framework so that more of the stuff gets tested sooner.
> >
> > When I'm satisfied that a branch has passed all of the 0day testing and
> > I'm no longer going to consider any changes to the patches in that
> > branch, then I'll make a k.o/<branchname> branch and I only push those
> > branches to the kernel.org repo.  Once a branch lands there, it is a
> > fast-forward only branch and will not see any rebases or edits of
> > patches.
> >
> > I'm doing this because of the large number of interrelated patches that
> > different people are working on right now.  This makes it easier for
> > people to be able to base their work off of the latest interrelated
> > patches from other people.  Once this backlog clears out, it might be
> > possible for me to drop the github repo.  Right now it's the only way I
> > have to provide the sort of early access sandbox that people need to get
> > their patches in without taking too many consecutive release cycles.
> 
> Doug,
> 
> Still, as things are now, you've already accepted patches for 4.2
> which are dependent on other patches which you've accepted too (e.g
> Ira's patches on top of Michael's patches)

Actually, no, this isn't true.  I accepted Ira's cleanup patches, and
they applied cleanly without Michael's patches.  The follow-on patches
to Michael's v8 patchset have not yet been posted since the last round
of review and requested changes.

>  --> @ this point (post
> 4.1-rc3) **something** has to be in your kernel.org branch for 4.2 --
> else the chain of dependencies can become really non-traceable.

They will land at kernel.org when I know they won't change again (which
really means when I have the final kdoc patch and Ira's dependent
patches and everything there is merged properly).  For now, they are
present at the github repo as:

mwang-v8
ira-cleanups
to-be-rebased/for-4.2 (which is nothing but a merge of the two above
branches)

-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
              GPG KeyID: 0E572FDD


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: rdma kernel tree

[Or Gerlitz]

On 5/13/2015 6:27 PM, Doug Ledford wrote:
> They will land at kernel.org when I know they won't change again (which
> really means when I have the final kdoc patch and Ira's dependent
> patches and everything there is merged properly).  For now, they are
> present at the github repo as:
>
> mwang-v8
> ira-cleanups
> to-be-rebased/for-4.2 (which is nothing but a merge of the two above
> branches)

Doug,

Developers whose work depends on other people can't chase multiple 
branches. And they need not wait for the maintainer to be 110% sure that 
something is final. Our community is small enough to swallow rebases you 
would do if at some point a patch for the next kernel is replaced, etc.

As others companies we have here internal review (Gerrit), build and 
regression systems which are dependent on the open-source maintainers 
trees/branches (for example, Dave Miller's net and net-next trees and 
used to be also on Roland infiniband.git / for-next branch).  These 
branches must be well known in location and name.

Lets find a way to get things in that direction, for everyone's benefit.

Or.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: rdma kernel tree

[Or Gerlitz]

On 5/13/2015 6:27 PM, Doug Ledford wrote:
> They will land at kernel.org when I know they won't change again (which
> really means when I have the final kdoc patch and Ira's dependent
> patches and everything there is merged properly).  For now, they are
> present at the github repo as:
>
> mwang-v8

This branch in your tree still have the way-too-many-Cc-and-such people 
on each of the 23 patches and is not aligned with the v8 posted to the 
list which don't have them. Something went wrong.

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: rdma kernel tree

[Doug Ledford]

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

On Thu, 2015-05-14 at 17:57 +0300, Or Gerlitz wrote:
> On 5/13/2015 6:27 PM, Doug Ledford wrote:
> > They will land at kernel.org when I know they won't change again (which
> > really means when I have the final kdoc patch and Ira's dependent
> > patches and everything there is merged properly).  For now, they are
> > present at the github repo as:
> >
> > mwang-v8
> 
> This branch in your tree still have the way-too-many-Cc-and-such people 
> on each of the 23 patches and is not aligned with the v8 posted to the 
> list which don't have them. Something went wrong.
> 

I pulled that via a bundle from patchworks.  I'll double check it.

-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
              GPG KeyID: 0E572FDD


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: rdma kernel tree

[Doug Ledford]

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

On Thu, 2015-05-14 at 16:03 +0300, Or Gerlitz wrote:
> On 5/13/2015 6:27 PM, Doug Ledford wrote:
> > They will land at kernel.org when I know they won't change again (which
> > really means when I have the final kdoc patch and Ira's dependent
> > patches and everything there is merged properly).  For now, they are
> > present at the github repo as:
> >
> > mwang-v8
> > ira-cleanups
> > to-be-rebased/for-4.2 (which is nothing but a merge of the two above
> > branches)
> 
> Doug,
> 
> Developers whose work depends on other people can't chase multiple 
> branches.

Fair enough.  I'll still keep my various topic branches, but I'll also
keep a for-next tag that you can easily pull to always get the right
stuff.

>  And they need not wait for the maintainer to be 110% sure that 
> something is final. Our community is small enough to swallow rebases you 
> would do if at some point a patch for the next kernel is replaced, etc.

My reason for not rebasing anything that touches kernel.org is because
that was a specific request from Linus.  Other people might do it, but
I'm going to respect his wishes.  I agree with you that we have a small
enough community and the people are generally able to deal with rebases.
That's why I have my github repo too.  To further keep with Linus'
wishes, my branches on github that might rebase are clearly labeled as
such (although that won't be obvious pulling a tag, but that's the best
I can do).

> As others companies we have here internal review (Gerrit), build and 
> regression systems which are dependent on the open-source maintainers 
> trees/branches (for example, Dave Miller's net and net-next trees and 
> used to be also on Roland infiniband.git / for-next branch).  These 
> branches must be well known in location and name.
> 
> Lets find a way to get things in that direction, for everyone's benefit.

I'm fine with that.  What I'll propose is the following:

Kernel.org tree: never rebases, will use a topic branch per release, I
will coordinate tags on the different branches because Linus prefers to
pull from signed tags anyway.  So, for-linus tag will always be the
current code I wish Linus to pull, for-next will be the official next
tag and it won't rebase, it will only move forward.

github.com tree: will have my various topic branches (these will come
and go as code is taken, merged into mainline, and then branch deleted),
will have copies of the official k.o/ branches (which won't rebase), and
will have to-be-rebase/* branches where I pull things together until I
am happy with the overall branch and then I will move it over to k.o/*
and it will no longer rebase.  It will also contain the most recent
for-linus tag, and it will contain a for-next that.  The only special
thing about the tags is if the for-next tag on k.o and here don't match,
it means that this tag points to a branch that might be rebased and has
not been blessed as official yet.  Once the tags between the two repos
are identical again, you will know I've made the last rebase and moved
the branch to the official status.

So, under that scheme, your automated stuff can be pointed at k.o
for-next, or if it is able to deal with rebases (meaning that your
automated system blows away the last kernel and performs the merges all
over again each time it runs) then you could point it at github
for-next.  Is that acceptable?


-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
              GPG KeyID: 0E572FDD


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: rdma kernel tree

[Or Gerlitz]

On Thu, May 14, 2015 at 6:07 PM, Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> [...] Is that acceptable?


I'll discuss that with folks here and provide feedback.

Or.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: rdma kernel tree

[Or Gerlitz]

On Thu, May 14, 2015 at 6:02 PM, Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> On Thu, 2015-05-14 at 17:57 +0300, Or Gerlitz wrote:
>> On 5/13/2015 6:27 PM, Doug Ledford wrote:
>> > They will land at kernel.org when I know they won't change again (which
>> > really means when I have the final kdoc patch and Ira's dependent
>> > patches and everything there is merged properly).  For now, they are
>> > present at the github repo as:
>> >
>> > mwang-v8
>>
>> This branch in your tree still have the way-too-many-Cc-and-such people
>> on each of the 23 patches and is not aligned with the v8 posted to the
>> list which don't have them. Something went wrong.
>>
>
> I pulled that via a bundle from patchworks.  I'll double check it.

Did  you check it out? fixed it out?
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: rdma kernel tree

[Or Gerlitz]

On Thu, May 14, 2015 at 6:07 PM, Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:

>> Lets find a way to get things in that direction, for everyone's benefit.

> I'm fine with that.  What I'll propose is the following:

> Kernel.org tree: never rebases, will use a topic branch per release, I
> will coordinate tags on the different branches because Linus prefers to
> pull from signed tags anyway.  So, for-linus tag will always be the
> current code I wish Linus to pull, for-next will be the official next
> tag and it won't rebase, it will only move forward.

The official for-linus / for-next tag branding sounds OK, conditioned
on the git mechanics for the day-to-day developers use case to be
really simple (no need for checkouts? only pulls? maybe give few
examples on how people are expected to use that).

Personally, I am terribly sold out for the ultra simple practice of
two trees (e.g the netdev case) or two branches of the same tree (e.g
for-next, for-rc) which I always know where to get and what would they
contain. So I am a bit annoyed from the per-release topic branches.
But if everyone else are OK with your proposal we can go there (Amir -
is this OK for our automated systems?)


> github.com tree: will have my various topic branches (these will come
> and go as code is taken, merged into mainline, and then branch deleted),
> will have copies of the official k.o/ branches (which won't rebase), and
> will have to-be-rebase/* branches where I pull things together until I
> am happy with the overall branch and then I will move it over to k.o/*
> and it will no longer rebase.  It will also contain the most recent
> for-linus tag, and it will contain a for-next that.  The only special
> thing about the tags is if the for-next tag on k.o and here don't match,
> it means that this tag points to a branch that might be rebased and has
> not been blessed as official yet.  Once the tags between the two repos
> are identical again, you will know I've made the last rebase and moved
> the branch to the official status.

Sort of too complex for me to follow. I am on upstream for coupled of
years and worked with few maintainers, didn't had to go into that
level. I would prefer just to use your kernel.org and for-next things
need to be there before rc4 (today).

> So, under that scheme, your automated stuff can be pointed at k.o
> for-next, or if it is able to deal with rebases (meaning that your
> automated system blows away the last kernel and performs the merges all
> over again each time it runs) then you could point it at github
> for-next.  Is that acceptable?

Again, for the automated Amir needs to reply. For the day-to-day I
replied how I personally see things.

Another thing to nail down is patch subject line tagging. Currently it
seems no agreed practice. Under Roland we had for-next or nothing
(mostly the latter...)

I would suggest one of:

for-next (next release) and for-rc (current release)

or

rdma-next (next release) and rdma-rc (current release)

or

something else? RFCs are exception.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: rdma kernel tree

[Or Gerlitz]

>> I pulled that via a bundle from patchworks.  I'll double check it.
> Did  you check it out? fixed it out?

I took a look now, you've rebased to-be-rebased/for-4.2 to 4.1-rc4 and 
it seems this is what you are going to push into the kernel.org treem 
but this series is still there with the zillion tested/reviewed/etc 
signature per one 2-3 patch, I think we've agreed this needs to be 
addressed prior to the upstream push, right?

Or.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: rdma kernel tree

[Doug Ledford]

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

On Tue, 2015-05-19 at 07:35 +0300, Or Gerlitz wrote:
> >> I pulled that via a bundle from patchworks.  I'll double check it.
> > Did  you check it out? fixed it out?
> 
> I took a look now, you've rebased to-be-rebased/for-4.2 to 4.1-rc4 and 

Correct.

> it seems this is what you are going to push into the kernel.org treem 

Correct.

> but this series is still there with the zillion tested/reviewed/etc 
> signature per one 2-3 patch, I think we've agreed this needs to be 
> addressed prior to the upstream push, right?

Incorrect.  What you objected to before was the large Cc: list in the
patches.  That is gone.  What is there now is just the reviewed-by: list
of three people, and the tested-by list of two people.  As the entire
patch set as a whole was reviewed and tested by those people, it seems
accurate to me.

-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
              GPG KeyID: 0E572FDD


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: rdma kernel tree

[Or Gerlitz]

On Tue, May 19, 2015 at 3:22 PM, Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> On Tue, 2015-05-19 at 07:35 +0300, Or Gerlitz wrote:
>> >> I pulled that via a bundle from patchworks.  I'll double check it.
>> > Did  you check it out? fixed it out?
>>
>> I took a look now, you've rebased to-be-rebased/for-4.2 to 4.1-rc4 and
>
> Correct.
>
>> it seems this is what you are going to push into the kernel.org treem
>
> Correct.
>
>> but this series is still there with the zillion tested/reviewed/etc
>> signature per one 2-3 patch, I think we've agreed this needs to be
>> addressed prior to the upstream push, right?
>
> Incorrect.  What you objected to before was the large Cc: list in the
> patches.  That is gone.  What is there now is just the reviewed-by: list
> of three people, and the tested-by list of two people.  As the entire
> patch set as a whole was reviewed and tested by those people, it seems
> accurate to me.

Doug, I have never ever seen a patch set (specifically the 15~23 part
of it) with that level of simplicity and
signature/reviewers/tested-by/etc inflation. It's just eye burner.
Maybe that long list is OK for patch #1 but very much not to these
bunch of 1-2 liner downstream patches.

AFAIK, this is Michael's 1st upstream contribution and there's no
reason for him to think something here is deeply wrong and/or should
have been done differently if we let it go that way into the kernel
logs forever.

Or.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: rdma kernel tree

[Jason Gunthorpe]

On Tue, May 19, 2015 at 09:47:06PM +0300, Or Gerlitz wrote:

> Doug, I have never ever seen a patch set (specifically the 15~23 part
> of it) with that level of simplicity and
> signature/reviewers/tested-by/etc inflation. It's just eye burner.
> Maybe that long list is OK for patch #1 but very much not to these
> bunch of 1-2 liner downstream patches.

The work was done, credit is due.

Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: rdma kernel tree

[Doug Ledford]

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

On Tue, 2015-05-19 at 21:47 +0300, Or Gerlitz wrote:
> On Tue, May 19, 2015 at 3:22 PM, Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> > On Tue, 2015-05-19 at 07:35 +0300, Or Gerlitz wrote:
> >> >> I pulled that via a bundle from patchworks.  I'll double check it.
> >> > Did  you check it out? fixed it out?
> >>
> >> I took a look now, you've rebased to-be-rebased/for-4.2 to 4.1-rc4 and
> >
> > Correct.
> >
> >> it seems this is what you are going to push into the kernel.org treem
> >
> > Correct.
> >
> >> but this series is still there with the zillion tested/reviewed/etc
> >> signature per one 2-3 patch, I think we've agreed this needs to be
> >> addressed prior to the upstream push, right?
> >
> > Incorrect.  What you objected to before was the large Cc: list in the
> > patches.  That is gone.  What is there now is just the reviewed-by: list
> > of three people, and the tested-by list of two people.  As the entire
> > patch set as a whole was reviewed and tested by those people, it seems
> > accurate to me.
> 
> Doug, I have never ever seen a patch set (specifically the 15~23 part
> of it) with that level of simplicity

That portion of the patchset didn't start out with that level of
simplicity per patch, it evolved to that because it made review
*significantly* easier.  It's very simple to review a patch that does:

Add 1 helper
Replace tests in code with just that 1 helper

because you can scroll through that patch and know that every line being
replaced is related to that one helper.  If you want to know every line
that was replaced with rdma_cap_iw_cm, you go to that one patch and it's
all listed very easy to read.

On the other hand, when you squash all those patches together, review
becomes much harder because if you want to see what a single helper
does, you have to sift through all of the other helper changes and hope
you find the right ones, and that you found all of the right ones.

>  and
> signature/reviewers/tested-by/etc inflation.

I added those myself as part of an automated addition.  It applied to
the entire series, so it was put on each patch.  The people that
tested/reviewed the series did not do so to individual patches, they hit
all of them.  And as was pointed out a couple of weeks ago on an earlier
patchset I picked up, it is generally good behavior to give attribution
where it is due to encourage people to participate.

-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
              GPG KeyID: 0E572FDD


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: rdma kernel tree

[Yann Droneaud]

Hi,

Le mardi 19 mai 2015 à 15:49 -0400, Doug Ledford a écrit :
> On Tue, 2015-05-19 at 21:47 +0300, Or Gerlitz wrote:
> > On Tue, May 19, 2015 at 3:22 PM, Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> > > On Tue, 2015-05-19 at 07:35 +0300, Or Gerlitz wrote:
> > >> >> I pulled that via a bundle from patchworks.  I'll double check it.
> > >> > Did  you check it out? fixed it out?
> > >>
> > >> I took a look now, you've rebased to-be-rebased/for-4.2 to 4.1-rc4 and
> > >
> > > Correct.
> > >
> > >> it seems this is what you are going to push into the kernel.org treem
> > >
> > > Correct.
> > >
> > >> but this series is still there with the zillion tested/reviewed/etc
> > >> signature per one 2-3 patch, I think we've agreed this needs to be
> > >> addressed prior to the upstream push, right?
> > >
> > > Incorrect.  What you objected to before was the large Cc: list in the
> > > patches.  That is gone.  What is there now is just the reviewed-by: list
> > > of three people, and the tested-by list of two people.  As the entire
> > > patch set as a whole was reviewed and tested by those people, it seems
> > > accurate to me.
> > 
> > Doug, I have never ever seen a patch set (specifically the 15~23 part
> > of it) with that level of simplicity
> 
> That portion of the patchset didn't start out with that level of
> simplicity per patch, it evolved to that because it made review
> *significantly* easier.  It's very simple to review a patch that does:
> 
> Add 1 helper
> Replace tests in code with just that 1 helper
> 
> because you can scroll through that patch and know that every line being
> replaced is related to that one helper.  If you want to know every line
> that was replaced with rdma_cap_iw_cm, you go to that one patch and it's
> all listed very easy to read.
> 
> On the other hand, when you squash all those patches together, review
> becomes much harder because if you want to see what a single helper
> does, you have to sift through all of the other helper changes and hope
> you find the right ones, and that you found all of the right ones.
> 
> >  and
> > signature/reviewers/tested-by/etc inflation.
> 
> I added those myself as part of an automated addition.  It applied to
> the entire series, so it was put on each patch.  The people that
> tested/reviewed the series did not do so to individual patches, they hit
> all of them.  And as was pointed out a couple of weeks ago on an earlier
> patchset I picked up, it is generally good behavior to give attribution
> where it is due to encourage people to participate.
> 

I agree with all the above replies from Doug:

- small patches are easier to read and review: I prefer reviewing 10
littles patches than one big patch.

- Signed-off-by:, Reviewed-by:, Tested-by: and Cc: are required too
so that when it come to modifying existing code, we can contact people
previously involved for reviews, tests, advice, etc.

(I usually add Link: with a reference to the e-mail so that one commit
 can be traced back to the related patch submission and discussions  
 (cover-letter !), and, to be able to trace back all patch iterations,
 I add a link to the previous patchset submission, and so on).

Regards.

-- 
Yann Droneaud
OPTEYA


--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: rdma kernel tree

[Or Gerlitz]

Doug,

Do you have everything in place such that what you stage for upstream
is subject to linux-next auto merge tests and such?

Or.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: rdma kernel tree

[Doug Ledford]

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

On Wed, 2015-05-27 at 12:50 +0300, Or Gerlitz wrote:
> Doug,
> 
> Do you have everything in place such that what you stage for upstream
> is subject to linux-next auto merge tests and such?
> 
> Or.

No, I have 0day in place, but not linux-next to my knowledge (unless
Stephen already set it up, but I haven't asked him to yet).

Stephen, can you set it up so that the linux-next tag from
git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma.git is added
to the linux-next testing please?

-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
              GPG KeyID: 0E572FDD


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: rdma kernel tree

[Or Gerlitz]

On Wed, May 27, 2015 at 4:13 PM, Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> On Wed, 2015-05-27 at 12:50 +0300, Or Gerlitz wrote:
>> Doug,
>>
>> Do you have everything in place such that what you stage for upstream
>> is subject to linux-next auto merge tests and such?
>>
>> Or.
>
> No, I have 0day in place, but not linux-next to my knowledge (unless
> Stephen already set it up, but I haven't asked him to yet).

Oh, please rush to make sure this is in place,

>
> Stephen, can you set it up so that the linux-next tag from
> git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma.git is added
> to the linux-next testing please?
>
> --
> Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>               GPG KeyID: 0E572FDD
>
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: rdma kernel tree

[Stephen Rothwell]

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

Hi Doug,

On Wed, 27 May 2015 09:13:29 -0400 Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>
> Stephen, can you set it up so that the linux-next tag from
> git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma.git is added
> to the linux-next testing please?

I haven't fetched tags in the past, only branches (it is a little
tricky, but I can work on it) and there is no linux-next tag in that
tree anyway (I assume that you mean for-next).

Also, how does this relate to Roland's infiniband tree
(git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git#for-next)
that is already in linux-next?

Added from today.
Thanks for adding your subsystem tree as a participant of linux-next.  As
you may know, this is not a judgment of your code.  The purpose of
linux-next is for integration testing and to lower the impact of
conflicts between subsystems in the next merge window. 

You will need to ensure that the patches/commits in your tree/series have
been:
     * submitted under GPL v2 (or later) and include the Contributor's
        Signed-off-by,
     * posted to the relevant mailing list,
     * reviewed by you (or another maintainer of your subsystem tree),
     * successfully unit tested, and 
     * destined for the current or next Linux merge window.

Basically, this should be just what you would send to Linus (or ask him
to fetch).  It is allowed to be rebased if you deem it necessary.

-- 
Cheers,
Stephen Rothwell 
sfr-3FnU+UHB4dNDw9hX6IcOSA@public.gmane.org

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

Re: rdma kernel tree

[Doug Ledford]

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

On Thu, 2015-05-28 at 11:02 +1000, Stephen Rothwell wrote:
> Hi Doug,
> 
> On Wed, 27 May 2015 09:13:29 -0400 Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> >
> > Stephen, can you set it up so that the linux-next tag from
> > git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma.git is added
> > to the linux-next testing please?
> 
> I haven't fetched tags in the past, only branches (it is a little
> tricky, but I can work on it) and there is no linux-next tag in that
> tree anyway (I assume that you mean for-next).

Sorry, you are correct, for-next is the right tag.

> Also, how does this relate to Roland's infiniband tree
> (git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git#for-next)
> that is already in linux-next?

Roland has stepped down as maintainer.  The community selected me to try
to pick up where he has left off.

> Added from today.
> Thanks for adding your subsystem tree as a participant of linux-next.  As
> you may know, this is not a judgment of your code.  The purpose of
> linux-next is for integration testing and to lower the impact of
> conflicts between subsystems in the next merge window. 
> 
> You will need to ensure that the patches/commits in your tree/series have
> been:
>      * submitted under GPL v2 (or later) and include the Contributor's
>         Signed-off-by,
>      * posted to the relevant mailing list,
>      * reviewed by you (or another maintainer of your subsystem tree),
>      * successfully unit tested, and 
>      * destined for the current or next Linux merge window.
> 
> Basically, this should be just what you would send to Linus (or ask him
> to fetch).  It is allowed to be rebased if you deem it necessary.
> 


-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
              GPG KeyID: 0E572FDD


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: rdma kernel tree

[Doug Ledford]

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

On Thu, 2015-05-28 at 11:40 +1000, Stephen Rothwell wrote:
> Hi Doug, Roland,
> 
> On Wed, 27 May 2015 21:14:03 -0400 Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> >
> > > Also, how does this relate to Roland's infiniband tree
> > > (git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git#for-next)
> > > that is already in linux-next?
> > 
> > Roland has stepped down as maintainer.  The community selected me to try
> > to pick up where he has left off.
> 
> So, I assume that I should remove the infiniband tree from linux-next?

Here's the link to Roland's announcement:

http://marc.info/?l=linux-rdma&m=142860130010529&w=2

Based upon his comments there, I would say it's a good bet that he
doesn't plan to continue hosting his own tree now that the switch over
has happened.  But, of course, he can speak for himself.

-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
              GPG KeyID: 0E572FDD


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: rdma kernel tree

[Roland Dreier]

> Also, how does this relate to Roland's infiniband tree
> (git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git#for-next)
> that is already in linux-next?

You can drop my tree, I'm no longer updating it.

 - R.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: rdma kernel tree

[Stephen Rothwell]

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

Hi Roland,

On Wed, 3 Jun 2015 19:07:45 -0700 Roland Dreier <roland-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
>
> > Also, how does this relate to Roland's infiniband tree
> > (git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git#for-next)
> > that is already in linux-next?
> 
> You can drop my tree, I'm no longer updating it.

OK, thanks, will do.

-- 
Cheers,
Stephen Rothwell                    sfr-3FnU+UHB4dNDw9hX6IcOSA@public.gmane.org

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

Re: rdma kernel tree

[Stephen Rothwell]

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

Hi Roland,

On Wed, 3 Jun 2015 19:07:45 -0700 Roland Dreier <roland-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
>
> > Also, how does this relate to Roland's infiniband tree
> > (git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git#for-next)
> > that is already in linux-next?
> 
> You can drop my tree, I'm no longer updating it.

Done.  Thanks.

-- 
Cheers,
Stephen Rothwell                    sfr-3FnU+UHB4dNDw9hX6IcOSA@public.gmane.org

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