Gerrit/Project ownership

__NEWSECTIONLINK__ This page queues individuals' requests to be added to the Gerrit project owner groups for specific Gerrit projects (each of which corresponds to a Git repository). A Gerrit project owner has the power to approve changes for merger into that Gerrit project's master branch, and to veto changes.

"When/how we'll add, remove people from Gerrit project owner groups" has procedural details. Sumana Harihareswara will regularly look at new requests for project owner membership and contact the existing project owners. If the candidate gets zero vetoes and at least one yes from the existing project owners, then we'll approve the candidate. For each new candidate the process shouldn't take more than two weeks, and usually much less.

If your codebase/extension/tool isn't in Gerrit yet, use this form: Git/New repositories

To see the current list of Gerrit project owners for a specific Gerrit project, visit https://gerrit.wikimedia.org/r/#/admin/groups/.

Ownership structure
Example: an extension is named foo.
 * The Gerrit group "foo" should usually be an owner of the Gerrit project "foo."
 * Sometimes, meta-groups will be included in the group. This is for people have ownership over multiple extensions, so you can add/remove members in one place.
 * Rights to the group may be inherited from other groups (Look for a "Rights Inherit From:" in the project access.)

Specific example: the project "mediawiki/extensions/DonationInterface" is owned by group "extension-DonationInterface." This group includes the meta-group "fundraising." Also members of the group "mediawiki" has ownership via "Rights Inherit From: "mediawiki/extensions access"

By keeping the naming convention ("extensions/foo" is owned by group "extension-foo"), it'll make the "automatically setup a repo" process much more scriptable when we hit that bridge.

(Note to Gerrit group creators: remember to check the "Make group visible to all registered users." checkbox and leave the group type as "Internal group" and not LDAP.)

= Requests =

[ Add a request]

A bunch of new groups
I'd like to have an $extension-trusted group (initially empty and with no rights assigned) for the following extensions: Validator, Maps, SemanticMaps, Push, LiveTranslate, SubPageList, Spark, IncludeWP, Survey, DidYouKnow, Gitweb (once created), DataValues (once created), Diff, SemanticWatchlist, SemanticImageInput and SemanticBundle.

These groups would be owned by their respective $extension-owner group.

This will allow me to manage my extension myself without posting a request here each time someone should get access :) --Jeroen De Dauw (talk) 19:25, 17 August 2012 (UTC)

Comments

 * Support. --siebrand (talk) 16:06, 21 August 2012 (UTC)
 * Since these are non-deployed extensions, I think this is fine. But I'd like to get input from Chad before we start introducing new group structures. --Catrope (talk) 18:02, 21 August 2012 (UTC)
 * I don't *like* it as proposed since this is very quickly going to explode the number of groups we have. Ideally all extension-$name groups should be owned by an extension-$name-owner (other than deployed exts, perhaps). The reason it's all currently owned by the "Project & Group Creators" was so people could process this page and add new users to their respective groups. What I'd like is either A) A way to manage all groups without giving out admin privs, or B) Multiple owners of groups. The former is probably easier. This all being said, perhaps we can go ahead with this structure for a few non-deployed extensions anyway and see if we really need this page at all for granting access to those. ^demon (talk) 14:05, 22 August 2012 (UTC)
 * Well then I suppose we'd be supportive of adding Jeroen as the owner of all those groups? Also, it seems to me that there are a number of them should be in some metagroup fro SMW. Tychay (talk) 20:56, 5 October 2012 (UTC)
 * Chad, sorry for being obtuse, but when you say "perhaps" is that a go-ahead for me to go ahead and create the "extension-Validator-trusted", "extension-Maps-trusted", etc. Gerrit groups, and when necessary, the "extension-[name]" groups to own the "trusted" groups? Thanks. Sharihareswara (WMF) (talk) 15:44, 8 October 2012 (UTC)

