On 5/2/15, 7:37 AM, "Thomas F Herbert" <thomasfherbert at 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 >
