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

[Neil Horman <nhorman@tuxdriver.com>]

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.

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