From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx.bisdn.de (mx.bisdn.de [185.27.182.31]) by dpdk.org (Postfix) with ESMTP id 91466C37E for ; Sat, 25 Apr 2015 15:30:49 +0200 (CEST) Received: from [192.168.1.102] (x55b32002.dyn.telefonica.de [85.179.32.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx.bisdn.de (Postfix) with ESMTPSA id 33BD0A3B40 for ; Sat, 25 Apr 2015 15:30:49 +0200 (CEST) Message-ID: <553B9706.1060904@bisdn.de> Date: Sat, 25 Apr 2015 15:30:46 +0200 From: Marc Sune User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.6.0 MIME-Version: 1.0 To: dev@dpdk.org References: <26FA93C7ED1EAA44AB77D62FBE1D27BA54D1A917@IRSMSX102.ger.corp.intel.com> <20150424175124.GA30624@mhcomputing.net> In-Reply-To: <20150424175124.GA30624@mhcomputing.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] Beyond DPDK 2.0 X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Apr 2015 13:30:49 -0000 On 24/04/15 19:51, Matthew Hall wrote: > On Fri, Apr 24, 2015 at 12:39:47PM -0500, Jay Rolette wrote: >> I can tell you that if DPDK were GPL-based, my company wouldn't be using >> it. I suspect we wouldn't be the only ones... >> >> Jay > I could second this, from the past employer where I used it. Right now I am > using it in an open source app, I have a bit of GPL here and there but I'm > trying to get rid of it or confine it to separate address spaces, where it > won't impact the core code written around DPDK, as I don't want to cause > headaches for any downstream users I attract someday. > > Hard-core GPL would not be possible for most. LGPL could be possible, but I > don't think it could be worth the relicensing headache for that small change. > > Instead we should make the patch process as easy as humanly possible so people > are encouraged to send us the fixes and not cart them around their companies > constantly. I agree. My feeling is that as the number of patches in the mailing list grows, keeping track of them gets more and more complicated. Patchwork website was a way to try to address this issue. I think it was an improvement, but to be honest, patchwork lacks a lot of functionality, such as properly tracking multiple versions of the patch (superseding them automatically), and it lacks some filtering capabilities e.g. per user, per tag/label or library, automatically track if it has been merged, give an overall status of the pending vs merged patches, set milestones... Is there any alternative tool or improved version for that? On the other side, since user questions, community discussions and development happens in the same mailing list, things get really complicated, specially for users seeking for help. Even though I think the average skills of the users of DPDK is generally higher than in other software projects, if DPDK wants to attract more users, having a better user support is key, IMHO. So I would see with good eyes a separation between, at least, dpdk-user and dpdk-dev. If the number of patches keeps growing, splitting the "dev" mailing lists into different categories (eal and common, pmds, higher level abstractions...) could be an option. However, this last point opens a lot of questions on how to minimize interference between the different parts and API/ABI compatibility during the development. > > Perhaps it means having some ReviewBoard type of tools, a clone in Github or > Bitbucket where the less hardcore kernel-workflow types could send back their > small bug fixes a bit more easily, this kind of stuff. Google has been getting > good uptake since they moved most of their open source across to Github, > because the contribution workflow was more convenient than Google Code was. Although I agree, we have to be careful on how github or bitbucket is used. Having issues or even (e.g. github) pull requests *in addition* to the normal contribution workflow can be a nightmare to deal with, in terms of synchronization and preventing double work. So I guess setting up an official github or bitbucket mirror would be fine, via some simple cronjob, but I guess it would end-up not using PRs or issues in github like the Linux kernel does. Btw, is this github organization already registered by Intel or some other company of the community? https://github.com/dpdk Marc > > Matthew.