From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id BEB5E1396 for ; Wed, 13 May 2015 22:53:39 +0200 (CEST) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga103.jf.intel.com with ESMTP; 13 May 2015 13:53:38 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.13,422,1427785200"; d="scan'208";a="709807283" Received: from irsmsx151.ger.corp.intel.com ([163.33.192.59]) by fmsmga001.fm.intel.com with ESMTP; 13 May 2015 13:53:37 -0700 Received: from irsmsx102.ger.corp.intel.com ([169.254.2.36]) by IRSMSX151.ger.corp.intel.com ([169.254.4.102]) with mapi id 14.03.0224.002; Wed, 13 May 2015 21:53:37 +0100 From: "O'Driscoll, Tim" To: Dave Neary , "dev@dpdk.org" Thread-Topic: [dpdk-dev] DPDK Community Call - Beyond DPDK 2.0 Thread-Index: AdCEWkmVf8hlqxKzQVegHfJjY5yueQAAsLhw///1VwD//q1pwP/vXX/A/9vdi6AJC/wMAP//2FFg Date: Wed, 13 May 2015 20:53:36 +0000 Message-ID: <26FA93C7ED1EAA44AB77D62FBE1D27BA54D42588@IRSMSX102.ger.corp.intel.com> References: <26FA93C7ED1EAA44AB77D62FBE1D27BA54D3158A@IRSMSX102.ger.corp.intel.com> <55440154.7020502@redhat.com> <26FA93C7ED1EAA44AB77D62FBE1D27BA54D31A95@IRSMSX102.ger.corp.intel.com> <26FA93C7ED1EAA44AB77D62FBE1D27BA54D405A6@IRSMSX102.ger.corp.intel.com> <26FA93C7ED1EAA44AB77D62FBE1D27BA54D41E97@IRSMSX102.ger.corp.intel.com> <55535778.3060704@redhat.com> In-Reply-To: <55535778.3060704@redhat.com> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [163.33.239.180] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] DPDK Community Call - 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: Wed, 13 May 2015 20:53:40 -0000 Some great input Dave. We discussed a number of issues yesterday which, whi= le related, should probably be treated separately for clarity. For each of = these, I think we need to start with a clear problem statement and a concre= te proposal for change. I've added some further comments on the specific items below. > From: Dave Neary [mailto:dneary@redhat.com] >=20 > Thanks for the notes Tim! >=20 > I had intended to participate, but didn't realise that there was a > conflict with an OPNFV call at the same time, and a calendaring snafu. >=20 > In the interests of having some more focussed discussion, I have some > questions on the notes to get beyond passive voice. I think it will be > useful to have concrete proposals and understand the positions of > various entities participating in the project (both individuals and > companies). >=20 > On 05/13/2015 07:19 AM, O'Driscoll, Tim wrote: > > Thanks to all who attended and contributed to yesterday's discussion. > For the benefit of those who couldn't attend, here's a brief summary of > what was covered. Please feel free to point out any errors or omissions. > > > > Decision Making > > - There was a discussion on whether we need a Technical Steering > Committee or similar decision-making forum. The scope would be to make > long-term, strategic decisions and to provide a resolution for issues > that do not reach a consensus on the mailing list. > > - Some felt that this was a good idea and would help to reach a timely > conclusion on contentious issues. Others felt that these issues should > be resolved on the mailing list and/or by the Maintainer. >=20 > In this case, the problem statement could be that it's unclear how items > can be proposed for inclusion in future releases, and how decisions on > inclusion are made once proposals are made. Is that correct? >=20 > I am a big fan of transparency in the decision making processes of a > project. The Linux decision process might be described as: "Subsystem > owners are kings of their space, but if there is a lack of consensus, > Linus decides". That works because people trust Linus to be an unbiased > arbitor of what is best for Linux. >=20 > What would the equivalent de facto decision making process for DPDK be? > And does it need changing? In the interests of clarity, my understanding > is that "the Maintainer" in the note above is Thomas Monjalon - can I > just confirm that this is true and understood by all? Yes, the Maintainer is Thomas. We do have the concept of separate Maintaine= rs for each library (documented in the MAINTAINERS file), but Thomas is the= overall Maintainer. As a follow-on to yesterday's call, I'm going to start a separate thread sp= ecifically on decision making and the role of a TSC. > > Github > > - There was some discussion on the merits of github. As with the > mailing list discussion on this, some were in favour and some against. > > - Nothing is stopping people using github today and then submitting > pull requests. >=20 > My feeling is that the tools discussion belies something deeper - it > could be "reviewing patches and getting a list of unreviewed patches is > hard", it could be "patches are not reviewed quickly enough", it could > be "there is no way to tell once a patch has been reviewed what, if any, > remediation is needed for the patch to be committed". I would like to > get some feeling on what people see as the underlying fundamental issue > which the tools change might address. >=20 > Can someone deeply involved in the project have a go at defining a patch > review workflow problem statement, please? +1 Any volunteers? > > DPDK Industry Representation > > - At the moment, we don't have any project-level DPDK entity or budget > that would ensure DPDK representation at relevant events. It's left to > individual contributors to do this. > > > > Independent Ownership > > - It was suggested that it would be better to have independent > community ownership of the DPDK project. > > - The argument against this is that the ownership of the > infrastructure (website, git repo) is not important and can be easily > cloned if required. >=20 > Were there any concrete proposals or requirements laid out in the call? >=20 > From my point of view, there are a few things which are important here: > - Community ownership of the DPDK trademark > - The ability to pool resources and enter into contracts for things > like marketing, developer event organisation, ordering swag > - The perception of a level playing field > - A framework for commercial entities to indicate their support for > (and intention to participate in) the project >=20 > The key word here is perception: DPDK is seen as an Intel platform only > project by those outside the project, and dpdk.org is seen as a 6WIND > owned community space. >=20 > I think that it would be valuable to have an independent entity who > could, without a huge cost structure, manage the trademark, enable the > pooling of resources, and provide a framework for commercial engagement > (whether that be through membership, sponsorship, a user advisory group, > whatever avenue is most appropriate). >=20 > Some options I see for that entity are the Software Freedom Conservancy, > the Linux Foundation (although I suspect the cost structure would be too > high for what we need), Software in the Public Interest, or some new > non-profit we create just for DPDK. There are a few other options too. > But to evaluate the options, we need the problem statement, and a set of > requirements. I don't think we have that yet (my effort at defining the > requirements is above). We didn't discuss specifics in the call, but you've identified the main opt= ions. To reach a conclusion on this, I agree that somebody needs to define = a clear problem statement, evaluate the alternatives, and propose a solutio= n, then we can see if people agree or not.