Re: [dpdk-dev] DPDK Community Call - Beyond DPDK 2.0

["O'Driscoll, Tim" <tim.o'driscoll@intel.com>]

Some great input Dave. We discussed a number of issues yesterday which, while 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 concrete proposal for change.

I've added some further comments on the specific items below.

> From: Dave Neary [mailto:dneary@redhat.com]
> 
> 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?

Yes, the Maintainer is Thomas. We do have the concept of separate Maintainers 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 specifically 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.
> 
> 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?

+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.
> 
> 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).

We didn't discuss specifics in the call, but you've identified the main options. To reach a conclusion on this, I agree that somebody needs to define a clear problem statement, evaluate the alternatives, and propose a solution, then we can see if people agree or not.