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>
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.
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-dev...)
> >
> > 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