Re: [dpdk-dev] Beyond DPDK 2.0

[Marc Sune <marc.sune@bisdn.de>]

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.