From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave Neary Subject: Proposals from project governance meeting at DPDK Userspace (was Notes from ...) Date: Mon, 12 Oct 2015 17:45:00 +0100 Message-ID: <561BE38C.8090507@redhat.com> References: <5619AF06.8070806@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: "dev@dpdk.org" Return-path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id AF08C8E6C for ; Mon, 12 Oct 2015 18:45:04 +0200 (CEST) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id 85DAEC0C1B36 for ; Mon, 12 Oct 2015 16:45:03 +0000 (UTC) Received: from dhcp-41-137.bos.redhat.com (ovpn-116-70.ams2.redhat.com [10.36.116.70]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t9CGj18B007861 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 12 Oct 2015 12:45:02 -0400 In-Reply-To: <5619AF06.8070806@redhat.com> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Hi, To explicitly call out the proposals and action items from the meeting: - Legal entity proposal: - PROPOSAL: Chris proposes moving DPDK to Linux Foundation, with low overhead option - Minimal governance, event, marketing budget - Legal governance around project name, trademark - Project leadership proposal (roadmap, scope) - ACTION: Venky to write a proposal for broadening scope as a patch to the website - PROPOSAL: Thomas proposes several smaller projects, rather than one umbrella project as scope broadens - ACTION: Jim proposed documenting current decision process, and improving on it - documenting it will help make it better. - ACTION: Tim proposed to resurface his TSC proposal and drive it to agreement and action - Proposed criteria which should be met by any technical governance model: 1. Everyone has a voice 2. Some voices carry more weight than others, based on technical seniority and participation in the community 3. Decisions should be time bound - after community debate, decision should converge quickly one way or the other to give clarity - Day to day patch review: - PROPOSAL: Thomas: Create hierarchical review process with maintainers responsible for sub-trees (to be housed in DPDK Git) - ACTION: (without owner?) Subtrees and maintainers to be identified, -next, crypto and (drivers, IIRC?) to be first trees - PROPOSAL: Thomas to identify replacement maintainers short-term when he is unable to do it (vacation, sickness, etc) - Stable patch maintenance - PROPOSAL: Maintain one release per year as a long term release, with point releases being made regularly (based on patch volume), with branches maintained for 2 years (2 stable branches + 1 devel branch active at all times). In addition to Thomas's notes, does this cover all of the conclusions that came out of the meeting? Thanks, Dave. On 10/11/2015 01:36 AM, Dave Neary wrote: > Hi everyone, >=20 > I took some notes from a discussion we had at the end of DPDK Userspace > in Dublin, concerning the growth and project structure for DPDK. If I > missed anyone's name, I apologise - there were many active contributors= , > including most prominently Venky, Jim St Leger, Bruce Richardson, > Stephen Hemminger, Chris Wright, myself, Keith Wiles, Cristian > Dumitrescu, Tim O'Driscoll, Thomas Monjalon, and (until he had to leave= ) > Vincent Jardin. There were a few others from Intel, ARM, and others, bu= t > I didn't get all the names during the discussion. If you see a comment > you made and would like attribution, reply - especially if it doesn't > quite match your view. >=20 > The discussion was wide ranging and we didn't quite stay on one topic > until we reached a conclusion, so some of these notes are not in strict > time order. >=20 > These are a mixture of notes and proposals for the project coming out o= f > the meeting - comments are welcome, all proposals are up for discussion= , > and nothing has been decided on the basis of this meeting. However, all > present expressed agreement that there are issues we need to address in > the near future. >=20 > Apologies for the non-linear note taking, for those who were not there = I > hope they're useful. >=20 > Thanks, > Dave. >=20 >=20 >=20 > Topic 1: Legal entity > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Do we need/want a legal entity independent of a commercial vendor who > can represent the project? >=20 > Things a legal entity could do: > - Sign contracts and raise money for events > - Organise events > - Own the trademark > - Own project infrastructure like DNS, website infrastructure > - Centralised pool for marketing budget? > - Brand awareness? >=20 > There was agreement that legal governance should be lightweight, and > completely independent of technical governance. Vincent insisted on the > low cost structure for entities like 6WIND who would not be able to > justify a 6 figure membership fee. >=20 > Topic 2: Technical governance (roadmap, project scope) > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D >=20 > Jim: What if soeone proposes a feature that competes with a commercial > offering from an incumbent? Is it rejected, accepted, ignored? >=20 > Thomas: Issue is one of trust - is Thomas a good maintainer or not? > (language moderated ;-) If we trust the maintainer, then no problem. If > people disagree with Thomas as maintainer, then there are multiple ways > around it - gang up on Thomas & change maintainer, or fork. >=20 > Scope is a big question - is (say) a TCP stack in scope, or not? Websit= e > says no. Thomas replies that website can be changed by a patch - patch > submission would be the start of a scope discussion, and the community > will decide. Venky: Scope narrowed compared to his initial goal - > satisfy needs of high volume servers. >=20 > How about ODP/DPDK convergence/co-operation? (nothing major noted, > beyond "the topic came up") >=20 > Do we want/need a TSC (Technical Steering Committee)? Do we need a > public roadmap? >=20 > Dave: If we have a TSC, then its membership should be from the technica= l > leadership of the project - users voices should be heard, and perhaps w= e > should have an official user advisory group, but the technical goals an= d > roadmap of the project should be owned by people actively developing th= e > project. >=20 > Topic 3: Day to day technical process > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Keith raised the issue of general throughput of patches, and the number > of unreviewed/wait state patches: need to actively scale the process. >=20 > Stephen: How about identifying reviewers, and Thomas designates lead > reviewer for each patch? Allows scaling of review, while allowing Thoma= s > to have last word. Alternative proposals are to have joint "maintainers= " > all of whom can commit patches, subject to certain constraints (don't > commit your own code), or subsystem maintainers, establishing a > hierarchy of trust so that Thomas can just scan and accept reviews 90% > of the time. >=20 > Thomas: Need many reviewers, but there should be one committer per tree= . >=20 > Stephen: Dave Miller acks minor changes, and for major changes drives > discussion - no need to wait for consensus for a small, localised > change. Activst maintainer means maintainer takes responsibility for > converging patch discussions. > Venky: Merge windows are a bad idea - batching patch merge just make it > harder to find out which patch slowed down performance - in a > performance driven project you want CI & testing to track changes acros= s > individual patchsets. > Venky also pointed out the cost when you need to sync patches across > multiple projects, with multi-month offsets in release dates. It can > take months for a full feature to be enabled in a distro if an OpenStac= k > patch depends on a QEMU, OVS or DPDK patch. >=20 > 3 proposals from Stephen: >=20 > 1. "Clone Thomas" - multiple top-level maintainers > 2. Delegate - maintainer names reviewer for each patch, and trusts revi= ew > 3. Subsystem maintainers - based on trust, maintainers are on the hook > for their tree. >=20 > Chris: Do we have enough ppl with skills to be reviewers? If not, how d= o > we get to that point? >=20 > Venky: Performance requires a specific skill set, not everyone has the > skills, but slow patch review has an opportunity cost, and we can > minimise cost of "bad" reviews with good CI performance tests that catc= h > regressions >=20 > How do we maintain review velocity when maintainer is unavailable (eg. > on vacation)? How does it happen in Linux? >=20 > - Linus delegates - names "locum" maintainer while he is away. Stephen > volunteered to do it for a week or two when necessary. >=20 > Thomas: Subsystem maintainers carry review weight when maintainer is ou= t. > Stephen: Subsystem maintainers are reviewers, need high level of trust > to be a top level maintainer. >=20 > Thomas - Subtrees can live in DPDK git tree, makes it easier to manage > merges afterwards. 2 volunteer subtree maintainers - Declan for crypto, > Kevin for (not noted). Is it an issue if only Intel people are subtree > maintainers? Venky: Yes, should have others. >=20 > Discussion summary > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > At this point, we synthesised the conversation and tried to converge on > a firm proposal for community discussion & action: >=20 > - Legal entity: > - Propose moving DPDK to Linux Foundation, with low overhead option > - Minimal governance, event, marketing budget > - Legal governance around project name, trademark >=20 > - Project leadership (roadmap, scope) > - Venky to write a proposal for broadening scope as a patch to the we= bsite > - Thomas proposes several smaller projects, rather than one umbrella > project as scope broadens > - Some discussion around whether we should limit to one project per > stack? Venky: Prefers not to > - Chris: How do decisions on new projects get made? > - Stephen: Proposed that in the event of contention, in-person debate > and consensus decides > - Jim proposed documenting current decision process, and improving on > it - documenting it will help make it better. >=20 > - Proposed criteria which should be met by any technical governance m= odel: > 1. Everyone has a voice > 2. Some voices carry more weight than others, based on technical > seniority and participation in the community > 3. Decisions should be time bound - after community debate, decision > should converge quickly one way or the other to give clarity >=20 > Further discussion on the composition and process for choosing a TSC: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > - Why not just have all the maintainers act as the TSC? > - Too many, but not open enough if community voice is not heard. > Maintainers may be tightly focused on one area, and not have overall > visibility of the project. >=20 > Bruce: We should have a TSC. Elected by contributors, with some minimum > bar for voting rights & being a candidate (eg. 10 patches) >=20 > Christian: Thinks it makes sense to first define scope of what a TSC > would own, before deciding on a format and process for voting >=20 > - Bruce: Anything that doesn't reach community consensus gets kicked t= o TSC > - Cristian: Better to only have TSC decide on things which do not have > a clear decision path elsewhere (don't 2nd guess maintainer decisions) >=20 > Dave: Recommended that TSC stay small (4-5 people) >=20 > Tim will resurface his TSC proposal, revised based on this discussion, > for community review and comment. >=20 > Stable/long-term releases > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D >=20 > We finished the discussion with a brief conversation on whether we > should maintain certain branches for a long time. >=20 > Bruce: Adds a lot of overhead > Venky: Can do point releases on some branches > Stephen: Prepared to "volunteer" someone from Brocade, because they nee= d > to maintain an older release anyway. >=20 > Proposal: How many parallel long-term branches? > - One per year (roughly one in 3 releases) > - 2 years maintenance after release (3 maintained branches in parallel > - 2 long-term, plus trunk) >=20 > Thanks, > Dave. >=20 --=20 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