Information regarding upcoming Gitlab Migration

Piyush Aggarwal piyushaggarwal002-Re5JQEeQqe8AvxtiuMwx3w at public.gmane.org
Mon Apr 27 11:49:39 BST 2020


On Mon, 27 Apr, 2020, 4:09 pm Aleix Pol, <aleixpol-RoXCvvDuEio at public.gmane.org> wrote:

> On Mon, Apr 27, 2020 at 3:41 AM Bhushan Shah <bshah-RoXCvvDuEio at public.gmane.org> wrote:
> >
> > [Please keep sysadmin-RoXCvvDuEio at public.gmane.org list or bshah-RoXCvvDuEio at public.gmane.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
> >
> > 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.
>
> Aleix
>

This is technical so I would love to hear Sysadmin team's thoughts on this:
Probably there can be a redirect system that lets us do git clone
kde:knotifications and manages to redirect it to
kde/frameworks/tier3/knotifications.git
So we can clone and tinker with stuff as we normally do while the sysadmin
team goes with the recommended system of setting up the repos.
I think this should be possible because Invent already redirects my URLs
which don't end with .git to .git ones. I might be wrong about my
assumption that both things can work similarly.

Best
Piyush Aggarwal

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20200427/1ce15a98/attachment.htm>


More information about the kde-core-devel mailing list