As a follow-up we had on Discourse there's a few more key takes I wanted to mention:
1. 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 for 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. This is the former "gnomecvs" group. 2. master_access has been renamed to maint_access, documentation has been updated. It effectively grants the ftpadmin role, 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. 3. If you do not have a GNOME Account at all, please use the new_account action, it'll make sure your account is created and access to GNOME's GitLab namespace is also granted. If you do have a GNOME account already and you need commit access please use the git_access action. Same applies if you're an existing maintainer and you need access to publish releases via master.gnome.org, in that case you will use the maint_access action. This will be the last update to this thread, for further updates please head to [1] or [2], thanks! [1] https://discourse.gnome.org/t/gnome-accounts-introducing-automation/11146/3 [2] https://wiki.gnome.org/Infrastructure/NewAccounts On Fri, Sep 16, 2022 at 11:32 AM Andrea Veri <a...@gnome.org> wrote: > Hello, > > 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: > > 1. new_account > 2. git_access > 3. master_access > 4. 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: > > 1. Your name, surname and username will be computed out of your full name > as found in your GitLab profile > 2. The registered email on your account will be the one of your GitLab > profile > > Other key takes when selecting the update_email action: > > 1. 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: > > 1. Generate your account information and allow the Accounts team to verify > compliance, also add necessary labels > 2. Mail individual existing GNOME module maintainers and have them > acknowledge your new or existing GNOME account request > 3. Once all the verifications have happened, automation will create your > account or update it with additional permissions > 4. 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. > > Thanks! > > [1] > https://gitlab.gnome.org/Infrastructure/Infrastructure/issues/new?issuable_template=account-request > [2] https://gitlab.gnome.org/GNOME > [3] https://gitlab.gnome.org/Infrastructure/Infrastructure/issues > > > -- > Cheers, > Andrea > > Principal Systems Engineer at Red Hat, > GNOME Infrastructure Team Coordinator, > Former GNOME Foundation Board of Directors Secretary, > GNOME Foundation Membership & Elections Committee Chairman > > Homepage: https://www.dragonsreach.it > -- Cheers, Andrea Principal Systems Engineer at Red Hat, GNOME Infrastructure Team Coordinator, Former GNOME Foundation Board of Directors Secretary, GNOME Foundation Membership & Elections Committee Chairman Homepage: https://www.dragonsreach.it
_______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
