DPDK community structure changes
 help / color / mirror / Atom feed
From: "O'Driscoll, Tim" <tim.odriscoll@intel.com>
To: "O'Driscoll, Tim" <tim.odriscoll@intel.com>,
	Thomas Monjalon <thomas.monjalon@6wind.com>,
	"moving@dpdk.org" <moving@dpdk.org>
Subject: Re: [dpdk-moving] description of technical governance
Date: Fri, 28 Oct 2016 09:13:51 +0000	[thread overview]
Message-ID: <26FA93C7ED1EAA44AB77D62FBE1D27BA676091C7@IRSMSX108.ger.corp.intel.com> (raw)
In-Reply-To: <26FA93C7ED1EAA44AB77D62FBE1D27BA67607DDE@IRSMSX108.ger.corp.intel.com>

> -----Original Message-----
> From: moving [mailto:moving-bounces@dpdk.org] On Behalf Of O'Driscoll,
> Tim
> Sent: Wednesday, October 26, 2016 11:22 AM
> To: Thomas Monjalon <thomas.monjalon@6wind.com>; moving@dpdk.org
> Subject: Re: [dpdk-moving] description of technical governance
> > -----Original Message-----
> > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> > Sent: Tuesday, October 25, 2016 3:00 PM
> > To: moving@dpdk.org
> > Cc: O'Driscoll, Tim <tim.odriscoll@intel.com>
> > Subject: Re: [dpdk-moving] description of technical governance
> >
> > 2016-10-25 11:27, O'Driscoll, Tim:
> > > We also have a gap in terms of documenting technical governance.
> > > Even ignoring the move to LF, Matt in particular was looking for
> > > more clarity on this.
> > > Thomas: would you be willing to create and post a proposal on this?
> >
> > The technical governance is consensus-based.
> > The board was built in case a consensus is not found.
> >
> > There are several projects with their own git trees.
> > DPDK and the web site are two of them.
> >
> > The DPDK project is organized around some git subtrees
> > and the mainline gathers every contributions accepted in the subtrees.
> > The component maintainers are quality responsibles for the code and
> > the git history. They coordinate how improvements and fixes are done.
> > The git tree committers are responsibles of the pace, giving time for
> > reviews and tests while releasing in time. They also do the last
> checks
> > or call for help when there is no progress on a patch.
> >
> > Is it the kind of information you are looking for?
> > I think the technical governance must be described on the web site
> > in the "development" page.
> > It is already partly described but it may requires more details and
> > updates.
> Yes, it's the additional detail that I was asking about. If you look at
> what we have at the moment (http://dpdk.org/dev), it's quite brief.
> Other projects typically have more detail, for example:
> - FD.io Technical Community Charter: https://fd.io/governance/technical-
> community-charter
> - OvS technical governance including committer responsibilities and
> process for adding and removing committers:
> http://openvswitch.github.io/contributors/
> - ODL TSC Charter: https://www.opendaylight.org/tsc-charter
> We don't necessarily need as much detail as they have, but I think we do
> need a bit more than we have at the moment. From a brief discussion with
> Mike Dolan during our previous engagement with the LF earlier in the
> year, the LF would simply be looking for DPDK technical governance to be
> properly documented, and for it to be meritocratic (e.g. committers
> chosen based on history of contributions rather than the company they
> work for).
> Matt also had some thoughts during our discussion in Dublin on things
> he'd like to see added to the technical governance. Perhaps he can
> comment further on what he'd like to see.
> In terms of where this is documented, I don't think that matters, and
> adding some additional detail to the existing Development page seems
> like a good solution to me.

I haven't seen anybody else comment on aspects of the technical governance that should be clarified, so here are a few comments/questions from me that might help to prompt some discussion.

We have a few different types of maintainers: 1) those responsible for reviewing changes in individual libraries who are identified in the MAINTAINERS file; 2) sub-tree maintainers who submit pull requests to the main tree; 3) stable release maintainer; 4) main tree maintainer; 5) maintainers for other projects hosted on dpdk.org (pktgen, spp etc.). We should document the responsibilities of each of these, and the process for adding and removing them.

At the moment, the MAINTAINERS file doesn't identify the sub-tree maintainers or the stable release maintainer. I think they should be included.

At the moment, other projects hosted on dpdk.org (pktgen, spp etc.) don't have a MAINTAINERS file. I think this should be mandatory for all sub-projects within DPDK.

Should every repo have more than one person with commit rights so that we're not dependent on a single person? They would obviously have to coordinate on who does what, which could involve sharing the workload or operating on an active/backup basis.

We should document how members of the Tech Board get added/removed. We should also clarify the scope. Is the scope of the Tech Board just DPDK itself (http://dpdk.org/browse/dpdk/tree/), or does it also cover the other projects hosted on dpdk.org (http://dpdk.org/browse/)? If it's just DPDK, then who provides the technical oversight for the other projects? My preference would be for the existing board to cover all sub-projects.

We should document the process for adding a new sub-project like pktgen or SPP. At the moment I think it's proposed on the dev mailing list and added if there's a consensus. Should it be mandatory that new project proposals are reviewed and approved by the Tech Board, to make sure there's consistency and nothing gets missed in a flood of email?

  reply	other threads:[~2016-10-28  9:13 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-25  8:58 [dpdk-moving] [Topics] Francois Ozog
2016-10-25 11:27 ` O'Driscoll, Tim
2016-10-25 14:00   ` [dpdk-moving] description of technical governance Thomas Monjalon
2016-10-26 10:21     ` O'Driscoll, Tim
2016-10-28  9:13       ` O'Driscoll, Tim [this message]
2016-10-28 16:52         ` Matt Spencer
2016-10-28 19:22           ` Thomas Monjalon
2016-10-28 22:54             ` Vincent Jardin
2016-10-31 15:20               ` Matt Spencer
2016-10-31 16:07                 ` Michael Dolan
2016-10-31 16:18                   ` Matt Spencer
2016-10-31 16:33                     ` Michael Dolan
2016-10-31 16:43                       ` Matt Spencer
2016-10-31 16:52                         ` Michael Dolan
2016-10-31 16:56                           ` O'Driscoll, Tim
2016-10-31 16:58                             ` Michael Dolan
2016-10-31 18:31                             ` Jan Blunck
2016-10-31 19:41                               ` Vincent JARDIN
     [not found]                   ` <DB5PR04MB1605482F1C67F9B797EB9AE289A60@DB5PR04MB1605.eurprd04.prod.outlook.com>
2016-11-08  8:11                     ` Jaswinder Singh
2016-11-08  9:37                       ` O'Driscoll, Tim
2016-12-20 14:41       ` Thomas Monjalon
2016-10-25 14:55 ` [dpdk-moving] [Topics] Dave Neary
2016-10-26 12:47 ` Dave Neary
2016-10-26 15:00   ` Francois Ozog

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=26FA93C7ED1EAA44AB77D62FBE1D27BA676091C7@IRSMSX108.ger.corp.intel.com \
    --to=tim.odriscoll@intel.com \
    --cc=moving@dpdk.org \
    --cc=thomas.monjalon@6wind.com \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).