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/ .
- 1 Ownership structure
- 2 To make a new Project Owner
- 3 Requests
- 3.1 Umherirrender for +2 for mediawiki/*
- 3.2 +2 for wctaiwan in extensions/MassMessage
- 3.3 +2 for swalling in GettingStarted and GuidedTour
- 3.4 +2 for paladox in extensions/Vector
- 3.5 Replacing mwalker with cscott for the OCG repositories.
- 3.6 Jack Phoenix for +2 in mediawiki/extensions/AJAXPoll
- 3.7 +2 for mwjames on extension/SemanticGlossary
- 3.8 TTO for mediawiki/extensions/PageNotice
Ownership structure[edit | edit source]
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.)
To make a new Project Owner[edit | edit source]
- 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[edit | edit source]
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.
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[edit | edit source]
Same procedure as for MediaWiki core, and the same Gerrit project owner groups.
Other MediaWiki extensions[edit | edit source]
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[edit | edit source]
Same procedure as for "other MediaWiki extensions" above.
Requests[edit | edit source]
Umherirrender for +2 for mediawiki/*[edit | edit source]
Umherirrender seems to be the single most active person in CR other than people with +2. Even without looking at stats, it would be hard to ignore the constant stream of all his helpful merged patches; but Aaron Schulz, Anomie, IAlex, Nikerabbit, Reedy and Siebrand, who take care of merging most of his contributions, are more qualified to speak of them. --Nemo 12:29, 28 July 2014 (UTC)
- Just for information: User:Matma Rex ask me a half year ago, but at that time I did not want that rights. If there is support for my work now, I would. Thanks for trust. Der Umherirrende (talk) 18:55, 28 July 2014 (UTC)
- It's fitting that I should be the first person to Support this then :) Matma Rex (talk) 21:05, 28 July 2014 (UTC)
- Support IAlex (talk) 11:40, 30 July 2014 (UTC)
- Support Legoktm (talk) 17:04, 31 July 2014 (UTC)
- Support I forgot this wasn't the case already. Aaron (talk) 03:32, 1 August 2014 (UTC)
- Support --Krenair (talk • contribs) 02:09, 30 August 2014 (UTC)
- Support Bawolff (talk) 03:48, 30 August 2014 (UTC)
+2 for wctaiwan in extensions/MassMessage[edit | edit source]
wctaiwan recently completed a GSoC project to implement better spamlist support in MassMessage through a contenthandler-based system. He's demonstrated familiarity with the code base, and is pretty good at code review. Additionally, it'll be good to have another maintainer for the extension. Legoktm (talk) 05:25, 19 August 2014 (UTC)
+2 for swalling in GettingStarted and GuidedTour[edit | edit source]
I will be losing my WMF LDAP authorization at the end of the month, since I am moving on to another job. I'd like to retain +2 in two extensions I have helped build while at WMF: GettingStarted and GuidedTour. Thanks, Steven Walling (WMF) • talk 19:17, 15 September 2014 (UTC)
- Support Steven has played a key role in shaping the direction of these extensions. Thus, although he's not primarily a software engineer (his code review feedback is mainly in design, i18n, and from a big-picture product perspective), I support him keeping project ownership for these projects. Mattflaschen (WMF) (talk) 02:57, 16 September 2014 (UTC)
+2 for paladox in extensions/Vector[edit | edit source]
Since vector merged into the core of mediawiki it is no longer used. I would like to take it over and add back CollapsibleNav that was removed in the core of mediawiki earlier this year. Paladox2017 (talk) 11:03, 30 September 2014 (UTC)
- Oppose for 2 reasons: First, I think it would be unnecessarily confusing if an extension that was previously merged with core were to be reused for other purposes. Second, given Paladox's history both on Gerrit and on this wiki, I don't currently have enough confidence in him. Jackmcbarn (talk) 02:39, 5 October 2014 (UTC)
- Oppose per Jack. --Krenair (talk • contribs) 11:35, 5 October 2014 (UTC)
- Oppose after reviewing the gerrit history, and per Jack --Florianschmidtwelzow (talk) 14:07, 5 October 2014 (UTC)
Replacing mwalker with cscott for the OCG repositories.[edit | edit source]
Matt Walker recently left the WMF; I'm maintaining the OCG code now. So this is a request to add
cscott as a project owner for:
Jack Phoenix for +2 in mediawiki/extensions/AJAXPoll[edit | edit source]
+2 for mwjames on extension/SemanticGlossary[edit | edit source]
TTO for mediawiki/extensions/PageNotice[edit | edit source]
The current maintainer of this extension, TBleher, hasn't been active for two years. It would be nice to have +2 rights for this non-WMF-deployed extension, so that I can merge the three patches I have prepared for this extension, and so I can continue to maintain it into the future. This, that and the other (talk) 01:58, 21 November 2014 (UTC)