> On Feb 13, 2017, at 9:21 AM, Mcnamara, John <[email protected]> wrote: > > > >> -----Original Message----- >> From: dev [mailto:[email protected]] On Behalf Of Stephen Hemminger >> Sent: Thursday, February 9, 2017 10:49 PM >> To: Richardson, Bruce <[email protected]> >> Cc: Thomas Monjalon <[email protected]>; [email protected]; >> [email protected] >> Subject: Re: [dpdk-dev] [dpdk-techboard] decision process and DPDK scope >> >> On Thu, 9 Feb 2017 12:20:47 +0000 >> Bruce Richardson <[email protected]> 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.
+1 What sub-trees would be the best place to start and then who would be best suited to the role? I was thinking net-next would be a good place to start. > > John > > Regards, Keith
