DPDK community structure changes
 help / color / mirror / Atom feed
* [dpdk-moving] Today's Meeting
@ 2016-11-29 10:58 O'Driscoll, Tim
  0 siblings, 0 replies; 4+ messages in thread
From: O'Driscoll, Tim @ 2016-11-29 10:58 UTC (permalink / raw)
  To: moving

We talked at the end of last week's meeting about how we can make this process go faster. We said we'd try to focus on existing comments on the doc rather than bringing up new issues. Below are the outstanding comments on the doc that I think we need to discuss. We won't get through them all today, but focusing on specific issues might help us make faster progress.

Also, just a reminder that today's meeting is at 3pm GMT, 4pm CET, 10am EST, 7am PST. Access numbers are:
    France: +33 1588 77298
    UK: +44 179340 2663
    USA: +1 916 356 2663	
    Bridge Number: 5
    Conference ID: 94641018
    Link to Skype meeting: https://meet.intel.com/tim.odriscoll/G7H113HY


- For Section 2 (Project Scope), Mike Dolan suggested removing info that can be maintained elsewhere and is likely to change. I've shortened this section so that it just defines scope at a high level and then references the website for details like specific git repos. The intent is just to clarify that we have one core project (DPDK), plus a few smaller sub-projects that are closely related to DPDK. I'm assuming nobody has any concerns with this.

- On the Governing Board scope (section 3.1.1), Matt still has a comment on the need for the GB to be able to define business requirements such as the need for an LTS release. We've discussed this a couple of times before but never reached a clear conclusion on it. We should conclude on this at tomorrow's meeting.

- On the GB composition (section 3.1.2), there have been a couple of comments at previous meetings and on the mailing list (most recently from Dave) on the need for technical representation. At the moment, this section just says that there's a rep from the Tech Board on the GB. We need to agree if this is sufficient or if we need additional technical members. Similarly, we need to agree whether there's any non-technical representation on the TB (section 3.2.2).

- For voting, I think we should be consistent between the two boards in terms of the quorum required for a meeting to proceed and the majority required for a vote. We should also discuss whether there are specific decisions where a higher than 50% majority from the TB/GB is required. Having a higher bar to pass a vote increases stability, but it also preserves the status quo and slows the rate of change. This applies to sections 3.1.3 and 3.2.3.

- We need to agree how people are added to/removed from the TB (section 3.2.2). How are people proposed? What are the criteria for accepting them? Is the board a fixed size or could it expand over time? What's the maximum representation from any single company?

- For Membership (section 4) we need to agree whether membership relates to the project or just to the GB. There are a couple of comments in the doc from Vincent, and Thomas has raised the same issue on the mailing list as well, saying that membership only applies to the GB. I'd viewed this differently, that people became members of the project and that one of the benefits is representation on the GB. We need to conclude on this.

- A related issue that we need to conclude on is whether we need a Contributor membership level as Matt has proposed (related to the CLA/DCO item below).

- For CI, good progress has been made on putting in place a distributed solution as we discussed previously. We do need to progress the discussion on a centralized performance lab. I think for the charter we just need to agree at a high level and resolve Matt and Jaswinder's comments. We can discuss the details (what tests, what hardware etc.) in a separate meeting.

- For Technical Governance (section 5), we need to agree how much of this should be in the charter and how much should be maintained in the Contributor's Guidelines and/or DPDK.org Development page. I put some proposed text in the doc which links to the other docs that cover this. If we agree that's the right approach then we don't need to discuss further. If we want more detail in this doc, then Thomas has proposed some initial text and Keith and others have commented on this.

- Where is the technical governance for apps that are not part of the DPDK project documented? These are small, but it should still be captured somewhere.

- For the IP Policy, the main question which has come up several times on the mailing list is whether we need a CLA or if the DCO is sufficient.

- At the moment, this section says that everything is BSD licensed. That's not strictly true as some small parts of DPDK use GPL or dual BSD/GPL. We need to capture those existing exceptions somewhere, either in this doc or in another location that we can link to.

- For Amendments, I think it was Dave who asked if changes to this doc should require approval from both the GB and the TB.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [dpdk-moving] Today's Meeting
  2016-12-13 16:22 ` Thomas Monjalon
@ 2016-12-13 19:22   ` Stephen Hemminger
  0 siblings, 0 replies; 4+ messages in thread
From: Stephen Hemminger @ 2016-12-13 19:22 UTC (permalink / raw)
  To: Thomas Monjalon; +Cc: moving

On Tue, 13 Dec 2016 17:22:29 +0100
Thomas Monjalon <thomas.monjalon@6wind.com> wrote:

> I give some thoughts here because there is no time during the meeting
> to talk between chatty people.

I have same issue with phone meetings with > 3 people.

> First I agree some progress could be done in managing contributions.
> Some progress could be done if people were giving some time.
> Unfortunately a lot of people complain but do not give so much time.
> There are basically 2 ways to give some time:
> - work more on his own contribution (without being disturbed by other projects)
> - review, test and give some opinions about other contributions or discussions

Managing is often code word for some other problem:
 - how can I get my change accepted or
 - how can we reduce the number of unwanted contributions

