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.
