Information regarding upcoming Gitlab Migration

[Ben Cooksley]

On Sat, May 2, 2020 at 2:33 AM Adriaan de Groot <groot at kde.org> wrote:
>
> On 2020 mayula d. 1id 07:08:41 CEST Ben Cooksley wrote:
> > On Fri, May 1, 2020 at 2:46 AM Nate Graham <nate at kde.org> wrote:
> > > If I'm understanding things, we have solutions to most or all of the
> > > objections raised so far:
> > >
> > > - Projects will be allowed to live in--or at least appear in--multiple
> > > top-level groups (e.g. plasma-framework could appear in both the
> > > Frameworks top-level group and also the Plasma top-level group)
> >
> > Projects will have the option to appear in multiple groups yes.
>
> Forgive me for coming full circle on this discussion, but
>
> - a group can have at most one workboard
> - a group offers some facilities for managing issues and reviews that cross
> over repositories within that group
> - a project (this is one-to-one with "repository", right?) can have as many
> workboards as it likes

Correct. Projects and repositories are the same thing, it is just a
matter of terminology.

>
> If a project can appear in more than one group, isn't the whole distinction
> between flat and namespaced a little ..

The ability for a project to appear in other groups is subject to some
limitations.
See https://invent.kde.org/groups/kde/-/shared for a list of
repositories currently shared with "KDE"

>
> well, how would this proposal fly?
>
> - Put everything in a single group called "kde" (this matches proposal 2 if I
> still remember the original numbering right -- flat, but not at top-level)

Proposal 2 had the groupings within a larger "KDE" group, rather than
at top level.

Proposal 1 was fully flat, just dump everything in one group.

> - Other groups hold things from "kde" (this matches proposal 3, giving more
> structure / hierarchy)
>
> People browsing *top* level would see group "kde" (for all I care, bookmark
> that one as "I want to browse the list of 1442 repositories") and a bunch of
> logical groups based on how the community organizes itself. People working
> inside a specific group can do their workboardy-things and focus on the
> repositories for that group, while people with an overall interest go to the
> KDE group.
>

Unfortunately sharing of projects/repositories across groups does not
impact on tasks and reviews.
This means that merge requests for Planet (which is currently shared
with "KDE") do not show up in the list of merge requests for "KDE".

Sharing repositories allows for a global listing only.

>
>
> Somehow I get the feeling that we started with some technical limitations
> which were driving particular choices, where those limitations aren't exactly
> what we assumed that they were, and now it looks to me like those limitations
> do not have to meaningfully impact *any* of the choices.
>
> (*if* my understanding is correct; I've been wrong enough times already today)
>
> [ade]

Cheers,
Ben