Re: [dpdk-dev] Beyond DPDK 2.0

[Dave Neary <dneary@redhat.com>]

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