As we discussed during GUADEC and as many of you know, processing new and existing GNOME account changes has been a manual action for many years now. With the introduction of OCP, GitLab CI/CD, IPA and SSO, we wanted to enable GNOME contributors and developers to fulfil their needs in total autonomy and freedom without requiring interventions from our side when it came to provision resources or build/test GNOME software.
With that in mind we’re happy to announce new and existing GNOME account changes are now processed via automation.
How it works
When visiting [1] you will be shown an issue template composed of some documentation on top and a json dictionary. The only field that requires an update is the json dictionary, the following format should be used:
action can be any of:
new_account
git_access
master_access
update_email
While the module key should be the name of any GNOME module as found within [2], the module key should only be specified with the new_account, git_access, master_access actions.
The title of the issue should be: “Account request”.
Other key takes when selecting the new_account action:
Your name, surname and username will be computed out of your full name as found in your GitLab profile
The registered email on your account will be the one of your GitLab profile
Other key takes when selecting the update_email action:
The email that will be synchronized with IPA is the primary one you have registered on your GitLab account, please make sure that one is up-to-date
What automation will take care of:
Generate your account information and allow the Accounts team to verify compliance, also add necessary labels
Mail individual existing GNOME module maintainers and have them acknowledge your new or existing GNOME account request
Once all the verifications have happened, automation will create your account or update it with additional permissions
Close the issue and turn the confidential flag to on once the full process has completed
Please let us know any feedback you may have, for any bug report please use [3].
Once an initial phase of testing has happened, the idea we have is introducing the same automation within the GNOME Foundation Membership Committee as well during the coming months.
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 gnomecvs role? 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 ^
averi:
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 ftpadmin role? 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!
I thought one could have a GNOME account without gnomecvs and be added to .doap to get git maintainer access for the module. So in this case, git_access action wouldn’t be required. Is that correct?
So far I have not seen gnomevcs being tied to modules that much. I probably use it the most for not having to fork every module when doing mass changes, for creating git labels for initiatives, editing GitLab Wikis, etc. So all not very module specific.
If you want to contribute to one module you would either have to create PRs anyways or could use GNOME account + .doap as a maintainer without gnomevcs if I understand the system correctly.
However, a module for new_account would make sense if all of this is correct.
I think it would be the typical situation that the person requesting ftpadmin would be the maintainer for the module, right? And often the only maintainer. So that path doesn’t make sense to me.
The tracking ‘why’/‘for what’ someone originally got the access does make total sense to me though.
It grants the gnomecvs role, that’s correct, the reason why it requires a module is explained ^
I thought one could have a GNOME account without gnomecvs and be added to .doap to get git maintainer access for the module. So in this case, git_access action wouldn’t be required. Is that correct?
That assumption is wrong, you need to have gnomecvs and your entry in the DOAP file for you to be effectively promoted to maintainer, see [1]. git_access and maint_access are entirely two different roles, usually you start with git_access and over time get promoted to maint_access in the long run.
So far I have not seen gnomevcs being tied to modules that much. I probably use it the most for not having to fork every module when doing mass changes, for creating git labels for initiatives, editing GitLab Wikis, etc. So all not very module specific.
If you want to contribute to one module you would either have to create PRs anyways or could use GNOME account + .doap as a maintainer without gnomevcs if I understand the system correctly.
If you want to contribute you have two paths:
PRs against individual modules
git_access approved by an existing maintainer in the long run
gnomecvs is mainly tied to [2], if you’re part of that group you have developer status within that namespace. For maintainers, they also have access to master.gnome.org and they’re able to access maintainer related spaces within GitLab for a specific module in case their name is there in the DOAP file.
However, a module for new_account would make sense if all of this is correct.
averi:
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
I think it would be the typical situation that the person requesting ftpadmin would be the maintainer for the module, right? And often the only maintainer. So that path doesn’t make sense to me.
Modules usually have more than one maintainer, the automation app has a specific check that allows approvals to come from anyone within gnomecvs in case no other maintainer is there on that specific module to approve the request. The case where one single committer is around and there’s a desire for this person to become a maintainer, the release team or really any other maintainer can vouch for this person.
| 
averi: