From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0b-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) by dpdk.org (Postfix) with ESMTP id 111345A50 for ; Mon, 2 Nov 2015 17:05:25 +0100 (CET) Received: from pps.filterd (m0049462.ppops.net [127.0.0.1]) by m0049462.ppops.net-00191d01. (8.15.0.59/8.15.0.59) with SMTP id tA2G0ZK3024821; Mon, 2 Nov 2015 11:05:24 -0500 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049462.ppops.net-00191d01. with ESMTP id 1xvpwt0yb8-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 02 Nov 2015 11:05:23 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id tA2G5Kou003153; Mon, 2 Nov 2015 11:05:22 -0500 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id tA2G59Lo002972 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 2 Nov 2015 11:05:16 -0500 Received: from MISOUT7MSGHUBAG.ITServices.sbc.com (MISOUT7MSGHUBAG.itservices.sbc.com [130.9.129.151]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Mon, 2 Nov 2015 16:04:56 GMT Received: from MISOUT7MSGUSRDD.ITServices.sbc.com ([169.254.4.198]) by MISOUT7MSGHUBAG.ITServices.sbc.com ([130.9.129.151]) with mapi id 14.03.0248.002; Mon, 2 Nov 2015 11:04:55 -0500 From: "CHIOSI, MARGARET T" To: Bagh Fares , "dev@dpdk.org" , "dneary@redhat.com" , "jim.st.leger@intel.com" , "Pradeep Kathail (pkathail@cisco.com)" Thread-Topic: [dpdk-dev] Proposals from project governance meeting at DPDK Userspace (was Notes from ...) Thread-Index: AdETO3UNrTlKQ/IxR1OwaDiPUSWx2gCTCdEg Date: Mon, 2 Nov 2015 16:04:55 +0000 Message-ID: <158A97FC7D125A40A52F49EE9C463AF522EE4594@MISOUT7MSGUSRDD.ITServices.sbc.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.103.117] MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2015-11-02_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1507310000 definitions=main-1511020286 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: Mon, 02 Nov 2015 16:05:26 -0000 To add to Bagh's comments - AT&T is very interested in the governance being= proposed in expanding to allow more equal voice including from the SOC ven= dors. We think it is important to rally around one API for data plane acceleratio= n which allows innovation to continue at the chip level. From: Bagh Fares [mailto:Fares.Bagh@freescale.com] Sent: Friday, October 30, 2015 2:01 PM To: dev@dpdk.org; dneary@redhat.com; jim.st.leger@intel.com; Pradeep Kathai= l (pkathail@cisco.com); CHIOSI, MARGARET T Subject: Re: [dpdk-dev] Proposals from project governance meeting at DPDK U= serspace (was Notes from ...) 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