From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id 338E65694 for ; Wed, 13 May 2015 15:54:03 +0200 (CEST) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (Postfix) with ESMTPS id 6A7BCA10D7; Wed, 13 May 2015 13:54:02 +0000 (UTC) Received: from leitrim.localdomain (ovpn-113-119.phx2.redhat.com [10.3.113.119]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t4DDs0UI031845 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 May 2015 09:54:01 -0400 Message-ID: <55535778.3060704@redhat.com> Date: Wed, 13 May 2015 09:54:00 -0400 From: Dave Neary User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "O'Driscoll, Tim" , "dev@dpdk.org" 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> In-Reply-To: <26FA93C7ED1EAA44AB77D62FBE1D27BA54D41E97@IRSMSX102.ger.corp.intel.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 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 13:54:03 -0000 Thanks for the notes Tim! 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. 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). 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. 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? 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. 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? > 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. 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. Can someone deeply involved in the project have a go at defining a patch review workflow problem statement, please? > 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. Were there any concrete proposals or requirements laid out in the call? >>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 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. 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). 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). Thanks, Dave. -- Dave Neary - NFV/SDN Community Strategy Open Source and Standards, Red Hat - http://community.redhat.com Ph: +1-978-399-2182 / Cell: +1-978-799-3338