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

-----Original Message-----
From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Stephen Hemminger
Sent: Thursday, February 9, 2017 10:49 PM
To: Richardson, Bruce <redacted>
Cc: Thomas Monjalon <redacted>; dev@dpdk.org;
techboard@dpdk.org
Subject: Re: [dpdk-dev] [dpdk-techboard] decision process and DPDK scope

On Thu, 9 Feb 2017 12:20:47 +0000
Bruce Richardson [off-list ref] wrote:

quoted

quoted

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.

quoted

quoted

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/

Hi Stephen,

That is an interesting case study. Perhaps it is something we could trial in 17.05 on one or more of the sub-trees.

John