On Tue, Apr 28, 2020 at 12:04 AM Ingo Klöcker <[email protected]> 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
