[adding [email protected] 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
signature.asc
Description: PGP signature
