Re: [dpdk-dev] Proposals from project governance meeting at DPDK Userspace (was Notes from ...)

Re: [dpdk-dev] Proposals from project governance meeting at DPDK Userspace (was Notes from ...)

[Bagh Fares]

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@freescale.com<mailto: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
> =====================
>
> 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)
> ======================================================
>
> 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
> =====================================
>
> 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
> ==================
>
> 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 website
>   - 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 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
>
> Further discussion on the composition and process for choosing a TSC:
> =====================================================================
>
> - 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
> =========================
>
> 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<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<http://dpdk.org/ml/archives/dev/2015-October/024845.html>
  *   Next message: [dpdk-dev] [PATCH v2 0/2] fm10k: enable TSO support<http://dpdk.org/ml/archives/dev/2015-October/024827.html>
  *   Messages sorted by: [ date ]<http://dpdk.org/ml/archives/dev/2015-October/date.html#24898> [ thread ]<http://dpdk.org/ml/archives/dev/2015-October/thread.html#24898> [ subject ]<http://dpdk.org/ml/archives/dev/2015-October/subject.html#24898> [ author ]<http://dpdk.org/ml/archives/dev/2015-October/author.html#24898>

________________________________
More information about the dev mailing list<http://dpdk.org/ml/listinfo/dev>

Re: [dpdk-dev] Proposals from project governance meeting at DPDK Userspace (was Notes from ...)

[CHIOSI, MARGARET T]

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 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.Bagh@freescale.com]
Sent: Friday, October 30, 2015 2:01 PM
To: dev@dpdk.org; dneary@redhat.com; jim.st.leger@intel.com; Pradeep Kathail (pkathail@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@freescale.com<mailto: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
> =====================
>
> 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)
> ======================================================
>
> 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
> =====================================
>
> 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
> ==================
>
> 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 website
>   - 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 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
>
> Further discussion on the composition and process for choosing a TSC:
> =====================================================================
>
> - 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
> =========================
>
> 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<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<http://dpdk.org/ml/archives/dev/2015-October/024845.html>
  *   Next message: [dpdk-dev] [PATCH v2 0/2] fm10k: enable TSO support<http://dpdk.org/ml/archives/dev/2015-October/024827.html>
  *   Messages sorted by: [ date ]<http://dpdk.org/ml/archives/dev/2015-October/date.html#24898> [ thread ]<http://dpdk.org/ml/archives/dev/2015-October/thread.html#24898> [ subject ]<http://dpdk.org/ml/archives/dev/2015-October/subject.html#24898> [ author ]<http://dpdk.org/ml/archives/dev/2015-October/author.html#24898>

________________________________
More information about the dev mailing list<http://dpdk.org/ml/listinfo/dev>

Re: [dpdk-dev] Proposals from project governance meeting at DPDK Userspace (was Notes from ...)

[Stephen Hemminger]

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.

Re: [dpdk-dev] Proposals from project governance meeting at DPDK Userspace (was Notes from ...)

