| sophieherold GNOME Team
September 16 |
- | - |
Hey,
I have a few questions:
averi:
git_access
In the Wiki is an example where it is called
"action": "git_account", that’s probably a typo?
Definitely a typo, fixed it, thanks!
I don’t really understand what this action does. Does it just change the .doap-file? Because that’s how git access to modules is managed, right?
The git_access action mainly verifies you’re actively contributing to a GNOME module and the module maintainer is willing to grant you access to the LDAP group responsible of providing read-write capabilities within the entire set of GNOME’s GitLab namespace hosted repositories. DOAP files only control who maintains a module, for committers we mainly have one single LDAP group which in turn maps to a GitLab group where everyone is allowed to commit to any repository within GNOME’s GitLab namespace.
Or does it grant the
gnomecvsrole? In that case, I don’t understand why that action needs a module.
It grants the gnomecvs role, that’s correct, the reason why it requires a module is explained ^
- master_access
The name is pretty self-unexplanatory to me. Could it maybe be something more clear and without ‘master’?
Made it maint_access and updated documentation, thanks!
Does it grant the
ftpadminrole? If so, of what use is the module parameter here?
It effectively does, the reason why we need a module param is that this role gives you access to master.gnome.org, as such we need an existing maintainer to vouch for your access to be created given these permission allow you to modify tarballs we globally serve. The idea with this self-service tool is that we also introduced additional auditing and accounting when it comes to GNOME accounts, each action is tracked within an individual GitLab issue and we can easily connect what was granted and when.
Hope this clarifies your doubts! Will mail desktop-devel-list and foundation-list with some of these notes, thanks!