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.
Regards
Michał
On 4/27/20 3:40 AM, Bhushan Shah wrote:
[Please keep sysad...@kde.org list or bs...@kde.org 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: 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
instance)
- Makes the most semantic sense, as the ‘KDE’ top level group suggested
in option 2 is duplicative considering the Gitlab instance is under
kde.org.
- 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 https://invent.kde.org.
Thanks!
Bhushan for sysadmin team
[1]
https://cgit.kde.org/sysadmin/repo-metadata.git/tree/projects-invent?h=bshah/invent
