Re: [dpdk-moving] Proposal a Committer model

["Wiles, Keith" <keith.wiles@intel.com>]

> On Nov 16, 2016, at 9:13 AM, Bruce Richardson <bruce.richardson@intel.com> 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.
> 

+1 I agree, your suggestion to commit sooner then later is reasonable plus timely for DPDK.

I think the multiple committer model is a requirement to get things done in a quicker manner as this does not place more pressure on a single committer.

> My 2c.
> 
> /Bruce

Regards,
Keith