The most productive open source projects make it clear the state and requirements
for getting patches accepted, DPDK is doing well on this. It is just that
with there are more contributors than reviewers (could also be a trust
issue).

As far as more changes, outside original scope. I agree with Linus,
who always wanted to make sure that some bluebird patch could be accepted
at anytime. I.e no hard and fast roadmap limiting scope.


> About the technical board, there is no point in using it if there is no
> online discussion first. If you see a problem, use your mailer and tell it.
> There is a real power in bringing some evidence to a public mailing list.
> If you do not trust in the power of open discussions, an Open Source project
> cannot do much for you.

Agreed. 

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [dpdk-moving] Today's Meeting
  2016-12-06 11:23 O'Driscoll, Tim
@ 2016-12-13 16:22 ` Thomas Monjalon
  2016-12-13 19:22   ` Stephen Hemminger
  0 siblings, 1 reply; 4+ messages in thread
From: Thomas Monjalon @ 2016-12-13 16:22 UTC (permalink / raw)
  To: moving

I give some thoughts here because there is no time during the meeting
to talk between chatty people.

First I agree some progress could be done in managing contributions.
Some progress could be done if people were giving some time.
Unfortunately a lot of people complain but do not give so much time.
There are basically 2 ways to give some time:
- work more on his own contribution (without being disturbed by other projects)
- review, test and give some opinions about other contributions or discussions

About the technical board, there is no point in using it if there is no
online discussion first. If you see a problem, use your mailer and tell it.
There is a real power in bringing some evidence to a public mailing list.
If you do not trust in the power of open discussions, an Open Source project
cannot do much for you.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [dpdk-moving] Today's Meeting
@ 2016-12-06 11:23 O'Driscoll, Tim
  2016-12-13 16:22 ` Thomas Monjalon
  0 siblings, 1 reply; 4+ messages in thread
From: O'Driscoll, Tim @ 2016-12-06 11:23 UTC (permalink / raw)
  To: moving

A reminder that today's meeting is at 3pm GMT, 4pm CET, 10am EST, 7am PST. Access numbers are:
    France: +33 1588 77298
    UK: +44 179340 2663
    USA: +1 916 356 2663	
    Bridge Number: 5
    Conference ID: 94641018
    Link to Skype meeting: https://meet.intel.com/tim.odriscoll/G7H113HY

Project Charter: https://docs.google.com/document/d/1x43ycfW3arJNX-e6NQt3OVzAuNXtD7dppIhrY48FoGs
Minutes from last week's meeting: http://dpdk.org/ml/archives/moving/2016-November/000099.html


Items that we should cover today include:

- We need to decide how we're going to proceed on the suggested adoption of a CLA and/or license change in order to provide patent protection. We have two options:
a) Agree that this is not within the scope of the initiative to move the project to the LF. The project charter will document the current process (BSD license and DCO). Once a Governing Board is in place, anybody can propose adoption of a CLA and/or a change in license, and the board will review and agree on how to proceed.
b) We ask the LF to facilitate separate meetings on this involving legal counsel from the major contributors to the project.

- For voting, the current draft of the charter specifies a quorum of 50% for the GB (see 3.1.3) and TB (3.2.3) for a meeting to proceed. Thomas suggested on the mailing list that the quorum for the TB should be higher. We should agree on the right percentage.

- For Membership (section 4) we need to agree whether membership relates to the project or just to the GB. There are a couple of comments in the doc from Vincent, and Thomas has raised the same issue on the mailing list as well, saying that membership only applies to the GB. I'd viewed this differently, that people became members of the project and that one of the benefits is representation on the GB. We need to conclude on this.

- A related issue that we need to conclude on is whether we need a Contributor membership level as Matt has proposed (related to the CLA/DCO item above).

- For CI, good progress has been made on putting in place a distributed solution as we discussed previously. For a centralized performance lab, Jaswinder submitted a comment proposing a cap on the number of boards a gold member can contribute, which seems reasonable. Matt added a comment saying that the scope should allow software vendors to submit DPDK-enabled applications to be run as part of the performance testing. Note that we don't need to define the full scope of performance testing here as that can be done separately. We just need to agree at a high level.

- For Technical Governance (section 5), we need to agree how much of this should be in the charter and how much should be maintained in the Contributor's Guidelines and/or DPDK.org Development page. I put some proposed text in the doc which links to the other docs that cover this. If we agree that's the right approach then we don't need to discuss further. If we want more detail in this doc, then Thomas has proposed some initial text and Keith and others have commented on this.

- Where is the technical governance for apps that are not part of the DPDK project documented? These are small, but it should still be captured somewhere.

- At the moment, the IP Policy (section 6) says that everything is BSD licensed. That's not strictly true as some small parts of DPDK use GPL or dual BSD/GPL. We need to capture those existing exceptions somewhere, either in this doc or in another location that we can link to.

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2016-12-13 19:22 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-11-29 10:58 [dpdk-moving] Today's Meeting O'Driscoll, Tim
2016-12-06 11:23 O'Driscoll, Tim
2016-12-13 16:22 ` Thomas Monjalon
2016-12-13 19:22   ` Stephen Hemminger

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