Re: [dpdk-dev] Architecture Board Proposal

["O'Driscoll, Tim" <tim.odriscoll@intel.com>]

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