From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id 71546C392 for ; Sat, 25 Apr 2015 18:08:25 +0200 (CEST) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga102.fm.intel.com with ESMTP; 25 Apr 2015 09:08:24 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.11,646,1422950400"; d="scan'208";a="561723758" Received: from orsmsx107.amr.corp.intel.com ([10.22.240.5]) by orsmga003.jf.intel.com with ESMTP; 25 Apr 2015 09:08:24 -0700 Received: from fmsmsx112.amr.corp.intel.com (10.18.116.6) by ORSMSX107.amr.corp.intel.com (10.22.240.5) with Microsoft SMTP Server (TLS) id 14.3.224.2; Sat, 25 Apr 2015 09:08:24 -0700 Received: from fmsmsx113.amr.corp.intel.com ([169.254.13.26]) by FMSMSX112.amr.corp.intel.com ([169.254.5.3]) with mapi id 14.03.0224.002; Sat, 25 Apr 2015 09:08:23 -0700 From: "Wiles, Keith" To: Marc Sune , "dev@dpdk.org" Thread-Topic: [dpdk-dev] Beyond DPDK 2.0 Thread-Index: AdB4KSdm1ftzhuzCQX2G2XNq9ZOWFAGdIAoAABSrQYAAAGfdAAApMFwA///YNYA= Date: Sat, 25 Apr 2015 16:08:23 +0000 Message-ID: References: <26FA93C7ED1EAA44AB77D62FBE1D27BA54D1A917@IRSMSX102.ger.corp.intel.com> <20150424175124.GA30624@mhcomputing.net> <553B9706.1060904@bisdn.de> In-Reply-To: <553B9706.1060904@bisdn.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.69.36] Content-Type: text/plain; charset="Windows-1252" Content-ID: <8C1C9AAABEBB7842BB69FDAF8061C570@intel.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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 16:08:26 -0000 On 4/25/15, 8:30 AM, "Marc Sune" wrote: > > >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. +1 and besides the GPL or LGPL ship has sailed IMHO and we can not go back. > >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? I agree patchwork has some limitation, but I think the biggest issue is keeping up with the patches. Getting patches introduced into the main line is very slow. A patch submitted today may not get applied for weeks or months, then when another person submits a patch he is starting to run a very high risk of having to redo that patch, because a pervious patch makes his fail weeks/months later. I would love to see a better tool then patchwork, but the biggest issue is we have a huge backlog of patches. Personally I am not sure how Thomas or any is able to keep up with the patches. The other problem I see is how patches are agreed on to be included in the mainline. Today it is just an ACK or a NAK on the mailing list. Then I see what I think to be only a few people ACKing or NAKing patches. This process has a lot of problems from a patch being ignore for some reason or someone having negative feed back on very minor detail or no way to push a patch forward a single NAK or comment. I would like to see some type of layering process to allow patches to be applied in a timely manner a few weeks not months or completely ignored. Maybe some type of voting is reasonable, but we need to do something to turn around the patches in clean reasonable manner. Think we need some type of group meeting every week to look at the patches and determining which ones get applied, this gives quick feedback to the submitter as to the status of the patch. > >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. I do not remember seeing too many users on the list and making a list just for then is OK if everyone is fine with a list that has very few emails. > >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. I believe if we just make sure we use tags in the subject line then we can have our email clients do the splitting of the emails instead of adding more emails lists. > >> >> 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. I like GitHub it is a much better designed tool then patchwork, plus it could get more eyes as it is very well know to the developer community in general. I feel GitHub has many advantages over the current systems in place but, it does not solve the all patch issues. The only way we can get patch issues resolved is to put a bit more process in place. > >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. >>From what I can tell GitHub seems to be a better solution for a free open environment. Bitbucket I have never used and GitHub seems more popular from one article I read. https://www.google.com/webhp?sourceid=3Dchrome-instant&ion=3D1&espv=3D2&ie= =3DUTF-8# q=3Dbitbucket%20vs%20github >Btw, is this github organization already registered by Intel or some >other company of the community? > >https://github.com/dpdk > >Marc If we can used the above that would be great, but a name like =8Cdpdk-community=B9 or something could work too. We can host the web site here and have many sub-projects like Pktgen-DPDK :-) under the same page. Not to say anything bad about our current web pages as I find it difficult to use sometimes and find things like patchwork link. Maintaining a web site is a full time job and GitHub does maintain the site, plus we can collaborate on host web page on the GitHub site easier. Moving to the Linux Foundation is an option as well as it is very well know and has some nice ways to get your project promoted. It does have a few drawbacks in process handling and cost to state a few. The process model is all ready defined, which is good and bad it just depends on your needs IMO. Regards, ++Keith > >> >> Matthew. >