From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id 2D0D7201; Fri, 10 Feb 2017 16:54:43 +0100 (CET) Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Feb 2017 07:54:42 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.35,142,1484035200"; d="scan'208";a="63570286" Received: from bricha3-mobl3.ger.corp.intel.com ([10.237.221.61]) by fmsmga005.fm.intel.com with SMTP; 10 Feb 2017 07:54:40 -0800 Received: by (sSMTP sendmail emulation); Fri, 10 Feb 2017 15:54:40 +0000 Date: Fri, 10 Feb 2017 15:54:39 +0000 From: Bruce Richardson To: Stephen Hemminger Cc: Thomas Monjalon , dev@dpdk.org, techboard@dpdk.org Message-ID: <20170210155439.GA365948@bricha3-MOBL3.ger.corp.intel.com> References: <1667864.GflPPoyiWF@xps13> <20170209122047.GA327480@bricha3-MOBL3.ger.corp.intel.com> <20170209144905.6dc0db5f@xeon-e3> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170209144905.6dc0db5f@xeon-e3> Organization: Intel Research and =?iso-8859-1?Q?De=ACvel?= =?iso-8859-1?Q?opment?= Ireland Ltd. User-Agent: Mutt/1.7.1 (2016-10-04) 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: Fri, 10 Feb 2017 15:54:44 -0000 On Thu, Feb 09, 2017 at 02:49:05PM -0800, Stephen Hemminger wrote: > On Thu, 9 Feb 2017 12:20:47 +0000 > Bruce Richardson 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/ > Might it be worthwhile to try out having 2 or 3 committers to each tree and see how it works? From the presentation you link too, the claim is that moving from 1 to 2 is the hardest, and expanding beyond that becomes easier. /Bruce