Information regarding upcoming Gitlab Migration: clarifications

[Aleix Pol]

On Wed, Apr 29, 2020 at 12:25 PM Bhushan Shah <bshah-RoXCvvDuEio at public.gmane.org> wrote:
>
> Good afternoon,
>
> [Please keep sysadmin-RoXCvvDuEio at public.gmane.org list or bshah-RoXCvvDuEio at public.gmane.org in the CC for
> replies]
>
> I want to clarify some bits for which we have gotten a questions about,
>
> - Non unique naming: There's some teams which prefer if we dropped the
>   namespace- part from their name which we have added. While currently
>   this does not result in the naming conflict right away, we realize
>   this will cause it at one point, for example,
>
>   maui-dialer -> maui/dialer
>   plasma-dialer -> plasma-mobile/dialer
>
>   To minimize the impact of the Gitlab move we won't be doing such
>   renames which introduce non-unique names right away. But we would
>   prefer if the existing tooling or infrastructure is ready for this
>   kind of cases at later point. Only way to enforce non-unique naming is
>   one big KDE/ subgroup which we want to avoid.
>
>   Current naming in the repo-metadata branch[1] I've pointed does not
>   reflect those renames, as we are not planning to do those renames
>   right away during gitlab move, but at a later stage.

We have made a big fuss in the past about having different projects
that do the same thing and now we'll have that but also we'll have
several projects with the same name?
It really feels off to me and I wonder if this is related to the move to gitlab.

> - Existing configurations: we want to reduce impact on existing release
>   schedule, and existing developer workflow,  therefore we will continue
>   to privide the existing anongit.kde.org and git.kde.org (although this
>   will be read-only) with current flat structuring for 3 weeks after
>   actual migration, which will keep the existing scripts/clones working
>   enough to give developers time to change to the new structure.
>
>   We will also try to provide a script which allows you to migrate your
>   existing clones to new repo paths and as mentioned by Ben in other
>   message, potentially a git-kde script which would allow you to clone
>   individual repository without knowing it's namespace (provided that
>   there is no conflict of it's name). like "git kde karchive"

IMHO needing tools ad-hoc to KDE development can be a barrier of entrance.
I feel like these things make us look distant, it's important that
people's skills translate automatically when they want to get started.

> - Translations: we will co-ordinate with the translations team to let
>   them adapt their tooling to updated structure as this requires changes
>   on their side how translations are stored in svn repository

Thanks! :)