Re: [dpdk-dev] GitHub sandbox for the DPDK community

["Wiles, Keith" <keith.wiles@intel.com>]

On 5/2/15, 7:37 AM, "Thomas F Herbert" <thomasfherbert@gmail.com> wrote:

>On 5/2/15 7:40 AM, Neil Horman wrote:
>> On Fri, May 01, 2015 at 01:36:58PM -0700, Matthew Hall wrote:
>>> On Fri, May 01, 2015 at 10:59:32PM +0300, Aaro Koskinen wrote:
>>>> Projects like GCC, GLIBC, binutils, busybox, etc or what?
>>>>
>>>> A.
>>> You'll notice all of these are low-level UNIX hacker sorts of tools
>>>mostly,
>>> with the partial exception of busybox. But even that is mainly for
>>>embedded
>>> use. It doesn't mean I don't think they're good and useful, but it
>>>does limit
>>> the possible size of the community in my view.
>>>
>>> Since we are talking about how to get the largest widest community
>>>possible
>>> for DPDK, it could require doing things a bit differently from how many
>>> low-level tools have historically done things.
>A look at gmane, http://dir.gmane.org/gmane.comp.networking.dpdk.devel,
>confirms the explosion of interest in DPDK in the last 6 months with
>postings up to almost 70/day.  There is no problem with lack of interest
>in DPDK nor is there a need to change the mechanics of hosting the

We do need to reach more developer as I see the DPDK community growing
around VNF/NFV to developers that are not experts in the fine details of
DPDK, but a group of developers wanting to get the highest performance out
of his NFV/VNF system.

The DPDK community needs to grow and will grow, at 70+ emails a day which
will only become more. Using something like GitHub we will be able to help
the DPDK community to become more then a niche project or a low level tool.

Moving to a new site helps us. I believe, it may not allow you to stay
using pure command line development, but we as developers can and will
adapt to the new process quickly as I see the DPDK community as a very
bright and resourceful group of developers.

> 
>source to widen the audience. The case for DPDK is really compelling,
>the idea for reducing the HW complexity by accelerating switch functions
>on commodity HW is a fantastic benefit. Easily integrated accelerated
>programmable switch functions is a great advantage as well.
>
>I do think there may be an argument for increasing the number of
>reviewers/maintainers or subdivide according to ares of interest perhaps
>into 4 categories:
>1. PMD drivers
>2. librte core
>3. applications
>4. vhost
>
>--TFH
>
>>>
>> Why?
>>
>> Contributors to GCC: ~600 (based on svn) review
>> Contrubutors to glibc : ~300 (based on git) review
>> Contributors to binutils: ~600
>> Contributors to busybox: ~300
>>
>> Contributors to DPDK: ~125
>>
>> Now I grant you that dpdk is a newer, much more niche project, but its
>> disingenuous to state that we _have_ to do things differently to reach
>>a wider
>> audience.  We can, but its by no means a prerequisite to gainining a
>>wider
>> audience.
>>
>
>
>-- 
>Thomas F. Herbert
>