Information regarding upcoming Gitlab Migration

[Ben Cooksley]

On Tue, Apr 28, 2020 at 12:04 AM Ingo Klöcker <kloecker at kde.org> wrote:
>
> On Montag, 27. April 2020 13:19:07 CEST Ben Cooksley wrote:
> > That requires that you know it exists. We have 1,043 mainline
> > repositories at the moment, which translates to 53 pages of projects
> > under a flat structure system.
> > Reality is nobody is going to page through that looking for something.
>
> I have to disagree. Whenever I'm looking for a project I browse
> https://projects.kde.org/ (aka https://cgit.kde.org/).
> Using a simple Ctrl+F in my browser allowed me to find what I was looking for
> rather easily.

Sorry, but cgit.kde.org will be gone once we have moved to Gitlab.

>
> Having to look into *several* subgroups (because I guess we all know from
> experience that any categorization into several groups never matches our
> expectation) would have been a pain in the ass.
>

Also note that Gitlab search spans across group boundaries.

>
> > Please also see my point regarding listing merge requests at the group
> > level
>
> This argument only holds if the subgroups match development teams. It does
> already break down if e.g. a KDE PIM developer wants to see merge requests for
> PIM related frameworks and for PIM applications.
>

That is unfortunate, but you will never get a perfect solution.

> I have experienced exactly this problem at work were we have put repos of
> unrelated projects into different groups. It was extremely inconvenient that,
> while working on more than one project at the same time, I couldn't see all
> MRs I'm interested in on a single page.
>
> IMNSHO the groups in GitLab are not the right solution for gathering all repos
> some dev team, let alone individual devs, is/are interested in, because the
> assumption that different dev teams are interested in *disjoint* sets of repos
> is simply wrong. Moreover, the assumption that all members of some dev team
> are interested in exactly the same repos is equally wrong (even if most team
> members are probably interested in most of the same repos).
>
> And while the mapping group to dev team might make sense for something like
> plasma or frameworks or KDE PIM, I sure that it makes less or no sense for
> groups like graphics were different teams are working on different
> applications in the same group.
>
>
> > - you can see an example of what a flat structure ends up
> > looking like at https://gitlab.gnome.org/GNOME
> >
> > For those projects that span multiple repositories, you have just
> > denied them any chance or ability to see a listing of everything
> > related to their wider project.
>
> I'm sorry, but I don't think that this is solved by your proposal for the KDE
> PIM projects because not everything related to KDE PIM (e.g. relevant
> frameworks like kcontacts, kholidays, kpeople and soon kdav) will be in the
> same group. The same is true for any project which uses some frameworks, e.g.
> graphics and the imageformats framework or whatever group kate and kwrite are
> going to end up in and the ktexteditor framework.
>
> The sad truth is that, AFAIK, GitLab lacks an n-to-m association of repos to
> user groups (e.g. dev teams). GitLab's 1-to-n association of repos to a single
> group is insufficient for us (while it's sufficient for most users of
> gitlab.com).
>
> Regards,
> Ingo

Regards,
Ben