Re: [dpdk-techboard] decision process and DPDK scope

[Bruce Richardson <bruce.richardson@intel.com>]

On Fri, Feb 10, 2017 at 06:23:11PM +0100, Thomas Monjalon wrote:
> 2017-02-10 15:54, Bruce Richardson:
> > On Thu, Feb 09, 2017 at 02:49:05PM -0800, Stephen Hemminger wrote:
> > > On Thu, 9 Feb 2017 12:20:47 +0000
> > > Bruce Richardson <bruce.richardson@intel.com> wrote:
> > > 
> > > > > I think we can use this case to avoid seeing it again in the future.
> > > > > I suggest that the technical board should check whether every new proposed
> > > > > features are explained, discussed and approved enough in the community.
> > > > > If needed, the technical board meeting minutes will give some lights to
> > > > > the threads which require more attention.
> > > > > Before adding a new library or adding a major API, there should be
> > > > > some strong reviews which include discussing the DPDK scope.
> > > > >   
> > > > 
> > > > The bigger question here is the default position of the DPDK community -
> > > > default accept, or default reject. Your statements above all are very
> > > > much keeping in the style of default reject i.e. every patch or change
> > > > suggested is assumed to be unfit for acceptance unless reviewed in
> > > > detail to prove beyond doubt otherwise.
> > > > 
> > > > I believe that we should change this default position, as I think that
> > > > reject by default is hurting the community and will continue to do so.
> 
> It is hurting because there is no clear explanation of the process.
> 
> > > > NOTE: I am not suggesting that we allow all code in with zero review,
> > > > but I am suggesting that if something has been reviewed and acked by at
> > > > least one reviewer it should be automatically accepted unless some other
> > > > reviewed objects in a TIMELY manner.
> 
> I see an issue with "automatic" decision after a period of time.
> It puts a lot of pressure on the community to check everything.
> I agree we should state this kind of default. But we should add two
> exceptions:
> 	- new API or API change
> 	- a maintainer explicitly ask for a techboard discussion
>
Ok, I will accept the referral to the tech board as a reason to not
automatically apply, but I disagree on the API one. For all types of
changes we need to clearly document the number of reviews needed to get
the patches in, and who needs to agree. Once those conditions are met,
we must have a mandatory merge. The difference between adding a new API
and adding an internal code change should only be in the conditions
required for mandatory merge. There must still be an automatic decision
after a set period of time, otherwise we will still see issues with
people leaving reviews till the last minute and then flagging problems
with a patch blocking its merge.

/Bruce