Information regarding upcoming Gitlab Migration

Michał Policht michal-PMmaGtoiPtfVItvQsEIGlw at
Sat May 2 15:13:06 BST 2020

Hi all,

Sorry for late response, but project "cutehmi" fits into "sdk" category 
better than "applications" (technically it's a framework, but I guess 
"frameorks" is reserved for well integrated KDE Frameworks).

Speaking generally on subject, categorization is always problematic. 
Categories often are fuzzy, they overlap, element can match more than 
one type/category/group at the same time and there are many criteria by 
which you could partition a set of elements.

Maybe for future reference, it would be good if there was some 
explanation on how these groups are created. From what I can see large 
projects organized into subprojects have dedicated groups (e.g. plasma, 
kdevelop). There are groups based on project status (e.g. unmaintained, 
historical). Then we have a division, which seems to be based on use 
case from development applicability perspective (e.g. libraries, 
frameworks, sdk). Then we have applications divided into something like 
user interests (e.g. multimedia, games, office, education). Since you 
mention that project may belong to many groups it would be nice to 
clarify, if for example game-oriented library (which occupies 
"libraries") fits into "games" group as well or.... is "games" group 
reserved for end-user applications only.


On 4/27/20 3:40 AM, Bhushan Shah wrote:
> [Please keep sysadmin-RoXCvvDuEio at list or bshah-RoXCvvDuEio at in the CC for
> replies]
> Hello Community members,
> In view of upcoming Gitlab migration, we sysadmin team wants to share
> the recommended structuring for the repositories on Gitlab.
> We had multiple options,
> - Flat structure: In this option we would have everything under one
>    single namespace/group:
> - Subgroups under top-level group: In this option we would have a groups
>    under KDE namespace:
> - Groups at top level: In this option we would establish a series of
>    groups at the top level, e.g.
> We have discussed this with small but representative group of
> contributors or maintainers, and based on their suggestions, we
> recommend that we go with option 3. Having sub-groups at top level will
> allow us to,
> - Provides good visibility on all reviews, tasks and other items within
>    the groups/modules we define
> - Provides improvements to discoverability of projects
> - Makes it possible for groups of projects to establish a group level
>    task board should it fit their needs (for tracking a release for
>    instance)
> - Makes the most semantic sense, as the ‘KDE’ top level group suggested
>    in option 2 is duplicative considering the Gitlab instance is under
> - The discoverability of projects is maximised, as there is no need to
>    open the top level ‘KDE’ group before going into the subgroup.
> I've worked on draft "move" of the current set of the repositories in
> their respective subgroups at the repo-metadata project's branch [1].
> You can browse the directory structure to get idea of how final
> structure on Gitlab would look like.
> If we don't have any objections we would like to implement this next
> week and move projects to
> Thanks!
> Bhushan for sysadmin team
> [1]

More information about the kde-core-devel mailing list