[dpdk-dev] [dpdk-techboard] decision process and DPDK scope

[Thomas Monjalon]

2017-02-10 15:54, Bruce Richardson:
> On Thu, Feb 09, 2017 at 02:49:05PM -0800, Stephen Hemminger wrote:
> > On Thu, 9 Feb 2017 12:20:47 +0000
> > Bruce Richardson <bruce.richardson at intel.com> wrote:
> > 
> > > > I think we can use this case to avoid seeing it again in the future.
> > > > I suggest that the technical board should check whether every new proposed
> > > > features are explained, discussed and approved enough in the community.
> > > > If needed, the technical board meeting minutes will give some lights to
> > > > the threads which require more attention.
> > > > Before adding a new library or adding a major API, there should be
> > > > some strong reviews which include discussing the DPDK scope.
> > > >   
> > > 
> > > The bigger question here is the default position of the DPDK community -
> > > default accept, or default reject. Your statements above all are very
> > > much keeping in the style of default reject i.e. every patch or change
> > > suggested is assumed to be unfit for acceptance unless reviewed in
> > > detail to prove beyond doubt otherwise.
> > > 
> > > I believe that we should change this default position, as I think that
> > > reject by default is hurting the community and will continue to do so.

It is hurting because there is no clear explanation of the process.

> > > NOTE: I am not suggesting that we allow all code in with zero review,
> > > but I am suggesting that if something has been reviewed and acked by at
> > > least one reviewer it should be automatically accepted unless some other
> > > reviewed objects in a TIMELY manner.

I see an issue with "automatic" decision after a period of time.
It puts a lot of pressure on the community to check everything.
I agree we should state this kind of default. But we should add two
exceptions:
	- new API or API change
	- a maintainer explicitly ask for a techboard discussion


> > I agree but in a more assertive manner. The maintainer should be the default
> > and active reviewer of all submissions. Like other projects the maintainers job
> > is to review and accept (or provide constructive feedback). Otherwise the
> > job could just by done by some manager.
> > 
> > But recently, I have changed my mind. The current DPDK project model is not
> > scaling well. After hearing some of the arguments in favor of a multiple
> > committer model (see "Maintainers Don't Scale" )
> > https://kernel-recipes.org/en/2016/talks/maintainers-dont-scale/
> > 
> > And comments on lwn:
> > https://lwn.net/Articles/703005/
> > 
> Might it be worthwhile to try out having 2 or 3 committers to each tree
> and see how it works? From the presentation you link too, the claim is
> that moving from 1 to 2 is the hardest, and expanding beyond that
> becomes easier.

I think the first thing to improve is the decision process.
Increasing the number of committers, without agreeing on a clear
decision process, would make things worse.