Information regarding upcoming Gitlab Migration

[Nate Graham]

On 4/27/20 4:38 AM, Aleix Pol wrote:
> 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?

Trying to categorize everything into a single group cannot succeed 
because many projects could logically belong to multiple groups (e.g 
plasma-framework is a framework that's a part of Plasma; Discover is an 
app that's a part of Plasma; kdenetwork-filesharing and kio-extras are 
libraries that are distributed via the apps release service). I foresee 
endless pointless arguments about the best group for something to live in.

Let's step back: do we have to put every repo inside a group in the 
first place? Is it solely so you can look at a nice list of all open 
merge requests for PIM/Frameworks/etc? If so, perhaps this workflow 
could be approximated with tags instead or group assignments instead

We create many very granular groups for the purposes of organizing teams 
and and performing code review (e.g. Plasma, KWin, Frameworks, PIM, 
Krita, Dolphin, Okular, VDG, etc.) and then every new merge request 
could receive a tag or assignee corresponding to its relevant code 
review groups (e.g. merge requests for kio and kio-extras could get get 
tagged with both "Frameworks", and "Dolphin"; plasma-frameworks MRs 
could get tagged with both "Plasma" and "Frameworks", and so on).

So +1 for a single top-level group I suppose.

Nate