[dpdk-moving] Proposal a Committer model

[Thomas Monjalon]

Hi,

2016-11-15 23:35, Mcnamara, John:
> 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.

Yes it's me. And we have three other committers (CC'ed) for the sub-trees
dpdk-next-net, dpdk-next-virtio and dpdk-next-crypto.

> One committer to master represents a single point of failure

For the release 16.11, 49% of the patches were committed by me.
Other patches came from sub-trees.

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

Most of the critical work is done in the sub-trees which cover every drivers.
However I feel we could add more sub-trees and especially for EAL.
Ideally, the master branch should just gather commits from the sub-trees.
About long vacation, we may find backup committers for each git tree if
it's really needed.

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

Committing faster means making patches disappear from the radar faster.
It does improve neither the quality nor the multi-vendor cooperation.

DPDK is mainly a community of hardware vendors. At the beginning, there
was only one vendor (Intel). After being open on dpdk.org, more vendors
joined. Nowadays we are still working to be more and more vendor neutral.
Examples of current work: bus abstraction, filter API, event model, etc.

I think there are two major issues when working on neutrality in DPDK:

1/ The first challenge and priority for a developer/vendor is to
push access to new hardware features and achieving the best performance.
It is not his priority to think about the genericity of the design
or the API. And he generally doesn't take care of the performance on
other hardware.

2/ There are not enough reviews to challenge genericity of developments.

The only solution to these issues is to give some time for proper reviews.

I would like to highlight again that having more good reviews is a good
way of accelerating pace while improving quality.
It is not so hard or long to commit patches which are ready.
It is longer when the committer must play the reviewer role because of an
obvious lack of review.

About "no single person should be required to make all of the decisions
on patches to be included in the release", I totally agree.
That's why the reviews and discussions must make clear what is the
consensus, the community decision.

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

I won't play the game of listing and comparing other projects, though
there are a lot (and famous) counter-examples.
The other model is to promote some sub-trees.

The current model pushes people to discuss and decide publicly.
If we had a small committee of 3 persons coordinating to commit, it
means they may are willing to take some decisions privately instead of
relying on community consensus.
And the risk is greater if these people are working for hardware vendors.