Re: Information regarding upcoming Gitlab Migration: clarifications

[Ben Cooksley]

On Fri, May 1, 2020 at 4:38 PM Nate Graham  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?

>
> The group categorization we've been discussing may be useful on the web
> UI for newcomers, but it has no value for your source checkout folder
> IMO, where it just makes it slightly more annoying to navigate from one
> repo to another.
>
> Nate

Cheers,
Ben

Re: Information regarding upcoming Gitlab Migration

[Ben Cooksley]

On Fri, May 1, 2020 at 2:46 AM Nate Graham  wrote:
>
> If I'm understanding things, we have solutions to most or all of the
> objections raised so far:
>
> - Projects will be allowed to live in--or at least appear in--multiple
> top-level groups (e.g. plasma-framework could appear in both the
> Frameworks top-level group and also the Plasma top-level group)

Projects will have the option to appear in multiple groups yes.

>
> - kdesrc-build and other scripts can be updated to allow people to
> easily check out repos using git prefixes (e.g. so that something like
> `git clone kde:dolphin` will still work regardlyss of a project's
> underlying group)

The syntax will probably be slightly different to that, but the
concept is correct yes.

>
> - cgit will continue to exist for three weeks to provide some transition
> time

Correct.

>
> - Each repo can have its own workboard in addition to the single
> group-level workboard

Correct, just one small clarification: each project (repository) can
have multiple workboards, there is no limit to this.
Groups are limited to a single workboard.

>
> If the above are accurate, then I firmly support the proposal.
>
> As for the actual grouping, I think it makes sense to have top-level
> groups for Frameworks, Plasma, PIM, etc. as originally proposed. I can
> support putting apps into category-specific groups (e.g. Multimedia,
> Office, Graphics, Games, etc) as long as apps could appear in multiple
> groups if needed for the case of apps that logically span boundaries
> (e.g. repos for PlaMo apps could appear in both the Plasma Mobile
> top-level group and also the relevant app group).
>
>
> Nate

Cheers,
Ben

Re: Information regarding upcoming Gitlab Migration: clarifications

[Nate Graham]

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?


The group categorization we've been discussing may be useful on the web 
UI for newcomers, but it has no value for your source checkout folder 
IMO, where it just makes it slightly more annoying to navigate from one 
repo to another.


Nate

Re: Information regarding upcoming Gitlab Migration: clarifications

[Aleix Pol]

On Fri, May 1, 2020 at 1:08 AM Nicolás Alvarez
 wrote:
>
> El jue., 30 de abr. de 2020 a la(s) 18:15, Albert Astals Cid
> (aa...@kde.org) escribió:
> >
> > El dijous, 30 d’abril de 2020, a les 21:31:02 CEST, Ben Cooksley va 
> > escriure:
> > > On Fri, May 1, 2020 at 6:04 AM Ivan Čukić  wrote:
> > > >
> > > > > 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.
> > > >
> > > > +1 to both sentiments - that projects should have different names and 
> > > > that
> > > > this is a bit off topic for the gitlab migration.
> > >
> > > The projects *DO* have very different names. That *HAS NOT* changed.
> > > To use the example Bhushan gave above, one is called Plasma Mobile
> > > Dialer and the other one is called Maui Dialer.
> > >
> > > With the current git.kde.org setup, we have a flat namespace, so all
> > > repositories if the name appears to be generic (as dialer is) have to
> > > be namespaced by prefixing of the repository name.
> > >
> > > With Gitlab however we will now namespaces that group repositories,
> > > making the prefixing unnecessary and as some projects have complained
> > > about, duplicative.
> > >
> > > Otherwise you end up with plasma-mobile/plasma-mobile-dialer as your
> > > path, which just looks silly.
> >
> > 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

> Oh, your local path could be anywhere. It doesn't even need the same
> name, you can put it in the same folder as the rest and call it
> dial-thingy :)

And then you'll have to have a modified build script to account for
thingy because KDE can't stay consistent at naming.

I suggest not to use the gitlab transition to make such an important change.

Aleix

Re: Information regarding upcoming Gitlab Migration: clarifications

[Nicolás Alvarez]

