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

[Mcnamara, John]

> -----Original Message-----
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Stephen Hemminger
> Sent: Thursday, February 9, 2017 10:49 PM
> To: Richardson, Bruce <bruce.richardson at intel.com>
> Cc: Thomas Monjalon <thomas.monjalon at 6wind.com>; dev at dpdk.org;
> techboard at dpdk.org
> Subject: Re: [dpdk-dev] [dpdk-techboard] decision process and DPDK scope
> 
> 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.
> >
> > 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 autom
> 
> 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/

Hi Stephen,

That is an interesting case study. Perhaps it is something we could trial in 17.05 on one or more of the sub-trees.

John