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(a)arrfab.net>
> > 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
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
> > >
> > > 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
> > 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.
> However, the one of the main issues i am noticing with our
> 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?
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.