[CHIOSI, MARGARET T]

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:stephen@networkplumber.org] 
Sent: Monday, November 02, 2015 12:22 PM
To: Bagh Fares
Cc: dev@dpdk.org; dneary@redhat.com; jim.st.leger@intel.com; Pradeep Kathail (pkathail@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.

Re: [dpdk-dev] Proposals from project governance meeting at DPDK Userspace (was Notes from ...)

[Dave Neary]

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 - they will be at a disadvantage.
> We need to have the DPDK organization support an API which supports a broader set of chips.

I think there is definitely a role for SOC vendors in the project
governance, but the TSC should be representative of the technical
contributors to the project, rather than an aspirational body aiming to
get more people involved.

I think there is an opportunity for future contributors/users to form a
powerful constituency in the project, but the TSC is not the right place
for that to happen IMHO.

Thanks,
Dave.

> -----Original Message-----
> From: Stephen Hemminger [mailto:stephen@networkplumber.org] 
> Sent: Monday, November 02, 2015 12:22 PM
> To: Bagh Fares
> Cc: dev@dpdk.org; dneary@redhat.com; jim.st.leger@intel.com; Pradeep Kathail (pkathail@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.
> 

-- 
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

Re: [dpdk-dev] Proposals from project governance meeting at DPDK Userspace (was Notes from ...)

[Bagh Fares]

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@redhat.com] 
Sent: Monday, November 02, 2015 11:31 AM
To: CHIOSI, MARGARET T <mc3124@att.com>; Stephen Hemminger <stephen@networkplumber.org>; Bagh Fares-B25033 <Fares.Bagh@freescale.com>
Cc: dev@dpdk.org; jim.st.leger@intel.com; Pradeep Kathail (pkathail@cisco.com) <pkathail@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 - they will be at a disadvantage.
> We need to have the DPDK organization support an API which supports a broader set of chips.

I think there is definitely a role for SOC vendors in the project governance, but the TSC should be representative of the technical contributors to the project, rather than an aspirational body aiming to get more people involved.

I think there is an opportunity for future contributors/users to form a powerful constituency in the project, but the TSC is not the right place for that to happen IMHO.

Thanks,
Dave.

> -----Original Message-----
> From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> Sent: Monday, November 02, 2015 12:22 PM
> To: Bagh Fares
> Cc: dev@dpdk.org; dneary@redhat.com; jim.st.leger@intel.com; Pradeep 
> Kathail (pkathail@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.
> 

--
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

Re: [dpdk-dev] Proposals from project governance meeting at DPDK Userspace (was Notes from ...)

[Dave Neary]

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@redhat.com] 
> Sent: Monday, November 02, 2015 11:31 AM
> To: CHIOSI, MARGARET T <mc3124@att.com>; Stephen Hemminger <stephen@networkplumber.org>; Bagh Fares-B25033 <Fares.Bagh@freescale.com>
> Cc: dev@dpdk.org; jim.st.leger@intel.com; Pradeep Kathail (pkathail@cisco.com) <pkathail@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 - they will be at a disadvantage.
>> We need to have the DPDK organization support an API which supports a broader set of chips.
> 
> I think there is definitely a role for SOC vendors in the project governance, but the TSC should be representative of the technical contributors to the project, rather than an aspirational body aiming to get more people involved.
> 
> I think there is an opportunity for future contributors/users to form a powerful constituency in the project, but the TSC is not the right place for that to happen IMHO.
> 
> Thanks,
> Dave.
> 
>> -----Original Message-----
>> From: Stephen Hemminger [mailto:stephen@networkplumber.org]
>> Sent: Monday, November 02, 2015 12:22 PM
>> To: Bagh Fares
>> Cc: dev@dpdk.org; dneary@redhat.com; jim.st.leger@intel.com; Pradeep 
>> Kathail (pkathail@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.
>>
> 
> --
> 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
> 

-- 
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

Re: [dpdk-dev] Proposals from project governance meeting at DPDK Userspace (was Notes from ...)

[Thomas Monjalon]

Hi,

It is really great to see various companies desiring to be part of the project.

2015-11-02 17:44, Bagh Fares:
> 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?

I think there is no doubt and you are very welcome.

It is planned (in the proposal) to welcome regularly some new contributors in the board.

Re: [dpdk-dev] Proposals from project governance meeting at DPDK Userspace (was Notes from ...)

[Bagh Fares]

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. 
So we need have a forum/place where this can be worked at . 
We are reaching out and we like to feel welcome and some love :-) 

-----Original Message-----
From: Dave Neary [mailto:dneary@redhat.com] 
Sent: Monday, November 02, 2015 11:55 AM
To: Bagh Fares-B25033 <Fares.Bagh@freescale.com>; CHIOSI, MARGARET T <mc3124@att.com>; Stephen Hemminger <stephen@networkplumber.org>
Cc: dev@dpdk.org; jim.st.leger@intel.com; Pradeep Kathail (pkathail@cisco.com) <pkathail@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@redhat.com]
> Sent: Monday, November 02, 2015 11:31 AM
> To: CHIOSI, MARGARET T <mc3124@att.com>; Stephen Hemminger 
> <stephen@networkplumber.org>; Bagh Fares-B25033 
> <Fares.Bagh@freescale.com>
> Cc: dev@dpdk.org; jim.st.leger@intel.com; Pradeep Kathail 
> (pkathail@cisco.com) <pkathail@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 - they will be at a disadvantage.
>> We need to have the DPDK organization support an API which supports a broader set of chips.
> 
> I think there is definitely a role for SOC vendors in the project governance, but the TSC should be representative of the technical contributors to the project, rather than an aspirational body aiming to get more people involved.
> 
> I think there is an opportunity for future contributors/users to form a powerful constituency in the project, but the TSC is not the right place for that to happen IMHO.
> 
> Thanks,
> Dave.
> 
>> -----Original Message-----
>> From: Stephen Hemminger [mailto:stephen@networkplumber.org]
>> Sent: Monday, November 02, 2015 12:22 PM
>> To: Bagh Fares
>> Cc: dev@dpdk.org; dneary@redhat.com; jim.st.leger@intel.com; Pradeep 
>> Kathail (pkathail@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.
>>
> 
> --
> 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
> 

--
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

Re: [dpdk-dev] Proposals from project governance meeting at DPDK Userspace (was Notes from ...)

[O'Driscoll, Tim]

> -----Original Message-----
> From: dev [mailto:dev-bounces@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@dpdk.org; Pradeep Kathail (pkathail@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@redhat.com]
> Sent: Monday, November 02, 2015 11:55 AM
> To: Bagh Fares-B25033 <Fares.Bagh@freescale.com>; CHIOSI, MARGARET T
> <mc3124@att.com>; Stephen Hemminger <stephen@networkplumber.org>
> Cc: dev@dpdk.org; jim.st.leger@intel.com; Pradeep Kathail
> (pkathail@cisco.com) <pkathail@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@redhat.com]
> > Sent: Monday, November 02, 2015 11:31 AM
> > To: CHIOSI, MARGARET T <mc3124@att.com>; Stephen Hemminger
> > <stephen@networkplumber.org>; Bagh Fares-B25033
> > <Fares.Bagh@freescale.com>
> > Cc: dev@dpdk.org; jim.st.leger@intel.com; Pradeep Kathail
> > (pkathail@cisco.com) <pkathail@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 - they will be at a disadvantage.
> >> We need to have the DPDK organization support an API which supports a
> broader set of chips.
> >
> > I think there is definitely a role for SOC vendors in the project
> governance, but the TSC should be representative of the technical
> contributors to the project, rather than an aspirational body aiming to
> get more people involved.
> >
> > I think there is an opportunity for future contributors/users to form
> a powerful constituency in the project, but the TSC is not the right
> place for that to happen IMHO.
> >
> > Thanks,
> > Dave.
> >
> >> -----Original Message-----
> >> From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> >> Sent: Monday, November 02, 2015 12:22 PM
> >> To: Bagh Fares
> >> Cc: dev@dpdk.org; dneary@redhat.com; jim.st.leger@intel.com; Pradeep
> >> Kathail (pkathail@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.
> >>
> >
> > --
> > 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
> >
> 
> --
> 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

Re: [dpdk-dev] Proposals from project governance meeting at DPDK Userspace (was Notes from ...)

[Pradeep Kathail]

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@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@dpdk.org; Pradeep Kathail (pkathail@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@redhat.com]
>> Sent: Monday, November 02, 2015 11:55 AM
>> To: Bagh Fares-B25033 <Fares.Bagh@freescale.com>; CHIOSI, MARGARET T
>> <mc3124@att.com>; Stephen Hemminger <stephen@networkplumber.org>
>> Cc: dev@dpdk.org; jim.st.leger@intel.com; Pradeep Kathail
>> (pkathail@cisco.com) <pkathail@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@redhat.com]
>>> Sent: Monday, November 02, 2015 11:31 AM
>>> To: CHIOSI, MARGARET T <mc3124@att.com>; Stephen Hemminger
>>> <stephen@networkplumber.org>; Bagh Fares-B25033
>>> <Fares.Bagh@freescale.com>
>>> Cc: dev@dpdk.org; jim.st.leger@intel.com; Pradeep Kathail
>>> (pkathail@cisco.com) <pkathail@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 - they will be at a disadvantage.
>>>> We need to have the DPDK organization support an API which supports a
>> broader set of chips.
>>> I think there is definitely a role for SOC vendors in the project
>> governance, but the TSC should be representative of the technical
>> contributors to the project, rather than an aspirational body aiming to
>> get more people involved.
>>> I think there is an opportunity for future contributors/users to form
>> a powerful constituency in the project, but the TSC is not the right
>> place for that to happen IMHO.
>>> Thanks,
>>> Dave.
>>>
>>>> -----Original Message-----
>>>> From: Stephen Hemminger [mailto:stephen@networkplumber.org]
>>>> Sent: Monday, November 02, 2015 12:22 PM
>>>> To: Bagh Fares
>>>> Cc: dev@dpdk.org; dneary@redhat.com; jim.st.leger@intel.com; Pradeep
>>>> Kathail (pkathail@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.
>>>>
>>> --
>>> 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
>>>
>> --
>> 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
> .
>

Re: [dpdk-dev] Proposals from project governance meeting at DPDK Userspace (was Notes from ...)

[O'Driscoll, Tim]

> -----Original Message-----
> From: Pradeep Kathail [mailto:pkathail@cisco.com]
> Sent: Monday, November 2, 2015 11:16 PM
> To: O'Driscoll, Tim; Bagh Fares; Dave Neary; CHIOSI, MARGARET T; Stephen
> Hemminger
> Cc: dev@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.

I think we might be talking about 2 slightly different things. You're asking how new contributors can participate and gain technical credibility. Anybody can do that via the dev@dpdk.org mailing list. I'm sure patches, RFCs or discussions on changes required in DPDK to better facilitate SoCs will be welcomed. There have been some good examples of this over the last few days on ARMv7/v8 support and a NEON-based ACL implementation.

The Architecture Board isn't intended as a forum for design discussions, which I think might be what you're looking for. It's intended to meet only occasionally to cover the items outlined in the proposal. We discussed composition of the board recently in Dublin and the community decided that, while users and potential contributors have an important role to play in the project, it should be composed solely of contributors. Dave Neary summed it up well in a previous email on this: "The TSC should be representative of the technical contributors to the project, rather than an aspirational body aiming to get more people involved."

It would be interesting to hear the thoughts of others on whether we should consider an exception in this case.


Tim

> 
> Pradeep
> 
> On 11/2/15 1:44 PM, O'Driscoll, Tim wrote:
> >> -----Original Message-----
> >> From: dev [mailto:dev-bounces@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@dpdk.org; Pradeep Kathail (pkathail@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@redhat.com]
> >> Sent: Monday, November 02, 2015 11:55 AM
> >> To: Bagh Fares-B25033 <Fares.Bagh@freescale.com>; CHIOSI, MARGARET T
> >> <mc3124@att.com>; Stephen Hemminger <stephen@networkplumber.org>
> >> Cc: dev@dpdk.org; jim.st.leger@intel.com; Pradeep Kathail
> >> (pkathail@cisco.com) <pkathail@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@redhat.com]
> >>> Sent: Monday, November 02, 2015 11:31 AM
> >>> To: CHIOSI, MARGARET T <mc3124@att.com>; Stephen Hemminger
> >>> <stephen@networkplumber.org>; Bagh Fares-B25033
> >>> <Fares.Bagh@freescale.com>
> >>> Cc: dev@dpdk.org; jim.st.leger@intel.com; Pradeep Kathail
> >>> (pkathail@cisco.com) <pkathail@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 - they will be at a
> disadvantage.
> >>>> We need to have the DPDK organization support an API which supports
> a
> >> broader set of chips.
> >>> I think there is definitely a role for SOC vendors in the project
> >> governance, but the TSC should be representative of the technical
> >> contributors to the project, rather than an aspirational body aiming
> to
> >> get more people involved.
> >>> I think there is an opportunity for future contributors/users to
> form
> >> a powerful constituency in the project, but the TSC is not the right
> >> place for that to happen IMHO.
> >>> Thanks,
> >>> Dave.
> >>>
> >>>> -----Original Message-----
> >>>> From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> >>>> Sent: Monday, November 02, 2015 12:22 PM
> >>>> To: Bagh Fares
> >>>> Cc: dev@dpdk.org; dneary@redhat.com; jim.st.leger@intel.com;
> Pradeep
> >>>> Kathail (pkathail@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.
> >>>>
> >>> --
> >>> 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
> >>>
> >> --
> >> 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
> > .
> >

Re: [dpdk-dev] Proposals from project governance meeting at DPDK Userspace (was Notes from ...)

[Thomas Monjalon]

2015-11-03 12:43, O'Driscoll, Tim:
> From: Pradeep Kathail [mailto:pkathail@cisco.com]
> > 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.
> 
> I think we might be talking about 2 slightly different things. You're asking how new contributors can participate and gain technical credibility. Anybody can do that via the dev@dpdk.org mailing list. I'm sure patches, RFCs or discussions on changes required in DPDK to better facilitate SoCs will be welcomed. There have been some good examples of this over the last few days on ARMv7/v8 support and a NEON-based ACL implementation.
> 
> The Architecture Board isn't intended as a forum for design discussions, which I think might be what you're looking for. It's intended to meet only occasionally to cover the items outlined in the proposal. We discussed composition of the board recently in Dublin and the community decided that, while users and potential contributors have an important role to play in the project, it should be composed solely of contributors. Dave Neary summed it up well in a previous email on this: "The TSC should be representative of the technical contributors to the project, rather than an aspirational body aiming to get more people involved."
> 
> It would be interesting to hear the thoughts of others on whether we should consider an exception in this case.

The Architecture Board would be useful only in case a consensus cannot be reached.
It has not happened yet.
We are a truly open community so you just have to contribute to make things happen.

Re: [dpdk-dev] Proposals from project governance meeting at DPDK Userspace (was Notes from ...)

[CHIOSI, MARGARET T]

I second Pradeep's comments - which was what I was driving at.

-----Original Message-----
From: Pradeep Kathail [mailto:pkathail@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@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@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@dpdk.org; Pradeep Kathail (pkathail@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@redhat.com]
>> Sent: Monday, November 02, 2015 11:55 AM
>> To: Bagh Fares-B25033 <Fares.Bagh@freescale.com>; CHIOSI, MARGARET T
>> <mc3124@att.com>; Stephen Hemminger <stephen@networkplumber.org>
>> Cc: dev@dpdk.org; jim.st.leger@intel.com; Pradeep Kathail
>> (pkathail@cisco.com) <pkathail@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@redhat.com]
>>> Sent: Monday, November 02, 2015 11:31 AM
>>> To: CHIOSI, MARGARET T <mc3124@att.com>; Stephen Hemminger
>>> <stephen@networkplumber.org>; Bagh Fares-B25033
>>> <Fares.Bagh@freescale.com>
>>> Cc: dev@dpdk.org; jim.st.leger@intel.com; Pradeep Kathail
>>> (pkathail@cisco.com) <pkathail@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 - they will be at a disadvantage.
>>>> We need to have the DPDK organization support an API which supports a
>> broader set of chips.
>>> I think there is definitely a role for SOC vendors in the project
>> governance, but the TSC should be representative of the technical
>> contributors to the project, rather than an aspirational body aiming to
>> get more people involved.
>>> I think there is an opportunity for future contributors/users to form
>> a powerful constituency in the project, but the TSC is not the right
>> place for that to happen IMHO.
>>> Thanks,
>>> Dave.
>>>
>>>> -----Original Message-----
>>>> From: Stephen Hemminger [mailto:stephen@networkplumber.org]
>>>> Sent: Monday, November 02, 2015 12:22 PM
>>>> To: Bagh Fares
>>>> Cc: dev@dpdk.org; dneary@redhat.com; jim.st.leger@intel.com; Pradeep
>>>> Kathail (pkathail@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.
>>>>
>>> --
>>> 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
>>>
>> --
>> 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
> .
>

Re: [dpdk-dev] Proposals from project governance meeting at DPDK Userspace (was Notes from ...)

[Bagh Fares]

Tim
Good clafication. What is the governance model. Can you point me to it? Thanks 

-----Original Message-----
From: O'Driscoll, Tim [mailto:tim.odriscoll@intel.com] 
Sent: Tuesday, November 03, 2015 6:43 AM
To: Pradeep Kathail <pkathail@cisco.com>; Bagh Fares-B25033 <Fares.Bagh@freescale.com>; Dave Neary <dneary@redhat.com>; CHIOSI, MARGARET T <mc3124@att.com>; Stephen Hemminger <stephen@networkplumber.org>; dev@dpdk.org
Subject: RE: [dpdk-dev] Proposals from project governance meeting at DPDK Userspace (was Notes from ...)


> -----Original Message-----
> From: Pradeep Kathail [mailto:pkathail@cisco.com]
> Sent: Monday, November 2, 2015 11:16 PM
> To: O'Driscoll, Tim; Bagh Fares; Dave Neary; CHIOSI, MARGARET T; 
> Stephen Hemminger
> Cc: dev@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.

I think we might be talking about 2 slightly different things. You're asking how new contributors can participate and gain technical credibility. Anybody can do that via the dev@dpdk.org mailing list. I'm sure patches, RFCs or discussions on changes required in DPDK to better facilitate SoCs will be welcomed. There have been some good examples of this over the last few days on ARMv7/v8 support and a NEON-based ACL implementation.

The Architecture Board isn't intended as a forum for design discussions, which I think might be what you're looking for. It's intended to meet only occasionally to cover the items outlined in the proposal. We discussed composition of the board recently in Dublin and the community decided that, while users and potential contributors have an important role to play in the project, it should be composed solely of contributors. Dave Neary summed it up well in a previous email on this: "The TSC should be representative of the technical contributors to the project, rather than an aspirational body aiming to get more people involved."

It would be interesting to hear the thoughts of others on whether we should consider an exception in this case.


Tim

> 
> Pradeep
> 
> On 11/2/15 1:44 PM, O'Driscoll, Tim wrote:
> >> -----Original Message-----
> >> From: dev [mailto:dev-bounces@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@dpdk.org; Pradeep Kathail (pkathail@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@redhat.com]
> >> Sent: Monday, November 02, 2015 11:55 AM
> >> To: Bagh Fares-B25033 <Fares.Bagh@freescale.com>; CHIOSI, MARGARET 
> >> T <mc3124@att.com>; Stephen Hemminger <stephen@networkplumber.org>
> >> Cc: dev@dpdk.org; jim.st.leger@intel.com; Pradeep Kathail
> >> (pkathail@cisco.com) <pkathail@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@redhat.com]
> >>> Sent: Monday, November 02, 2015 11:31 AM
> >>> To: CHIOSI, MARGARET T <mc3124@att.com>; Stephen Hemminger 
> >>> <stephen@networkplumber.org>; Bagh Fares-B25033 
> >>> <Fares.Bagh@freescale.com>
> >>> Cc: dev@dpdk.org; jim.st.leger@intel.com; Pradeep Kathail
> >>> (pkathail@cisco.com) <pkathail@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 - they will be at a
> disadvantage.
> >>>> We need to have the DPDK organization support an API which 
> >>>> supports
> a
> >> broader set of chips.
> >>> I think there is definitely a role for SOC vendors in the project
> >> governance, but the TSC should be representative of the technical 
> >> contributors to the project, rather than an aspirational body 
> >> aiming
> to
> >> get more people involved.
> >>> I think there is an opportunity for future contributors/users to
> form
> >> a powerful constituency in the project, but the TSC is not the 
> >> right place for that to happen IMHO.
> >>> Thanks,
> >>> Dave.
> >>>
> >>>> -----Original Message-----
> >>>> From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> >>>> Sent: Monday, November 02, 2015 12:22 PM
> >>>> To: Bagh Fares
> >>>> Cc: dev@dpdk.org; dneary@redhat.com; jim.st.leger@intel.com;
> Pradeep
> >>>> Kathail (pkathail@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.
> >>>>
> >>> --
> >>> 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
> >>>
> >> --
> >> 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
> > .
> >

Re: [dpdk-dev] Proposals from project governance meeting at DPDK Userspace (was Notes from ...)

[Vincent JARDIN]

Le 3 nov. 2015 23:05, "Bagh Fares" <Fares.Bagh@freescale.com> a écrit :
>
> Tim
> Good clafication. What is the governance model. Can you point me to it?
Thanks

First sentence of
  http://dpdk.org/dev
is
" Anyone is welcome to contribute."

Best regards,

>
> -----Original Message-----
> From: O'Driscoll, Tim [mailto:tim.odriscoll@intel.com]
> Sent: Tuesday, November 03, 2015 6:43 AM
> To: Pradeep Kathail <pkathail@cisco.com>; Bagh Fares-B25033 <
Fares.Bagh@freescale.com>; Dave Neary <dneary@redhat.com>; CHIOSI, MARGARET
T <mc3124@att.com>; Stephen Hemminger <stephen@networkplumber.org>;
dev@dpdk.org
> Subject: RE: [dpdk-dev] Proposals from project governance meeting at DPDK
Userspace (was Notes from ...)
>
>
> > -----Original Message-----
> > From: Pradeep Kathail [mailto:pkathail@cisco.com]
> > Sent: Monday, November 2, 2015 11:16 PM
> > To: O'Driscoll, Tim; Bagh Fares; Dave Neary; CHIOSI, MARGARET T;
> > Stephen Hemminger
> > Cc: dev@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.
>
> I think we might be talking about 2 slightly different things. You're
asking how new contributors can participate and gain technical credibility.
Anybody can do that via the dev@dpdk.org mailing list. I'm sure patches,
RFCs or discussions on changes required in DPDK to better facilitate SoCs
will be welcomed. There have been some good examples of this over the last
few days on ARMv7/v8 support and a NEON-based ACL implementation.
>
> The Architecture Board isn't intended as a forum for design discussions,
which I think might be what you're looking for. It's intended to meet only
occasionally to cover the items outlined in the proposal. We discussed
composition of the board recently in Dublin and the community decided that,
while users and potential contributors have an important role to play in
the project, it should be composed solely of contributors. Dave Neary
summed it up well in a previous email on this: "The TSC should be
representative of the technical contributors to the project, rather than an
aspirational body aiming to get more people involved."
>
> It would be interesting to hear the thoughts of others on whether we
should consider an exception in this case.
>
>
> Tim
>
> >
> > Pradeep
> >
> > On 11/2/15 1:44 PM, O'Driscoll, Tim wrote:
> > >> -----Original Message-----
> > >> From: dev [mailto:dev-bounces@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@dpdk.org; Pradeep Kathail (pkathail@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@redhat.com]
> > >> Sent: Monday, November 02, 2015 11:55 AM
> > >> To: Bagh Fares-B25033 <Fares.Bagh@freescale.com>; CHIOSI, MARGARET
> > >> T <mc3124@att.com>; Stephen Hemminger <stephen@networkplumber.org>
> > >> Cc: dev@dpdk.org; jim.st.leger@intel.com; Pradeep Kathail
> > >> (pkathail@cisco.com) <pkathail@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@redhat.com]
> > >>> Sent: Monday, November 02, 2015 11:31 AM
> > >>> To: CHIOSI, MARGARET T <mc3124@att.com>; Stephen Hemminger
> > >>> <stephen@networkplumber.org>; Bagh Fares-B25033
> > >>> <Fares.Bagh@freescale.com>
> > >>> Cc: dev@dpdk.org; jim.st.leger@intel.com; Pradeep Kathail
> > >>> (pkathail@cisco.com) <pkathail@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 - they will be at a
> > disadvantage.
> > >>>> We need to have the DPDK organization support an API which
> > >>>> supports
> > a
> > >> broader set of chips.
> > >>> I think there is definitely a role for SOC vendors in the project
> > >> governance, but the TSC should be representative of the technical
> > >> contributors to the project, rather than an aspirational body
> > >> aiming
> > to
> > >> get more people involved.
> > >>> I think there is an opportunity for future contributors/users to
> > form
> > >> a powerful constituency in the project, but the TSC is not the
> > >> right place for that to happen IMHO.
> > >>> Thanks,
> > >>> Dave.
> > >>>
> > >>>> -----Original Message-----
> > >>>> From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> > >>>> Sent: Monday, November 02, 2015 12:22 PM
> > >>>> To: Bagh Fares
> > >>>> Cc: dev@dpdk.org; dneary@redhat.com; jim.st.leger@intel.com;
> > Pradeep
> > >>>> Kathail (pkathail@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.
> > >>>>
> > >>> --
> > >>> 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
> > >>>
> > >> --
> > >> 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
> > > .
> > >
>

Re: [dpdk-dev] Proposals from project governance meeting at DPDK Userspace (was Notes from ...)

[Stephen Hemminger]

On Mon, 2 Nov 2015 15:16:16 -0800
Pradeep Kathail <pkathail@cisco.com> wrote:

> 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

Why doesn't one or more SOC vendors contribute patches or discuss
the issues on the mailing list or at DPDK meetings. I dont think we
need a behind closed doors planning session on this. Much prefer
the old "consensus and running code model".

Re: [dpdk-dev] Proposals from project governance meeting at DPDK Userspace (was Notes from ...)

[Pradeep Kathail]

No one is proposing any close door planning session and commits for 
ARM port of DPDK already staretd.

Pradeep

On 11/3/15 3:35 PM, Stephen Hemminger wrote:
> On Mon, 2 Nov 2015 15:16:16 -0800
> Pradeep Kathail <pkathail@cisco.com> wrote:
>
>> 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
> Why doesn't one or more SOC vendors contribute patches or discuss
> the issues on the mailing list or at DPDK meetings. I dont think we
> need a behind closed doors planning session on this. Much prefer
> the old "consensus and running code model".
> .
>

[dpdk-dev] Proposals from project governance meeting at DPDK Userspace (was Notes from ...)

[Dave Neary]

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
> 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)
> ======================================================
> 
> 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
> =====================================
> 
> 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
> ==================
> 
> 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 website
>   - 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 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
> 
> Further discussion on the composition and process for choosing a TSC:
> =====================================================================
> 
> - 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
> =========================
> 
> 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