From: "O'Driscoll, Tim" <firstname.lastname@example.org> To: "email@example.com" <firstname.lastname@example.org> Subject: [dpdk-moving] Today's Meeting Date: Tue, 29 Nov 2016 10:58:17 +0000 Message-ID: <26FA93C7ED1EAA44AB77D62FBE1D27BA67625C3C@IRSMSX108.ger.corp.intel.com> (raw) 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.
next reply index Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-11-29 10:58 O'Driscoll, Tim [this message] 2016-12-06 11:23 O'Driscoll, Tim 2016-12-13 16:22 ` Thomas Monjalon 2016-12-13 19:22 ` Stephen Hemminger
Reply instructions: You may reply publically 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=26FA93C7ED1EAA44AB77D62FBE1D27BA67625C3C@IRSMSX108.ger.corp.intel.com \ --email@example.com \ --firstname.lastname@example.org \ /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
DPDK community structure changes Archives are clonable: git clone --mirror http://inbox.dpdk.org/moving/0 moving/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 moving moving/ http://inbox.dpdk.org/moving \ email@example.com public-inbox-index moving Newsgroup available over NNTP: nntp://inbox.dpdk.org/inbox.dpdk.moving AGPL code for this site: git clone https://public-inbox.org/ public-inbox