This should probably be explicit about group membership imported from LDAP groups.

Yeah. Iirc for mediawiki/* the only Gerrit group sync is that wmf has equivalent rights to the mediawiki group. There's also a wmde-mediawiki Gerrit group with similar privs (but it's managed manually, not via LDAP), I think we want to preserve that as a separate list instead of merging it with everyone who's passed the MediaWiki-Gerrit-Group-Requests process.

What other existing Gerrit configuration do we need to be sure to account for?

Merge access to wmf/* branches must be restricted to deployers. Right now we have manual Gerrit group (wmf-deployment) but it'd be really nice if we could sync that automatically from the admin Puppet module.

A smaller group of Maintainers can create repos and sub-groups than the overall set of Developers.

Who would that be? I guess a similar set of people who are currently Gerrit admins or managers?

Who would that be? I guess a similar set of people who are currently Gerrit admins or managers?

I think that's the right idea, although maybe it could differ between for example the top-level /repos/mediawiki and /repos/mediawiki/services. Mainly I think we want to avoid creating any confusion about things that are aimed at production, or cluttering the overall structure too much.

Implied by MediaWiki-Gerrit-Group-Requests is the policy https://www.mediawiki.org/wiki/Gerrit/Privilege_policy . It is a subpage of Gerrit cause that is the application currently implementing it and is tied to how Gerrit works. Nonetheless it is one of our Development guidelines as shown by the navigation box at the bottom of the page.

We have another use case which is fundraising! From the mediawiki/ access we restrict operations to the fundraising/* branches to the fundraising group. There are further restrictions on the mediawiki/extensions/DonationInterface repository, and probably similar one on other extensions used by the fundraising team. If I remember properly it is a PCI compliance requirement (the same reason that forces them to run from a stable branch rather than HEAD/wmf branches). Maybe it is better suited for a sub task given it is very narrow and specific.

In T336807#8857176, @hashar wrote:

We have another use case which is fundraising! From the mediawiki/ access we restrict operations to the fundraising/* branches to the fundraising group. There are further restrictions on the mediawiki/extensions/DonationInterface repository, and probably similar one on other extensions used by the fundraising team. If I remember properly it is a PCI compliance requirement (the same reason that forces them to run from a stable branch rather than HEAD/wmf branches). Maybe it is better suited for a sub task given it is very narrow and specific.

Hi! Just to give some insights here: Indeed, FR-Tech did this purposefully to meet our PCI requirements.

There is a requirement that all code we use is code-reviewed by at least 1 other person than the author, and (maybe more importantly) there is a requirement that people who have access to "system components" (which merge access to our repos could be considered part of that) is limited to only those whose job requires access.

One thing I wanted to flag up is that main branches can be protected so that only developer can merge, or either developer + maintainers can merge, or no one can merge.

To me it seems to me that people who have +2 on repos in gerrit should get the "maintainer" role, and then other people have the developer role, and we protect main branches such that only maintainers, not developers+maintainers have it? But I'm still not that familiar with the permissions model.

In T336807#8882990, @Mvolz wrote:

One thing I wanted to flag up is that main branches can be protected so that only developer can merge, or either developer + maintainers can merge, or no one can merge.

To me it seems to me that people who have +2 on repos in gerrit should get the "maintainer" role, and then other people have the developer role, and we protect main branches such that only maintainers, not developers+maintainers have it?

That sounds right to me.

In T336807#8883317, @dancy wrote:

In T336807#8882990, @Mvolz wrote:

One thing I wanted to flag up is that main branches can be protected so that only developer can merge, or either developer + maintainers can merge, or no one can merge.

To me it seems to me that people who have +2 on repos in gerrit should get the "maintainer" role, and then other people have the developer role, and we protect main branches such that only maintainers, not developers+maintainers have it?

That sounds right to me.

I've altered the permissions model on wiki here to accurately reflect my experience of what permissions are currently available to each role but feel free to revert if this doesn't reflect the overall situation: https://www.mediawiki.org/w/index.php?title=GitLab%2FPolicy&diff=5950383&oldid=5928998

Only allowing Maintainers, not Developers, to merge to a protected branch currently only alterable by Owners. Anyone wanting to migrate their repos at this point needs to be an Owner, I think?

Both repos in the services group have a Maintainers only merge policy for the main branch. We should maybe have a policy about how Ownership works or it may be something we have to be more permissive from if we want people migrating their own repos.... or we might need to walk back who gets to be Owners later.

As an Owner in the Services group I got a request for @kostajh to be a member as they need to create a repo in the namespace - how does this work? What's the process for Owners approving and giving permissions? Should they ask you @brennen or file a task for that? Are other Owners allowed to approve those?

Oh, also, we should probably have a model for which roles we require 2FA to be set up in order to get the role. Thoughts? Developer and above I'd say?

I've altered the permissions model on wiki here to accurately reflect my experience of what permissions are currently available to each role
…
Only allowing Maintainers, not Developers, to merge to a protected branch currently only alterable by Owners. Anyone wanting to migrate their repos at this point needs to be an Owner, I think?

Thanks. I've reworked this overall after discussion with @thcipriani and @dancy today, as well as making some changes to group-level settings so that Developers can create projects and Maintainers can create subgroups.

Still a bit of an unanswered question here since Developers can create projects, but aren't then able to administer them or invite users. Will be partly solved by automatically importing some things, I think.

As an Owner in the Services group I got a request for @kostajh to be a member as they need to create a repo in the namespace - how does this work? What's the process for Owners approving and giving permissions? Should they ask you @brennen or file a task for that? Are other Owners allowed to approve those?

For GitLab in general, we've been creating groups in /repos, giving people ownership, and letting them manage membership as they see fit. Feels like an unanswered question how best to arrange this for /repos/mediawiki. For right now, you and @kostajh are both owners since I don't want to block any work there (apologies for any spam from GitLab as I investigate permissions).

Oh, also, we should probably have a model for which roles we require 2FA to be set up in order to get the role. Thoughts? Developer and above I'd say?

Elsewhere in the policy doc, we have:

Users with Developer privileges (or above) outside of their personal namespaces—those who merge code—must have two-factor authentication enabled on their account.

In practice we've relied on requiring 2fa for members of groups in order to enforce this. I don't think there's a mechanism for requiring it by role, or by role within a group.

we will establish a convention for names, e.g. review/[username]/[topic] , and likely enforce restrictions on this in code

Problem: How can we have multiple branches in GitLab (as multiple changes in Gerrit) for the same topic if we use this conversion?

In T336807#8900119, @Winston_Sung wrote:

we will establish a convention for names, e.g. review/[username]/[topic] , and likely enforce restrictions on this in code

Problem: How can we have multiple branches in GitLab (as multiple changes in Gerrit) for the same topic if we use this conversion?

Agreed. I often make many changes related to one ticket to reduce the overall size of each change. Could a integer be added after a dash to de-duplicate the name if two branches have the same topic?

In T336807#8900258, @Dreamy_Jazz wrote:

In T336807#8900119, @Winston_Sung wrote:

we will establish a convention for names, e.g. review/[username]/[topic] , and likely enforce restrictions on this in code

Problem: How can we have multiple branches in GitLab (as multiple changes in Gerrit) for the same topic if we use this conversion?

Agreed. I often make many changes related to one ticket to reduce the overall size of each change. Could a integer be added after a dash to de-duplicate the name if two branches have the same topic?

Despite what was written, I don't expect branch naming conventions to be automatically enforced, and even if there was some kind of enforcement, it would probably only apply to the review/[username] part of the branch name. My opinion is that you can and should use any convention that suits your needs.

I have noticed extensions-all and skins-all, I suspect those are place holders to potentially replace the functionality provided by Gerrit with the auto generated monorepositories mediawiki/extensions.git and mediawiki/skins.git. I think it is too early to define those two. If we were to define a mono repository for deployment, it might be better to have that either in the wmf branch of mediawiki/core or in a new repo dedicated to deployment.

Create new work branches (we will establish a convention for names, e.g. review/[username]/[topic], and likely enforce restrictions on this in code)

It would be really nice if individual work/patch branches were not part of the main Git repository because then anyone who clones MediaWiki is just going to end up with a ton of git branches that are mostly useless.