From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id F3ABF201; Mon, 13 Feb 2017 16:58:36 +0100 (CET) Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Feb 2017 07:58:35 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.35,156,1484035200"; d="scan'208";a="224728784" Received: from fmsmsx105.amr.corp.intel.com ([10.18.124.203]) by fmsmga004.fm.intel.com with ESMTP; 13 Feb 2017 07:58:35 -0800 Received: from fmsmsx153.amr.corp.intel.com (10.18.125.6) by FMSMSX105.amr.corp.intel.com (10.18.124.203) with Microsoft SMTP Server (TLS) id 14.3.248.2; Mon, 13 Feb 2017 07:58:35 -0800 Received: from fmsmsx113.amr.corp.intel.com ([169.254.13.230]) by FMSMSX153.amr.corp.intel.com ([169.254.9.17]) with mapi id 14.03.0248.002; Mon, 13 Feb 2017 07:58:35 -0800 From: "Wiles, Keith" To: "Mcnamara, John" CC: Stephen Hemminger , "Richardson, Bruce" , Thomas Monjalon , "dev@dpdk.org" , "techboard@dpdk.org" Thread-Topic: [dpdk-dev] [dpdk-techboard] decision process and DPDK scope Thread-Index: AQHSgs8GrQMamzAqpUe7NlVO//X54qFhzeyAgAXMXQCAAApCgA== Date: Mon, 13 Feb 2017 15:58:35 +0000 Message-ID: <0EAFC884-F2FD-4675-AB21-89A2502541C3@intel.com> References: <1667864.GflPPoyiWF@xps13> <20170209122047.GA327480@bricha3-MOBL3.ger.corp.intel.com> <20170209144905.6dc0db5f@xeon-e3> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.254.102.97] Content-Type: text/plain; charset="us-ascii" Content-ID: <2657CDD2E211704AA909C49C619E7E34@intel.com> 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:58:37 -0000 > On Feb 13, 2017, at 9:21 AM, Mcnamara, John wro= te: >=20 >=20 >=20 >> -----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. >>>>=20 >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> 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/ >=20 > Hi Stephen, >=20 > 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 be= st suited to the role? I was thinking net-next would be a good place to start. >=20 > John >=20 >=20 Regards, Keith