On Fri, Aug 04, 2023 at 02:04:22PM +0200, Fabian Arrotin wrote: > On 04/08/2023 08:49, Ryan Lerch wrote: > > On Fri, Aug 4, 2023 at 4:41 PM Fabian Arrotin <fabian.arrotin@xxxxxxxxxx> wrote: > > > > > > On 04/08/2023 02:25, Ryan Lerch wrote: > > > > I just would get a discussion started with the process of > > > > semi-formalizing the grouping and naming guidelines for the Fedora > > > > GitLab instance. Just a nitpick, this isn't a Fedora Gitlab instance. ;) it's a namespace on gitlab.com provided to us from gitlab. > > > > Currently there are a bunch of groups with subgroups in the main > > > > /fedora/ namespace: > > > > > > > > https://gitlab.com/fedora > > > > > > > > Depending on how we decide to group, some of these may remain there > > > > (or possibly be grouped together in another group) This is however > > > > some repos and groups that i'm not sure what they are or could > > > > probably be moved into some existing groups: > > > > > > > > * Source Git group (https://gitlab.com/fedora/src) -- not what you > > > > think it only has 4 repos so far This was the 'source git sig' wanting to try things out on gitlab. It could be moved to SIGs I think? We might ping them and see if it's even still needed however, since I don't know that they are active much these days. ;( > > > > * Fedora Podcast (https://gitlab.com/fedora/podcast) could possibly go > > > > under marketing maybe Sounds reasonable. > > > > * Packager-Tools (https://gitlab.com/fedora/packager-tools) Yeah, not sure about this one... I mean it's the mass prebuild tool, but not sure where moving it would make sense. > > > > * people (https://gitlab.com/fedora/people) a private group with one repo in it We likely need to ask that person about where to move these or keep them. > > > > > > > > This might have to be something that we have a meeting to discuss and > > > > figure out a scheme? Sure, or the scheme below seems good to me. > > > > > > > > cheers, > > > > ryanlerch > > > > > > Hi Ryan, > > > > > > We more or less discussed that with Kevin in the past and for CentOS > > > groups (all coming from same common IPA infra) I proposed that we used > > > something like : > > > <target>-<project>-<group_name> > > > > > > Let me explain : Assuming that we need to grant the CentOS Automotive > > > SIG access to gitlab, the name in FAS/IPA is : > > > gitlab-centos-sig-automotive-developer > > > (https://accounts.fedoraproject.org/group/gitlab-centos-sig-automotive-developer/) > > > > > > Same rule but for openshift/ocp : we need to grant the hyperscale sig > > > access to the openshift CI centos infra : > > > https://accounts.fedoraproject.org/group/ocp-cico-hyperscale/ > > > > > > It's then easier to identify which group has access to what > > > (gitlab/openshift/etc) *while* keeping the existing groups, as IPA > > > supports nested groups (so the ocp-cico-hyperscale group in fact > > > contains the sig-hyperscale group > > > (https://accounts.fedoraproject.org/group/sig-hyperscale/) > > > > > > At least that's the naming convention we agreed on so that we can also > > > easily identify if that's a fedora/centos group (all the sig-* groups > > > weren't following that naming convention as they were coming from > > > previous FAS and so imported/merged with the fedora groups in IPA, but > > > there was no conflicting group back then) > > > > > > > Oh, i can also definitely get on board with a set scheme for Fedora > > Accounts groups <-> Gitlab Groups naming conventions. Yeah, +1 > > However, the one of the main issues i am noticing with our current > > GitLab setup is that the groups that are being added are being done in > > an adhoc setting. > > > > For example, there are groups for Council and Mindshare (and not yet, > > but i can imagine a FesCO group too) -- should these be grouped > > together under, say a "Governance" Sub group? > > > > cheers, > > ryanlerch > > > > Multiple solutions : one can always create new groups and reflect that at > gitlab level (same membership but different group name[s]) and IPA supports > multiple "nesting" levels so you can (in your Governance example) have one > groups containining/nesting multiple other ones Yeah, or 'project' instead of 'govenance'? We should write up a doc with whatever we do to document it and make sure everything is on the same page. kevin
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ infrastructure mailing list -- infrastructure@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to infrastructure-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
