Information regarding upcoming Gitlab Migration

[Ingo Klöcker]

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.

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.


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

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-community/attachments/20200427/9f8d3d2d/attachment.sig>