[dpdk-dev] Proposal for a new Committer model

[Ferruh Yigit]

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.

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.

> I don't
> see any Merge commits in the master branch of his tree, so I'm left wondering
> what mechanic is being used to migrate patches from net-next or crypo-next to
> his tree.  Thomas, can you comment here?
> 
>>>
>>>
>>>>> We should be sharding that at a much higher
>>>>> granularity and using it much more consistently.  That is to say, that we
>>>>> should have a maintainer for all the ethernet pmds, and another for the
>>>>> crypto pmds, another for the core eal layer, another for misc libraries
>>>>> that have low patch volumes, etc.
>>>>
>>>> Yes we could open a tree for EAL and another one for the core libraries.
>>>>
>>> That could be worthwhile.  Lets see how the net and crypto subtrees work out
>>> (assuming again that these trees are newly founded)
>>>
>>>
>>>>> Each of those subdivisions should have
>>>>> their own list to communicate on, and each should have a tree that
>>>>> integrates patches for their own subsystem, and they should on a regular
>>>>> cycle send pull requests to Thomas.
>>>>
>>>> Yes I think it is now a good idea to split the mailing list traffic,
>>>> at least for netdev and cryptodev.
>>>>
>>> Agreed, that serves two purposes, it lowers the volume for people with a
>>> specific interest (i.e. its a rudimentary filter), and it avoids confusion
>>> between you and the subtree maintainer (that is to say, you don't have to even
>>> consider pulling patches that go to the crypo and net lists, you just have to
>>> trust that they pull those patches in and send you appropriate pull requests).
>>
>> I still find single mail list more useful.
> Why?  If you have interest in all the subsystems of a project, then its a small
> amount of overhead to subscribe to a set of mailing lists and dump them all to a
> single mail folder.  If you only have interest in a subset, its much more
> difficult to filter them out, given that we have a plethora of prefix tags for
> patches to define subsystems that aren't always used consistently.  Given that
> this thread is here because we've identified the patch volume as a problem, it
> seems fragmenting the list is the better solution.
> 
>> Also with current process, after -rc2 release, patches directly merged
>> into main tree instead of sub-trees...
>>
> Thats fine, at that point, if everything works properly, Thomas should only be
> getting low volume patch flow for stabilization/bug fixing.  If thats not the
> case, then perhaps we need to consider doing extra merges from the subtrees
> later in the cycle.
> 
> Neil
>