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

[Neil Horman <nhorman@tuxdriver.com>]

On Wed, Nov 23, 2016 at 04:21:00PM +0000, Ferruh Yigit wrote:
> 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.
> 
Fast forward-ability isn't determined by only touching orthogonal files, its
completely dependent on the relative HEAD and base pointers of each branch.  If
you send a pull request for your subtree on branch A from commit B to commit C,
the merge will resolve as a fast forward, if and only if, the HEAD commit of the
branch that the receiver is pulling to matches the base commit of the branch
being pulled (that is to say, commit B). If the receiving branch has any
additional commits on top of it, then the branches have diverged (even if the
applied patches don't touch a common set of files), and as a result a merge
commit is created (which may be empty if there are no conflicts).  Given that
there are no merge commits in Thomas tree, I conclude that you are either:

1) Not sending pull requests to Thomas - ie, just sending him a series of
patches to apply

2) Rebasing your work immediately prior to sending a pull request, resulting in
a fast-forward

Can either you or thomas provide some detail as to how you are doing patch
management between trees (details of the commands you use are what I would be
interested in). It sounds to me like there may be some optimization to be made
here before we even make changes to the subtrees.

Best
Neil

> > 
> > 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
> > 
> 
>