[dpdk-dev] Proposal for a new Committer model

[Neil Horman]

On Thu, Nov 17, 2016 at 09:20:50AM +0000, Mcnamara, John wrote:
> Repost from the moving at dpdk.org mailing list to get a wider audience.
> Original thread: http://dpdk.org/ml/archives/moving/2016-November/000059.html
> 
> 
> Hi,
> 
> I'd like to propose a change to the DPDK committer model. Currently we have one committer for the master branch of the DPDK project. 
> 
> One committer to master represents a single point of failure and at times can be inefficient. There is also no agreed cover for times when the committer is unavailable such as vacation, public holidays, etc. I propose that we change to a multi-committer model for the DPDK project. We should have three committers for each release that can commit changes to the master branch.
>  
> There are a number of benefits:
>  
> 1. Greater capacity to commit patches.
> 2. No single points of failure - a committer should always be available if we have three.
> 3. A more timely committing of patches. More committers should equal a faster turnaround - ideally, maintainers should also provide feedback on patches submitted within a 2-3 day period, as much as possible, to facilitate this. 
> 4. It follows best practice in creating a successful multi-vendor community - to achieve this we must ensure there is a level playing field for all participants, no single person should be required to make all of the decisions on patches to be included in the release.  
> 
> Having multiple committers will require some degree of co-ordination but there are a number of other communities successfully following this model such as Apache, OVS, FD.io, OpenStack etc. so the approach is workable.
> 
> John

I agree that the problems you are attempting to address exist and are
worth finding a solution for.  That said, I don't think the solution you
are proposing is the ideal, or complete fix for any of the issues being
addressed.

If I may, I'd like to ennumerate the issues I think you are trying to
address based on your comments above, then make a counter-proposal for a
solution:

Problems to address:

1) high-availability - There is a desire to make sure that, when patches
are proposed, they are integrated in a timely fashion.

2) high-throughput - DPDK has a large volume of patches, more than one
person can normally integrate.  There is a desire to shard that work such
that it is handled by multiple individuals

3) Multi-Vendor fairness - There is a desire for multiple vendors to feel
as though the project tree maintainer isn't biased toward any individual
vendor.

To solve these I would propose the following solution (which is simmilar
to, but not quite identical, to yours).

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

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.

Regards
Neil