Information regarding upcoming Gitlab Migration

Ben Cooksley bcooksley at kde.org
Mon Apr 27 11:57:09 BST 2020


On Mon, Apr 27, 2020 at 10:50 PM Piyush Aggarwal
<piyushaggarwal002 at gmail.com> wrote:
>
>
>
> On Mon, 27 Apr, 2020, 4:09 pm Aleix Pol, <aleixpol at kde.org> wrote:
>>
>> 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
>> >
>> > 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.

That would require modifications to Gitlab, which may not even be
technically possible.
It is likely a rewrite script will be provided to smooth the transition.

Please note that knotifications would go to
https://invent.kde.org/frameworks/knotifications under this proposal,
not the longer path you've referred to above.

>
> Best
> Piyush Aggarwal

Cheers,
Ben


More information about the Kde-frameworks-devel mailing list