Information regarding upcoming Gitlab Migration: clarifications

[Ben Cooksley]

On Fri, May 1, 2020 at 5:44 AM Aleix Pol <aleixpol at kde.org> wrote:
>
> On Wed, Apr 29, 2020 at 12:25 PM Bhushan Shah <bshah at kde.org> wrote:
> >
> > Good afternoon,
> >
> > [Please keep sysadmin at kde.org list or bshah at kde.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.

These tools are being provided as migration assistants.

New contributors won't have a problem, as they'll be used to finding
the project at games/knetwalk (to use an example).

>
> > - 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! :)

Cheers,
Ben