Information regarding upcoming Gitlab Migration

[Bhushan Shah]

[adding sysadmin at kde.org in CC, please make sure you keep it in CC]

On Mon, Apr 27, 2020 at 02:03:48PM +0200, Ingo Klöcker 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.
> 
> 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.
> 

This is something which can be easily solved by Gitlab, Gitlab offers a
solution where project can be shared with another group.

So e.g. sharing kcontacts with kdepim should be possible, then all merge
requests/issues from kcontacts would show up under pim as well.

> 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



-- 
Bhushan Shah
http://blog.bshah.in
IRC Nick : bshah on Freenode
GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-community/attachments/20200427/b8290b1f/attachment.sig>