For example someone writes a change at gerrit, and we give some people access to git, that thex can fetch it, and checkout master again, later?

But this has a security impact: For example you can reactivate the checkuser-extension, and view private data, by assigning rights to *.

You need access to the deployment-prep labs project and then you can deploy config changes to beta to test them there. That's easy to give out.

Any config change or only stuff already merged on wmf/master branches?

As Krenair said, quick cherry-picks/test changes on Beta Cluster are easy/straight-forward and it's simple to make sure people have the right access.

In T136828#2351391, @Dereckson wrote:

Any config change or only stuff already merged on wmf/master branches?

Just for context: There's a slight difference between MW+Ext and rOMWC (mw-config) in how code developed and deployed to production is managed.

For MW+Ext it's usually:

1. Develop against master, which is deployed to Beta within 10 minutes of merge
2. RelEng cuts a branch from master each week to deploy to production (when we migrate to long-lived branches (T89945) it's still a similar workflow, just semantics change)

That can be put into words as: Develop against what the current production environment (services/mw-config) looks like.

For rOMWC it's:

For Beta Cluster only changes:

• Develop (on master) using the -labs.php versions of relevant rOMWC files that take effect in Beta Cluster (and let Beta Cluster auto-update)

For Production changes:

• Write new patch (sometimes, but not always, based on the changes you tested in Beta Cluster) and deploy from master immediately after merge (we actually have an icinga check for when what's in master and what's on tin/mira is out of sync)

So, options:

1. make rOMWC act more like MW+Ext (develop on master, master on Beta Cluster, create new deploy branches, then deploy new branches to production)
2. Don't change anything technically but have deployers wait ~10 after each merge into rOMWC (ie: let Beta catch up) before deploying to production
   1. I don't like this one, but it's the right direction (having Beta or something test post merge automatically before push to production)
3. something else...

Bringing this back, I'd like to see the possibility of cherry-pick on one target host, instead of the entire cluster getting the impact. Example: a couple days ago i really wanted to be able to cherry-pick a change to MW on one instance to check something on my snapshot01 instance, without polluting all of the other mediawiki instances. Can we figure out a slick way to do this?