Information regarding upcoming Gitlab Migration

[Ingo Klöcker]

On Montag, 27. April 2020 14:10:55 CEST Bhushan Shah wrote:
> [adding sysadmin-RoXCvvDuEio at public.gmane.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.

Great. So we could put all repos into an "all" group (e.g. rename kde to all) 
and then have every subcommunity decide for themselves which repos they want 
to see in their group.

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-core-devel/attachments/20200427/f6f4a79c/attachment.sig>