From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0133.outbound.protection.outlook.com [65.55.169.133]) by dpdk.org (Postfix) with ESMTP id 6782B8E78 for ; Fri, 30 Oct 2015 19:01:16 +0100 (CET) Received: from BLUPR0301MB1651.namprd03.prod.outlook.com (10.162.214.145) by BLUPR0301MB1652.namprd03.prod.outlook.com (10.162.214.146) with Microsoft SMTP Server (TLS) id 15.1.312.18; Fri, 30 Oct 2015 18:01:13 +0000 Received: from BLUPR0301MB1651.namprd03.prod.outlook.com ([10.162.214.145]) by BLUPR0301MB1651.namprd03.prod.outlook.com ([10.162.214.145]) with mapi id 15.01.0312.014; Fri, 30 Oct 2015 18:01:13 +0000 From: Bagh Fares To: "dev@dpdk.org" , "dneary@redhat.com" , "jim.st.leger@intel.com" , "Pradeep Kathail (pkathail@cisco.com)" , "CHIOSI, MARGARET T (mc3124@att.com)" Thread-Topic: [dpdk-dev] Proposals from project governance meeting at DPDK Userspace (was Notes from ...) Thread-Index: AdETO3UNrTlKQ/IxR1OwaDiPUSWx2g== Date: Fri, 30 Oct 2015 18:01:13 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Fares.Bagh@freescale.com; x-originating-ip: [192.88.168.49] x-microsoft-exchange-diagnostics: 1; BLUPR0301MB1652; 5:TtUgJBWi95fSVf9+C+Wn9s8Y37LOfu7uZDA/xS5YCUrT2E73UQ0wZo8N/ULT5W9smrk+CiBlFtZTmpgruI+Ptr1rFqxYpE5J1PbrfE8Qlat2G0h+WNPb1C4IL6/FU7Yysu6rRehe0drPG3jRWSeh5g==; 24:ho1TltrIxR04Zy2dfguldFpIQ3KbbSfRTIIBHuXQV2ll7CXKfvlW+STRq0xnNb6YAWbkXXaeTw+kCI25AqYVFYMe2BH6Ah/SpErHx/4qqNM=; 20:m9XSXdOcm03V4jAVl8vbQIlEbHV83veKgsTi/XAg5hBBpoP2kh/FvioWOD/cVAoFBlINhOiMRTwSxdrvx4ynBA== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR0301MB1652; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(101931422205132)(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(10201501046)(3002001)(102215026); SRVR:BLUPR0301MB1652; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0301MB1652; x-forefront-prvs: 07459438AA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(164054003)(57704003)(53754006)(199003)(24454002)(479174004)(189002)(2900100001)(16236675004)(19580395003)(11100500001)(54356999)(15395725005)(81156007)(561944003)(33656002)(92566002)(5001770100001)(87936001)(19625215002)(86362001)(5007970100001)(5003600100002)(555904002)(74316001)(101416001)(102836002)(97736004)(5004730100002)(50986999)(66066001)(5008740100001)(107886002)(5002640100001)(76576001)(5001960100002)(16601075003)(2201001)(77096005)(105586002)(189998001)(15975445007)(587094005)(19617315012)(99286002)(40100003)(10400500002)(19273905006)(106356001)(122556002)(19300405004)(19580405001)(2501003)(266164003)(579004)(36394004); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR0301MB1652; H:BLUPR0301MB1651.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: freescale.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: freescale.com X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Oct 2015 18:01:13.2873 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 710a03f5-10f6-4d38-9ff4-a80b81da590d X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0301MB1652 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] Proposals from project governance meeting at DPDK Userspace (was Notes from ...) X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2015 18:01:17 -0000 Hi dave My name is Fares Bagh. I am from Freescale networking division. We are very interested and supportive in the proposal below. Our main interest is enabling HW acceleration options for our customers sta= rting with crypto function. We like to have a road map for acceleration bey= ond crypto. We support having the group under linux foundation. Lot of work ahead so please let me know how I can help. Fares VP. Hardware and Architecture, Networking. fares.bagh@freescale.com 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, > > 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, but > 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. > > 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. > > These are a mixture of notes and proposals for the project coming out of > 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. > > Apologies for the non-linear note taking, for those who were not there I > hope they're useful. > > Thanks, > Dave. > > > > 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 > > Do we need/want a legal entity independent of a commercial vendor who > can represent the project? > > 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? > > 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. > > 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 > > Jim: What if soeone proposes a feature that competes with a commercial > offering from an incumbent? Is it rejected, accepted, ignored? > > 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. > > Scope is a big question - is (say) a TCP stack in scope, or not? Website > 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. > > How about ODP/DPDK convergence/co-operation? (nothing major noted, > beyond "the topic came up") > > Do we want/need a TSC (Technical Steering Committee)? Do we need a > public roadmap? > > Dave: If we have a TSC, then its membership should be from the technical > leadership of the project - users voices should be heard, and perhaps we > should have an official user advisory group, but the technical goals and > roadmap of the project should be owned by people actively developing the > project. > > 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 > > Keith raised the issue of general throughput of patches, and the number > of unreviewed/wait state patches: need to actively scale the process. > > Stephen: How about identifying reviewers, and Thomas designates lead > reviewer for each patch? Allows scaling of review, while allowing Thomas > 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. > > Thomas: Need many reviewers, but there should be one committer per tree. > > 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 across > 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 OpenStack > patch depends on a QEMU, OVS or DPDK patch. > > 3 proposals from Stephen: > > 1. "Clone Thomas" - multiple top-level maintainers > 2. Delegate - maintainer names reviewer for each patch, and trusts review > 3. Subsystem maintainers - based on trust, maintainers are on the hook > for their tree. > > Chris: Do we have enough ppl with skills to be reviewers? If not, how do > we get to that point? > > 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 catch > regressions > > How do we maintain review velocity when maintainer is unavailable (eg. > on vacation)? How does it happen in Linux? > > - Linus delegates - names "locum" maintainer while he is away. Stephen > volunteered to do it for a week or two when necessary. > > Thomas: Subsystem maintainers carry review weight when maintainer is out. > Stephen: Subsystem maintainers are reviewers, need high level of trust > to be a top level maintainer. > > 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. > > Discussion summary > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > At this point, we synthesised the conversation and tried to converge on > a firm proposal for community discussion & action: > > - Legal entity: > - Propose moving DPDK to Linux Foundation, with low overhead option > - Minimal governance, event, marketing budget > - Legal governance around project name, trademark > > - Project leadership (roadmap, scope) > - Venky to write a proposal for broadening scope as a patch to the webs= ite > - 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. > > - Proposed criteria which should be met by any technical governance mod= el: > 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 > > 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 > > - 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. > > Bruce: We should have a TSC. Elected by contributors, with some minimum > bar for voting rights & being a candidate (eg. 10 patches) > > Christian: Thinks it makes sense to first define scope of what a TSC > would own, before deciding on a format and process for voting > > - Bruce: Anything that doesn't reach community consensus gets kicked to = 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) > > Dave: Recommended that TSC stay small (4-5 people) > > Tim will resurface his TSC proposal, revised based on this discussion, > for community review and comment. > > 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 > > We finished the discussion with a brief conversation on whether we > should maintain certain branches for a long time. > > Bruce: Adds a lot of overhead > Venky: Can do point releases on some branches > Stephen: Prepared to "volunteer" someone from Brocade, because they need > to maintain an older release anyway. > > 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) > > 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 ________________________________ * Previous message: [dpdk-dev] Notes from project governance meeting at= DPDK Userspace * Next message: [dpdk-dev] [PATCH v2 0/2] fm10k: enable TSO support * Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] ________________________________ More information about the dev mailing list