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 (see +2).

"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 there is consensus 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. Ownership can be revoked.

If your codebase/extension/tool isn't in Git yet, use this form to create a new Gerrit project: Gerrit/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.)

= To make a new Project Owner =


 * Create a group
 * Give it ownership of a Project
 * Anyone in that group can now add more owners via https://gerrit.wikimedia.org/r/#/admin/projects/ (but we prefer to keep that process public via Git/Gerrit project ownership)
 * Click Groups
 * As long as you are a member of the group, you can edit the group
 * example: https://gerrit.wikimedia.org/r/#/admin/projects/mediawiki,access

MediaWiki core
We are maintaining a "WMF" branch of mediawiki/core.git. We use submodules for deployed extensions, and can pull from master as regularly as we want for deployments. At the start of the migration to git, the project owners of this branch are going to be the people who have the ability to deploy code to Wikimedia Foundation servers. gerrit will offer a list of the "Gerrit project owners" for this branch, except for the Operations (system administration) group, which is an LDAP group. Every member of the Wikimedia Foundation operations team will also be in the Gerrit project owners group insofar as they have code review rights globally, but in practice will rarely review code. We may add some existing code reviewers to this Gerrit project owners group. Details; you can request to be added.

At the start of the migration, this list of Gerrit project owners for the WMF branch is also the list of Gerrit project owners for the master branch. However, eventually, we will add to the list of Gerrit project owners for master, using as criteria the number and quality of developers' previous commits and code reviews.

Details and procedure for adding and removing people from the Gerrit project owners groups.

MediaWiki has release branches (19 so far) for core, and master (the default branch previously known as "trunk" in SVN). Example: ("heads" is gitweb's term for branches). MediaWiki core and WMF-deployed extensions will be tagging releases just as we did in Subversion, except they'll be Git tags instead of SVN tags. Any other extension will make its own decisions regarding tagging.

MediaWiki extensions that the Wikimedia Foundation deploys
Same procedure as for MediaWiki core, and the same Gerrit project owner groups.

Other MediaWiki extensions
Every extension author can choose between two choices here for non-master branches: the gated-trunk/push-for-review model, and a straight push model. For any given extension, we will honor the wishes of the person/s listed as the main author on the extension's mediawiki.org page.


 * The gated-trunk/push-for-review is the model that we are using for MediaWiki core, as mentioned above. A Gerrit project owners group (plus the above mentioned Gerrit project owners group for MediaWiki core) will be able to "+2" (approve and merge) changes to their extensions.  The extension author(s) will be able to define a Gerrit project owners group and add others to it.


 * The straight push model is similar to how we did things in Subversion; anyone can suggest a change and submit a pull request, and it will automatically be approved and merged.

Master branches must go through Gerrit and cannot be straight push. This is necessary to facilitate a number of Gerrit features, including replication, updating of the extension meta-repository, and ability of Translatewiki to provide localization updates.

We could define groups to make this easier for batches of extensions (e.g. SMW developers). Chad will offer your community a choice. Please let Chad what you would like via Git/New repositories.

Other Gerrit projects
Same procedure as for "other MediaWiki extensions" above.

= 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)
 * Jeroen, I set up the relevant groups for Validator and I think I set them up how you'd like. Is that right? Tried to ping you in IRC, haven't gotten a response -- let me know if that's the right model and I'll do the rest of the groups. Sharihareswara (WMF) (talk) 23:52, 9 November 2012 (UTC)

Thanks for setting that group up Sumanah. You made the group owner of itself. If this is an acceptable thing to do, then perhaps there is no point in having such extra groups, as you could just make the extension-name groups own themselves, solving the issue with less work and clutter. Think chad had some reason to not do this though. --Jeroen De Dauw (talk) 20:15, 12 November 2012 (UTC)
 * Yeah, the reason was that it made it impossible for people in the "Project and Group Creators" group to manage any group member. This is being solved in the near future. ^demon[omg plz] 15:58, 21 February 2013 (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)


 * Yes ^demon (talk) 18:21, 18 October 2012 (UTC)

This does not appear to work - can you check the settings to see if they are correct? --Jeroen De Dauw (talk) 18:53, 21 October 2012 (UTC)

