From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Hemminger Subject: Re: [dpdk-techboard] decision process and DPDK scope Date: Thu, 9 Feb 2017 14:49:05 -0800 Message-ID: <20170209144905.6dc0db5f@xeon-e3> References: <1667864.GflPPoyiWF@xps13> <20170209122047.GA327480@bricha3-MOBL3.ger.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Thomas Monjalon , dev@dpdk.org, techboard@dpdk.org To: Bruce Richardson Return-path: Received: from mail-pf0-f172.google.com (mail-pf0-f172.google.com [209.85.192.172]) by dpdk.org (Postfix) with ESMTP id 6402CFAF9 for ; Thu, 9 Feb 2017 23:49:13 +0100 (CET) Received: by mail-pf0-f172.google.com with SMTP id e4so3794032pfg.1 for ; Thu, 09 Feb 2017 14:49:13 -0800 (PST) In-Reply-To: <20170209122047.GA327480@bricha3-MOBL3.ger.corp.intel.com> List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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/