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
