> -----Original Message----- > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Stephen Hemminger > Sent: Thursday, February 9, 2017 10:49 PM > To: Richardson, Bruce <bruce.richard...@intel.com> > Cc: Thomas Monjalon <thomas.monja...@6wind.com>; dev@dpdk.org; > techbo...@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.richard...@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
