From mboxrd@z Thu Jan 1 00:00:00 1970 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) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=kumW7c3eoOQXRxC5eriQI+7YAzgz8jRD+uBsutbvDlg=; b=WyuywJGf3uibsm4MCxx4YM2WTB7yBr94csmIcUt0q9CiNO/ZEw+KL0Cyc6L/LDC6BP WIZSAcvpABGdHv6opz8WkTejMBK8Vwu2YX8L5wXzT5MrtOkOOv6IsmBhZEL9o6mYl1fC p+5q9RmzbjN6gx4tzH/s9hqA1YhxmLYr8+Mcdr7ffj0UVsUUv5d8p55hUEA5px7OELpJ tVG4pJ9RMwZvTGtCXHeKPPC8sbsaARoKZZ21/qlRe6+nyOsEqFB/AeBP/SqSlFN+kjt7 +bPw5mGM2LoRzUQbPEBno6mKotymgJHkgFL5mV4HcU+6wyitHiSA0eD21YQLVf7YGCbe 4FnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=kumW7c3eoOQXRxC5eriQI+7YAzgz8jRD+uBsutbvDlg=; b=KOtGHVU610iey75FJwOq88AjF4Cka3/eG8HDjP7YhprFGoJB2y/9DGf7K32BCOqjrr jQGwOuCQpvZnR8PVXcnQ455mFFWWFTV850U9UQNVs5BgU9aMQYOOF1vJBoDluXIwKtZI 3ucKlkfK/RC8AFO247QTS61rh2GUDOwBrLQqdmwOX8Mr1kqUZSAkwHC72XvPs5t0YWbI /DCvzUE8RNrqyfAs/d9IuawBtebWzih6AiUU7H6Q5CkXML+rNmEvE2VZCSKJp06Eob+p K5WxTFehijuXdHTrPAidlEFVXQeXjsCjbefv9f5OawAT7GTCNj+HkzCrNWnRlELR/tO5 EUmw== X-Gm-Message-State: AMke39kLJXXd4uHOApwdeomYsVIdiG0LQWh+Tg8kyqlnpdDMlniEHlpWKi736R2Sfl4UvA== X-Received: by 10.98.194.153 with SMTP id w25mr6226669pfk.181.1486680552637; Thu, 09 Feb 2017 14:49:12 -0800 (PST) Received: from xeon-e3 (204-195-18-65.wavecable.com. [204.195.18.65]) by smtp.gmail.com with ESMTPSA id 19sm31399113pft.46.2017.02.09.14.49.12 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 09 Feb 2017 14:49:12 -0800 (PST) Date: Thu, 9 Feb 2017 14:49:05 -0800 From: Stephen Hemminger To: Bruce Richardson Cc: Thomas Monjalon , dev@dpdk.org, techboard@dpdk.org Message-ID: <20170209144905.6dc0db5f@xeon-e3> In-Reply-To: <20170209122047.GA327480@bricha3-MOBL3.ger.corp.intel.com> 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 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: Thu, 09 Feb 2017 22:49:13 -0000 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/