Re: [ANNOUNCE] Shared pull requests (was Re: Workflow for i40iw patch submissions)

[Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]

[-- Attachment #1.1: Type: text/plain, Size: 6618 bytes --]

On 9/26/2017 2:56 AM, Leon Romanovsky wrote:
> On Tue, Sep 26, 2017 at 08:13:49AM +0300, Leon Romanovsky wrote:
>> On Mon, Sep 25, 2017 at 10:31:47PM -0400, Doug Ledford wrote:
>>> On 9/25/2017 11:57 AM, Leon Romanovsky wrote:
>>>> On Mon, Sep 25, 2017 at 10:53:01AM -0400, Doug Ledford wrote:
>>>>> On 9/24/2017 11:59 PM, Leon Romanovsky wrote:
>>>>>> On Sat, Sep 23, 2017 at 11:03:25AM -0400, Doug Ledford wrote:
>>>>>>
>>>>>> <...>
>>>>>>
>>>>>>>
>>>>>>> I want any shared pull requests to be based on nothing newer than an
>>>>>>> rc2 kernel.  I branch my for-next branch at rc2, so if your pull
>>>>>>> request is on something later it will pollute my main for-next branch
>>>>>>> to merge it.  I plan to merge my own -rc pull requests after rc2 into
>>>>>>> my for-next branch, so you won't be missing code that goes into later
>>>>>>> rcs if you base your work on my for-next branch, so that's a second
>>>>>>> alternative starting point for your shared pull requests should you
>>>>>>> need it.
>>>>>>
>>>>>> From our experience, it is not feasible to demand shared pull
>>>>>> requests on "newer than an rc2 kernel".
>>>>>
>>>>> I said "nothing newer than an rc2 kernel".  Did you mean to leave out
>>>>> the nothing?
>>>>
>>>> Most probably I translated it incorrectly. I wanted to say that all
>>>> shared pull requests will be -rc2, -rc3, e.t.c. and probably will never
>>>> be -rc1. Did you mean the same?
>>>>
>>>>>
>>>>>> The magic of shared pull request
>>>>>> is in the fact that it is based on the same origin for both trees.
>>>>>
>>>>> Correct.  So, for instance, I'm opening up my for-next area today and it
>>>>> will be based on a clean v4.14-rc2.  What I'm then asking for is that
>>>>> subsequent driver shared pull requests be based on a v4.14-rc2 tree.
>>>>> Your last shared pull request was mostly OK, but it was based on a
>>>>> v4.13-rc4 kernel and so it would have simultaneously brought in your
>>>>> patches and also all the changes between 4.13-rc2 and 4.13-rc4.
>>>>
>>>> Why is it "undesired behavior"? Anyhow git request-pull to Linus will
>>>> filter all patches which already exist in Linus's tree and you will get
>>>> merge of -rc fixes for free in your for-next.
>>>
>>> You obviously have not been paying attention when Linus yells at me.
>>
>> I do, but probably we are understanding Linus's responses differently.
>>
>> You probably mean the conversation after that pull request.
>>  * First round of RC fixes for 4.13
>>    https://marc.info/?l=linux-rdma&m=150039306716272&w=2

More than just that conversation.  There have been offline conversations
too.

>> He started to complain about empty merge commit with v4.13-rc1, and continued with explanations
>> about difference between back and forward merges. From my point of view, my intention to base
>> shared pull request on latest -rcX is exactly forward (good) merge, because it ensures that
>> all our future submissions for net/net-next/rdma-rc/rdma-next are completely in sync and
>> ready to go.

This is why, when I submit a pull request for -rc, I also merge it into
for-next.  It keeps this up to date as you say, without needing to pull
in all of the -rc, so it gives Linus an easier history to look at.  It
does not, however, sync up the net side of things.

> And if we are talking about back-forward merges, the following merge is
> a back one and it was mentioned by Linus as a bad type of merge which
> should be avoided:
>  * Merge tag 'v4.14-rc2' into k.o/for-next
>    https://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma.git/commit/?h=k.o/for-next&id=0d9c2ff1c9f7f8b339fc42ac9763b28c71f1c115
> 
> Because your previous for-next was fully merged

It was...

> and new one was opened after
> -rc2

It was...

> and your initial pull request with fixes was accepted during in -rc1 too,

It was...

> you was supposed simply reset your for-next to v4.14-rc2 tag
> git reset --hard v4.14-rc2) as a starting point of for-next.

I didn't think this would work on k.o (and it's why I did the merge),
but it does work.  The reason I didn't think it would work is that even
though v4.14-rc2 and my branch merged with v4.14-rc2 have the same final
image, their path to get there (as shown by git log --oneline
--topo-order) would be different.  As such, I expected the k.o git
server to kick it as a non-fast-forward update when I attempted to push
after having used git reset --hard v4.14-rc2.  But, it didn't, it took
it, and a git pull of the tree before the reset and after the reset was
totally non-eventful.  So, I won't do that next time.

> Thanks
> 
>>
>>> This is something he specifically does *not* want, and if you send me a
>>> shared pull request that is based on, say, -rc4, then I can't merge it
>>> into my for-next branch and instead of I have to carry a separate branch
>>> and send a separate pull request just for that branch.
>>
>> I don't think so, but we can probably catch Linus at KS next month and
>> ask him directly.
>>
>>>
>>> The reason is that Linus wants to be able to pull up gitk on my pull
>>> request and see the changes I am submitting for easy review.  If I merge
>>> a shared pull request that also includes an update to the -rc level of
>>> my tree, then all those -rc patches get mixed into the gitk ordering and
>>> it makes it hard for Linus to find just the patches he wants.  So, this
>>> is a Linus issue, not so much my issue.  If he didn't care, I wouldn't
>>> either, but this is the way it is.
>>>
>>
>> I don't know how gitk presents git history, but the following command
>> "git log --graph --no-merges -- drivers/infiniband include/rdma/ include/uapi/rdma" works like
>> a charm and presents only RDMA related commits.
>>
>> Other replies from Linus about late submission, compiler warnings, tree-wide changes,
>> request to separate pull requests, fix with strange name ("Add ...") are completely unrelated.
>>
>> I read upto 19 Mar 2016, in that pull request Linus explained to us how we should create shared pull request.
>> Everything before is not relevant for shared pull requests.
>>
>> Thanks
>>
>>>
>>> --
>>> Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>>>     GPG Key ID: B826A3330E572FDD
>>>     Key fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD
>>>
>>
>>
>>
> 
> 


-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
    GPG Key ID: B826A3330E572FDD
    Key fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD


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