[dpdk-moving] Minutes from "Moving DPDK to Linux Foundation" call, December 13th

[dpdk-moving] Minutes from "Moving DPDK to Linux Foundation" call, December 13th

[O'Driscoll, Tim]

Here are my notes from Tuesday's call. Please feel free to correct any errors or to add additional details.

Attendees: Ed Warnicke (Cisco), Francois-Frederic Ozog (Linaro), Hemant Agrawal (NXP), Jan Blunck (Brocade), Jaswinder Singh (NXP), John Bromhead (Cavium), Keith Wiles (Intel), Kevin Traynor (Red Hat), Matt Spencer (ARM), Olga Shern (Mellanox), Thomas Monjalon (6WIND), Tim O'Driscoll (Intel), Yoni Luzon (Mellanox). Note that there may have been others, but as people joined at different times it was difficult to keep track.

Firstly, here are some links to help keep track of things:
Project Charter: https://docs.google.com/document/d/1x43ycfW3arJNX-e6NQt3OVzAuNXtD7dppIhrY48FoGs
Summary of discussion at Userspace event in Dublin: http://dpdk.org/ml/archives/dev/2016-October/049259.html
Minutes of October 31st call: http://dpdk.org/ml/archives/moving/2016-November/000031.html
Minutes of November 8th call: http://dpdk.org/ml/archives/moving/2016-November/000058.html
Minutes of November 15th call: http://dpdk.org/ml/archives/moving/2016-November/000061.html
Minutes of November 22nd call: http://dpdk.org/ml/archives/moving/2016-November/000085.html
Minutes of November 29th call: http://dpdk.org/ml/archives/moving/2016-November/000099.html
Minutes of December 6th call: http://dpdk.org/ml/archives/moving/2016-December/000121.html
Current technical governance, including composition of the Tech Board: http://dpdk.org/doc/guides/contributing/index.html & http://dpdk.org/dev.


A lot of yesterday's meeting was taken up with issues that we've discussed and reached a conclusion on previously. Some degree of that is inevitable, but where possible we should avoid doing this as it slows things down.

1. Next week's meeting:
Most people seem to be available so we'll continue with that. After that we'll break for 2 weeks for the holiday period and then we can resume again.

2. CI:
This came up again, in relation to an open CI lab (similar to FD.io's CSIT) and the costs associated with this. During previous discussions on this we agreed:
- CI discussions should be on the ci@dpdk.org mailing list.
- It's not realistic for DPDK to have a lab setup of the size of FD.io. Therefore, Thomas has implemented a distributed CI system that's integrated with Patchwork.
- We do want a reference lab for performance testing. We'll need to keep this small initially in order to control costs.

3. Contributor membership level:
At last week's meeting we decided not to have a Contributor membership level based largely on guidance from Mike Dolan who said that it doesn't add any real benefit but does add complexity. Matt questioned what complexity this actually adds.
Mike: Can you clarify the reasons for not having a Contributor level?
We should aim to reach a final decision on this at next week's meeting.

4. Technical governance:
Agreed that the Technical Governance section of the doc (section 5) will just reference other locations in which this info is already captured. I've updated the doc accordingly.

5. Composition of Tech Board:
A number of questions came up, mostly ones that we've discussed and dispositioned before. These were:
- Do we review and update the Tech Board membership as things have changed since it was put in place about a year ago. My proposal is that we ask the Tech Board to consider this and remove any members who are no longer active and add any new ones that they think merit inclusion.
- Discussed the possibility of limiting participation to 1 rep per company. The issue with this is that it distorts meritocracy. We have an item in the charter (section 3.2.2, item III.c) specifying that no single company can have a majority.
- The question came up again of the Governing Board defining policy for the Technical Board to implement. We've discussed and concluded previously that we don't want to do this.
- Keith suggested holding Tech Board meetings at regular intervals, perhaps monthly. That's something the Tech Board should consider.
- The question came up again of whether members should get a seat on the Tech Board. We've agreed previously that we don't want to do this.

6.Efficiency of the review process:
As part of the Tech Board discussions, the topic of patch reviews came up:
- The question of slow reviews came up specifically in relation to a patch set a few months ago from NXP.
- The key issue with reviews is that participating companies allocate time from their engineers to make contributions, but don't always allocate time for them to do reviews. The only way to fix this problem is for all participating companies to allocate more time to reviews. Thomas in particular has been highlighting this gap since the beginning of the open source project.
- Maintainer responsibilities are being documented by John McNamara in the Contributor's Guidelines. Details are in this thread: http://dpdk.org/ml/archives/dev/2016-December/051201.html. Those with ideas for improvement should contribute to that thread on the mailing list.

Next Meeting:
Tuesday December 20th at 3pm GMT, 4pm CET, 10am EST, 7am PST. We should try to disposition any remaining comments on the charter so that we have a good draft in place before the end of the year. I think we also need to identify the remaining things that we need to do to complete this process (finalise charter, get it reviewed/approved by LF, determine membership contribution levels, recruit members, launch project etc.) and agree some target dates for these. That will give us a timeline to work towards. I'll post some further thoughts on this ahead of the next meeting.

Re: [dpdk-moving] Minutes from "Moving DPDK to Linux Foundation" call, December 13th

[Stephen Hemminger]

On Wed, 14 Dec 2016 17:45:49 +0000
"O'Driscoll, Tim" <tim.odriscoll@intel.com> wrote:

> 6.Efficiency of the review process:
> As part of the Tech Board discussions, the topic of patch reviews came up:
> - The question of slow reviews came up specifically in relation to a patch set a few months ago from NXP.
> - The key issue with reviews is that participating companies allocate time from their engineers to make contributions, but don't always allocate time for them to do reviews. The only way to fix this problem is for all participating companies to allocate more time to reviews. Thomas in particular has been highlighting this gap since the beginning of the open source project.
> - Maintainer responsibilities are being documented by John McNamara in the Contributor's Guidelines. Details are in this thread: http://dpdk.org/ml/archives/dev/2016-December/051201.html. Those with ideas for improvement should contribute to that thread on the mailing list.

Some projects like BSD and Linux take an active maintainer model. The maintainer is repsonsible
for doing reviews and will accept changes after a few days by doing review on their own.
In these projects if no objections are received, it is up the maintainer to review and comment/accept.

Other projects like Openstack and DPDK use a passive maintainer model. Patches are expected
to be reviewed by the mailing list and acked before accepted.

There seems to be some confusion (and dissent) on which model is being used and why.