On Sun, May 3, 2020 at 2:13 AM Michał Policht <mic...@policht.pl> wrote: > > Hi all,
Hi Michal, > > 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 requesting repositories. > > Regards > Michał Cheers, Ben > > > 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 > > >