| • flimport | |
| May 10 2014, 12:51 PM |
| F2538248: herald-commit-rule-example.png | |
| Sep 3 2015, 8:00 PM |
Gerrit has fine-grained per-branch ACLs. I haven't been able to find documentation for access control in Phabricator. For feature parity with Gerrit, we'll at least need to lock down approval rights to certain user groups on a per-branch basis, with wildcard support (for all branches, grant approval rights to group X, but for branches of the form wmf/*, grant approval rights only to the deployers group).
See also: T184: Inherited settings and access control for code repositories
| Status | Subtype | Assigned | Task | |
|---|---|---|---|---|
| · · · | ||||
| Declined | None | T167 Align basics of current Gerrit code-review process with Differential | ||
| Resolved | • mmodell | T183 Per-branch access control in code repositories | ||
| · · · |
It's useful for deployment, but otherwise not terribly useful I think (others may disagree).
We could work around the deployment case if we had to.
Herald can be used to create very fine-grained rules about which commits to accept.
Here's just a simple example I came up with to illustrate:
It might be useful to have explicit examples from Gerrit's ACLs that we need to reproduce (or not, we can debate them).
After reading the backscroll in -releng, it seems Mukunda and Chad think we're good here, don't take my previous comment as a statement of "thou shalt do this" ;)
The main per-branch ACL we have right now is +2 and submit on wmf/* branches is limited to people in the wmf-deployment group, but +2 on all other branches is granted to the "mediawiki" group AFAIK.
The fun bit from IRC:
+ostriches> Although, if we do the Right Thing and move the deployment repo to a fork of MW and stop using submodules, we won't have need for those wmf/* branches everywhere.