El jue., 30 de abr. de 2020 a la(s) 18:15, Albert Astals Cid
(aa...@kde.org) escribió:
>
> El dijous, 30 d’abril de 2020, a les 21:31:02 CEST, Ben Cooksley va escriure:
> > On Fri, May 1, 2020 at 6:04 AM Ivan Čukić  wrote:
> > >
> > > > 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.
> > >
> > > +1 to both sentiments - that projects should have different names and that
> > > this is a bit off topic for the gitlab migration.
> >
> > The projects *DO* have very different names. That *HAS NOT* changed.
> > To use the example Bhushan gave above, one is called Plasma Mobile
> > Dialer and the other one is called Maui Dialer.
> >
> > With the current git.kde.org setup, we have a flat namespace, so all
> > repositories if the name appears to be generic (as dialer is) have to
> > be namespaced by prefixing of the repository name.
> >
> > With Gitlab however we will now namespaces that group repositories,
> > making the prefixing unnecessary and as some projects have complained
> > about, duplicative.
> >
> > Otherwise you end up with plasma-mobile/plasma-mobile-dialer as your
> > path, which just looks silly.
>
> Am I the only person that just has all the repos on the same folder? I 
> thought it was the common thing to do :?

Oh, your local path could be anywhere. It doesn't even need the same
name, you can put it in the same folder as the rest and call it
dial-thingy :)

This is about the server path (eg. the clone URL) looking redundant:
invent.kde.org/plasma-mobile/plasma-mobile-dialer.

-- 
Nicolás

Re: Information regarding upcoming Gitlab Migration: clarifications

[Albert Astals Cid]

El dijous, 30 d’abril de 2020, a les 21:31:02 CEST, Ben Cooksley va escriure:
> On Fri, May 1, 2020 at 6:04 AM Ivan Čukić  wrote:
> >
> > > 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.
> >
> > +1 to both sentiments - that projects should have different names and that
> > this is a bit off topic for the gitlab migration.
> 
> The projects *DO* have very different names. That *HAS NOT* changed.
> To use the example Bhushan gave above, one is called Plasma Mobile
> Dialer and the other one is called Maui Dialer.
> 
> With the current git.kde.org setup, we have a flat namespace, so all
> repositories if the name appears to be generic (as dialer is) have to
> be namespaced by prefixing of the repository name.
> 
> With Gitlab however we will now namespaces that group repositories,
> making the prefixing unnecessary and as some projects have complained
> about, duplicative.
> 
> Otherwise you end up with plasma-mobile/plasma-mobile-dialer as your
> path, which just looks silly.

Am I the only person that just has all the repos on the same folder? I thought 
it was the common thing to do :?

Cheers,
  Albert

> 
> >
> > Cheers,
> > Ivan
> >
> >
> 
> Regards,
> Ben
> 
> >
> > --
> > dr Ivan Čukić
> > i...@cukic.co, https://cukic.co/
> > gpg key fingerprint: 8FE4 D32F 7061 EA9C 8232  07AE 01C6 CE2B FF04 1C12
> >
> >
> 

Re: Mentors needed

[Timothée Giet]

Le 30/04/2020 à 22:07, Timothée Giet a écrit :
> Le 30/04/2020 à 21:38, Valorie Zimmerman a écrit :
>> Hello folks, we have a project about porting a QtQuickControls module
>> to QtQuickControls2 with only one mentor who marked "I want to
>> mentor" on the GSoC webapp.
>>
>> If you have already signed into the GSoC webapp as a mentor, and
>> would like to help out with this project, please mark "I want to
>> mentor" in the app.
>>
>> If you have the skills needed to mentor but have not yet logged into
>> the app, please: 
>>
>> 1. ensure that you are subscribed to KDE-Soc-Mentor mail list [1]
>>
>> 2. write to kde-soc-managem...@kde.org
>>  and ask to be invited to the webapp.
>>
>> Thanks!
>>
>> Valorie
>>
>> 1. https://mail.kde.org/mailman/listinfo/kde-soc-mentor
>>
>> -- 
>> http://about.me/valoriez - pronouns: she/her
>>
>>
> I may not be the best mentor this project, but as GCompris would
> benefit a lot from the output of this proposal (this missing module is
> the main blocker we have to migrate to QtQuickControls2), I'm ok to
> backup-mentor it... At least I can provide generic advices and testing.
>
> But some help from someone more specialist of Qt internals would be
> welcome!
>
> Timothée
>
On second thought, as I'm not so sure I can provide valuable help to
mentor this project, I unchecked the "want to mentor" button there...
but again, if there's anyone else willing to help mentoring this
project, it would be awesome.

