Re: [dpdk-moving] Proposal a Committer model

[Jerin Jacob <jerin.jacob@caviumnetworks.com>]

On Wed, Nov 16, 2016 at 03:13:49PM +0000, Bruce Richardson wrote:
> 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.

The main question would be who will part of committers list?

I believe the multi-committers model may not fix current consensus
slowness issue. Instead, if we are focusing on reducing the workload of
Thomas, then I think git pull request based scheme will reduce the
workload.

Jerin