Information regarding upcoming Gitlab Migration: clarifications

[Aleix Pol]

On Fri, May 1, 2020 at 7:18 AM Ben Cooksley <bcooksley at kde.org> wrote:
>
> On Fri, May 1, 2020 at 4:38 PM Nate Graham <nate at kde.org> wrote:
> >
> >
> >
> > On 4/30/20 5:59 PM, Aleix Pol wrote:
> > > El jue., 30 de abr. de 2020 a la(s) 18:15, Albert Astals Cid
> > >> Am I the only person that just has all the repos on the same folder? I thought it was the common thing to do :?
> > >
> > > I do too
> >
> > Same here. kdesrc-build's default settings do this, and download all
> > repos into ~/kde/src without any of the levels of hierarchy. This would
> > seem to require unique repo names, no?
>
> Not necessarily.
>
> Git allows you to override the name that the local folder is called
> when cloning, so there is no reason why we can't specify something in
> the metadata to override the local name that the folder gets called in
> your local checkout folder.
> This would allow for example:
>
> - frameworks/kcoreaddons on Gitlab continues to be called
> 'kcoreaddons' in your local checkout folder
> - maui/dialer on Gitlab gets called 'maui-dialer' in your local checkout folder
>
> This allows for the URLs on Gitlab to make sense, while simultaneously
> allowing your local source checkout folders to continue to work in the
> manner in which they do currently.
> Note that we do not expect people to hit this in many cases - this is
> about giving us the flexibility for the long term without imposing
> unnecessary bureaucracy and limits on projects within the KDE
> umbrella.
>
> Automated tooling such as kdesrc-build and the proposed clone script
> (that searches in namespaces) should be able to handle this without
> much issue.
> In the case of manually done clones, it is reasonable to expect people
> to know what they're doing with their clones, and name them
> appropriately in the event they have a collision.
>
> Does this sound acceptable?

Okay, if that's necessary, we'll have to do it.

We'll appreciate simpler bureaucracy.

Aleix