From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id 0323A37AC; Mon, 13 Feb 2017 16:21:53 +0100 (CET) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Feb 2017 07:21:52 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.35,156,1484035200"; d="scan'208";a="1106774038" Received: from irsmsx154.ger.corp.intel.com ([163.33.192.96]) by fmsmga001.fm.intel.com with ESMTP; 13 Feb 2017 07:21:51 -0800 Received: from irsmsx103.ger.corp.intel.com ([169.254.3.77]) by IRSMSX154.ger.corp.intel.com ([169.254.12.40]) with mapi id 14.03.0248.002; Mon, 13 Feb 2017 15:21:50 +0000 From: "Mcnamara, John" To: Stephen Hemminger , "Richardson, Bruce" CC: Thomas Monjalon , "dev@dpdk.org" , "techboard@dpdk.org" Thread-Topic: [dpdk-dev] [dpdk-techboard] decision process and DPDK scope Thread-Index: AQHSgs8HxTKODfO/kkOUZhFRwe+4qqFhR9CAgAXLFcA= Date: Mon, 13 Feb 2017 15:21:50 +0000 Message-ID: References: <1667864.GflPPoyiWF@xps13> <20170209122047.GA327480@bricha3-MOBL3.ger.corp.intel.com> <20170209144905.6dc0db5f@xeon-e3> In-Reply-To: <20170209144905.6dc0db5f@xeon-e3> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ctpclassification: CTP_PUBLIC x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiZWI5ODljNzUtMjczYy00NzFlLWE2MTAtMjU1YWQyYTEzMmI4IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX1BVQkxJQyJ9XX1dfSwiU3ViamVjdExhYmVscyI6W10sIlRNQ1ZlcnNpb24iOiIxNS45LjYuNiIsIlRydXN0ZWRMYWJlbEhhc2giOiJwSFp4eWZTZU5hSmpLMWY2bWlPc1wvWkJrT0xrK2FWVnd3a1VXTzBrVzMzYz0ifQ== x-originating-ip: [163.33.239.180] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [dpdk-techboard] decision process and DPDK scope X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 15:21:54 -0000 > -----Original Message----- > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Stephen Hemminger > Sent: Thursday, February 9, 2017 10:49 PM > To: Richardson, Bruce > Cc: Thomas Monjalon ; dev@dpdk.org; > techboard@dpdk.org > Subject: Re: [dpdk-dev] [dpdk-techboard] decision process and DPDK scope >=20 > On Thu, 9 Feb 2017 12:20:47 +0000 > Bruce Richardson wrote: >=20 > > > 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 >=20 > 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. >=20 > 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/ >=20 > And comments on lwn: > https://lwn.net/Articles/703005/ Hi Stephen, That is an interesting case study. Perhaps it is something we could trial i= n 17.05 on one or more of the sub-trees. John