Creation of a repository for my extension, PreloadContent
I am developing a new extension, Extension:PreloadContent and I want to have my code hosted on MediaWiki repos. --Milad Naseri (talk) 11:09, 3 December 2012 (UTC)
 * Can you please describe this extension in greater detail, or provide a code sample? --ori (talk) 00:40, 28 December 2012 (UTC)


 * I think you're looking for Git/New_repositories. Bawolff (talk) 15:58, 21 February 2013 (UTC)

extension-MediaWikiAuth
As the original creator of the extension, I (GreenReaper) request project ownership for extension-MediaWikiAuth. GreenReaper (talk) 04:35, 20 March 2013 (UTC)
 * Done, I think. Hopefully you'll have more of an idea what you're doing than I do. *shifty eyes* -— Isarra ༆ 20:15, 21 March 2013 (UTC)

Matma Rex (Bartosz Dziewoński) for mediawiki/core
I'm a pretty new developer (first gerrit patch merged in August last year), but I'm a (Polish) Wikipedia editor since 2007 and active gadget&template writer and an all-around tech guy since about 2009.

My forte is frontend (CSS and JS), and this is reflected in my commits and reviews. We have a huge backlog in this area, and I hope I'll be able to help.

Changes I was a reviewer of &bull; Bugzilla activity

I'm aware I have little experience compared to most of other core maintainers, but I thought, why not? Both positive and negative comments welcome :) Matma Rex (talk) 00:24, 24 March 2013 (UTC)
 * Just a note from Sumana here -- I'm notifying our community now and would like to wait a week before checking for consensus, just to give some folks time to look at Matma Rex's commits and reviews. (In my experience it usually takes several days anyway for people to think and put down their thoughts; I just figured I'd actually note it here so people have some kind of expectation regarding timeframe.)  Thanks for your work, Bartosz. Sharihareswara (WMF) (talk) 21:56, 25 March 2013 (UTC)
 * Weak +1. Weak because I've had limited opportunities to interact with him, +1 because they've always been very positive. Yuvipanda (talk) 22:00, 25 March 2013 (UTC)
 * I was actually thinking about nominating you. Bawolff (talk) 22:03, 25 March 2013 (UTC)
 * Useful insights and active in helping other contributors by giving a first review (thus saving work). But in my opinion still too inexperienced to be reviewing with CR+2 for merge. Krinkle (talk) 23:29, 25 March 2013 (UTC)
 * : Ideally nobody should be merging patches without a second opinion. I trust Matma Rex to know what and what not to merge. --MZMcBride (talk) 02:50, 26 March 2013 (UTC)
 * : I think MatmaRex will know how to use it responsibly. -- Krenair (talk &bull; contribs) 16:39, 26 March 2013 (UTC)
 * : If bunnies are allowed, why not him? --Nikerabbit (talk) 19:34, 26 March 2013 (UTC)
 * per MZMcBride --Waldir (talk) 19:54, 26 March 2013 (UTC)
 * The skill and commitment is there, but his manner of expressing criticism is scathing and combative and filled with contempt for anything he doesn't like. Maybe in the future, but not now. --Ori.livneh (talk) 04:29, 28 March 2013 (UTC)
 * I could say the same of a number of people with +2 access, if you know what I mean. I share your concern, but I don't think it should preclude forward progress in development. If you think the skill and commitment are there and there are reasonable safeguards in place, it seems like it would be awfully difficult to oppose. For me, the benefit outweighs the (potential) cost. --MZMcBride (talk) 05:13, 28 March 2013 (UTC)
 * No, I don't know what you mean. If you see a current core committer behaving in a combative way, please call it out. --Ori.livneh (talk) 09:09, 28 March 2013 (UTC)
 * for what it's worth I also support and ask for more civility. OrenB talk contib 04:38, 28 March 2013 (UTC)
 * - per MZMcBride. MatmaRex has also demonstrated an unusual impartiality, looking at the code itself and giving feedback based on what it is there rather than judging based on who submitted it - a valuable trait in a friend if you need someone to review your code, and, I would hope, a valuable trait in general when considering someone for core. -— Isarra ༆ 18:48, 28 March 2013 (UTC)