Re: [dpdk-dev] Architecture Board Proposal

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

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