[dpdk-dev] [dpdk-techboard] decision process and DPDK scope

[Stephen Hemminger]

On Thu, 9 Feb 2017 12:20:47 +0000
Bruce Richardson <bruce.richardson at 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.
> 
> 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 autom

I agree but in a more assertive manner. The maintainer should be the default
and active reviewer of all submissions. Like other projects the maintainers job
is to review and accept (or provide constructive feedback). Otherwise the
job could just by done by some manager.

But recently, I have changed my mind. The current DPDK project model is not
scaling well. After hearing some of the arguments in favor of a multiple
committer model (see "Maintainers Don't Scale" )
https://kernel-recipes.org/en/2016/talks/maintainers-dont-scale/

And comments on lwn:
https://lwn.net/Articles/703005/