[dpdk-dev] Proposals from project governance meeting at DPDK Userspace (was Notes from ...)
I second Pradeep's comments - which was what I was driving at. -Original Message- From: Pradeep Kathail [mailto:pkath...@cisco.com] Sent: Monday, November 02, 2015 6:16 PM To: O'Driscoll, Tim; Bagh Fares; Dave Neary; CHIOSI, MARGARET T; Stephen Hemminger Cc: dev at dpdk.org Subject: Re: [dpdk-dev] Proposals from project governance meeting at DPDK Userspace (was Notes from ...) Tim and Dave, I agree that an architecture board membership should be based on technical standing and contribution but at the same time, if you are trying to bring a new hardware paradigm into a project, you need to give a chance to some of those experts to participate and gain the standing. If community is serious about supporting SOC's, my suggestion will be to allow few (2?) members from SOC community for limited time (6? months) and then evaluate based on their contributions. Pradeep On 11/2/15 1:44 PM, O'Driscoll, Tim wrote: >> -Original Message- >> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Bagh Fares >> Sent: Monday, November 2, 2015 6:03 PM >> To: Dave Neary; CHIOSI, MARGARET T; Stephen Hemminger >> Cc: dev at dpdk.org; Pradeep Kathail (pkathail at cisco.com) >> Subject: Re: [dpdk-dev] Proposals from project governance meeting at >> DPDK Userspace (was Notes from ...) >> >> Yes. Thank you. What we like is to get to a point where we discuss API >> and align on APIs for SOC as Margaret mention. As you know Arm has been >> driving ODP as the API for SOC. >> What we like to do is to drive the APIs under DPDK even for Arm SOC. >> Long term, and based on shrinking silicon geometries, and desire to fill >> fabs, Intel will do more SOCs. I was SOC design manager in Intel :-) >> We like to spare the customers like red hat, Cisco, and ATT the pain of >> supporting multiple APIs and code bases. > That's our goal too, so it's good to hear that we're in agreement on this. > >> So we need have a forum/place where this can be worked at . > If you have some ideas, then the best way to get some discussion going is > through the mailing list. You could post a set of patches for proposed > changes, a higher-level RFC outlining your thoughts, or just specific > questions/issues that you see. > > On the TSC that was specifically referenced earlier in this thread, there is > a proposal for what we're now calling the Architecture Board at: > http://dpdk.org/ml/archives/dev/2015-October/026598.html. As Dave mentioned, > we agreed at our recent Userspace event in Dublin that membership of the > board should be based on contributions and technical standing in the > community. The board will review and approve new members on an annual basis. > >> We are reaching out and we like to feel welcome and some love :-) > As Thomas already said, new contributors are always welcome! > > > Tim > > >> -Original Message- >> From: Dave Neary [mailto:dneary at redhat.com] >> Sent: Monday, November 02, 2015 11:55 AM >> To: Bagh Fares-B25033 ; CHIOSI, MARGARET T >> ; Stephen Hemminger >> Cc: dev at dpdk.org; jim.st.leger at intel.com; Pradeep Kathail >> (pkathail at cisco.com) >> Subject: Re: [dpdk-dev] Proposals from project governance meeting at >> DPDK Userspace (was Notes from ...) >> >> Hi, >> >> On the contrary! I am aware that Freescale has been engaged for some >> time in DPDK. I was responding to Margaret's contention that future >> contributors (and she called out ARM and SOC vendors) should have a >> voice. >> >> I hope that clarifies my position and meaning. >> >> Thanks, >> Dave. >> >> On 11/02/2015 12:44 PM, Bagh Fares wrote: >>> As SOC vendor we will contribute heavily to the project. Example >> crypto acceleration. We already contribute a lot to the linux community. >>> So not sure why the doubt about of contribution? >>> >>> >>> -Original Message- >>> From: Dave Neary [mailto:dneary at redhat.com] >>> Sent: Monday, November 02, 2015 11:31 AM >>> To: CHIOSI, MARGARET T ; Stephen Hemminger >>> ; Bagh Fares-B25033 >>> >>> Cc: dev at dpdk.org; jim.st.leger at intel.com; Pradeep Kathail >>> (pkathail at cisco.com) >>> Subject: Re: [dpdk-dev] Proposals from project governance meeting at >>> DPDK Userspace (was Notes from ...) >>> >>> Hi Margaret, >>> >>> On 11/02/2015 12:28 PM, CHIOSI, MARGARET T wrote: >>>> I think it is very important for the first version of governance that >> we have ARM/SOC vendor/future contributors to be part of TSC. >>>> If based on historical contribution -
[dpdk-dev] Proposals from project governance meeting at DPDK Userspace (was Notes from ...)
I think it is very important for the first version of governance that we have ARM/SOC vendor/future contributors to be part of TSC. If based on historical contribution - they will be at a disadvantage. We need to have the DPDK organization support an API which supports a broader set of chips. -Original Message- From: Stephen Hemminger [mailto:step...@networkplumber.org] Sent: Monday, November 02, 2015 12:22 PM To: Bagh Fares Cc: dev at dpdk.org; dneary at redhat.com; jim.st.leger at intel.com; Pradeep Kathail (pkathail at cisco.com); CHIOSI, MARGARET T Subject: Re: [dpdk-dev] Proposals from project governance meeting at DPDK Userspace (was Notes from ...) There were two outcomes. One was a proposal to move governance under Linux Foundation. The other was to have a technical steering committee. It was agreed the TSC would be based on the contributors to the project, although we didn't come to a conclusion on a voting model. I would propose that TSC should be elected at regular user summit from nominees; in a manner similar to LF Technical Advisory Board.
[dpdk-dev] Proposals from project governance meeting at DPDK Userspace (was Notes from ...)
To add to Bagh's comments - AT is very interested in the governance being proposed in expanding to allow more equal voice including from the SOC vendors. We think it is important to rally around one API for data plane acceleration which allows innovation to continue at the chip level. From: Bagh Fares [mailto:fares.b...@freescale.com] Sent: Friday, October 30, 2015 2:01 PM To: dev at dpdk.org; dneary at redhat.com; jim.st.leger at intel.com; Pradeep Kathail (pkathail at cisco.com); CHIOSI, MARGARET T Subject: Re: [dpdk-dev] Proposals from project governance meeting at DPDK Userspace (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 starting with crypto function. We like to have a road map for acceleration beyond 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 at freescale.com<mailto:fares.bagh at 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 > = > > 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 > complete
