From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58]) by dpdk.org (Postfix) with ESMTP id 724355A34 for ; Mon, 27 Apr 2015 15:41:26 +0200 (CEST) Received: from hmsreliant.think-freely.org ([2001:470:8:a08:7aac:c0ff:fec2:933b] helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1YmjHk-0003fH-1e; Mon, 27 Apr 2015 09:41:22 -0400 Date: Mon, 27 Apr 2015 09:41:14 -0400 From: Neil Horman To: Dave Neary Message-ID: <20150427134114.GC17179@hmsreliant.think-freely.org> References: <26FA93C7ED1EAA44AB77D62FBE1D27BA54D1A917@IRSMSX102.ger.corp.intel.com> <20150424175124.GA30624@mhcomputing.net> <553B9706.1060904@bisdn.de> <20150426215644.GA9021@neilslaptop.think-freely.org> <553E2DD8.6080908@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <553E2DD8.6080908@redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Score: -2.9 (--) X-Spam-Status: No Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] Beyond DPDK 2.0 X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2015 13:41:26 -0000 On Mon, Apr 27, 2015 at 08:38:48AM -0400, Dave Neary wrote: > Hi, > > On 04/26/2015 05:56 PM, Neil Horman wrote: > > On Sat, Apr 25, 2015 at 04:08:23PM +0000, Wiles, Keith wrote: > >> I would like to see some type of layering process to allow patches to be > >> applied in a timely manner a few weeks not months or completely ignored. > >> Maybe some type of voting is reasonable, but we need to do something to > >> turn around the patches in clean reasonable manner. > >> > >> Think we need some type of group meeting every week to look at the patches > >> and determining which ones get applied, this gives quick feedback to the > >> submitter as to the status of the patch. > >> > > I think a group meeting is going to be way too much overhead to manage properly. > > You'll get different people every week with agenda that may not line up with > > code quality, which is really what the review is meant to provide. I think > > perhaps a better approach would be to require that that code owners from the > > maintainer file provide and ACK/NAK on their patches within 3-4 days, and > > require a corresponding tree maintainer to apply the patch within 7 or so. That > > would cap our patch latency. Likewise, if a patch slips in creating a > > regression, the author needs to be alerted and given a time window in which to > > fix the problem before the offending patch is reverted during the QE cycle. > > What Keith is describing is very similar to a change management/change > control board you might find for production/IT processes: > http://en.wikipedia.org/wiki/Change_control_board > > An efficient change management board approves "low overhead" changes > automatically/very quickly, and focusses on the 10% of changes which > could be disruptive (and what disruptive means changes from one > environment to another) - for code it would be any patches that > potentially conflict, anything that could cause regressions, add > instability or uncertainty, and any feature which can be implemented > multiple ways. > > Not saying this would work - I have never seen an open source project > implement a change management process for handling patches, and > instinctively I agree with you Neil that it would be a lot of overhead, > but it's an interesting thought exercise to think how it might work. > I take you're meaning Dave, and it is an interesting thought experiment. how would such a change control board mesh with a public review list however? That is to say, would such a voting board not insulate decision makers from community participation? Perhaps I'm mistaken there, but it seems like allowing a small group of maintainers make acceptance decisions in a private meeting would insulate them from individual accountability on a list. Neil > Thanks, > Dave. > > -- > Dave Neary - NFV/SDN Community Strategy > Open Source and Standards, Red Hat - http://community.redhat.com > Ph: +1-978-399-2182 / Cell: +1-978-799-3338 >