Gerrit Access Rights Policies
This page attempts to establish a community-wide policy to handle project access rights on gerrithub. We start defining the roles:
Roles are:
gerrit admins: gerrit admins own all the projects inside the midonet/* namespace on gerrithub. They need to know how gerrit works, but they don't need to know the code of the project that they will administer. They will be responsible to:
- Configure the project's admin rights
- Create/import new projects
They should not:
- Have permissions to interfere on code workflow (neither +2 to code reviews nor +1 to validate or submit new code)
core developers: It is recommended that only a small subset of Midonet contributors be part of the core developers. Each project can have its own core developer team. A core developer is able to:
- Have FULL control over code workflow. They should be able to accept code contributions, push new tags, push new branches and everything related to code.
- Manage his team. Add or remove new members.
A project developer can not:
- Modify the access rights of the project he works. To do so, he has to ask to a gerrit admin if he has a good reason to modify them.
contributors: the rest of us. It matches on gerrit's Anonymous Users or Registered Users. A Registered User in gerrit inherit all the access right of an Anonymous User. In gerrithub, you must be registered to do anything, so we can use both concepts indistiguible.
All the access rights proposed are intended to follow this idea. So maybe if something proposed does not work as expected, please contact to midonet-admins.
Common access rights proposed are included in this image. This is how midostack is configured today:
TODO!! I need a bigger screen to screenshot :S
Let's explain what means each box:
Set the owner of all namespaces inside the refs/*. The gerrit admins (midonet-admins) are able to modify the access rights for all the project. This is what we want.
refs/drafts/* and refs/publish/* namespaces are related about who is able to push and clone patchsets to review. Everyone should be to do it. (As I told you, in gerrithub we can use Registered Users and Anonimous Users either. Sorry for the incoherence) The difference between them is refs/publish/* is a public patchset (the default behaviour when you execute git review) and refs/drafts/* are only visible to you an manual reviewers you may add (git review -D)
This is the main box to configure. It is related to code workflow over development branches. I am going to explain each permission:
- Read: easy. Anyone should be able to download development branches from gerrit.
- Push: This should never be used. But sometimes a core developer (that belongs to midonet-integration team in this case) needs to push a change directly to gerrit repository without a code review. This permission allows this.
- Forge Author Identity, Forge Commiter Identity:This one is related to Push one. This permission allow to core developers to push commits not authored or commited by them.
- Push merge commit: Merge commits are special commits after perform a merge between to branches. A core developer should be able to push them to gerrit repository too.
- Label Code-Review: Permission to +1 or +2 over a patchset. This maybe is counter-intuitive because it seems like this permission should be defined in refs/drafts/* or refs/publish/*. But it is not. Should be here. Core developers should be able to +2 and anyone should be able to +1
- Label Verified: Jenkins verification over a patch. Core developers are able to verify too. Please, use it wisely and only in very special cases. If Jenkins don't set +1 when it should, it is preferable to fix Jenkins!
- Remove reviewer: Ability to remove a review from a non-desired reviewer or invalidate a midonet-bots CI feedback.
- Submit: Push the change into main branch. It only appears after a +2 code review and +1 verification.
- Create reference: Ability to create a branch. Only a core developer can create a branch.
Please note the Exclusive checkbox on the right side of the box. That means that ONLY the defined groups are able to perform the actions and prevents gerrit administrators to do so.
Tag permissions belong to core developers.
We think with this permissions we will achieve configure gerrit with the goals we explained in section ROLES.
In gerrit, a group can own another group. And a group can be invisible to others. We don't want this. What we want:
Each group should:
- Own itself. This guarantees the members of the group be able to add and remove members as they wish.
- Be visible. So the gerrit-admins can assign to them the proper permissions.
A project should be configured this way:
The option 'Create a new change...' guarantees we can chain patchsets that are not already merged. The option 'Require Signed-off-by' is annoying. Disable it. The option 'Change-Id' is important to have different patchsets into the same review. Set it as TRUE