Re: [dpdk-moving] Proposal a Committer model

[Bruce Richardson <bruce.richardson@intel.com>]

On Wed, Nov 16, 2016 at 10:45:55AM +0000, Thomas Monjalon wrote:
> Hi,
> 
> 2016-11-15 23:35, Mcnamara, John:
<snip>
> > 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.
> 

There is one big issue that I see with the current consensus model -
consensus is very slow. There are two ways to get the new features to
the quality we want:
1) we all work together to get the patches to 100% quality and then they
get committed once everyone is happy.
2) a number of the most interested parties work together to get the
patches to the point where they are all happy - where quality may be
only 90% there - and the patches are applied. Anyone who subsequently
has additional comments to improve things supplies patches for the
improvement.

Where this becomes really visible to me is where we have a feature under
discussion for a number of weeks and has reached a consensus among the
few people looking at it. It's been acked and is supposedly ready for
merge. But...then someone new comes and looks at it for the first time,
kicking off a whole new round of discussion that goes on for another number
of weeks.

Personally I'd much rather see a system whereby the first consensus version
gets merged in sooner, so that everyone else can make progress based on
that, rather than having to wait for absolutely everyone to agree. That
way:
a) the improvements can still be made by additional patches,
b) the "shape" of the release becomes clearer sooner as there is less
big bang application of all patches at the end
c) it makes life far easier for people basing patches on other earlier
patches in the same release
d) it makes validation easier since things can be tested earlier as part
of a full tree
AND BEST OF ALL
e) it encourages people to do reviews sooner as they have to catch that
initial review window, or else they are on the hook to do the extra
cleanup patches themselves. [Right now, there is little pressure on
people to do timely reviews - if they review the patch after two days or
two weeks, that patch still has to wait for their agreement to be merged
in.]

Now, I believe multi-committer model is much more conducive to this way
of working (though it does not strictly require multiple committers).
So long as one trusted committer (and all committers need to be trusted)
is happy with a patchset it should go in - provided a reasonable review
period has elapsed. There is too much waiting for everyone to agree
right now.

My 2c.

/Bruce