Re: [dpdk-dev] Proposal for a new Committer model

[Ferruh Yigit <ferruh.yigit@intel.com>]

On 11/23/2016 3:33 PM, Neil Horman wrote:
> On Wed, Nov 23, 2016 at 02:01:44PM +0000, Ferruh Yigit wrote:
>> On 11/23/2016 1:48 PM, Neil Horman wrote:
>>> On Tue, Nov 22, 2016 at 08:56:23PM +0000, Ferruh Yigit wrote:
>>>> On 11/22/2016 7:52 PM, Neil Horman wrote:
>>>>> On Mon, Nov 21, 2016 at 09:52:41AM +0100, Thomas Monjalon wrote:
>>>>>> 2016-11-18 13:09, Neil Horman:
>>>>>>> A) Further promote subtree maintainership.  This was a conversation that I
>>>>>>> proposed some time ago, but my proposed granularity was discarded in favor
>>>>>>> of something that hasn't worked as well (in my opinion).  That is to say a
>>>>>>> few driver pmds (i40e and fm10k come to mind) have their own tree that
>>>>>>> send pull requests to Thomas.
>>>>>>
>>>>>> Yes we tried this fine granularity and stated that it was not working well.
>>>>>> We are now using the bigger granularity that you describe below.
>>>>>>
>>>>> Ok, thats good, but that must be _very_ new.  Looking at your git tree, I see no
>>>>> merge commits.  How are you pulling from those subtrees?
>>>>
>>>> next-net tree is active for last three releases.
>>>>
>>> What!?  What is the purpose of holding patches in a subtree for multiple
>>> releases?  
>>
>> :) Of course not holding them in the sub-tree.
>>
> Ok, glad that we're on the same page.
> 
>> Briefly, process is:
>> - sub-tree gets patches during merge window
>> - sub-tree first merged into main tree in -rc1 and later in -r2
>>
>> next-net tree is actively in use for last three releases, and driver/net
>> patches delegated to this tree. You can see different commiters in main
>> tree.
>>
>>> If a given changeset isn't ready for merge to Thomas tree the people
>>> working on it should clone the subtree to some place they can all collaborate on
>>> it.  Once it goes into a subtree there needs to be a defined workflow to get it
>>> into the canonical tree that Thomas maintains on a regular, short time frame.
>>> to do less is to confuse the process for everyone involved, and slow people
>>> down, rather than accelerate their work.
>>>
>>>> I guess following is the first commit to the sub-tree:
>>>> http://dpdk.org/ml/archives/dev/2016-February/032580.html
>>>>
>>>> sub-trees rebase on top of main tree regularly, that is why there is no
>>>> merge commit.
>>>>
>>> I'm not asking about merge commits in the sub-tree, I'm asking about merge
>>> commits in thomas's tree.
>>
>> Same, talking about Thomas' tree.
>>
>>>  There should be a merge commit every time he pulls
>>> from a sub-tree (unless its a fast-forward I think, but with multiple subtrees
>>> and commits going to thomas directly, that should never really happen).  
>>
>> That is what happening. Since sub-tree's rebase on top of main tree,
>> when Thomas merges, it is just plain fast-forward. So it is allowed to
>> re-write to history in sub-trees.
>>
> ok, I see what you're saying here, but I still don't see how this results in no
> merge commits.  From what I can see we have at least 4 subtrees (next-crypto,
> next-net, next-eventdev, next-virtio).  If you rebase all on lastest version of
> thomas's tree, and then they all make changes and send a pull request, the first
> to be merged will, by definition be a fast forward.  The remaining three
> however, cannot be, because the prior merge has advanced the HEAD commit in
> Thomas's tree such that its divergent from the subsequent tree to be merged.  So there
> should be some merge commits in Thomas's tree.

This is simple indeed, all can do fast-forward, because all sub-trees
touch to different files.

Currently:
next-net: drivers/net/* [except virtio and vhost]
next-crypto: drivers/crypto/*
next-virtio: drivers/net/virtio/*, drivers/net/vhost/*

Common files are in main tree, when all rebased on top of it, they all
can be merged as fast-forward.

> 
> The only way I see around that, is if the merges are serialized (i.e. if you
> provide an order to the subtrees and each subtree rebases from thomas prior to
> applying its patches, then merges back to thomas's tree).  Thats rather defeating
> of the purpose of parallel trees though.  You can all rebase, but then you
> operate independently of each other.  Thats how we realize a speedup here
> 
> 
> Neil
>