Information regarding upcoming Gitlab Migration

[Ben Cooksley]

On Tue, Apr 28, 2020 at 1:46 AM Nate Graham <nate at kde.org> wrote:
>
>
>
> 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.

Sorry, but I don't think that will be a problem in reality.
Historically, back in the Subversion era, we had no choice but to
assign things to modules
(multimedia/graphics/office/network/games/etc) and we made that work
without much in the way of problems.

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

Given the complaints we have had around Phabricator, I can assure you
that tags/labels will not work.

People won't understand them, and we will have discoverability issues
with them especially for newcomers.

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

Regards,
Ben