From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f52.google.com (mail-wm0-f52.google.com [74.125.82.52]) by dpdk.org (Postfix) with ESMTP id 022C9DE0 for ; Fri, 10 Feb 2017 18:23:12 +0100 (CET) Received: by mail-wm0-f52.google.com with SMTP id v186so116334513wmd.0 for ; Fri, 10 Feb 2017 09:23:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:user-agent:in-reply-to :references:mime-version:content-transfer-encoding; bh=kIt195qXKzZV9O1Ovfv9A2cly8hmY06w/H3W+uVIRl8=; b=Cf9KoSGYaiSj0cLles1jhI9/ZprcuO/qwKpbm1Y9zG/WA2ecn3BswM+KYtIfx4Mm+O Goe6SzVomUqlmjw/g15N1ficP2iItALndt22QC0wRVDkqM0UYjydJVLLvGSz4GZ2PlHJ gG1SI23azA9PWI2cNR88pGM6ceVzHfOxSJZznsfweeR+idjc0hLdjwTMgvltUIFnpPnh rT56q7imCzQYzl+0L2ZpPeRKQqjyViIAzN1/UUP18sPVIUC7/2FNVjREqRzZzT23Oy6w ihBmd5kYQDy+5o+0JUbrpa31RfsJ2OFlYJ/x90AXrTKNHVJIQ/wEyBNOAMXJrjrchZr5 V1cA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:user-agent :in-reply-to:references:mime-version:content-transfer-encoding; bh=kIt195qXKzZV9O1Ovfv9A2cly8hmY06w/H3W+uVIRl8=; b=IiMweqhVFB3Lw7mb6dzcV/69fFDqJKTPMpXVxopoEZosqicbQd3bEIsnRJgV0yfFdS 39FdymbFmMf/Buf6a2huLQli/K0OagA6fbfcX/XmEAgB4FUNk4pdc+rBTQjdq8BSkVmU ONGerJ1aiCEHXlMTRCSez7jUcgGyOb02unqIetqTRLe8fkQu3r1QU/fu/27lpM2gMEXi WDs5C44H2t0wAk0lq5MlDTtG7+S1oSa4AbO0+P+brJRh2DXxNKcKJUIb2H2QlAPJOIWC 4BXVPqFOjPiDNkhwX6OGbvFTy0/sa0SCbxUhflILohq5DvVULH9Tlaiocoa1mQ1qdozn EREQ== X-Gm-Message-State: AMke39mQHZwkU+LJ8+BjrYTE1xP42xxtO5sR9QDdhBrXcY96DBN+1M6jL7/S/S/w+pURRKPj X-Received: by 10.28.58.204 with SMTP id h195mr27613669wma.116.1486747392622; Fri, 10 Feb 2017 09:23:12 -0800 (PST) Received: from xps13.localnet (184.203.134.77.rev.sfr.net. [77.134.203.184]) by smtp.gmail.com with ESMTPSA id l37sm3547761wrc.41.2017.02.10.09.23.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Feb 2017 09:23:11 -0800 (PST) From: Thomas Monjalon To: Bruce Richardson Cc: Stephen Hemminger , dev@dpdk.org, techboard@dpdk.org Date: Fri, 10 Feb 2017 18:23:11 +0100 Message-ID: <2387427.oe7MCbVTs3@xps13> User-Agent: KMail/4.14.10 (Linux/4.5.4-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <20170210155439.GA365948@bricha3-MOBL3.ger.corp.intel.com> References: <1667864.GflPPoyiWF@xps13> <20170209144905.6dc0db5f@xeon-e3> <20170210155439.GA365948@bricha3-MOBL3.ger.corp.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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 17:23:13 -0000 2017-02-10 15:54, Bruce Richardson: > 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. It is hurting because there is no clear explanation of the process. > > > 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 automatically accepted unless some other > > > reviewed objects in a TIMELY manner. I see an issue with "automatic" decision after a period of time. It puts a lot of pressure on the community to check everything. I agree we should state this kind of default. But we should add two exceptions: - new API or API change - a maintainer explicitly ask for a techboard discussion > > 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. I think the first thing to improve is the decision process. Increasing the number of committers, without agreeing on a clear decision process, would make things worse.