From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Hemminger Subject: Re: Beyond DPDK 2.0 Date: Mon, 27 Apr 2015 09:09:22 -0700 Message-ID: <20150427090922.3d8ef2c6@urahara> 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-Transfer-Encoding: 7bit Cc: "dev-VfR2kkLFssw@public.gmane.org" To: Dave Neary Return-path: In-Reply-To: <553E2DD8.6080908-H+wXaHxf7aLQT0dZR+AlfA@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" On Mon, 27 Apr 2015 08:38:48 -0400 Dave Neary wrote: > 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 ZMQ has a community process with a simple review process and a "default YES" policy. http://rfc.zeromq.org/spec:22