Timo.

Re: Mentors needed

[Timothée Giet]

Le 30/04/2020 à 21:38, Valorie Zimmerman a écrit :
> Hello folks, we have a project about porting a QtQuickControls module
> to QtQuickControls2 with only one mentor who marked "I want to mentor"
> on the GSoC webapp.
>
> If you have already signed into the GSoC webapp as a mentor, and would
> like to help out with this project, please mark "I want to mentor" in
> the app.
>
> If you have the skills needed to mentor but have not yet logged into
> the app, please: 
>
> 1. ensure that you are subscribed to KDE-Soc-Mentor mail list [1]
>
> 2. write to kde-soc-managem...@kde.org
>  and ask to be invited to the webapp.
>
> Thanks!
>
> Valorie
>
> 1. https://mail.kde.org/mailman/listinfo/kde-soc-mentor
>
> -- 
> http://about.me/valoriez - pronouns: she/her
>
>
I may not be the best mentor this project, but as GCompris would benefit
a lot from the output of this proposal (this missing module is the main
blocker we have to migrate to QtQuickControls2), I'm ok to backup-mentor
it... At least I can provide generic advices and testing.

But some help from someone more specialist of Qt internals would be welcome!

Timothée

Mentors needed

[Valorie Zimmerman]

Hello folks, we have a project about porting a QtQuickControls module to
QtQuickControls2 with only one mentor who marked "I want to mentor" on the
GSoC webapp.

If you have already signed into the GSoC webapp as a mentor, and would like
to help out with this project, please mark "I want to mentor" in the app.

If you have the skills needed to mentor but have not yet logged into the
app, please:

1. ensure that you are subscribed to KDE-Soc-Mentor mail list [1]

2. write to kde-soc-managem...@kde.org and ask to be invited to the webapp.

Thanks!

Valorie

1. https://mail.kde.org/mailman/listinfo/kde-soc-mentor

-- 
http://about.me/valoriez - pronouns: she/her

Re: Information regarding upcoming Gitlab Migration: clarifications

[Ben Cooksley]

On Fri, May 1, 2020 at 5:58 AM Nate Graham  wrote:
>
>
>
> On 4/30/20 11:43 AM, Aleix Pol wrote:
> > 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.
>
> True, but if you're a new contributor, presumably our infrastructure
> would do the right thing the first time and you wouldn't need to use any
> migration script, right?

That is correct.

>
> Nate

Cheers,
Ben

Re: Information regarding upcoming Gitlab Migration: clarifications

[Ben Cooksley]

On Fri, May 1, 2020 at 6:04 AM Ivan Čukić  wrote:
>
> > 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.
>
> +1 to both sentiments - that projects should have different names and that
> this is a bit off topic for the gitlab migration.

The projects *DO* have very different names. That *HAS NOT* changed.
To use the example Bhushan gave above, one is called Plasma Mobile
Dialer and the other one is called Maui Dialer.

With the current git.kde.org setup, we have a flat namespace, so all
repositories if the name appears to be generic (as dialer is) have to
be namespaced by prefixing of the repository name.

With Gitlab however we will now namespaces that group repositories,
making the prefixing unnecessary and as some projects have complained
about, duplicative.

Otherwise you end up with plasma-mobile/plasma-mobile-dialer as your
path, which just looks silly.

>
> Cheers,
> Ivan
>
>

Regards,
Ben

>
> --
> dr Ivan Čukić
> i...@cukic.co, https://cukic.co/
> gpg key fingerprint: 8FE4 D32F 7061 EA9C 8232  07AE 01C6 CE2B FF04 1C12
>
>

Re: Information regarding upcoming Gitlab Migration: clarifications

[Ben Cooksley]

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

Re: Information regarding upcoming Gitlab Migration: clarifications

[Ivan Čukić]

> 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.

+1 to both sentiments - that projects should have different names and that 
this is a bit off topic for the gitlab migration.

Cheers,
Ivan



-- 
dr Ivan Čukić
i...@cukic.co, https://cukic.co/
gpg key fingerprint: 8FE4 D32F 7061 EA9C 8232  07AE 01C6 CE2B FF04 1C12

