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

[Neil Horman <nhorman@tuxdriver.com>]

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?


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

> > Thomas in turn should by and large,
> > only be integrating pull requests.  This should address our high-
> > throughput issue, in that it will allow multiple maintainers to share the
> > workload, and integration should be relatively easy.
> 
> Yes in an ideal organization, the last committer does only a last check
> that technical plan and fairness are respected.
> So it gives more time to coordinate the plans :)
> 
Correct.  Thats never 100% accurate of course, some things will still have to
come to you directly, simply by virtue of the fact that they don't completely
fit anywhere else, but thats ok, the goal is really just to get your total patch
volume lower, and replace it with pull requests that you can either trivialy
mere or figure out with the help of the subtree maintainer.

> > B) Designate alternates to serve as backups for the maintainer when they
> > are unavailable.  This provides high-availablility, and sounds very much
> > like your proposal, but in the interests of clarity, there is still a
> > single maintainer at any one time, it just may change to ensure the
> > continued merging of patches, if the primary maintainer isn't available.
> > Ideally however, those backup alternates arent needed, because most of the
> > primary maintainers work in merging pull requests, which are done based on
> > the trust of the submaintainer, and done during a very limited window of
> > time.  This also partially addreses multi-vendor fairness if your subtree
> > maintainers come from multiple participating companies.
> 
> About the merge window, I do not have a strong opinion about how it can be
> improved. However, I know that closing the window too early makes developer
> unhappy because it makes wait - between development start and its release -
> longer.

This is a fair point, but I'm not talking about closing it early here, all
I'm suggesting is that, if you do proper pull requests from subtrees, your tree
Thomas will only need a reasonably small window of time to accept new features,
because you'll just merge the subtrees, rather than integrating individual
patches.  E.g. you won't be constantly merging patches over the course of a
development cycle, your tree's HEAD will mostly consist of merge commits as
subtree maintainers send you pull requests, and ideally they will send those
near the start of a window.  How long you keep your merge window open after that
is up to you.

Neil


 
>