[dpdk-dev] Architecture Board Proposal

[dpdk-dev] Architecture Board Proposal

[O'Driscoll, Tim]

At the recent DPDK Userspace event we agreed that we need a body to make technical decisions for the project. In Dublin we referred to this as a Technical Steering Committee, but that term is often used on other projects to describe a body with a more political charter.  To avoid confusion, and clarify that the scope of this body for DPDK is purely technical, I propose calling it the DPDK Architecture Board.

Justification
-------------
The role of the Maintainer is to be the gate-keeper for the project, and to only accept contributions that are properly implemented, properly reviewed, and consistent with the agreed project scope/charter. However, it shouldn't be the responsibility of the Maintainer to be the final decision maker (after community discussion) on issues affecting the strategic direction of the project. Instead, this should be determined by a higher level body that's representative of the DPDK community.

Having an Architecture Board will help to provide a clear direction/strategy for the project, and help to resolve complex issues which don't reach a consensus on the mailing list in a timely manner.

Scope
----- 
Issues that are within the scope of the Architecture Board include:
- Project scope/charter. What is and isn't within the scope of the project? What happens if somebody wants to upstream a new library/capability and it's not clear whether it fits within DPDK or not? As a random example, if somebody wanted to upstream a DPDK-enabled TCP/IP stack to dpdk.org, should that be accepted or rejected?
- Performance vs functionality considerations. If we need to make a change and there's an unavoidable performance impact to doing so (maybe something like extending the mbuf again), does that change get accepted or not? In most cases you can probably work around situations like this by making them optional, but that might not always be possible. If it's not, who decides whether performance or functionality is more important?
- Replacing existing functionality versus adding new alternatives. If there's a new implementation of an existing DPDK capability that performs better in some use cases but worse in others, does that get accepted and replace the existing implementation, does it get accepted as an alternative, or does it get rejected?
- Unresolved issues. Provide a decision on issues that don't reach a consensus on the mailing list in a timely manner.

Composition
-----------
For composition of the Architecture Board, I'd propose the following:
- It needs to be kept to a manageable size. I propose limiting it to 5 initially (it should be an odd number to minimize deadlocks).
- Membership should be based on: number and quality of contributions, technical standing in the community, breadth of involvement (involvement in many areas, not just a single part of DPDK).
- No single company/organization can have more than 2 members.
- The Architecture Board will elect its own chair, who will have the deciding vote in the event of a deadlock.
- The board will review its own composition and co-opt/approve any new members on an annual basis.

There are three main options for determining who is on the board:
1. Nomination of representatives by contributing companies. We could allocate a number of positions on the board based on the contributions from each company and then allow those companies to nominate their representatives. The downsides are that many companies contribute but not all can be represented on the board so we'd need a way to decide which companies get a seat and which don't, and that this focuses the discussion on company contributions rather than individuals with the best technical standing
2. Election of representatives. We could poll for candidates and then vote. This is likely to take time because we'll need to agree and implement the process to support an election.
3. Seed the board with those who have the best technical standing in the community. We could determine the initial composition by consensus. I think the prime candidates for an Architecture Board will be obvious to most of us.

My preference would be for option 3. Any other opinions or comments on this proposal?


Tim

Re: [dpdk-dev] Architecture Board Proposal

[Thomas Monjalon]

Hi Tim,

2015-10-29 15:21, O'Driscoll, Tim:
> Scope
> ----- 
> Issues that are within the scope of the Architecture Board include:
> - Project scope/charter. What is and isn't within the scope of the project? What happens if somebody wants to upstream a new library/capability and it's not clear whether it fits within DPDK or not? As a random example, if somebody wanted to upstream a DPDK-enabled TCP/IP stack to dpdk.org, should that be accepted or rejected?

Do you mean the scope of this board would be about the whole projects hosted
on dpdk.org (http://dpdk.org/browse/) or only the DPDK (http://dpdk.org/browse/dpdk)?

Using your TCP stack example, I think it should be hosted on dpdk.org
but it may be out of the scope of the DPDK tree.

Re: [dpdk-dev] Architecture Board Proposal

[O'Driscoll, Tim]

> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Thomas Monjalon
> Sent: Thursday, October 29, 2015 3:43 PM
> To: O'Driscoll, Tim
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] Architecture Board Proposal
> 
> Hi Tim,
> 
> 2015-10-29 15:21, O'Driscoll, Tim:
> > Scope
> > -----
> > Issues that are within the scope of the Architecture Board include:
> > - Project scope/charter. What is and isn't within the scope of the
> project? What happens if somebody wants to upstream a new
> library/capability and it's not clear whether it fits within DPDK or
> not? As a random example, if somebody wanted to upstream a DPDK-enabled
> TCP/IP stack to dpdk.org, should that be accepted or rejected?
> 
> Do you mean the scope of this board would be about the whole projects
> hosted
> on dpdk.org (http://dpdk.org/browse/) or only the DPDK
> (http://dpdk.org/browse/dpdk)?
> 
> Using your TCP stack example, I think it should be hosted on dpdk.org
> but it may be out of the scope of the DPDK tree.

Good question. I think the scope should be just the DPDK project.

Re: [dpdk-dev] Architecture Board Proposal

[Dave Neary]

Thanks Tim,

Great to see some momentum coming out of DPDK Userspace.

On 10/29/2015 11:21 AM, O'Driscoll, Tim wrote:
> At the recent DPDK Userspace event we agreed that we need a body to
> make technical decisions for the project. In Dublin we referred to this
> as a Technical Steering Committee, but that term is often used on other
> projects to describe a body with a more political charter. To avoid
> confusion, and clarify that the scope of this body for DPDK is purely
> technical, I propose calling it the DPDK Architecture Board.

Speaking personally, I don't mind what we call it once there is an
agreed scope, membership process, and decision making process.
Architecture Board seems OK to me.

> Justification
> -------------
> The role of the Maintainer is to be the gate-keeper for the project,
> and to only accept contributions that are properly implemented, properly
> reviewed, and consistent with the agreed project scope/charter. However,
> it shouldn't be the responsibility of the Maintainer to be the final
> decision maker (after community discussion) on issues affecting the
> strategic direction of the project. Instead, this should be determined
> by a higher level body that's representative of the DPDK community.
> 
> Having an Architecture Board will help to provide a clear
> direction/strategy for the project, and help to resolve complex issues
> which don't reach a consensus on the mailing list in a timely manner.
> 
> Scope
> ----- 
> Issues that are within the scope of the Architecture Board include:
> - Project scope/charter. What is and isn't within the scope of the
>   project? What happens if somebody wants to upstream a new
>   library/capability and it's not clear whether it fits within DPDK or
>   not? As a random example, if somebody wanted to upstream a DPDK-enabled
>   TCP/IP stack to dpdk.org, should that be accepted or rejected?

I agree with Thomas here that this seems like it would be a separate
project under dpdk.org, rather than part of DPDK - I think it's OK for
the Architecture Board to own the scope of "projects on dpdk.org" rather
than just DPDK.

> - Performance vs functionality considerations. If we need to make a
>   change and there's an unavoidable performance impact to doing so (maybe
>   something like extending the mbuf again), does that change get accepted
>   or not? In most cases you can probably work around situations like this
>   by making them optional, but that might not always be possible. If it's
>   not, who decides whether performance or functionality is more important?
> - Replacing existing functionality versus adding new alternatives.
>   If there's a new implementation of an existing DPDK capability that
>   performs better in some use cases but worse in others, does that get
>   accepted and replace the existing implementation, does it get accepted
>   as an alternative, or does it get rejected?
> - Unresolved issues. Provide a decision on issues that don't reach a
>   consensus on the mailing list in a timely manner.

In general I would summarise these as "act as a decision making body
when there is a difficulty converging to a decision in the community".
That includes competing technology, priorities and in general
non-converging discussions.

I think it's important to say that this body kicks in after a decision
has not converged, it is not (apart from project scope considerations,
wich will not evolve very often) a leading body, rather, it's a "last
resort" providing clarity when the community does not generate a consensus.


> Composition
> -----------
> For composition of the Architecture Board, I'd propose the following:
> - It needs to be kept to a manageable size. I propose limiting it to
>   5 initially (it should be an odd number to minimize deadlocks).
> - Membership should be based on: number and quality of
>   contributions, technical standing in the community, breadth of involvement
>   (involvement in many areas, not just a single part of DPDK).
> - No single company/organization can have more than 2 members.
> - The Architecture Board will elect its own chair, who will have the
>   deciding vote in the event of a deadlock.
> - The board will review its own composition and co-opt/approve any
>   new members on an annual basis.
> 
> There are three main options for determining who is on the board:
> 1. Nomination of representatives by contributing companies. We could
>    allocate a number of positions on the board based on the contributions
>    from each company and then allow those companies to nominate their
>    representatives. The downsides are that many companies contribute but
>    not all can be represented on the board so we'd need a way to decide
>    which companies get a seat and which don't, and that this focuses the
>    discussion on company contributions rather than individuals with the
>    best technical standing
> 2. Election of representatives. We could poll for candidates and
>    then vote. This is likely to take time because we'll need to agree and
>    implement the process to support an election.
> 3. Seed the board with those who have the best technical standing in
>    the community. We could determine the initial composition by consensus.
>    I think the prime candidates for an Architecture Board will be obvious
>    to most of us.
> 
> My preference would be for option 3. Any other opinions or comments on this proposal?

I like co-option in this case, but I would like to have some kind of
criteria for how board removals can happen - that might be a detail, but
it's important that the architect board continue to represent the most
influential participants in the community, and I could imagine a
scenario where someone named to the board moves to a different position
and over the course of 6-12 months is less active in the project - would
they be expected to nominate a successor? Withdraw and alow others to
nominate? If they don't volunteer to withdraw, what criteria can the
board use to request that they withdrawal?

One thing I think is important is that seats are not considered "owned"
by a company. There isn't a 6WIND seat or an Intel seat - seats are held
by individuals representing the interests of the technical community,
not companies invested in the project. In general, though, I think 2
seats per company may is a good number, I would not want to have even
the perception of a majority voting block by one company.

Overall, thanks Tim! I think this is a really solid proposal.

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

Re: [dpdk-dev] Architecture Board Proposal

[O'Driscoll, Tim]

> -----Original Message-----
> From: Dave Neary [mailto:dneary@redhat.com]
> Sent: Thursday, October 29, 2015 7:49 PM
> To: O'Driscoll, Tim; dev@dpdk.org
> Subject: Re: [dpdk-dev] Architecture Board Proposal
> 
> Thanks Tim,
> 
> Great to see some momentum coming out of DPDK Userspace.
> 
> On 10/29/2015 11:21 AM, O'Driscoll, Tim wrote:
> > At the recent DPDK Userspace event we agreed that we need a body to
> > make technical decisions for the project. In Dublin we referred to
> this
> > as a Technical Steering Committee, but that term is often used on
> other
> > projects to describe a body with a more political charter. To avoid
> > confusion, and clarify that the scope of this body for DPDK is purely
> > technical, I propose calling it the DPDK Architecture Board.
> 
> Speaking personally, I don't mind what we call it once there is an
> agreed scope, membership process, and decision making process.
> Architecture Board seems OK to me.
> 
> > Justification
> > -------------
> > The role of the Maintainer is to be the gate-keeper for the project,
> > and to only accept contributions that are properly implemented,
> properly
> > reviewed, and consistent with the agreed project scope/charter.
> However,
> > it shouldn't be the responsibility of the Maintainer to be the final
> > decision maker (after community discussion) on issues affecting the
> > strategic direction of the project. Instead, this should be determined
> > by a higher level body that's representative of the DPDK community.
> >
> > Having an Architecture Board will help to provide a clear
> > direction/strategy for the project, and help to resolve complex issues
> > which don't reach a consensus on the mailing list in a timely manner.
> >
> > Scope
> > -----
> > Issues that are within the scope of the Architecture Board include:
> > - Project scope/charter. What is and isn't within the scope of the
> >   project? What happens if somebody wants to upstream a new
> >   library/capability and it's not clear whether it fits within DPDK or
> >   not? As a random example, if somebody wanted to upstream a DPDK-
> enabled
> >   TCP/IP stack to dpdk.org, should that be accepted or rejected?
> 
> I agree with Thomas here that this seems like it would be a separate
> project under dpdk.org, rather than part of DPDK - I think it's OK for
> the Architecture Board to own the scope of "projects on dpdk.org" rather
> than just DPDK.

I think there are two questions here. The first is one that Thomas raised and you've also touched on: Is the scope of the Architecture Board just DPDK (i.e. everything in http://dpdk.org/browse/dpdk/), or is it everything hosted on dpdk.org (list at: http://dpdk.org/browse/). My original intent was just DPDK, but I'm fine with either option.

The second question is who decides whether something is within the scope of DPDK or not? A TCP/IP stack was just an example. If I were to submit patches for a DPDK-accelerated IPsec library (librte_ipsec), who would decide whether that's OK or if it needs to reside somewhere else outside of the DPDK? I think that managing the scope of the project should be one of the roles of the Architecture Board.

> > - Performance vs functionality considerations. If we need to make a
> >   change and there's an unavoidable performance impact to doing so
> (maybe
> >   something like extending the mbuf again), does that change get
> accepted
> >   or not? In most cases you can probably work around situations like
> this
> >   by making them optional, but that might not always be possible. If
> it's
> >   not, who decides whether performance or functionality is more
> important?
> > - Replacing existing functionality versus adding new alternatives.
> >   If there's a new implementation of an existing DPDK capability that
> >   performs better in some use cases but worse in others, does that get
> >   accepted and replace the existing implementation, does it get
> accepted
> >   as an alternative, or does it get rejected?
> > - Unresolved issues. Provide a decision on issues that don't reach a
> >   consensus on the mailing list in a timely manner.
> 
> In general I would summarise these as "act as a decision making body
> when there is a difficulty converging to a decision in the community".
> That includes competing technology, priorities and in general
> non-converging discussions.
> 
> I think it's important to say that this body kicks in after a decision
> has not converged, it is not (apart from project scope considerations,
> wich will not evolve very often) a leading body, rather, it's a "last
> resort" providing clarity when the community does not generate a
> consensus.

Exactly.

> > Composition
> > -----------
> > For composition of the Architecture Board, I'd propose the following:
> > - It needs to be kept to a manageable size. I propose limiting it to
> >   5 initially (it should be an odd number to minimize deadlocks).
> > - Membership should be based on: number and quality of
> >   contributions, technical standing in the community, breadth of
> involvement
> >   (involvement in many areas, not just a single part of DPDK).
> > - No single company/organization can have more than 2 members.
> > - The Architecture Board will elect its own chair, who will have the
> >   deciding vote in the event of a deadlock.
> > - The board will review its own composition and co-opt/approve any
> >   new members on an annual basis.
> >
> > There are three main options for determining who is on the board:
> > 1. Nomination of representatives by contributing companies. We could
> >    allocate a number of positions on the board based on the
> contributions
> >    from each company and then allow those companies to nominate their
> >    representatives. The downsides are that many companies contribute
> but
> >    not all can be represented on the board so we'd need a way to
> decide
> >    which companies get a seat and which don't, and that this focuses
> the
> >    discussion on company contributions rather than individuals with
> the
> >    best technical standing
> > 2. Election of representatives. We could poll for candidates and
> >    then vote. This is likely to take time because we'll need to agree
> and
> >    implement the process to support an election.
> > 3. Seed the board with those who have the best technical standing in
> >    the community. We could determine the initial composition by
> consensus.
> >    I think the prime candidates for an Architecture Board will be
> obvious
> >    to most of us.
> >
> > My preference would be for option 3. Any other opinions or comments on
> this proposal?
> 
> I like co-option in this case, but I would like to have some kind of
> criteria for how board removals can happen - that might be a detail, but
> it's important that the architect board continue to represent the most
> influential participants in the community, and I could imagine a
> scenario where someone named to the board moves to a different position
> and over the course of 6-12 months is less active in the project - would
> they be expected to nominate a successor? Withdraw and alow others to
> nominate? If they don't volunteer to withdraw, what criteria can the
> board use to request that they withdrawal?

That's a good point. I do think the board needs to review its own composition on an annual basis to make sure that existing members still meet the criteria and to identify/co-opt new members. The expectation would be that people who are no longer actively involved would withdraw themselves in good faith, but if that didn't happen then the board would need to propose their removal and vote on it.

> One thing I think is important is that seats are not considered "owned"
> by a company. There isn't a 6WIND seat or an Intel seat - seats are held
> by individuals representing the interests of the technical community,
> not companies invested in the project. In general, though, I think 2
> seats per company may is a good number, I would not want to have even
> the perception of a majority voting block by one company.

Agreed. This is why I strongly prefer option 3 where we pick the best individuals based on technical merit rather than option 1 where companies nominate.

> Overall, thanks Tim! I think this is a really solid proposal.
> 
> 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

Re: [dpdk-dev] Architecture Board Proposal

[Dave Neary]

Hi,

On 10/30/2015 07:01 AM, O'Driscoll, Tim wrote:
>>> Scope
>>> -----
>>> Issues that are within the scope of the Architecture Board include:
>>> - Project scope/charter. What is and isn't within the scope of the
>>>   project? What happens if somebody wants to upstream a new
>>>   library/capability and it's not clear whether it fits within DPDK or
>>>   not? As a random example, if somebody wanted to upstream a DPDK-
>> enabled
>>>   TCP/IP stack to dpdk.org, should that be accepted or rejected?
>>
>> I agree with Thomas here that this seems like it would be a separate
>> project under dpdk.org, rather than part of DPDK - I think it's OK for
>> the Architecture Board to own the scope of "projects on dpdk.org" rather
>> than just DPDK.
> 
> I think there are two questions here. The first is one that Thomas raised and you've also touched on: Is the scope of the Architecture Board just DPDK (i.e. everything in http://dpdk.org/browse/dpdk/), or is it everything hosted on dpdk.org (list at: http://dpdk.org/browse/). My original intent was just DPDK, but I'm fine with either option.
> 
> The second question is who decides whether something is within the scope of DPDK or not? A TCP/IP stack was just an example. If I were to submit patches for a DPDK-accelerated IPsec library (librte_ipsec), who would decide whether that's OK or if it needs to reside somewhere else outside of the DPDK? I think that managing the scope of the project should be one of the roles of the Architecture Board.

The issue I see is that if we agree that the architecture board's scope
is limited to DPDK only, and the architecture board owns the scope of
DPDK, that we still have the open question of which projects are
appropriate to be housed under dpdk.org

There was a general agreement in Dublin that DPDK related projects and
applications could live in dpdk.org, but we didn't really touch on the
process or requirements for adding new projects. I think it's
appropriate for the architecture board to own those too.

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

Re: [dpdk-dev] Architecture Board Proposal

[O'Driscoll, Tim]

> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Dave Neary
> Sent: Friday, October 30, 2015 1:11 PM
> To: O'Driscoll, Tim; dev@dpdk.org
> Subject: Re: [dpdk-dev] Architecture Board Proposal
> 
> Hi,
> 
> On 10/30/2015 07:01 AM, O'Driscoll, Tim wrote:
> >>> Scope
> >>> -----
> >>> Issues that are within the scope of the Architecture Board include:
> >>> - Project scope/charter. What is and isn't within the scope of the
> >>>   project? What happens if somebody wants to upstream a new
> >>>   library/capability and it's not clear whether it fits within DPDK
> or
> >>>   not? As a random example, if somebody wanted to upstream a DPDK-
> >> enabled
> >>>   TCP/IP stack to dpdk.org, should that be accepted or rejected?
> >>
> >> I agree with Thomas here that this seems like it would be a separate
> >> project under dpdk.org, rather than part of DPDK - I think it's OK
> for
> >> the Architecture Board to own the scope of "projects on dpdk.org"
> rather
> >> than just DPDK.
> >
> > I think there are two questions here. The first is one that Thomas
> raised and you've also touched on: Is the scope of the Architecture
> Board just DPDK (i.e. everything in http://dpdk.org/browse/dpdk/), or is
> it everything hosted on dpdk.org (list at: http://dpdk.org/browse/). My
> original intent was just DPDK, but I'm fine with either option.
> >
> > The second question is who decides whether something is within the
> scope of DPDK or not? A TCP/IP stack was just an example. If I were to
> submit patches for a DPDK-accelerated IPsec library (librte_ipsec), who
> would decide whether that's OK or if it needs to reside somewhere else
> outside of the DPDK? I think that managing the scope of the project
> should be one of the roles of the Architecture Board.
> 
> The issue I see is that if we agree that the architecture board's scope
> is limited to DPDK only, and the architecture board owns the scope of
> DPDK, that we still have the open question of which projects are
> appropriate to be housed under dpdk.org
> 
> There was a general agreement in Dublin that DPDK related projects and
> applications could live in dpdk.org, but we didn't really touch on the
> process or requirements for adding new projects. I think it's
> appropriate for the architecture board to own those too.
> 

That makes sense. So maybe what we're converging on is the following:
- The scope of the Architecture Board covers all projects hosted on dpdk.org.
- The Architecture Board will approve new projects to be hosted on dpdk.org.
- If it's not clear whether a new piece of functionality resides within one of the existing projects on dpdk.org or needs a new project of its own, the Architecture Board will decide.

Is that in line with your thoughts on this?


Tim

Re: [dpdk-dev] Architecture Board Proposal

[Thomas Monjalon]

2015-10-30 13:23, O'Driscoll, Tim:
> From: Dave Neary
> > There was a general agreement in Dublin that DPDK related projects and
> > applications could live in dpdk.org, but we didn't really touch on the
> > process or requirements for adding new projects. I think it's
> > appropriate for the architecture board to own those too.
> 
> That makes sense. So maybe what we're converging on is the following:
> - The scope of the Architecture Board covers all projects hosted on dpdk.org.
> - The Architecture Board will approve new projects to be hosted on dpdk.org.
> - If it's not clear whether a new piece of functionality resides within one of the existing projects on dpdk.org or needs a new project of its own, the Architecture Board will decide.
> 
> Is that in line with your thoughts on this?

Do we need a board to define the scope of this board? ;)

The only reason I see to reject a project, would be to consider that the
project is not related to DPDK enough. I think it will be an obvious decision.
So it shouldn't be a high responsibility nor a high workload to add to this
board.
But clearly, the hosted projects (except DPDK itself) should not be impacted
by the DPDK board.

Re: [dpdk-dev] Architecture Board Proposal

[Dave Neary]

On 10/30/2015 09:25 AM, Thomas Monjalon wrote:
> 2015-10-30 13:23, O'Driscoll, Tim:
>> From: Dave Neary
>>> There was a general agreement in Dublin that DPDK related projects and
>>> applications could live in dpdk.org, but we didn't really touch on the
>>> process or requirements for adding new projects. I think it's
>>> appropriate for the architecture board to own those too.
>>
>> That makes sense. So maybe what we're converging on is the following:
>> - The scope of the Architecture Board covers all projects hosted on dpdk.org.
>> - The Architecture Board will approve new projects to be hosted on dpdk.org.
>> - If it's not clear whether a new piece of functionality resides within one of the existing projects on dpdk.org or needs a new project of its own, the Architecture Board will decide.
>>
>> Is that in line with your thoughts on this?
> 
> Do we need a board to define the scope of this board? ;)

:-)

> The only reason I see to reject a project, would be to consider that the
> project is not related to DPDK enough. I think it will be an obvious decision.
> So it shouldn't be a high responsibility nor a high workload to add to this
> board.
> But clearly, the hosted projects (except DPDK itself) should not be impacted
> by the DPDK board.

You have a good point - and in the spirit of "the board exists only to
make decisions that aren't converging in the community", maybe we don't
need more.

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

Re: [dpdk-dev] Architecture Board Proposal

[Matthew Hall]

On Fri, Oct 30, 2015 at 01:23:52PM +0000, O'Driscoll, Tim wrote:
> That makes sense. So maybe what we're converging on is the following:
> - The scope of the Architecture Board covers all projects hosted on dpdk.org.
> - The Architecture Board will approve new projects to be hosted on dpdk.org.
> - If it's not clear whether a new piece of functionality resides within one of the existing projects on dpdk.org or needs a new project of its own, the Architecture Board will decide.
> 
> Is that in line with your thoughts on this?
> Tim

I think a small adjustment to this part could be valuable.

DPDK itself is kind of an embedded C programmer thing. So this is likely who 
will appear in the Arch Board.

So is the TCP / IP stack if one comes out.

But librte_ipsec and some other stuff would be security related.

Something like Apache's ability to have a loosely affiliated / Incubator / 
Partner project controlled by its original maintainers, and somehow labeled as 
a friend of DPDK but managed by its original maintainers could be useful.

To set expectations it would be labeled on the page for that sort of project 
that it is included because the DPDK Team felt it is useful, but it does not 
necessarily follow the standard guarantees of the more official entrants.

Matthew.

Re: [dpdk-dev] Architecture Board Proposal

[Stephen Hemminger]

On Thu, 29 Oct 2015 15:21:48 +0000
"O'Driscoll, Tim" <tim.odriscoll@intel.com> wrote:

> At the recent DPDK Userspace event we agreed that we need a body to make technical decisions for the project. In Dublin we referred to this as a Technical Steering Committee, but that term is often used on other projects to describe a body with a more political charter.  To avoid confusion, and clarify that the scope of this body for DPDK is purely technical, I propose calling it the DPDK Architecture Board.

Great idea. I like good names.

Re: [dpdk-dev] Architecture Board Proposal

[O'Driscoll, Tim]

In order to progress this, I'd like to summarise what's been discussed on the mailing list so far (both in this thread and in the one Dave Neary started on governance proposals from the Userspace event) and give a final chance to people to provide any additional input. The main things that came up in the discussion were:

- We need to agree whether the scope of the board is just DPDK (http://dpdk.org/browse/dpdk/) or if it's all projects hosted on dpdk.org (http://dpdk.org/browse/). The consensus seemed to be just DPDK.

- It was reiterated that the board should only make decisions when a consensus isn't reached on the mailing this. This should not happen often, so the workload should be light.

- Membership needs to be based on contributions. There were requests for ARM SoC representation on the board, but most people felt that contributions should come from the SoC vendors first. Now that we're seeing more ARM-related contributions this may be less of an issue as we would have at least one ARM SoC rep to consider for membership based on recent contributions.

We do still have the difficult topic of membership to agree on. For now though, I want to make sure that we have agreement on the scope and purpose of the board. We can address membership once we've finalized that.


Tim

> -----Original Message-----
> From: O'Driscoll, Tim
> Sent: Thursday, October 29, 2015 3:22 PM
> To: dev@dpdk.org
> Subject: Architecture Board Proposal
> 
> At the recent DPDK Userspace event we agreed that we need a body to make
> technical decisions for the project. In Dublin we referred to this as a
> Technical Steering Committee, but that term is often used on other
> projects to describe a body with a more political charter.  To avoid
> confusion, and clarify that the scope of this body for DPDK is purely
> technical, I propose calling it the DPDK Architecture Board.
> 
> Justification
> -------------
> The role of the Maintainer is to be the gate-keeper for the project, and
> to only accept contributions that are properly implemented, properly
> reviewed, and consistent with the agreed project scope/charter. However,
> it shouldn't be the responsibility of the Maintainer to be the final
> decision maker (after community discussion) on issues affecting the
> strategic direction of the project. Instead, this should be determined
> by a higher level body that's representative of the DPDK community.
> 
> Having an Architecture Board will help to provide a clear
> direction/strategy for the project, and help to resolve complex issues
> which don't reach a consensus on the mailing list in a timely manner.
> 
> Scope
> -----
> Issues that are within the scope of the Architecture Board include:
> - Project scope/charter. What is and isn't within the scope of the
> project? What happens if somebody wants to upstream a new
> library/capability and it's not clear whether it fits within DPDK or
> not? As a random example, if somebody wanted to upstream a DPDK-enabled
> TCP/IP stack to dpdk.org, should that be accepted or rejected?
> - Performance vs functionality considerations. If we need to make a
> change and there's an unavoidable performance impact to doing so (maybe
> something like extending the mbuf again), does that change get accepted
> or not? In most cases you can probably work around situations like this
> by making them optional, but that might not always be possible. If it's
> not, who decides whether performance or functionality is more important?
> - Replacing existing functionality versus adding new alternatives. If
> there's a new implementation of an existing DPDK capability that
> performs better in some use cases but worse in others, does that get
> accepted and replace the existing implementation, does it get accepted
> as an alternative, or does it get rejected?
> - Unresolved issues. Provide a decision on issues that don't reach a
> consensus on the mailing list in a timely manner.
> 
> Composition
> -----------
> For composition of the Architecture Board, I'd propose the following:
> - It needs to be kept to a manageable size. I propose limiting it to 5
> initially (it should be an odd number to minimize deadlocks).
> - Membership should be based on: number and quality of contributions,
> technical standing in the community, breadth of involvement (involvement
> in many areas, not just a single part of DPDK).
> - No single company/organization can have more than 2 members.
> - The Architecture Board will elect its own chair, who will have the
> deciding vote in the event of a deadlock.
> - The board will review its own composition and co-opt/approve any new
> members on an annual basis.
> 
> There are three main options for determining who is on the board:
> 1. Nomination of representatives by contributing companies. We could
> allocate a number of positions on the board based on the contributions
> from each company and then allow those companies to nominate their
> representatives. The downsides are that many companies contribute but
> not all can be represented on the board so we'd need a way to decide
> which companies get a seat and which don't, and that this focuses the
> discussion on company contributions rather than individuals with the
> best technical standing
> 2. Election of representatives. We could poll for candidates and then
> vote. This is likely to take time because we'll need to agree and
> implement the process to support an election.
> 3. Seed the board with those who have the best technical standing in the
> community. We could determine the initial composition by consensus. I
> think the prime candidates for an Architecture Board will be obvious to
> most of us.
> 
> My preference would be for option 3. Any other opinions or comments on
> this proposal?
> 
> 
> Tim

Re: [dpdk-dev] Architecture Board Proposal

[O'Driscoll, Tim]

Since we have agreement on the purpose and scope of the board, I'd like to make a proposal on the composition. I think the following people all have a strong history of contributions and technical credibility within the community, and represent a broad range of perspectives on DPDK: Stephen Hemminger, Thomas Monjalon, Olivier Matz, Panu Matilainen, Jerin Jacob, Bruce Richardson, Konstantin Ananyev.

I'd propose that this group have an initial meeting early in the new year. A good topic for a first meeting would be to clarify the scope of DPDK. We discussed this at the Userspace event (including questions such as whether an IPsec sample application is or is not within DPDK scope), and Venky agreed to draft an initial proposal, but due to other commitments he hasn't had time to do this yet. If Venky does get time to do this then his draft can be an input to the board for discussion/approval, otherwise I think the board members should just determine and document the scope themselves.

If anybody has comments on this or alternative proposals, please feel free to air them on the mailing list. We can also add this to the agenda for our community call on Wednesday and hopefully finalise it then.


Tim

> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of O'Driscoll, Tim
> Sent: Wednesday, November 18, 2015 5:55 PM
> To: 'dev@dpdk.org'
> Subject: Re: [dpdk-dev] Architecture Board Proposal
> 
> In order to progress this, I'd like to summarise what's been discussed
> on the mailing list so far (both in this thread and in the one Dave
> Neary started on governance proposals from the Userspace event) and give
> a final chance to people to provide any additional input. The main
> things that came up in the discussion were:
> 
> - We need to agree whether the scope of the board is just DPDK
> (http://dpdk.org/browse/dpdk/) or if it's all projects hosted on
> dpdk.org (http://dpdk.org/browse/). The consensus seemed to be just
> DPDK.
> 
> - It was reiterated that the board should only make decisions when a
> consensus isn't reached on the mailing this. This should not happen
> often, so the workload should be light.
> 
> - Membership needs to be based on contributions. There were requests for
> ARM SoC representation on the board, but most people felt that
> contributions should come from the SoC vendors first. Now that we're
> seeing more ARM-related contributions this may be less of an issue as we
> would have at least one ARM SoC rep to consider for membership based on
> recent contributions.
> 
> We do still have the difficult topic of membership to agree on. For now
> though, I want to make sure that we have agreement on the scope and
> purpose of the board. We can address membership once we've finalized
> that.
> 
> 
> Tim
> 
> > -----Original Message-----
> > From: O'Driscoll, Tim
> > Sent: Thursday, October 29, 2015 3:22 PM
> > To: dev@dpdk.org
> > Subject: Architecture Board Proposal
> >
> > At the recent DPDK Userspace event we agreed that we need a body to
> make
> > technical decisions for the project. In Dublin we referred to this as
> a
> > Technical Steering Committee, but that term is often used on other
> > projects to describe a body with a more political charter.  To avoid
> > confusion, and clarify that the scope of this body for DPDK is purely
> > technical, I propose calling it the DPDK Architecture Board.
> >
> > Justification
> > -------------
> > The role of the Maintainer is to be the gate-keeper for the project,
> and
> > to only accept contributions that are properly implemented, properly
> > reviewed, and consistent with the agreed project scope/charter.
> However,
> > it shouldn't be the responsibility of the Maintainer to be the final
> > decision maker (after community discussion) on issues affecting the
> > strategic direction of the project. Instead, this should be determined
> > by a higher level body that's representative of the DPDK community.
> >
> > Having an Architecture Board will help to provide a clear
> > direction/strategy for the project, and help to resolve complex issues
> > which don't reach a consensus on the mailing list in a timely manner.
> >
> > Scope
> > -----
> > Issues that are within the scope of the Architecture Board include:
> > - Project scope/charter. What is and isn't within the scope of the
> > project? What happens if somebody wants to upstream a new
> > library/capability and it's not clear whether it fits within DPDK or
> > not? As a random example, if somebody wanted to upstream a DPDK-
> enabled
> > TCP/IP stack to dpdk.org, should that be accepted or rejected?
> > - Performance vs functionality considerations. If we need to make a
> > change and there's an unavoidable performance impact to doing so
> (maybe
> > something like extending the mbuf again), does that change get
> accepted
> > or not? In most cases you can probably work around situations like
> this
> > by making them optional, but that might not always be possible. If
> it's
> > not, who decides whether performance or functionality is more
> important?
> > - Replacing existing functionality versus adding new alternatives. If
> > there's a new implementation of an existing DPDK capability that
> > performs better in some use cases but worse in others, does that get
> > accepted and replace the existing implementation, does it get accepted
> > as an alternative, or does it get rejected?
> > - Unresolved issues. Provide a decision on issues that don't reach a
> > consensus on the mailing list in a timely manner.
> >
> > Composition
> > -----------
> > For composition of the Architecture Board, I'd propose the following:
> > - It needs to be kept to a manageable size. I propose limiting it to 5
> > initially (it should be an odd number to minimize deadlocks).
> > - Membership should be based on: number and quality of contributions,
> > technical standing in the community, breadth of involvement
> (involvement
> > in many areas, not just a single part of DPDK).
> > - No single company/organization can have more than 2 members.
> > - The Architecture Board will elect its own chair, who will have the
> > deciding vote in the event of a deadlock.
> > - The board will review its own composition and co-opt/approve any new
> > members on an annual basis.
> >
> > There are three main options for determining who is on the board:
> > 1. Nomination of representatives by contributing companies. We could
> > allocate a number of positions on the board based on the contributions
> > from each company and then allow those companies to nominate their
> > representatives. The downsides are that many companies contribute but
> > not all can be represented on the board so we'd need a way to decide
> > which companies get a seat and which don't, and that this focuses the
> > discussion on company contributions rather than individuals with the
> > best technical standing
> > 2. Election of representatives. We could poll for candidates and then
> > vote. This is likely to take time because we'll need to agree and
> > implement the process to support an election.
> > 3. Seed the board with those who have the best technical standing in
> the
> > community. We could determine the initial composition by consensus. I
> > think the prime candidates for an Architecture Board will be obvious
> to
> > most of us.
> >
> > My preference would be for option 3. Any other opinions or comments on
> > this proposal?
> >
> >
> > Tim