From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave Neary Subject: Re: Beyond DPDK 2.0 Date: Mon, 27 Apr 2015 08:38:48 -0400 Message-ID: <553E2DD8.6080908@redhat.com> References: <26FA93C7ED1EAA44AB77D62FBE1D27BA54D1A917@IRSMSX102.ger.corp.intel.com> <20150424175124.GA30624@mhcomputing.net> <553B9706.1060904@bisdn.de> <20150426215644.GA9021@neilslaptop.think-freely.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: "dev-VfR2kkLFssw@public.gmane.org" To: Neil Horman , "Wiles, Keith" Return-path: In-Reply-To: <20150426215644.GA9021-0o1r3XBGOEbbgkc5XkKeNuvMHUBZFtU3YPYVAmT7z5s@public.gmane.org> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces-VfR2kkLFssw@public.gmane.org Sender: "dev" 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 ignore= d. >> Maybe some type of voting is reasonable, but we need to do something t= o >> turn around the patches in clean reasonable manner. >> >> Think we need some type of group meeting every week to look at the pat= ches >> and determining which ones get applied, this gives quick feedback to t= he >> 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 t= hink > perhaps a better approach would be to require that that code owners fro= m the > maintainer file provide and ACK/NAK on their patches within 3-4 days, a= nd > 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 w= hich to > fix the problem before the offending patch is reverted during the QE cy= cle. 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. --=20 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