From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id 992D3ADA2 for ; Mon, 27 Apr 2015 14:38:52 +0200 (CEST) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t3RCco0r026819 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 27 Apr 2015 08:38:51 -0400 Received: from leitrim.localdomain (ovpn-113-35.phx2.redhat.com [10.3.113.35]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t3RCcmn8015804 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Apr 2015 08:38:49 -0400 Message-ID: <553E2DD8.6080908@redhat.com> Date: Mon, 27 Apr 2015 08:38:48 -0400 From: Dave Neary User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Neil Horman , "Wiles, Keith" References: <26FA93C7ED1EAA44AB77D62FBE1D27BA54D1A917@IRSMSX102.ger.corp.intel.com> <20150424175124.GA30624@mhcomputing.net> <553B9706.1060904@bisdn.de> <20150426215644.GA9021@neilslaptop.think-freely.org> In-Reply-To: <20150426215644.GA9021@neilslaptop.think-freely.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 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 12:38:53 -0000 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. 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