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

[Neil Horman <nhorman@tuxdriver.com>]

On Thu, Nov 24, 2016 at 10:17:09AM +0100, Thomas Monjalon wrote:
> 2016-11-23 15:13, Neil Horman:
> > 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.
> 
> Until now, we preferred avoiding merge commits.
> That's why I rebase sub-trees to integrate them in the mainline.
> As Ferruh explained, it does not require more work because sub-trees are
> regularly rebased anyway.
> And I use a script to keep original committer name and date.
> 
> Hope it's clear now
> 
It is clear, but I would make the assertion that performing that rebase
yourselves (and arguably having the subtree maintainers do that too), you are
undoing all the speedup that you would otherwise have gained.

To illustrate, from what it sounds like to me, this is your workflow, from the
moment that a merge window starts:

1) Each subtree maintainer syncrhonizes with your tree (either via a rebase, or
a simple pull and creation of a new next version branch), the specific method
can really be left up to the preference of the subtree maintainer

2) Developent procedes in parallel on multiple subtrees, and to your tree (for
those patches that have no other designated subtree)

3) At some point, you opt to merge subtrees to your trees.  For each tree you
ostensibly then need to:

3a) Inform the subtree maintainer (or otherwise record the point up to which you
decided to integrate)

3b) Grab a copy of that tree from the start to the end point (either via a
remote branch clone or some other method)

3c) Rebase the branch in 3(b) to the HEAD of your tree, correcting any errors
along the way

3d) preform a merge to your master branch, which, after 3(c), will by definition
be a fast forward branch

While thats a workable solution, it suffers from many drawbacks:

a) It looses your commit history.  That is to say, with a true merge, you record
several other relevant pieces of information, including:
	* The branch/tree that the series came from
	* The changes that needed to be made to make the series fit (conflict
	  tracking)
	* The sha1 sums of the commits (immutable changeset tracking).
   By rebasing you loose all of that, especially that last piece because the
rebase you preform changes your shasums.  With a non-merge, you keep all that
information properly.

b) You increase your error risk.  With a true merge, all the changes you need to
make to get a merge to resolve properly are contained in a single commit (the
merge commit),  providing easy review of your updates (not that they should
happen frequently).  By rebasing, you are left with potentially changed commits
that aren't trackable or easily comparable to the origional submission.

c) Perhaps most importantly, you serialize the entire process.  To follow the
above, you need to merge one branch at a time, rebasing each until it works
properly, then merging it.  With a true merge, you are afforded the opportunity
to merge any number of branches in parallel (see git-octopus-merge).


Apologies if this was discussed on list previously, but what was the percieved
advantage to avoiding merge commits?  It seems like alot of lost opportunity to
avoid something that is actually fairly informative in the toolchain.

Regards
Neil