Re: Information regarding upcoming Gitlab Migration
On Fri, May 1, 2020 at 10:14 PM Ben Cooksley wrote: > On Sat, May 2, 2020 at 6:17 AM Alexander Potashev > wrote: > > I have a similar use case. Sometimes I need to share a URL to a > > project. For this purpose I used to share e.g. > > https://cgit.kde.org/releaseme.git/about > > > > Does this migration make such permalinks impossible? > > > > > > From what I see, we lose permalinks because > > 1. cgit.kde.org will be discontinued > > We provide the commits.kde.org redirector for permanent links. > Anywhere needing a long life link to a particular repository, commit, > etc (like documentation) should be using these links and not anything > else. This is helpful. Thank you Ben! -- Alexander Potashev
Re: Information regarding upcoming Gitlab Migration
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
Re: Information regarding upcoming Gitlab Migration
On Sun, May 3, 2020 at 2:13 AM Michał Policht 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 > > >
Re: Information regarding upcoming Gitlab Migration: clarifications
On Fri, May 01, 2020 at 09:25:18AM -0400, Allen Winter wrote: > On Thursday, April 30, 2020 5:15:43 PM EDT Albert Astals Cid wrote: > > El dijous, 30 d’abril de 2020, a les 21:31:02 CEST, Ben Cooksley va > > escriure: > > > On Fri, May 1, 2020 at 6:04 AM Ivan Čukić wrote: > > > > > > > > > We have made a big fuss in the past about having different projects > > > > > that do the same thing and now we'll have that but also we'll have > > > > > several projects with the same name? > > > > > It really feels off to me and I wonder if this is related to the move > > > > > to > > > > > gitlab. > > > > > > > > +1 to both sentiments - that projects should have different names and > > > > that > > > > this is a bit off topic for the gitlab migration. > > > > > > The projects *DO* have very different names. That *HAS NOT* changed. > > > To use the example Bhushan gave above, one is called Plasma Mobile > > > Dialer and the other one is called Maui Dialer. > > > > > > With the current git.kde.org setup, we have a flat namespace, so all > > > repositories if the name appears to be generic (as dialer is) have to > > > be namespaced by prefixing of the repository name. > > > > > > With Gitlab however we will now namespaces that group repositories, > > > making the prefixing unnecessary and as some projects have complained > > > about, duplicative. > > > > > > Otherwise you end up with plasma-mobile/plasma-mobile-dialer as your > > > path, which just looks silly. > > > > Am I the only person that just has all the repos on the same folder? I > > thought it was the common thing to do :? > > > I use kdesrc-build and I see the repos in a hierarchy. > In particular, I like frameworks in frameworks in kdepim in kde/pim > > I don't see that I'm setting any special "layout in a hierarchy" option in my > kdesrc-buildrc So it's been a few months since we had switched the default, but since it's clearly an invasive change, the way we addressed it was to make the flat hierarchy a default for new users (who use either of the 'quick config' schemes like kdesrc-build-setup or kdesrc-build --initial-setup), but to leave the built-in default unchanged. So in essence, existing kdesrc-build users (who had a folder-based layout by default unless they went out of their way to find the right option) saw no change, but new users would have that option pre-set for them in the config. Regards, - Michael Pyne
