DPDK patches and discussions
 help / color / mirror / Atom feed
From: Dave Neary <dneary@redhat.com>
To: "O'Driscoll, Tim" <tim.o'driscoll@intel.com>,
	"dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] DPDK Community Call - Beyond DPDK 2.0
Date: Wed, 13 May 2015 09:54:00 -0400	[thread overview]
Message-ID: <55535778.3060704@redhat.com> (raw)
In-Reply-To: <26FA93C7ED1EAA44AB77D62FBE1D27BA54D41E97@IRSMSX102.ger.corp.intel.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?

> 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

  reply	other threads:[~2015-05-13 13:54 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-01 22:20 O'Driscoll, Tim
2015-05-01 22:42 ` Dave Neary
2015-05-02 18:01   ` O'Driscoll, Tim
2015-05-11 15:34     ` O'Driscoll, Tim
2015-05-13 11:19       ` O'Driscoll, Tim
2015-05-13 13:54         ` Dave Neary [this message]
2015-05-13 20:53           ` O'Driscoll, Tim

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=55535778.3060704@redhat.com \
    --to=dneary@redhat.com \
    --cc=dev@dpdk.org \
    --cc=tim.o'driscoll@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).