Information regarding upcoming Gitlab Migration
bcooksley at kde.org
Sun May 3 00:10:57 BST 2020
On Sun, May 3, 2020 at 2:13 AM Michał Policht <michal at policht.pl> wrote:
> 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).
I have now relocated CuteHMI within the proposed layout to SDK.
The initial allocation to applications/ was done based on it's
position at the moment in playground/base/
> 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.
There are no hard and fast rules for categorisation.
Libraries that are only suitable for a specific purpose (like Games)
could certainly go in Games.
In general we'd expect maintainers to indicate a preference when
> On 4/27/20 3:40 AM, Bhushan Shah wrote:
> > [Please keep sysadmin at kde.org list or bshah at 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 .
> > 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
> >  https://cgit.kde.org/sysadmin/repo-metadata.git/tree/projects-invent?h=bshah/invent
More information about the kde-core-devel