Nischyan branch owner in SemanticMaps
I tried making Nischyan owner of the nischyan branch of SemanticMaps by adding a group he's member of as owner of this branch. I want him to be able to happily merge in stuff without needing approval of someone else. Since this did not work, I tried giving him pretty much all other rights on the branch, but he says he's still not able to approve his own commits. Am I doing something wrong? https://gerrit.wikimedia.org/r/#/admin/projects/mediawiki/extensions/SemanticMaps,access
 * -- Jeroen De Dauw (talk) 15:04, 24 September 2012 (UTC)


 * Reviewing commits (Verified+1, CodeReview+2, Submit) needs to be assigned to the appropriate refs/for/* refspace, not the destination ref. Compare and . ^demon (talk) 19:23, 24 September 2012 (UTC)


 * So it should be refs/for/refs/heads/nischyan? --Jeroen De Dauw (talk) 18:26, 28 September 2012 (UTC)

suggesting thedj for MediaWiki Core
I suggest that TheDJ (Derk-Jan Hartman) be given Gerrit project ownership for the "mediawiki/core" Gerrit project. He's authored many improvements in MediaWiki, in Git and in Subversion, and reviewed as well. Sharihareswara (WMF) (talk) 19:38, 9 October 2012 (UTC)
 * +1, TheDJ is a solid long-time contributor, and we could definitely use another frontend reviewer with approval rights --Catrope (talk) 22:30, 9 October 2012 (UTC)
 * Support. Mind you that "reviewed" is not very accurate. The query result provides "submits to which a user was added as reviewer", which is in no way the same as "has reviewed revision and provided feedback". siebrand (talk) 22:31, 9 October 2012 (UTC)
 * +1 Krinkle (talk) 22:44, 9 October 2012 (UTC)
 * +1 Platonides (talk) 22:57, 9 October 2012 (UTC)
 * +1 I think he would be quite useful to help with core review and approval. Kaldari (talk) 20:58, 10 October 2012 (UTC)
 * , as if more support was needed. ;-) --Eloquence (talk) 22:40, 10 October 2012 (UTC)

Suggesting SPQRobin for MediaWiki core
I suggest that we give SPQRobin (Robin Pepermans) Gerrit project ownership for the "mediawiki/core" Gerrit project. He is currently the maintainer of the Wikimedia Incubator and was a Google Summer of Code student with Wikimedia in 2012. He's authored many MediaWiki changesets in Git and in Subversion, and has reviewed code as well. There are dozens of Gerrit reviews where he +1'd or merged without comment; he commented in at least the following reviews:


 * Sharihareswara (WMF) (talk) 19:33, 10 October 2012 (UTC)

Suggesting yuvipanda for MediaWiki core
I suggest that yuvipanda (Yuvaraj Pandian) get +2 a.k.a. Gerrit project ownership for the "mediawiki/core" Gerrit project. He was a Google Summer of Code student with Wikimedia in 2011 and has been a WMF contractor working on various mobile projects. He authored the ShortURL extension. He's the author of many commits in Subversion, and he has authored and reviewed some MediaWiki changesets in Git. Sharihareswara (WMF) (talk) 22:33, 10 October 2012 (UTC)
 * +1 Arthur Richards (talk) 22:42, 10 October 2012 (UTC)

suggesting Anomie for MediaWiki Core
I suggest that Anomie (Brad Jorsch) be given Gerrit project ownership for the "mediawiki/core" Gerrit project. He has submitted several MediaWiki changesets that were merged in Git. Merged patches by Anomie in Subversion:

Substantive discussion, patches, or review include bugs and patches going back to 2008:

His reviews in Gerrit include:


 * Sharihareswara (WMF) (talk) 00:23, 11 October 2012 (UTC)
 * Anomie has been around for years, so he's very familiar with a couple of obscure things in MW core like the API and the preprocessor. He also knows a lot about JavaScript internals, which few of our +2ers do. He's been more actively eviewing code lately and the reviews I've seen from him were all good ones, so +1 --Catrope (talk) 00:26, 11 October 2012 (UTC)\