From: "O'Driscoll, Tim" <firstname.lastname@example.org> To: "O'Driscoll, Tim" <email@example.com>, Thomas Monjalon <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org> Subject: Re: [dpdk-moving] description of technical governance Date: Fri, 28 Oct 2016 09:13:51 +0000 Message-ID: <26FA93C7ED1EAA44AB77D62FBE1D27BA676091C7@IRSMSX108.ger.corp.intel.com> (raw) In-Reply-To: <26FA93C7ED1EAA44AB77D62FBE1D27BA67607DDE@IRSMSX108.ger.corp.intel.com> > -----Original Message----- > From: moving [mailto:email@example.com] On Behalf Of O'Driscoll, > Tim > Sent: Wednesday, October 26, 2016 11:22 AM > To: Thomas Monjalon <firstname.lastname@example.org>; email@example.com > Subject: Re: [dpdk-moving] description of technical governance > > > > -----Original Message----- > > From: Thomas Monjalon [mailto:firstname.lastname@example.org] > > Sent: Tuesday, October 25, 2016 3:00 PM > > To: email@example.com > > Cc: O'Driscoll, Tim <firstname.lastname@example.org> > > 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?
next prev parent reply index 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 publically 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: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * 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 \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
DPDK community structure changes Archives are clonable: git clone --mirror http://inbox.dpdk.org/moving/0 moving/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 moving moving/ http://inbox.dpdk.org/moving \ firstname.lastname@example.org public-inbox-index moving Newsgroup available over NNTP: nntp://inbox.dpdk.org/inbox.dpdk.moving AGPL code for this site: git clone https://public-inbox.org/ public-inbox