[dpdk-dev] [dpdk-techboard] decision process and DPDK scope
Wiles, Keith
keith.wiles at intel.com
Mon Feb 13 16:58:35 CET 2017
> On Feb 13, 2017, at 9:21 AM, Mcnamara, John <john.mcnamara at intel.com> wrote:
>
>
>
>> -----Original Message-----
>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Stephen Hemminger
>> Sent: Thursday, February 9, 2017 10:49 PM
>> To: Richardson, Bruce <bruce.richardson at intel.com>
>> Cc: Thomas Monjalon <thomas.monjalon at 6wind.com>; dev at dpdk.org;
>> techboard at dpdk.org
>> Subject: Re: [dpdk-dev] [dpdk-techboard] decision process and DPDK scope
>>
>> 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/
>
> 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.
+1 What sub-trees would be the best place to start and then who would be best suited to the role?
I was thinking net-next would be a good place to start.
>
> John
>
>
Regards,
Keith
More information about the dev
mailing list