Re: [dpdk-dev] Beyond DPDK 2.0

[Neil Horman <nhorman@tuxdriver.com>]

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
>