Information regarding upcoming Gitlab Migration

[Olivier Churlaud]

Le 27 avril 2020 22:33:12 GMT+02:00, Ben Cooksley <bcooksley at kde.org> a écrit :
>On Tue, Apr 28, 2020 at 8:31 AM Albert Astals Cid <aacid at kde.org>
>wrote:
>>
>> El dilluns, 27 d’abril de 2020, a les 13:19:07 CEST, Ben Cooksley va
>escriure:
>> > On Mon, Apr 27, 2020 at 11:12 PM Olivier Churlaud
><olivier at churlaud.com> wrote:
>> > >
>> > > Hi,
>> > >
>> > > Le lundi 27 avril 2020, 12:38:42 CEST Aleix Pol a écrit :
>> > > > On Mon, Apr 27, 2020 at 3:41 AM Bhushan Shah <bshah at kde.org>
>wrote:
>> > > > >
>> > > > > [Please keep sysadmin at kde.org list or bshah at kde.org in the CC
>for
>> > > > > replies]
>> > > > >
>> > > > > Hello Community members,
>> > > > >
>> > > > > In view of upcoming Gitlab migration, we sysadmin team wants
>to share
>> > > > > the recommended structuring for the repositories on Gitlab.
>> > > > >
>> > > > > We had multiple options,
>> > > > >
>> > > > > - Flat structure: In this option we would have everything
>under one
>> > > > > single namespace/group: https://invent.kde.org/kde/knetwalk
>> > > > > - Subgroups under top-level group: In this option we would
>have a groups
>> > > > > under KDE namespace:
>https://invent.kde.org/kde/games/knetwalk
>> > > > > - Groups at top level: In this option we would establish a
>series of
>> > > > > groups at the top level, e.g. 
>https://invent.kde.org/games/knetwalk
>> > > > >
>> > >
>> > > Thank you for having options and talking to us before
>implementing it.
>> > >
>> > > > > We have discussed this with small but representative group of
>> > > > > contributors or maintainers, and based on their suggestions,
>we
>> > > > > recommend that we go with option 3. Having sub-groups at top
>level will
>> > > > > allow us to,
>> > > > >
>> > > > > - Provides good visibility on all reviews, tasks and other
>items within
>> > > > > the groups/modules we define
>> > > > > - Provides improvements to discoverability of projects
>> > > > > - Makes it possible for groups of projects to establish a
>group level
>> > > > > task board should it fit their needs (for tracking a release
>for
>> > > > > instance)
>> > > > > - Makes the most semantic sense, as the ‘KDE’ top level group
>suggested
>> > > > > in option 2 is duplicative considering the Gitlab instance is
>under
>> > > > > kde.org.
>> > > > > - The discoverability of projects is maximised, as there is
>no need to
>> > > > > open the top level ‘KDE’ group before going into the
>subgroup.
>> > > > >
>> > > > > I've worked on draft "move" of the current set of the
>repositories in
>> > > > > their respective subgroups at the repo-metadata project's
>branch [1].
>> > > > > You can browse the directory structure to get idea of how
>final
>> > > > > structure on Gitlab would look like.
>> > > > >
>> > > > > If we don't have any objections we would like to implement
>this next
>> > > > > week and move projects to https://invent.kde.org.
>> > > > >
>> > > > > Thanks!
>> > > > > Bhushan for sysadmin team
>> > > > >
>> > > > > [1]
>https://cgit.kde.org/sysadmin/repo-metadata.git/tree/projects-invent?h=bshah/invent
>> > > >
>> > > > Does this mean that to clone it we'll have to go "git clone
>> > > > kde:games/knetwalk" or something along the lines?
>> > > >
>> > > > If that's the case I'd much prefer if we didn't do this, at the
>moment
>> > > > it's already uncomfortable for me to remember the URL for some
>of the
>> > > > repos (e.g. is it sysadmin/ or not?), this will only increase
>the
>> > > > problem and I personally don't see the advantage.
>> > > >
>> > > > e.g. Is okular graphics or office? Is gwenview plasma or
>graphics? Is
>> > > > krita graphics or its own thing?
>> > > >
>> > > > I really prefer when I don't have to guess this kind of things
>when
>> > > > fetching a repository.
>> > > >
>> > >
>> > > I 100% agree with Aleix and I think it would also be detrimental
>for discoverability, exactly for the examples Aleix just gave.
>> > >
>> > > We came back from this subgroups ideas some times ago : wiki
>pages were hard to find because hidden under layers of groups. The same
>was true for api documentations. Now everything is flat and I think
>it's easier to find.
>> > >
>> > > Another bad message could also be sent by this: instead of
>exposing Konsole or Ark as two applications under the KDE umbrella, it
>would look like Utils for KDE, bringing back the KDE Desktop idea
>(where every application is already store in a submenu).
>> > >
>> > > As someone wrote later, if I'm looking for a given application,
>there is always the search function...
>> >
>> > 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.
>>
>> But they have gitlab search, don't they?
>
>They do yes.
>
>>
>> I mean it's the solution you told Aleix to figure out if Okular was
>inside graphics or okular.
>>
>> Why is search valid for one case and not for the other?
>
>Because in order to search for something, you need to know it exists.
>
>If you are just casually browsing, then the search can't help you.

I don't think people casually browse our repos. What use case is more likely to happen and do we want to support? 

Use case 1 : Jerry learns about KDE and go in their forge in the Multimedia section. After carefully reading the code of two applications and three libs he starts contributing to Elisa. 

Use case 2 : While using her Ubuntu installation of Elisa / while reading on reddit about Elisa, Jerry decides to try to contribute to this project/fix this bug that itches her and searches for it in KDE's forge. 

On the other hand, I think the discussion about spotting open merge requests (in a derived thread from this one) should be answered, being by relevant tags, subgroups or whatever. 

Best regards
Olivier
>
>>
>> Cheers,
>>   Albert
>
>Cheers,
>Ben
>
>>
>> >
>> > Please also see my point regarding listing merge requests at the
>group
>> > level - 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.
>> >
>> > >
>> > > Best regards,
>> > > Olivier
>> > > > Aleix
>> > >
>> > >
>> >
>> > Cheers,
>> > Ben
>> >
>>
>>
>>
>>