Re: Information regarding upcoming Gitlab Migration: clarifications

[Nate Graham]

On 4/30/20 11:43 AM, Aleix Pol wrote:

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.


True, but if you're a new contributor, presumably our infrastructure 
would do the right thing the first time and you wouldn't need to use any 
migration script, right?


Nate

Re: Information regarding upcoming Gitlab Migration: clarifications

[Aleix Pol]

On Wed, Apr 29, 2020 at 12:25 PM Bhushan Shah  wrote:
>
> Good afternoon,
>
> [Please keep sysad...@kde.org list or bs...@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.

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

Re: Information regarding upcoming Gitlab Migration

[Nate Graham]

If I'm understanding things, we have solutions to most or all of the 
objections raised so far:


- Projects will be allowed to live in--or at least appear in--multiple 
top-level groups (e.g. plasma-framework could appear in both the 
Frameworks top-level group and also the Plasma top-level group)


- kdesrc-build and other scripts can be updated to allow people to 
easily check out repos using git prefixes (e.g. so that something like 
`git clone kde:dolphin` will still work regardlyss of a project's 
underlying group)


- cgit will continue to exist for three weeks to provide some transition 
time


- Each repo can have its own workboard in addition to the single 
group-level workboard


If the above are accurate, then I firmly support the proposal.

As for the actual grouping, I think it makes sense to have top-level 
groups for Frameworks, Plasma, PIM, etc. as originally proposed. I can 
support putting apps into category-specific groups (e.g. Multimedia, 
Office, Graphics, Games, etc) as long as apps could appear in multiple 
groups if needed for the case of apps that logically span boundaries 
(e.g. repos for PlaMo apps could appear in both the Plasma Mobile 
top-level group and also the relevant app group).



Nate

Re: KDE's Feel-Good Bulletin, Issue #01

[Nate Graham]

Thanks for the positivity in these trying times!

Nate


On 4/27/20 6:16 AM, Aniqa Khokhar wrote:

Dear KDE Community Members,

It's official: You are amazing.

And you don't have to take it from me -- here are some of the more positive
reactions from users we have had this week:

--
" Finally, I found the best desktop environment for me. It's modern, highly
customizable and well optimized. @kdecommunity KDE Plasma is amazing!"

-- Juan José Quiroz O. on Twitter (https://twitter.com/juanjqo/status/
1252109821559668736)
--
"Thank you for all your work."

-- Vance W. on LinkedIn 
(https://www.linkedin.com/feed/update/urn:li:activity:

6659074456079613952?
commentUrn=urn%3Ali%3Acomment%3A%28activity%3A6659074456079613952%2C6659399380723912704%29)
--
"The best desktop environment"

-- Claudio Grassi on LinkedIn (https://www.linkedin.com/feed/update/
urn:li:activity:6659074456079613952?
commentUrn=urn%3Ali%3Acomment%3A%28activity%3A6659074456079613952%2C6659864226674290688%29)
--
"Marvelous! KDE is the world's digital treasure."

-- redboygoes2town on Reddit (https://www.reddit.com/r/kde/comments/g6mbc1/
dolphin_kdes_file_manager_improvements_gestures/fob5o0r/)
--
"sudo pacman -S kdenlive 🙂"

-- Radwan Programer on Facebook (https://www.facebook.com/kde/posts/
10157555246413918)
--

Regards,

Aniqa Khokhar
--
Promotion & Communication

www:http://kde.org 
Mastodon:https://mastodon.technology/@kde
Facebook:https://www.facebook.com/kde/
Twitter:https://twitter.com/kdecommunity
LinkedIn:https://www.linkedin.com/company/kde

Re: Information regarding upcoming Gitlab Migration: clarifications

[Marco Martin]

+1
Those proposals seems sensible to me

-- 
Marco Martin

On Wed, Apr 29, 2020 at 12:25 PM Bhushan Shah  wrote:
>
> Good afternoon,
>
> [Please keep sysad...@kde.org list or bs...@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.
>
> - 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"
>
> - 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!
>
> [1] 
> https://cgit.kde.org/sysadmin/repo-metadata.git/tree/projects-invent?h=bshah/invent
>
> --
> Bhushan Shah
> http://blog.bshah.in
> IRC Nick : bshah on Freenode
> GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11