[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-frameworks-devel
Subject:    Re: Information regarding upcoming Gitlab Migration
From:       Olivier Churlaud <olivier () churlaud ! com>
Date:       2020-04-27 20:49:46
Message-ID: F86401F1-593A-4A2B-BD47-123C9ECD35B7 () churlaud ! com
[Download RAW message or body]



Le 27 avril 2020 22:33:12 GMT+02:00, Ben Cooksley <bcooksley@kde.org> a écrit :
> On Tue, Apr 28, 2020 at 8:31 AM Albert Astals Cid <aacid@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@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@kde.org>
> wrote:
> > > > > > 
> > > > > > [Please keep sysadmin@kde.org list or bshah@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
> > > 
> > 
> > 
> > 
> > 


[prev in list] [next in list] [prev in thread] [next in thread]