Information regarding upcoming Gitlab Migration
michal-PMmaGtoiPtfVItvQsEIGlw at public.gmane.org
Sat May 2 15:13:06 BST 2020
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 public.gmane.org list or bshah-RoXCvvDuEio at public.gmane.org in the CC for
> 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: https://invent.kde.org/kde/knetwalk
> - Subgroups under top-level group: In this option we would have a groups
> under KDE namespace: https://invent.kde.org/kde/games/knetwalk
> - Groups at top level: In this option we would establish a series of
> groups at the top level, e.g. https://invent.kde.org/games/knetwalk
> 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
> - 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 .
> 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 https://invent.kde.org.
> Bhushan for sysadmin team
>  https://cgit.kde.org/sysadmin/repo-metadata.git/tree/projects-invent?h=bshah/invent
More information about the kde-core-devel