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
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
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 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
On 5/1/20 2:09 PM, Ben Cooksley wrote: Unfortunately sharing of projects/repositories across groups does not impact on tasks and reviews. This means that merge requests for Planet (which is currently shared with "KDE") do not show up in the list of merge requests for "KDE". Sharing repositories allows for a global listing only. Are you saying that if we put plasma-framework in Plasma and share it with the Plasma group, then its MRs won't show up in the Plasma group's MR list? And that if we put it in the Plasma group and share it with the Frameworks group, then its MRs won't show up in the Frameworks group's MR list? If so, that seems like it defeats one of the points of sharing a project/repo across groups. :( Is this fixed in EE, or is it just a bug affecting all versions? Nate
Re: Information regarding upcoming Gitlab Migration
On Sat, May 2, 2020 at 9:04 AM Nate Graham wrote: > > On 5/1/20 2:09 PM, Ben Cooksley wrote: > > Unfortunately sharing of projects/repositories across groups does not > > impact on tasks and reviews. > > This means that merge requests for Planet (which is currently shared > > with "KDE") do not show up in the list of merge requests for "KDE". > > > > Sharing repositories allows for a global listing only. > Are you saying that if we put plasma-framework in Plasma and share it > with the Plasma group, then its MRs won't show up in the Plasma group's > MR list? And that if we put it in the Plasma group and share it with the > Frameworks group, then its MRs won't show up in the Frameworks group's > MR list? That is correct. > > If so, that seems like it defeats one of the points of sharing a > project/repo across groups. :( > > Is this fixed in EE, or is it just a bug affecting all versions? It affects all versions. > > Nate Regards, Ben
Re: Information regarding upcoming Gitlab Migration
On Sat, May 2, 2020 at 6:17 AM Alexander Potashev wrote: > > On Tue, Apr 28, 2020 at 6:47 AM Bhushan Shah wrote: > > Use case 4 : Tom is a student in Germany and is interested in > > contributing to wikitolearn, and he asks where can I find code of the > > wikitolearn? > > Hi, Hi Alexander, > > 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. > 2. A once valid URL https://invent.kde.org/games/knetwalk may become > unavailable if the project moves to another group, for example > https://invent.kde.org/unmaintained/knetwalk > As mentioned by Nicolas, Gitlab maintains redirects so if such a move were to take place, the above links would continue to work. The only time this is not the case is when a new repository takes it's place. > -- > Alexander Potashev Cheers, Ben
Re: Information regarding upcoming Gitlab Migration
On Sat, May 2, 2020 at 2:33 AM Adriaan de Groot wrote: > > On 2020 mayula d. 1id 07:08:41 CEST Ben Cooksley wrote: > > On Fri, May 1, 2020 at 2:46 AM Nate Graham wrote: > > > If I'm understanding things, we have solutions to most or all of the > > > objections raised so far: > > > > > > - Projects will be allowed to live in--or at least appear in--multiple > > > top-level groups (e.g. plasma-framework could appear in both the > > > Frameworks top-level group and also the Plasma top-level group) > > > > Projects will have the option to appear in multiple groups yes. > > Forgive me for coming full circle on this discussion, but > > - a group can have at most one workboard > - a group offers some facilities for managing issues and reviews that cross > over repositories within that group > - a project (this is one-to-one with "repository", right?) can have as many > workboards as it likes Correct. Projects and repositories are the same thing, it is just a matter of terminology. > > If a project can appear in more than one group, isn't the whole distinction > between flat and namespaced a little .. The ability for a project to appear in other groups is subject to some limitations. See https://invent.kde.org/groups/kde/-/shared for a list of repositories currently shared with "KDE" > > well, how would this proposal fly? > > - Put everything in a single group called "kde" (this matches proposal 2 if I > still remember the original numbering right -- flat, but not at top-level) Proposal 2 had the groupings within a larger "KDE" group, rather than at top level. Proposal 1 was fully flat, just dump everything in one group. > - Other groups hold things from "kde" (this matches proposal 3, giving more > structure / hierarchy) > > People browsing *top* level would see group "kde" (for all I care, bookmark > that one as "I want to browse the list of 1442 repositories") and a bunch of > logical groups based on how the community organizes itself. People working > inside a specific group can do their workboardy-things and focus on the > repositories for that group, while people with an overall interest go to the > KDE group. > Unfortunately sharing of projects/repositories across groups does not impact on tasks and reviews. This means that merge requests for Planet (which is currently shared with "KDE") do not show up in the list of merge requests for "KDE". Sharing repositories allows for a global listing only. > > > Somehow I get the feeling that we started with some technical limitations > which were driving particular choices, where those limitations aren't exactly > what we assumed that they were, and now it looks to me like those limitations > do not have to meaningfully impact *any* of the choices. > > (*if* my understanding is correct; I've been wrong enough times already today) > > [ade] Cheers, Ben
Re: Information regarding upcoming Gitlab Migration
> On 1 May 2020, at 15:17, Alexander Potashev wrote: > > On Tue, Apr 28, 2020 at 6:47 AM Bhushan Shah wrote: >> Use case 4 : Tom is a student in Germany and is interested in >> contributing to wikitolearn, and he asks where can I find code of the >> wikitolearn? > > Hi, > > 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 > 2. A once valid URL https://invent.kde.org/games/knetwalk may become > unavailable if the project moves to another group, for example > https://invent.kde.org/unmaintained/knetwalk As I understand it, games/knetwalk will become a redirect to unmaintained/knetwalk, so the old link will still work. This is handled by GitLab automatically. Even on gitlab.com, if you rename a repository on your personal account or transfer it to another group or user, the old name will forward to the new one. -- Nicolás
Re: Information regarding upcoming Gitlab Migration
On Tue, Apr 28, 2020 at 6:47 AM Bhushan Shah wrote: > Use case 4 : Tom is a student in Germany and is interested in > contributing to wikitolearn, and he asks where can I find code of the > wikitolearn? Hi, 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 2. A once valid URL https://invent.kde.org/games/knetwalk may become unavailable if the project moves to another group, for example https://invent.kde.org/unmaintained/knetwalk -- Alexander Potashev
Re: Information regarding upcoming Gitlab Migration: clarifications
On 5/1/20 9:02 AM, Johan Ouwerkerk wrote: No, that is not the default. Actually, it is: https://invent.kde.org/kde/kdesrc-build/-/blob/master/kdesrc-build-setup#L389 and download all repos into ~/kde/src without any of the levels of hierarchy. But it is sufficiently common that there is a dedicated setting for it: `ignore-kde-structure`. Kinda does what it says on the tin ;) Yes, and this setting is set by default. :) Nate
Re: Information regarding upcoming Gitlab Migration: clarifications
Ben Cooksley ha scritto: > On Fri, May 1, 2020 at 4:38 PM Nate Graham wrote: >> >> >> >> On 4/30/20 5:59 PM, Aleix Pol wrote: >>> El jue., 30 de abr. de 2020 a la(s) 18:15, Albert Astals Cid 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 do too >> >> Same here. kdesrc-build's default settings do this, and download all >> repos into ~/kde/src without any of the levels of hierarchy. This would >> seem to require unique repo names, no? > > Not necessarily. > > Git allows you to override the name that the local folder is called > when cloning, so there is no reason why we can't specify something in > the metadata to override the local name that the folder gets called in > your local checkout folder. > This would allow for example: > > - frameworks/kcoreaddons on Gitlab continues to be called > 'kcoreaddons' in your local checkout folder > - maui/dialer on Gitlab gets called 'maui-dialer' in your local checkout > folder > > This allows for the URLs on Gitlab to make sense, while simultaneously > allowing your local source checkout folders to continue to work in the > manner in which they do currently. > Note that we do not expect people to hit this in many cases - this is > about giving us the flexibility for the long term without imposing > unnecessary bureaucracy and limits on projects within the KDE > umbrella. > > Automated tooling such as kdesrc-build and the proposed clone script > (that searches in namespaces) should be able to handle this without > much issue. > In the case of manually done clones, it is reasonable to expect people > to know what they're doing with their clones, and name them > appropriately in the event they have a collision. > > Does this sound acceptable? I'd like to add that this would solve an issue we have on the translation side. Right now, a few translation files use the repository names as the base part of the template file name. For example, the translation files for the desktop and json files, which are called ._desktop_.po(t) and ._json_.po(t) respectively. In the case where the repository name is not unique we would need to record the expected name for the template somewhere. If this information is added to the repository metadata, would have scripty rely on that and don't need to write it down somewhere else. So yes, if you can please add this optional override which sets a unique name to the metadata, that would help, thanks! -- Luigi
Re: Information regarding upcoming Gitlab Migration: clarifications
On Fri, May 1, 2020 at 6:38 AM Nate Graham wrote: > > On 4/30/20 5:59 PM, Aleix Pol wrote: > > El jue., 30 de abr. de 2020 a la(s) 18:15, Albert Astals Cid > >> 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 do too > > Same here. kdesrc-build's default settings do this, > No, that is not the default. By default the hierarchy is mirrored. > and download all > repos into ~/kde/src without any of the levels of hierarchy. > But it is sufficiently common that there is a dedicated setting for it: `ignore-kde-structure`. Kinda does what it says on the tin ;) > This would > seem to require unique repo names, no? > Yes, it does. Also whether the hierarchy is preserved locally or not, kdesrc-build currently requires that the leaf names ($repo.git) be unique. It cannot fully and consistently distinguish between a maui/dialer and a plasma-mobile/dialer because at certain points in Perl we map to/from module names which are mapped onto those leaf names (i.e. both would be considered "dialer" and it would be anybody's guess at this point what you'd get if you did a `kdesrc-build dialer`). Might be fixable, but is definitely not trivial and would require people to help review and test. Also would require some "cleverness" to preserve the ability to refer to modules by their leaf names when possible (i.e. continuing to be able to do `kdesrc-build kate`), otherwise kdesrc-build becomes a *lot* less user friendly all of a sudden. Regards, - Johan
Re: Information regarding upcoming Gitlab Migration: clarifications
On Fri, May 1, 2020 at 7:18 AM Ben Cooksley wrote: > > On Fri, May 1, 2020 at 4:38 PM Nate Graham wrote: > > > > > > > > On 4/30/20 5:59 PM, Aleix Pol wrote: > > > El jue., 30 de abr. de 2020 a la(s) 18:15, Albert Astals Cid > > >> 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 do too > > > > Same here. kdesrc-build's default settings do this, and download all > > repos into ~/kde/src without any of the levels of hierarchy. This would > > seem to require unique repo names, no? > > Not necessarily. > > Git allows you to override the name that the local folder is called > when cloning, so there is no reason why we can't specify something in > the metadata to override the local name that the folder gets called in > your local checkout folder. > This would allow for example: > > - frameworks/kcoreaddons on Gitlab continues to be called > 'kcoreaddons' in your local checkout folder > - maui/dialer on Gitlab gets called 'maui-dialer' in your local checkout > folder > > This allows for the URLs on Gitlab to make sense, while simultaneously > allowing your local source checkout folders to continue to work in the > manner in which they do currently. > Note that we do not expect people to hit this in many cases - this is > about giving us the flexibility for the long term without imposing > unnecessary bureaucracy and limits on projects within the KDE > umbrella. > > Automated tooling such as kdesrc-build and the proposed clone script > (that searches in namespaces) should be able to handle this without > much issue. > In the case of manually done clones, it is reasonable to expect people > to know what they're doing with their clones, and name them > appropriately in the event they have a collision. > > Does this sound acceptable? Okay, if that's necessary, we'll have to do it. We'll appreciate simpler bureaucracy. Aleix
Re: Information regarding upcoming Gitlab Migration
On 2020 mayula d. 1id 07:08:41 CEST Ben Cooksley wrote: > On Fri, May 1, 2020 at 2:46 AM Nate Graham wrote: > > If I'm understanding things, we have solutions to most or all of the > > objections raised so far: > > > > - Projects will be allowed to live in--or at least appear in--multiple > > top-level groups (e.g. plasma-framework could appear in both the > > Frameworks top-level group and also the Plasma top-level group) > > Projects will have the option to appear in multiple groups yes. Forgive me for coming full circle on this discussion, but - a group can have at most one workboard - a group offers some facilities for managing issues and reviews that cross over repositories within that group - a project (this is one-to-one with "repository", right?) can have as many workboards as it likes If a project can appear in more than one group, isn't the whole distinction between flat and namespaced a little .. well, how would this proposal fly? - Put everything in a single group called "kde" (this matches proposal 2 if I still remember the original numbering right -- flat, but not at top-level) - Other groups hold things from "kde" (this matches proposal 3, giving more structure / hierarchy) People browsing *top* level would see group "kde" (for all I care, bookmark that one as "I want to browse the list of 1442 repositories") and a bunch of logical groups based on how the community organizes itself. People working inside a specific group can do their workboardy-things and focus on the repositories for that group, while people with an overall interest go to the KDE group. Somehow I get the feeling that we started with some technical limitations which were driving particular choices, where those limitations aren't exactly what we assumed that they were, and now it looks to me like those limitations do not have to meaningfully impact *any* of the choices. (*if* my understanding is correct; I've been wrong enough times already today) [ade] signature.asc Description: This is a digitally signed message part.
Re: Information regarding upcoming Gitlab Migration: clarifications
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
Re: Information regarding upcoming Gitlab Migration
Thanks for the clarifications, Ben. Then I think the original proposal is perfectly reasonable and I fully support it. Nate
Re: Information regarding upcoming Gitlab Migration: clarifications
On 4/30/20 11:17 PM, Ben Cooksley wrote: Not necessarily. Git allows you to override the name that the local folder is called when cloning, so there is no reason why we can't specify something in the metadata to override the local name that the folder gets called in your local checkout folder. This would allow for example: - frameworks/kcoreaddons on Gitlab continues to be called 'kcoreaddons' in your local checkout folder - maui/dialer on Gitlab gets called 'maui-dialer' in your local checkout folder This allows for the URLs on Gitlab to make sense, while simultaneously allowing your local source checkout folders to continue to work in the manner in which they do currently. Note that we do not expect people to hit this in many cases - this is about giving us the flexibility for the long term without imposing unnecessary bureaucracy and limits on projects within the KDE umbrella. Automated tooling such as kdesrc-build and the proposed clone script (that searches in namespaces) should be able to handle this without much issue. In the case of manually done clones, it is reasonable to expect people to know what they're doing with their clones, and name them appropriately in the event they have a collision. Does this sound acceptable? A little weird, but probably acceptable. I suppose it's no worse than having discover build an executable called "plasma-discover", which trips me up like five times a day :) Nate
Re: Information regarding upcoming Gitlab Migration: clarifications
On 4/30/20 5:59 PM, Aleix Pol wrote: El jue., 30 de abr. de 2020 a la(s) 18:15, Albert Astals Cid 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 do too Same here. kdesrc-build's default settings do this, and download all repos into ~/kde/src without any of the levels of hierarchy. This would seem to require unique repo names, no? The group categorization we've been discussing may be useful on the web UI for newcomers, but it has no value for your source checkout folder IMO, where it just makes it slightly more annoying to navigate from one repo to another. Nate
Re: Information regarding upcoming Gitlab Migration: clarifications
On Fri, May 1, 2020 at 4:38 PM Nate Graham wrote: > > > > On 4/30/20 5:59 PM, Aleix Pol wrote: > > El jue., 30 de abr. de 2020 a la(s) 18:15, Albert Astals Cid > >> 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 do too > > Same here. kdesrc-build's default settings do this, and download all > repos into ~/kde/src without any of the levels of hierarchy. This would > seem to require unique repo names, no? Not necessarily. Git allows you to override the name that the local folder is called when cloning, so there is no reason why we can't specify something in the metadata to override the local name that the folder gets called in your local checkout folder. This would allow for example: - frameworks/kcoreaddons on Gitlab continues to be called 'kcoreaddons' in your local checkout folder - maui/dialer on Gitlab gets called 'maui-dialer' in your local checkout folder This allows for the URLs on Gitlab to make sense, while simultaneously allowing your local source checkout folders to continue to work in the manner in which they do currently. Note that we do not expect people to hit this in many cases - this is about giving us the flexibility for the long term without imposing unnecessary bureaucracy and limits on projects within the KDE umbrella. Automated tooling such as kdesrc-build and the proposed clone script (that searches in namespaces) should be able to handle this without much issue. In the case of manually done clones, it is reasonable to expect people to know what they're doing with their clones, and name them appropriately in the event they have a collision. Does this sound acceptable? > > The group categorization we've been discussing may be useful on the web > UI for newcomers, but it has no value for your source checkout folder > IMO, where it just makes it slightly more annoying to navigate from one > repo to another. > > Nate Cheers, Ben
Re: Information regarding upcoming Gitlab Migration
On Fri, May 1, 2020 at 2:46 AM Nate Graham wrote: > > If I'm understanding things, we have solutions to most or all of the > objections raised so far: > > - Projects will be allowed to live in--or at least appear in--multiple > top-level groups (e.g. plasma-framework could appear in both the > Frameworks top-level group and also the Plasma top-level group) Projects will have the option to appear in multiple groups yes. > > - kdesrc-build and other scripts can be updated to allow people to > easily check out repos using git prefixes (e.g. so that something like > `git clone kde:dolphin` will still work regardlyss of a project's > underlying group) The syntax will probably be slightly different to that, but the concept is correct yes. > > - cgit will continue to exist for three weeks to provide some transition > time Correct. > > - Each repo can have its own workboard in addition to the single > group-level workboard Correct, just one small clarification: each project (repository) can have multiple workboards, there is no limit to this. Groups are limited to a single workboard. > > If the above are accurate, then I firmly support the proposal. > > As for the actual grouping, I think it makes sense to have top-level > groups for Frameworks, Plasma, PIM, etc. as originally proposed. I can > support putting apps into category-specific groups (e.g. Multimedia, > Office, Graphics, Games, etc) as long as apps could appear in multiple > groups if needed for the case of apps that logically span boundaries > (e.g. repos for PlaMo apps could appear in both the Plasma Mobile > top-level group and also the relevant app group). > > > Nate Cheers, Ben
Re: Information regarding upcoming Gitlab Migration: clarifications
On Fri, May 1, 2020 at 1:08 AM Nicolás Alvarez wrote: > > El jue., 30 de abr. de 2020 a la(s) 18:15, Albert Astals Cid > (aa...@kde.org) escribió: > > > > 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 do too > Oh, your local path could be anywhere. It doesn't even need the same > name, you can put it in the same folder as the rest and call it > dial-thingy :) And then you'll have to have a modified build script to account for thingy because KDE can't stay consistent at naming. I suggest not to use the gitlab transition to make such an important change. Aleix
Re: Information regarding upcoming Gitlab Migration: clarifications
El jue., 30 de abr. de 2020 a la(s) 18:15, Albert Astals Cid (aa...@kde.org) escribió: > > 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 :? Oh, your local path could be anywhere. It doesn't even need the same name, you can put it in the same folder as the rest and call it dial-thingy :) This is about the server path (eg. the clone URL) looking redundant: invent.kde.org/plasma-mobile/plasma-mobile-dialer. -- Nicolás
Re: Information regarding upcoming Gitlab Migration: clarifications
On 4/30/20 11:43 AM, Aleix Pol wrote: IMHO needing tools ad-hoc to KDE development can be a barrier of entrance. I feel like these things make us look distant, it's important that people's skills translate automatically when they want to get started. True, but if you're a new contributor, presumably our infrastructure would do the right thing the first time and you wouldn't need to use any migration script, right? Nate
Re: Information regarding upcoming Gitlab Migration: clarifications
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 :? Cheers, Albert > > > > > Cheers, > > Ivan > > > > > > Regards, > Ben > > > > > -- > > dr Ivan Čukić > > i...@cukic.co, https://cukic.co/ > > gpg key fingerprint: 8FE4 D32F 7061 EA9C 8232 07AE 01C6 CE2B FF04 1C12 > > > > >
Re: Information regarding upcoming Gitlab Migration: clarifications
On Fri, May 1, 2020 at 5:58 AM Nate Graham wrote: > > > > On 4/30/20 11:43 AM, Aleix Pol wrote: > > IMHO needing tools ad-hoc to KDE development can be a barrier of entrance. > > I feel like these things make us look distant, it's important that > > people's skills translate automatically when they want to get started. > > True, but if you're a new contributor, presumably our infrastructure > would do the right thing the first time and you wouldn't need to use any > migration script, right? That is correct. > > Nate Cheers, Ben
Re: Information regarding upcoming Gitlab Migration: clarifications
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. > > Cheers, > Ivan > > Regards, Ben > > -- > dr Ivan Čukić > i...@cukic.co, https://cukic.co/ > gpg key fingerprint: 8FE4 D32F 7061 EA9C 8232 07AE 01C6 CE2B FF04 1C12 > >
Re: Information regarding upcoming Gitlab Migration: clarifications
On Fri, May 1, 2020 at 5:44 AM Aleix Pol wrote: > > On Wed, Apr 29, 2020 at 12:25 PM Bhushan Shah wrote: > > > > Good afternoon, > > > > [Please keep sysad...@kde.org list or bs...@kde.org in the CC for > > replies] > > > > I want to clarify some bits for which we have gotten a questions about, > > > > - Non unique naming: There's some teams which prefer if we dropped the > > namespace- part from their name which we have added. While currently > > this does not result in the naming conflict right away, we realize > > this will cause it at one point, for example, > > > > maui-dialer -> maui/dialer > > plasma-dialer -> plasma-mobile/dialer > > > > To minimize the impact of the Gitlab move we won't be doing such > > renames which introduce non-unique names right away. But we would > > prefer if the existing tooling or infrastructure is ready for this > > kind of cases at later point. Only way to enforce non-unique naming is > > one big KDE/ subgroup which we want to avoid. > > > > Current naming in the repo-metadata branch[1] I've pointed does not > > reflect those renames, as we are not planning to do those renames > > right away during gitlab move, but at a later stage. > > 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. > > > - Existing configurations: we want to reduce impact on existing release > > schedule, and existing developer workflow, therefore we will continue > > to privide the existing anongit.kde.org and git.kde.org (although this > > will be read-only) with current flat structuring for 3 weeks after > > actual migration, which will keep the existing scripts/clones working > > enough to give developers time to change to the new structure. > > > > We will also try to provide a script which allows you to migrate your > > existing clones to new repo paths and as mentioned by Ben in other > > message, potentially a git-kde script which would allow you to clone > > individual repository without knowing it's namespace (provided that > > there is no conflict of it's name). like "git kde karchive" > > IMHO needing tools ad-hoc to KDE development can be a barrier of entrance. > I feel like these things make us look distant, it's important that > people's skills translate automatically when they want to get started. These tools are being provided as migration assistants. New contributors won't have a problem, as they'll be used to finding the project at games/knetwalk (to use an example). > > > - Translations: we will co-ordinate with the translations team to let > > them adapt their tooling to updated structure as this requires changes > > on their side how translations are stored in svn repository > > Thanks! :) Cheers, Ben
Re: Information regarding upcoming Gitlab Migration: clarifications
> 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. Cheers, Ivan -- dr Ivan Čukić i...@cukic.co, https://cukic.co/ gpg key fingerprint: 8FE4 D32F 7061 EA9C 8232 07AE 01C6 CE2B FF04 1C12
Re: Information regarding upcoming Gitlab Migration: clarifications
On Wed, Apr 29, 2020 at 12:25 PM Bhushan Shah wrote: > > Good afternoon, > > [Please keep sysad...@kde.org list or bs...@kde.org in the CC for > replies] > > I want to clarify some bits for which we have gotten a questions about, > > - Non unique naming: There's some teams which prefer if we dropped the > namespace- part from their name which we have added. While currently > this does not result in the naming conflict right away, we realize > this will cause it at one point, for example, > > maui-dialer -> maui/dialer > plasma-dialer -> plasma-mobile/dialer > > To minimize the impact of the Gitlab move we won't be doing such > renames which introduce non-unique names right away. But we would > prefer if the existing tooling or infrastructure is ready for this > kind of cases at later point. Only way to enforce non-unique naming is > one big KDE/ subgroup which we want to avoid. > > Current naming in the repo-metadata branch[1] I've pointed does not > reflect those renames, as we are not planning to do those renames > right away during gitlab move, but at a later stage. 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. > - Existing configurations: we want to reduce impact on existing release > schedule, and existing developer workflow, therefore we will continue > to privide the existing anongit.kde.org and git.kde.org (although this > will be read-only) with current flat structuring for 3 weeks after > actual migration, which will keep the existing scripts/clones working > enough to give developers time to change to the new structure. > > We will also try to provide a script which allows you to migrate your > existing clones to new repo paths and as mentioned by Ben in other > message, potentially a git-kde script which would allow you to clone > individual repository without knowing it's namespace (provided that > there is no conflict of it's name). like "git kde karchive" IMHO needing tools ad-hoc to KDE development can be a barrier of entrance. I feel like these things make us look distant, it's important that people's skills translate automatically when they want to get started. > - Translations: we will co-ordinate with the translations team to let > them adapt their tooling to updated structure as this requires changes > on their side how translations are stored in svn repository Thanks! :)
Re: Information regarding upcoming Gitlab Migration
If I'm understanding things, we have solutions to most or all of the objections raised so far: - Projects will be allowed to live in--or at least appear in--multiple top-level groups (e.g. plasma-framework could appear in both the Frameworks top-level group and also the Plasma top-level group) - kdesrc-build and other scripts can be updated to allow people to easily check out repos using git prefixes (e.g. so that something like `git clone kde:dolphin` will still work regardlyss of a project's underlying group) - cgit will continue to exist for three weeks to provide some transition time - Each repo can have its own workboard in addition to the single group-level workboard If the above are accurate, then I firmly support the proposal. As for the actual grouping, I think it makes sense to have top-level groups for Frameworks, Plasma, PIM, etc. as originally proposed. I can support putting apps into category-specific groups (e.g. Multimedia, Office, Graphics, Games, etc) as long as apps could appear in multiple groups if needed for the case of apps that logically span boundaries (e.g. repos for PlaMo apps could appear in both the Plasma Mobile top-level group and also the relevant app group). Nate
Re: Information regarding upcoming Gitlab Migration
On 2020 prilula d. 28id 13:35:22 CEST Ben Cooksley wrote: > Would some form of git alias/custom command script that works similar > to the following be suitable? > > git kde-clone skrooge > > That script would then search the appropriate groups (ignoring any > personal repositories including forks), find the necessary repository > and perform the clone as appropriate for you. Should it find multiple > results it would output it's results and then exit with a failure > (giving you names and the clone urls to pick from manually) That'd actually be pretty cool. As a standalone script it'd be useful to migrate existing checkouts, so that's shooting two birds in one foot. And then you can have a somewhat structured namespace, still with simple lookup and unstructured names (until, as Bhushan points out in a different message in this thread, you get non-unique labels when decomposing structures names). [ade] signature.asc Description: This is a digitally signed message part.
Information regarding upcoming Gitlab Migration: clarifications
Good afternoon, [Please keep sysad...@kde.org list or bs...@kde.org in the CC for replies] I want to clarify some bits for which we have gotten a questions about, - Non unique naming: There's some teams which prefer if we dropped the namespace- part from their name which we have added. While currently this does not result in the naming conflict right away, we realize this will cause it at one point, for example, maui-dialer -> maui/dialer plasma-dialer -> plasma-mobile/dialer To minimize the impact of the Gitlab move we won't be doing such renames which introduce non-unique names right away. But we would prefer if the existing tooling or infrastructure is ready for this kind of cases at later point. Only way to enforce non-unique naming is one big KDE/ subgroup which we want to avoid. Current naming in the repo-metadata branch[1] I've pointed does not reflect those renames, as we are not planning to do those renames right away during gitlab move, but at a later stage. - Existing configurations: we want to reduce impact on existing release schedule, and existing developer workflow, therefore we will continue to privide the existing anongit.kde.org and git.kde.org (although this will be read-only) with current flat structuring for 3 weeks after actual migration, which will keep the existing scripts/clones working enough to give developers time to change to the new structure. We will also try to provide a script which allows you to migrate your existing clones to new repo paths and as mentioned by Ben in other message, potentially a git-kde script which would allow you to clone individual repository without knowing it's namespace (provided that there is no conflict of it's name). like "git kde karchive" - Translations: we will co-ordinate with the translations team to let them adapt their tooling to updated structure as this requires changes on their side how translations are stored in svn repository Thanks! [1] https://cgit.kde.org/sysadmin/repo-metadata.git/tree/projects-invent?h=bshah/invent -- Bhushan Shah http://blog.bshah.in IRC Nick : bshah on Freenode GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D signature.asc Description: PGP signature
Re: Information regarding upcoming Gitlab Migration
Um, guys… Google is your friend... I am a former KDE Games developer. I play KPatience quite a lot, as well as other games to keep my brain active, especially during COVID-19 lockdown. Recently I thought I could see where the answer lay to three bugs in the solver(s), two in the Forty Eight variant and one, very recently reported, in the Klondike variant. So I thought I would have a look at the source code to see if my hypotheses might be correct and maybe work out a patch. My first problem was to track down where the repos that I need are and how to clone read-only copies. I didn’t even know what websites they are on any more and KPatience is actually called kpat in the code (which I remembered). However I can google “source code KDE KPatience” and the pat repository comes up as the first hit, presumably because “KPatience” is used in the repository’s description. Again “… card games” got the repo as hit 2 and “… solitaire” (the American term for such games) got it as the first hit. I have also found that several of the tricky cases mentioned earlier in this thread can be resolved with Google search terms beginning “source code KDE xxx”. For example, seeing xxx as “Plasma Mobile” get the repo as hit 2. And just using “go” as xxx finds the Kigo repository as hit 3. Even a search with xxx = “loderunner” finds the KGoldRunner repository as hit 1, even though Loderunner is not mentioned in the repository’s description. I wonder how far down repositories Google indexing goes. Even using xxx = “lode runner” (2 words), as suggested by Google, finds the KGoldrunner Handbook, though not the repository. Still, a smart newbie might guess the name used for that type of game in KDE and refine his source code search accordingly. Even after I found the kpat repository, I could not understand where the souce code was getting the card decks it uses. I knew from memory that they are in some library somewhere, but there is no libkdecards. Googling with xxx = something like “library cards” found the cards as a sub-directory of the libkdegames repository. So my suggestion is to keep whatever categories you like, including multiple categories as required, as long as the category names are in plain English, not KDE jargon. In addition, please continue to pepper repository descriptions with search terms (words) that are easy for laymen and non-core KDE developers to find. Another possibility is to construct (automatically) a text-file “catalog” with one line for each of the 1000+ repositories, containing (at least) the repo name and description, but maybe other keywords. Then people could just “grep” and “sort” it to find what they wanted. My 2 cents, Ian Wadham. > On 28 Apr 2020, at 2:46 pm, Bhushan Shah wrote: > > Hi Olivier, > > On Mon, Apr 27, 2020 at 10:49:46PM +0200, Olivier Churlaud wrote: >>> Because in order to search for something, you need to know it exists. >>> >>> If you are just casually browsing, then the search can't help you. >> >> I don't think people casually browse our repos. What use case is more likely >> to happen and do we want to support? > > We don't really want to discard use-cases just because it does not suit > our workflow. That is not how we are going to gain new contributors, we > should value each contribution, be it drive-by contribution, or focused > contribution towards one single project. > >> Use case 1 : Jerry learns about KDE and go in their forge in the Multimedia >> section. After carefully reading the code of two applications and three libs >> he starts contributing to Elisa. >> >> Use case 2 : While using her Ubuntu installation of Elisa / while reading on >> reddit about Elisa, Jerry decides to try to contribute to this project/fix >> this bug that itches her and searches for it in KDE's forge. > > Let me add a some more usecases, some of which I've been dealing with in > project I maintain. > > Use case 3 : Tom comes in Plasma Mobile channel and asks for Plasma > Mobile applications source code > > Use case 4 : Tom is a student in Germany and is interested in > contributing to wikitolearn, and he asks where can I find code of the > wikitolearn? > > Suggestion offered by sysadmin team does not cater to one single > use-case, but offers a way to provide a solution to all 4 usecases. For > Plasma Mobile team or Wikitolearn team it would be much easier to refer > contributors to the https://invent.kde.org/plasma-mobile or > https://invent.kde.org/wikitolearn then tell them to go to > https://invent.kde.org/KDE and search for the tag wikitolearn or Plasma > Mobile. > >> On the other hand, I think the discussion about spotting open merge requests >> (in a derived thread from this one) should be answered, being by relevant >> tags, subgroups or whatever. > > (super personal note) > > Ironically, Usecase 1 is how I started contributing to KDE 7 years back. > While I was inspired by battery monitor re-design in 4.11 release, I
Re: Information regarding upcoming Gitlab Migration
There are a whole bunch of considerations and use-cases being discussed at once in this thread, and Leinir's post made me think a bit about different actors can interact with "the collection of repositories". One actor is "tooling", as Albert has pointed out. Whatever the resulting structure is, it needs to be communicated to tool authors on time for tools to be updated, released, and rolled out for use. Tools mentioned so far: - kdesrc-build - i18n / scripty - release scripts The tools don't have An Opinion regarding the layout, they just need to be updated. A tool-like actor that I don't think has been mentioned so far is "existing checkouts". I have a src/kde with all the bits I've looked at "recently". There may even be some SVN checkouts there -- I'm willing to forget about those. Surprising and annoying me every time I update those sometime in the future is not good, but it's only going to annoy me once (per repo, so at most 143 times for my clones). I'd be *vaguely* worried about existing crontabs and automatic jobs that we've forgotten about, or which others have forgotten about. Those aren't fixable in the face of any changes to repositories, anyway. Turning to human actors, who are the more interesting ones, On 2020 prilula d. 28id 10:38:36 CEST Dan Leinir Turthra Jensen wrote: > On Monday, 27 April 2020 21:25:09 BST Albert Astals Cid wrote: > > El dilluns, 27 d’abril de 2020, a les 13:58:02 CEST, Bhushan Shah va > > > On Mon, Apr 27, 2020 at 12:38:42PM +0200, Aleix Pol wrote: > > > > Does this mean that to clone it we'll have to go "git clone > > > > kde:games/knetwalk" or something along the lines? > > > > If that's the case I'd much prefer if we didn't do this, at the moment > > > > it's already uncomfortable for me to remember the URL for some of the > > > > repos (e.g. is it sysadmin/ or not?), this will only increase the > > > > problem and I personally don't see the advantage. Humans come in all shapes and sizes; here's one called Aleix who likes to remember the name of a thing, one single label. (Ironic: this particular Aleix is also labelled "Aleix Pol" and possibly "Aleix Pol Gonzales") The question I'd ask is "in what **context** do you need to remember the URL of a repo?" and for that matter: "why is 'knetwalk' an obvious thing to remember, and 'games/knetwalk' not-obvious?" Context here can mean many things. In this thread we've had mentioned: - people just browsing and wanting A Big List Here a hierarchical approach means more clicks and navigating a tree, rather than a flat structure. - people browsing for a known label Using ^F in a flat list or some search field (see also Ian Wadham's message just now) doesn't seem *that* different to me, although I've got to give ^F the benefit of speed and simplicity. - developers sharing a task list and reviews .. probably more. Some of these roles have, depending on the chosen solution, problems that can be solved with a *technical* addition (bigflatlistofrepositories.kde.org .. or whatever), others are going to need a social solution. Personally, I'm with Leinir here: > Just adding my "i don't use kdesrc-build, and git clone kde:x everything > myself" voice, here. Perhaps it's the "old school", but kdesrc-build doesn't do anything for me. I'm intermittently interested in the source of some random part of KDE -- generally because it's mentioned on IRC -- and then I need that source where I can look at it. Whether it's 'git clone' or 'kdesrc-build --just-the-source- please' doesn't matter much. If there's any compiling to be done, the less magic there is between me and the compile, the better. So, yeah: `git clone kde:x` all the way, but I'm also not really invested in the structure of the label x, or the precise configuration of kde:. > Now, if a simple(ish) script can be created to make > something akin to the kde: rewriting work, even if what it really does is to > search gitlab and create a clone with the appropriate command, i could deal > with that, but having the ability to simply ask for the project name is > more than a little useful. I think we shouldn't underestimate how names are a social construct, though: the current flat structure comes after a structured SVN naming epoch. But I'd totes +1 a search-and-redirector, especially if it means I can write `git clone kde:peruse` and the resulting .git/config has followed the redirects and whatnot and ended up with `url: kdeforreal:audio/peruse` (That said, bigflatlistofrepositories.kde.org .. or maybe call it cgit.kde.org .. could be a particular view onto gitlab which does flattening and search, but only if there's people around to create it and maintain it) [ade] signature.asc Description: This is a digitally signed message part.
Re: Information regarding upcoming Gitlab Migration
On Monday, 27 April 2020 21:25:09 BST Albert Astals Cid wrote: > El dilluns, 27 d’abril de 2020, a les 13:58:02 CEST, Bhushan Shah va escriure: > > In part I am mostly re-iterating what Ben already mentioned in different > > messages. > > > > On Mon, Apr 27, 2020 at 12:38:42PM +0200, Aleix Pol wrote: > > > Does this mean that to clone it we'll have to go "git clone > > > kde:games/knetwalk" or something along the lines? > > > > Yes > > > > [Rest of message is with sysadmin hat off and as a developer] > > > > > If that's the case I'd much prefer if we didn't do this, at the moment > > > it's already uncomfortable for me to remember the URL for some of the > > > repos (e.g. is it sysadmin/ or not?), this will only increase the > > > problem and I personally don't see the advantage. > > > > I do agree that it maybe small inconvience, but let's be honest, most of > > us have been using kdesrc-build or some kind of automated tooling for > > building everything, apart from very rare case we never have to manually > > clone any of KDE repository, at least it is true for me personally. I am > > not sure about others. > > Please let's refrain from saying things like "most of us have been using > kdesrc-build" when you don't have any data to back that up. > > Cheers, > Albert Just adding my "i don't use kdesrc-build, and git clone kde:x everything myself" voice, here. Now, if a simple(ish) script can be created to make something akin to the kde: rewriting work, even if what it really does is to search gitlab and create a clone with the appropriate command, i could deal with that, but having the ability to simply ask for the project name is more than a little useful. -- ..dan / leinir.. http://leinir.dk/
Re: Information regarding upcoming Gitlab Migration
Hi Adriaan, On Tue, Apr 28, 2020 at 01:08:33PM +0200, Adriaan de Groot wrote: > A tool-like actor that I don't think has been mentioned so far is "existing > checkouts". I have a src/kde with all the bits I've looked at "recently". > There may even be some SVN checkouts there -- I'm willing to forget about > those. Surprising and annoying me every time I update those sometime in the > future is not good, but it's only going to annoy me once (per repo, so at > most > 143 times for my clones). We have a plan to provide a script which can change remotes in existing clones. (It would take a top-level directory path for all your clones). > Perhaps it's the "old school", but kdesrc-build doesn't do anything for me. > I'm intermittently interested in the source of some random part of KDE -- > generally because it's mentioned on IRC -- and then I need that source where > I > can look at it. Whether it's 'git clone' or 'kdesrc-build --just-the-source- > please' doesn't matter much. > > If there's any compiling to be done, the less magic there is between me and > the compile, the better. > > So, yeah: `git clone kde:x` all the way, but I'm also not really invested in > the structure of the label x, or the precise configuration of kde:. > > > > Now, if a simple(ish) script can be created to make > > something akin to the kde: rewriting work, even if what it really does is to > > search gitlab and create a clone with the appropriate command, i could deal > > with that, but having the ability to simply ask for the project name is > > more than a little useful. > > I think we shouldn't underestimate how names are a social construct, though: > the current flat structure comes after a structured SVN naming epoch. But I'd > totes +1 a search-and-redirector, especially if it means I can write `git > clone kde:peruse` and the resulting .git/config has followed the redirects > and > whatnot and ended up with `url: kdeforreal:audio/peruse` One thing to remember is, you can't really have a dynamic insteadOf URL setup. Besides, even if we had a everything under KDE namespace I'd find a setup for this weird enough. Let's assume that everything is under invent.kde.org/kde (and invent.kde.org/sysadmin and invent.kde.org/websites as it is right now). Now you add a following snippet in gitconfig, [url "https://invent.kde.org/KDE/;] insteadOf = kde: [url "g...@invent.kde.org:KDE/"] pushInsteadOf = kde: Which is slightly modified version of the existing kde: URL helper shown here, https://community.kde.org/Sysadmin/GitKdeOrgManual#Let_Git_rewrite_URL_prefixes Now this is perfectly fine for the something which is kde/ so you can do git clone kde:krita and it would happily replace 'kde:' part with 'https://invent.kde.org/KDE/' and would clone 'https://invent.kde.org/KDE/krita' But, now things get interesting when you want to clone the docs-krita-org which is in the websites/ namespace. We will have to keep this things in separate namespace for policy reasons (and same goes for sysadmin stuff). How would you clone docs-krita-org? git clone kde:../websites/krita-org ? add a separate prefix for websites and sysadmin? Let's assume that you added snippet for sysadmin and websites, it's just 8 more lines after all, [url "https://invent.kde.org/websites/;] insteadOf = websites: [url "g...@invent.kde.org:websites/"] pushInsteadOf = websites: [url "https://invent.kde.org/sysadmin/;] insteadOf = sysadmin: [url "g...@invent.kde.org:sysadmin/"] pushInsteadOf = sysadmin: Does this solve all use-cases? I believe no, it still does not support the personal repositories of users. So you also need to add 4 more lines for your own user, and 4 for each user whose repository you want to clone. What our workflow with the kde: prefix so far had been really useful I agree, and I will miss it, but with departure of gitolite which allowed repositories at top-level, we can't easily support this, and we have to accept it. Perhaps solution suggested by Ben in his email could be useful instead and in addition generic invent: snippet which does not include any namespace. [url "https://invent.kde.org/;] insteadOf = invent: [url "g...@invent.kde.org:"] pushInsteadOf = invent: > (That said, bigflatlistofrepositories.kde.org .. or maybe call it > cgit.kde.org > .. could be a particular view onto gitlab which does flattening and search, > but only if there's people around to create it and maintain it) Just to clarify, sysadmins have no plan to support or maintain the cgit instance once we migrate to Gitlab. Thanks -- Bhushan Shah http://blog.bshah.in IRC Nick : bshah on Freenode GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D signature.asc Description: PGP signature
Re: Information regarding upcoming Gitlab Migration
On Tue, Apr 28, 2020 at 11:09 PM Adriaan de Groot wrote: > > There are a whole bunch of considerations and use-cases being discussed at > once in this thread, and Leinir's post made me think a bit about different > actors can interact with "the collection of repositories". > > One actor is "tooling", as Albert has pointed out. Whatever the resulting > structure is, it needs to be communicated to tool authors on time for tools to > be updated, released, and rolled out for use. Tools mentioned so far: > - kdesrc-build > - i18n / scripty > - release scripts > The tools don't have An Opinion regarding the layout, they just need to be > updated. > > A tool-like actor that I don't think has been mentioned so far is "existing > checkouts". I have a src/kde with all the bits I've looked at "recently". > There may even be some SVN checkouts there -- I'm willing to forget about > those. Surprising and annoying me every time I update those sometime in the > future is not good, but it's only going to annoy me once (per repo, so at most > 143 times for my clones). > > I'd be *vaguely* worried about existing crontabs and automatic jobs that we've > forgotten about, or which others have forgotten about. Those aren't fixable in > the face of any changes to repositories, anyway. > > > Turning to human actors, who are the more interesting ones, > > On 2020 prilula d. 28id 10:38:36 CEST Dan Leinir Turthra Jensen wrote: > > On Monday, 27 April 2020 21:25:09 BST Albert Astals Cid wrote: > > > El dilluns, 27 d’abril de 2020, a les 13:58:02 CEST, Bhushan Shah va > > > > On Mon, Apr 27, 2020 at 12:38:42PM +0200, Aleix Pol wrote: > > > > > Does this mean that to clone it we'll have to go "git clone > > > > > kde:games/knetwalk" or something along the lines? > > > > > > If that's the case I'd much prefer if we didn't do this, at the moment > > > > > it's already uncomfortable for me to remember the URL for some of the > > > > > repos (e.g. is it sysadmin/ or not?), this will only increase the > > > > > problem and I personally don't see the advantage. > > > Humans come in all shapes and sizes; here's one called Aleix who likes to > remember the name of a thing, one single label. (Ironic: this particular Aleix > is also labelled "Aleix Pol" and possibly "Aleix Pol Gonzales") The question > I'd ask is "in what **context** do you need to remember the URL of a repo?" > and for that matter: "why is 'knetwalk' an obvious thing to remember, and > 'games/knetwalk' not-obvious?" > > Context here can mean many things. In this thread we've had mentioned: > - people just browsing and wanting A Big List >Here a hierarchical approach means more clicks and navigating a tree, >rather than a flat structure. > - people browsing for a known label >Using ^F in a flat list or some search field (see also Ian Wadham's >message just now) doesn't seem *that* different to me, although I've >got to give ^F the benefit of speed and simplicity. > - developers sharing a task list and reviews > > .. probably more. Some of these roles have, depending on the chosen solution, > problems that can be solved with a *technical* addition > (bigflatlistofrepositories.kde.org .. or whatever), others are going to need a > social solution. > > > > Personally, I'm with Leinir here: > > > Just adding my "i don't use kdesrc-build, and git clone kde:x everything > > myself" voice, here. > > Perhaps it's the "old school", but kdesrc-build doesn't do anything for me. > I'm intermittently interested in the source of some random part of KDE -- > generally because it's mentioned on IRC -- and then I need that source where I > can look at it. Whether it's 'git clone' or 'kdesrc-build --just-the-source- > please' doesn't matter much. > > If there's any compiling to be done, the less magic there is between me and > the compile, the better. > > So, yeah: `git clone kde:x` all the way, but I'm also not really invested in > the structure of the label x, or the precise configuration of kde:. > > > > Now, if a simple(ish) script can be created to make > > something akin to the kde: rewriting work, even if what it really does is to > > search gitlab and create a clone with the appropriate command, i could deal > > with that, but having the ability to simply ask for the project name is > > more than a little useful. > > I think we shouldn't underestimate how names are a social construct, though: > the current flat structure comes after a structured SVN naming epoch. But I'd > totes +1 a search-and-redirector, especially if it means I can write `git > clone kde:peruse` and the resulting .git/config has followed the redirects and > whatnot and ended up with `url: kdeforreal:audio/peruse` Would some form of git alias/custom command script that works similar to the following be suitable? git kde-clone skrooge That script would then search the appropriate groups (ignoring any personal repositories including forks), find the necessary repository and perform the clone
Re: Information regarding upcoming Gitlab Migration
Hi Olivier, On Mon, Apr 27, 2020 at 10:49:46PM +0200, Olivier Churlaud wrote: > >Because in order to search for something, you need to know it exists. > > > >If you are just casually browsing, then the search can't help you. > > I don't think people casually browse our repos. What use case is more likely > to happen and do we want to support? We don't really want to discard use-cases just because it does not suit our workflow. That is not how we are going to gain new contributors, we should value each contribution, be it drive-by contribution, or focused contribution towards one single project. > Use case 1 : Jerry learns about KDE and go in their forge in the Multimedia > section. After carefully reading the code of two applications and three libs > he starts contributing to Elisa. > > Use case 2 : While using her Ubuntu installation of Elisa / while reading on > reddit about Elisa, Jerry decides to try to contribute to this project/fix > this bug that itches her and searches for it in KDE's forge. Let me add a some more usecases, some of which I've been dealing with in project I maintain. Use case 3 : Tom comes in Plasma Mobile channel and asks for Plasma Mobile applications source code Use case 4 : Tom is a student in Germany and is interested in contributing to wikitolearn, and he asks where can I find code of the wikitolearn? Suggestion offered by sysadmin team does not cater to one single use-case, but offers a way to provide a solution to all 4 usecases. For Plasma Mobile team or Wikitolearn team it would be much easier to refer contributors to the https://invent.kde.org/plasma-mobile or https://invent.kde.org/wikitolearn then tell them to go to https://invent.kde.org/KDE and search for the tag wikitolearn or Plasma Mobile. > On the other hand, I think the discussion about spotting open merge requests > (in a derived thread from this one) should be answered, being by relevant > tags, subgroups or whatever. (super personal note) Ironically, Usecase 1 is how I started contributing to KDE 7 years back. While I was inspired by battery monitor re-design in 4.11 release, I wanted to work on "something" so I did literally browse through various repositories to find something where my technical capabilities were enough to work on [1]. Back then it was projects.kde.org (chiliproject installation). [1] https://blog.bshah.in/2013/09/01/hello-planet/ -- Bhushan Shah http://blog.bshah.in IRC Nick : bshah on Freenode GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D signature.asc Description: PGP signature
Re: Information regarding upcoming Gitlab Migration
Hi Ingo, On Mon, Apr 27, 2020 at 03:46:13PM +0200, Ingo Klöcker wrote: > > > I'm sorry, but I don't think that this is solved by your proposal for the > > > KDE PIM projects because not everything related to KDE PIM (e.g. relevant > > > frameworks like kcontacts, kholidays, kpeople and soon kdav) will be in > > > the same group. The same is true for any project which uses some > > > frameworks, e.g. graphics and the imageformats framework or whatever > > > group kate and kwrite are going to end up in and the ktexteditor > > > framework. > > > > This is something which can be easily solved by Gitlab, Gitlab offers a > > solution where project can be shared with another group. > > > > So e.g. sharing kcontacts with kdepim should be possible, then all merge > > requests/issues from kcontacts would show up under pim as well. > > Great. So we could put all repos into an "all" group (e.g. rename kde to all) > and then have every subcommunity decide for themselves which repos they want > to see in their group. No, sadly this does not work, I just tested this, I have two different groups here - https://invent.kde.org/sysadmin/test/test1 - https://invent.kde.org/sysadmin/test/test2 test1 have a repo called foo under it, which is shared with the test2 group. When someone visits test2, they are not offered the list of the shared repositories but they are instead offered the empty page. One have to click on Shared repositories tab to actually see the list. https://invent.kde.org/groups/sysadmin/test/test2/-/shared This defeats the purpose of the creating subgroups (offering easy reachability). -- Bhushan Shah http://blog.bshah.in IRC Nick : bshah on Freenode GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D signature.asc Description: PGP signature
Re: Information regarding upcoming Gitlab Migration
Hi Nate, On Mon, Apr 27, 2020 at 07:45:23AM -0600, Nate Graham wrote: > Trying to categorize everything into a single group cannot succeed because > many projects could logically belong to multiple groups (e.g > plasma-framework is a framework that's a part of Plasma; Discover is an app > that's a part of Plasma; kdenetwork-filesharing and kio-extras are libraries > that are distributed via the apps release service). I foresee endless > pointless arguments about the best group for something to live in. I've agreed in previous threads that sometime our grouping is not perfect, but this is something we can improve instead of throwing idea of grouping out altogether. > Let's step back: do we have to put every repo inside a group in the first > place? Is it solely so you can look at a nice list of all open merge > requests for PIM/Frameworks/etc? If so, perhaps this workflow could be > approximated with tags instead or group assignments instead No goal is not just that you get nice list of all open merge requests or issues. Main goal is we want to offer user or potential contributors a list of closely related projects instead of list of all 1100+ projects we have. That would mean, If user wants to see all frameworks, or graphics applications, or multimedia applications, they can. The workflow, with labels you mention is trying to achieve a totally different goal then what we are trying to solve here. Labels/Tags are for sorting issues, and/or merge requests. They can't be reliable solution for the sorting of the multiple repositories. On technical side, Gitlab does not offer labels for projects, but setting called topic. You can see that in screenshot[1] linked. Besides, from home page there's no way to filter something for e.g "Graphics". nore project listing shows the tags alongside of the project names, also making use of this tags means that if user clicks this tags, what they are offered is *all* the repositories including forks of the repositories, which means when you search for graphics [2], you get many duplicative results and this is really not something discoverable. > We create many very granular groups for the purposes of organizing teams and > and performing code review (e.g. Plasma, KWin, Frameworks, PIM, Krita, > Dolphin, Okular, VDG, etc.) and then every new merge request could receive a > tag or assignee corresponding to its relevant code review groups (e.g. merge > requests for kio and kio-extras could get get tagged with both "Frameworks", > and "Dolphin"; plasma-frameworks MRs could get tagged with both "Plasma" and > "Frameworks", and so on). As explained above, while grouping repositories is trying to solve the merge requests/issue organization, it is not sole purpose of the suggested grouping, discoverability and reachability is the main issue we are trying to solve here. [1] https://i.imgur.com/h1L1A5H.png [2] https://i.imgur.com/ajOszEL.png -- Bhushan Shah http://blog.bshah.in IRC Nick : bshah on Freenode GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D signature.asc Description: PGP signature
Re: Information regarding upcoming Gitlab Migration
Le 27 avril 2020 22:33:12 GMT+02:00, Ben Cooksley a écrit : >On Tue, Apr 28, 2020 at 8:31 AM Albert Astals Cid >wrote: >> >> El dilluns, 27 d’abril de 2020, a les 13:19:07 CEST, Ben Cooksley va >escriure: >> > On Mon, Apr 27, 2020 at 11:12 PM Olivier Churlaud > wrote: >> > > >> > > Hi, >> > > >> > > Le lundi 27 avril 2020, 12:38:42 CEST Aleix Pol a écrit : >> > > > On Mon, Apr 27, 2020 at 3:41 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 >> > > > > >> > > >> > > Thank you for having options and talking to us before >implementing it. >> > > >> > > > > 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 >> > > > >> > > > Does this mean that to clone it we'll have to go "git clone >> > > > kde:games/knetwalk" or something along the lines? >> > > > >> > > > If that's the case I'd much prefer if we didn't do this, at the >moment >> > > > it's already uncomfortable for me to remember the URL for some >of the >> > > > repos (e.g. is it sysadmin/ or not?), this will only increase >the >> > > > problem and I personally don't see the advantage. >> > > > >> > > > e.g. Is okular graphics or office? Is gwenview plasma or >graphics? Is >> > > > krita graphics or its own thing? >> > > > >> > > > I really prefer when I don't have to guess this kind of things >when >> > > > fetching a repository. >> > > > >> > > >> > > I 100% agree with Aleix and I think it would also be detrimental >for discoverability, exactly for the examples Aleix just gave. >> > > >> > > We came back from this subgroups ideas some times ago : wiki >pages were hard to find because hidden under layers of groups. The same >was true for api documentations. Now everything is flat and I think >it's easier to find. >> > > >> > > Another bad message could also be sent by this: instead of >exposing Konsole or Ark as two applications under the KDE umbrella, it >would look like Utils for KDE, bringing back the KDE Desktop idea >(where every application is already store in a submenu). >> > > >> > > As someone wrote later, if I'm looking for a given application, >there is always the search function... >> > >> > That requires that you know it exists. We have 1,043 mainline >> > repositories at the moment, which translates to 53 pages of >projects >> > under a flat structure system. >> > Reality is nobody is going to page through that looking for >something. >> >> But they have gitlab search, don't they? > >They do yes. > >> >> I mean it's the solution you told Aleix to figure out if Okular was >inside graphics or okular. >> >> Why is search valid for one case and not for the other? > >Because in order to search for something,
Re: Information regarding upcoming Gitlab Migration
El dilluns, 27 d’abril de 2020, a les 3:40:01 CEST, Bhushan Shah va escriure: > [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. Anything that breaks kde:$repo will break the release-tools used for the monthly releases done by the release service and the l10n scripty scripts. If it ends up happening it would be good if such change is as far away as possible from a release so the scripts can be adapted timely and hopefully without mistakes. Cheers, Albert > > 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 Tue, Apr 28, 2020 at 8:31 AM Albert Astals Cid wrote: > > El dilluns, 27 d’abril de 2020, a les 13:19:07 CEST, Ben Cooksley va escriure: > > On Mon, Apr 27, 2020 at 11:12 PM Olivier Churlaud > > wrote: > > > > > > Hi, > > > > > > Le lundi 27 avril 2020, 12:38:42 CEST Aleix Pol a écrit : > > > > On Mon, Apr 27, 2020 at 3:41 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 > > > > > > > > > > > Thank you for having options and talking to us before implementing it. > > > > > > > > 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 > > > > > > > > Does this mean that to clone it we'll have to go "git clone > > > > kde:games/knetwalk" or something along the lines? > > > > > > > > If that's the case I'd much prefer if we didn't do this, at the moment > > > > it's already uncomfortable for me to remember the URL for some of the > > > > repos (e.g. is it sysadmin/ or not?), this will only increase the > > > > problem and I personally don't see the advantage. > > > > > > > > e.g. Is okular graphics or office? Is gwenview plasma or graphics? Is > > > > krita graphics or its own thing? > > > > > > > > I really prefer when I don't have to guess this kind of things when > > > > fetching a repository. > > > > > > > > > > I 100% agree with Aleix and I think it would also be detrimental for > > > discoverability, exactly for the examples Aleix just gave. > > > > > > We came back from this subgroups ideas some times ago : wiki pages were > > > hard to find because hidden under layers of groups. The same was true for > > > api documentations. Now everything is flat and I think it's easier to > > > find. > > > > > > Another bad message could also be sent by this: instead of exposing > > > Konsole or Ark as two applications under the KDE umbrella, it would look > > > like Utils for KDE, bringing back the KDE Desktop idea (where every > > > application is already store in a submenu). > > > > > > As someone wrote later, if I'm looking for a given application, there is > > > always the search function... > > > > That requires that you know it exists. We have 1,043 mainline > > repositories at the moment, which translates to 53 pages of projects > > under a flat structure system. > > Reality is nobody is going to page through that looking for something. > > But they have gitlab search, don't they? They do yes. > > I mean it's the solution you told Aleix to figure out if Okular was inside > graphics or okular. > > Why is search valid for one case and not for the other? Because in order to search for something, you need to know it exists. If you are just casually browsing, then the search can't
Re: Information regarding upcoming Gitlab Migration
El dilluns, 27 d’abril de 2020, a les 13:19:07 CEST, Ben Cooksley va escriure: > On Mon, Apr 27, 2020 at 11:12 PM Olivier Churlaud > wrote: > > > > Hi, > > > > Le lundi 27 avril 2020, 12:38:42 CEST Aleix Pol a écrit : > > > On Mon, Apr 27, 2020 at 3:41 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 > > > > > > > > Thank you for having options and talking to us before implementing it. > > > > > > 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 > > > > > > Does this mean that to clone it we'll have to go "git clone > > > kde:games/knetwalk" or something along the lines? > > > > > > If that's the case I'd much prefer if we didn't do this, at the moment > > > it's already uncomfortable for me to remember the URL for some of the > > > repos (e.g. is it sysadmin/ or not?), this will only increase the > > > problem and I personally don't see the advantage. > > > > > > e.g. Is okular graphics or office? Is gwenview plasma or graphics? Is > > > krita graphics or its own thing? > > > > > > I really prefer when I don't have to guess this kind of things when > > > fetching a repository. > > > > > > > I 100% agree with Aleix and I think it would also be detrimental for > > discoverability, exactly for the examples Aleix just gave. > > > > We came back from this subgroups ideas some times ago : wiki pages were > > hard to find because hidden under layers of groups. The same was true for > > api documentations. Now everything is flat and I think it's easier to find. > > > > Another bad message could also be sent by this: instead of exposing Konsole > > or Ark as two applications under the KDE umbrella, it would look like Utils > > for KDE, bringing back the KDE Desktop idea (where every application is > > already store in a submenu). > > > > As someone wrote later, if I'm looking for a given application, there is > > always the search function... > > That requires that you know it exists. We have 1,043 mainline > repositories at the moment, which translates to 53 pages of projects > under a flat structure system. > Reality is nobody is going to page through that looking for something. But they have gitlab search, don't they? I mean it's the solution you told Aleix to figure out if Okular was inside graphics or okular. Why is search valid for one case and not for the other? Cheers, Albert > > Please also see my point regarding listing merge requests at the group > level - you can see an example of what a flat structure ends up > looking like at https://gitlab.gnome.org/GNOME > > For those projects that span multiple repositories, you have just > denied them any chance or ability to see a listing of everything > related to their wider project. > > > > > Best regards, > > Olivier > > > Aleix > > > > > > Cheers, >
Re: Information regarding upcoming Gitlab Migration
El dilluns, 27 d’abril de 2020, a les 13:58:02 CEST, Bhushan Shah va escriure: > In part I am mostly re-iterating what Ben already mentioned in different > messages. > > On Mon, Apr 27, 2020 at 12:38:42PM +0200, Aleix Pol wrote: > > Does this mean that to clone it we'll have to go "git clone > > kde:games/knetwalk" or something along the lines? > > Yes > > [Rest of message is with sysadmin hat off and as a developer] > > > If that's the case I'd much prefer if we didn't do this, at the moment > > it's already uncomfortable for me to remember the URL for some of the > > repos (e.g. is it sysadmin/ or not?), this will only increase the > > problem and I personally don't see the advantage. > > I do agree that it maybe small inconvience, but let's be honest, most of > us have been using kdesrc-build or some kind of automated tooling for > building everything, apart from very rare case we never have to manually > clone any of KDE repository, at least it is true for me personally. I am > not sure about others. Please let's refrain from saying things like "most of us have been using kdesrc-build" when you don't have any data to back that up. Cheers, Albert
Re: Information regarding upcoming Gitlab Migration
On Tue, Apr 28, 2020 at 1:46 AM Nate Graham wrote: > > > > On 4/27/20 4:38 AM, Aleix Pol wrote: > > Does this mean that to clone it we'll have to go "git clone > > kde:games/knetwalk" or something along the lines? > > > > If that's the case I'd much prefer if we didn't do this, at the moment > > it's already uncomfortable for me to remember the URL for some of the > > repos (e.g. is it sysadmin/ or not?), this will only increase the > > problem and I personally don't see the advantage. > > > > e.g. Is okular graphics or office? Is gwenview plasma or graphics? Is > > krita graphics or its own thing? > > Trying to categorize everything into a single group cannot succeed > because many projects could logically belong to multiple groups (e.g > plasma-framework is a framework that's a part of Plasma; Discover is an > app that's a part of Plasma; kdenetwork-filesharing and kio-extras are > libraries that are distributed via the apps release service). I foresee > endless pointless arguments about the best group for something to live in. Sorry, but I don't think that will be a problem in reality. Historically, back in the Subversion era, we had no choice but to assign things to modules (multimedia/graphics/office/network/games/etc) and we made that work without much in the way of problems. > > Let's step back: do we have to put every repo inside a group in the > first place? Is it solely so you can look at a nice list of all open > merge requests for PIM/Frameworks/etc? If so, perhaps this workflow > could be approximated with tags instead or group assignments instead Given the complaints we have had around Phabricator, I can assure you that tags/labels will not work. People won't understand them, and we will have discoverability issues with them especially for newcomers. > > We create many very granular groups for the purposes of organizing teams > and and performing code review (e.g. Plasma, KWin, Frameworks, PIM, > Krita, Dolphin, Okular, VDG, etc.) and then every new merge request > could receive a tag or assignee corresponding to its relevant code > review groups (e.g. merge requests for kio and kio-extras could get get > tagged with both "Frameworks", and "Dolphin"; plasma-frameworks MRs > could get tagged with both "Plasma" and "Frameworks", and so on). > > So +1 for a single top-level group I suppose. > > Nate Regards, Ben
Re: Information regarding upcoming Gitlab Migration
Hello Bhushan! Thank you for you work on the Gitlab migration! The lists look good! Here are some ideas that I have, in case you think they can be considered before we transition: • The "applications" category is somewhat misleading to me: it does not include all KDE applications, and not all repositories in that category are applications either. Looking through the list of projects in there, I think they can be safely distributed across other categories. Most complicated there are IMO kate, dolphin, klook, konqueror, konsole and yakuake. Somehow terminal emulators, file managers and text editors feel like they belong to the same category, but I don't know how to call it; maybe "files"? • Tentative, but I think a category called "science" might make sense creating. Since KDE regularly attempts to promote usage of our software in scientific institutions, that wouldn't hurt either. E.g. Mark (an app for data science) doesn't really belong in "education", and I think is also true for labplot and rkward. • I see a category named "others". Looking at its contents, maybe it can be renamed to "community"? Looking forward to the move! Cheers, Ilya. Дата: Пн, 27 апр 2020 04:40:01 +0300 Bhushan Shah написал(а) [Please keep mailto:sysad...@kde.org list or mailto: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 -- Bhushan Shah http://blog.bshah.in IRC Nick : bshah on Freenode GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D
Re: Information regarding upcoming Gitlab Migration
On 4/27/20 7:52 AM, Nate Graham wrote: On 4/27/20 7:46 AM, Ingo Klöcker wrote: On Montag, 27. April 2020 14:10:55 CEST Bhushan Shah wrote: This is something which can be easily solved by Gitlab, Gitlab offers a solution where project can be shared with another group. So e.g. sharing kcontacts with kdepim should be possible, then all merge requests/issues from kcontacts would show up under pim as well. Great. So we could put all repos into an "all" group (e.g. rename kde to all) and then have every subcommunity decide for themselves which repos they want to see in their group. If this is possible, it seems like the best solution to me. I've just been informed that it's possible to have a project appear in multiple groups such that I could find plasma-frameworks in both the Frameworks and Plasma top-level groups. Therefore I rescind my objection and endorse having many top-level groups instead of a single flat top-level namespace, provided that we do put projects that are related to multiple groups into those multiple groups. Nate
Re: Information regarding upcoming Gitlab Migration
Hi, Le lundi 27 avril 2020, 12:38:42 CEST Aleix Pol a écrit : > On Mon, Apr 27, 2020 at 3:41 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 > > Thank you for having options and talking to us before implementing it. > > 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 > > Does this mean that to clone it we'll have to go "git clone > kde:games/knetwalk" or something along the lines? > > If that's the case I'd much prefer if we didn't do this, at the moment > it's already uncomfortable for me to remember the URL for some of the > repos (e.g. is it sysadmin/ or not?), this will only increase the > problem and I personally don't see the advantage. > > e.g. Is okular graphics or office? Is gwenview plasma or graphics? Is > krita graphics or its own thing? > > I really prefer when I don't have to guess this kind of things when > fetching a repository. > I 100% agree with Aleix and I think it would also be detrimental for discoverability, exactly for the examples Aleix just gave. We came back from this subgroups ideas some times ago : wiki pages were hard to find because hidden under layers of groups. The same was true for api documentations. Now everything is flat and I think it's easier to find. Another bad message could also be sent by this: instead of exposing Konsole or Ark as two applications under the KDE umbrella, it would look like Utils for KDE, bringing back the KDE Desktop idea (where every application is already store in a submenu). As someone wrote later, if I'm looking for a given application, there is always the search function... Best regards, Olivier > Aleix
Re: Information regarding upcoming Gitlab Migration
On Montag, 27. April 2020 14:10:55 CEST Bhushan Shah wrote: > [adding sysad...@kde.org in CC, please make sure you keep it in CC] > > On Mon, Apr 27, 2020 at 02:03:48PM +0200, Ingo Klöcker wrote: > > On Montag, 27. April 2020 13:19:07 CEST Ben Cooksley wrote: > > > That requires that you know it exists. We have 1,043 mainline > > > repositories at the moment, which translates to 53 pages of projects > > > under a flat structure system. > > > Reality is nobody is going to page through that looking for something. > > > > I have to disagree. Whenever I'm looking for a project I browse > > https://projects.kde.org/ (aka https://cgit.kde.org/). > > Using a simple Ctrl+F in my browser allowed me to find what I was looking > > for rather easily. > > > > Having to look into *several* subgroups (because I guess we all know from > > experience that any categorization into several groups never matches our > > expectation) would have been a pain in the ass. > > > > > Please also see my point regarding listing merge requests at the group > > > level > > > > This argument only holds if the subgroups match development teams. It does > > already break down if e.g. a KDE PIM developer wants to see merge requests > > for PIM related frameworks and for PIM applications. > > > > I have experienced exactly this problem at work were we have put repos of > > unrelated projects into different groups. It was extremely inconvenient > > that, while working on more than one project at the same time, I couldn't > > see all MRs I'm interested in on a single page. > > > > IMNSHO the groups in GitLab are not the right solution for gathering all > > repos some dev team, let alone individual devs, is/are interested in, > > because the assumption that different dev teams are interested in > > *disjoint* sets of repos is simply wrong. Moreover, the assumption that > > all members of some dev team are interested in exactly the same repos is > > equally wrong (even if most team members are probably interested in most > > of the same repos). > > > > And while the mapping group to dev team might make sense for something > > like > > plasma or frameworks or KDE PIM, I sure that it makes less or no sense for > > groups like graphics were different teams are working on different > > applications in the same group. > > > > > - you can see an example of what a flat structure ends up > > > looking like at https://gitlab.gnome.org/GNOME > > > > > > For those projects that span multiple repositories, you have just > > > denied them any chance or ability to see a listing of everything > > > related to their wider project. > > > > I'm sorry, but I don't think that this is solved by your proposal for the > > KDE PIM projects because not everything related to KDE PIM (e.g. relevant > > frameworks like kcontacts, kholidays, kpeople and soon kdav) will be in > > the same group. The same is true for any project which uses some > > frameworks, e.g. graphics and the imageformats framework or whatever > > group kate and kwrite are going to end up in and the ktexteditor > > framework. > > This is something which can be easily solved by Gitlab, Gitlab offers a > solution where project can be shared with another group. > > So e.g. sharing kcontacts with kdepim should be possible, then all merge > requests/issues from kcontacts would show up under pim as well. Great. So we could put all repos into an "all" group (e.g. rename kde to all) and then have every subcommunity decide for themselves which repos they want to see in their group. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Information regarding upcoming Gitlab Migration
Le lundi 27 avril 2020, 13:19:07 CEST Ben Cooksley a écrit : > On Mon, Apr 27, 2020 at 11:12 PM Olivier Churlaud > wrote: > > > > Hi, > > > > Le lundi 27 avril 2020, 12:38:42 CEST Aleix Pol a écrit : > > > On Mon, Apr 27, 2020 at 3:41 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 > > > > > > > > Thank you for having options and talking to us before implementing it. > > > > > > 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 > > > > > > Does this mean that to clone it we'll have to go "git clone > > > kde:games/knetwalk" or something along the lines? > > > > > > If that's the case I'd much prefer if we didn't do this, at the moment > > > it's already uncomfortable for me to remember the URL for some of the > > > repos (e.g. is it sysadmin/ or not?), this will only increase the > > > problem and I personally don't see the advantage. > > > > > > e.g. Is okular graphics or office? Is gwenview plasma or graphics? Is > > > krita graphics or its own thing? > > > > > > I really prefer when I don't have to guess this kind of things when > > > fetching a repository. > > > > > > > I 100% agree with Aleix and I think it would also be detrimental for > > discoverability, exactly for the examples Aleix just gave. > > > > We came back from this subgroups ideas some times ago : wiki pages were > > hard to find because hidden under layers of groups. The same was true for > > api documentations. Now everything is flat and I think it's easier to find. > > > > Another bad message could also be sent by this: instead of exposing Konsole > > or Ark as two applications under the KDE umbrella, it would look like Utils > > for KDE, bringing back the KDE Desktop idea (where every application is > > already store in a submenu). > > > > As someone wrote later, if I'm looking for a given application, there is > > always the search function... > > That requires that you know it exists. We have 1,043 mainline > repositories at the moment, which translates to 53 pages of projects > under a flat structure system. > Reality is nobody is going to page through that looking for something. > > Please also see my point regarding listing merge requests at the group > level - you can see an example of what a flat structure ends up > looking like at https://gitlab.gnome.org/GNOME > > For those projects that span multiple repositories, you have just > denied them any chance or ability to see a listing of everything > related to their wider project. Maybe the middle ground would be to have applications and standalone libraries stored flat, and things that go together in a group, the same we tried to achieve on api.kde.org by defining products (either a repo or a group of repos). I guess that you would have PIM/ Frameworks/
Re: Information regarding upcoming Gitlab Migration
On 4/27/20 7:46 AM, Ingo Klöcker wrote: On Montag, 27. April 2020 14:10:55 CEST Bhushan Shah wrote: This is something which can be easily solved by Gitlab, Gitlab offers a solution where project can be shared with another group. So e.g. sharing kcontacts with kdepim should be possible, then all merge requests/issues from kcontacts would show up under pim as well. Great. So we could put all repos into an "all" group (e.g. rename kde to all) and then have every subcommunity decide for themselves which repos they want to see in their group. If this is possible, it seems like the best solution to me. Nate
Re: Information regarding upcoming Gitlab Migration
On Mon, 27 Apr, 2020, 4:09 pm Aleix Pol, wrote: > On Mon, Apr 27, 2020 at 3:41 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 > > Does this mean that to clone it we'll have to go "git clone > kde:games/knetwalk" or something along the lines? > > If that's the case I'd much prefer if we didn't do this, at the moment > it's already uncomfortable for me to remember the URL for some of the > repos (e.g. is it sysadmin/ or not?), this will only increase the > problem and I personally don't see the advantage. > > e.g. Is okular graphics or office? Is gwenview plasma or graphics? Is > krita graphics or its own thing? > > I really prefer when I don't have to guess this kind of things when > fetching a repository. > > Aleix > This is technical so I would love to hear Sysadmin team's thoughts on this: Probably there can be a redirect system that lets us do git clone kde:knotifications and manages to redirect it to kde/frameworks/tier3/knotifications.git So we can clone and tinker with stuff as we normally do while the sysadmin team goes with the recommended system of setting up the repos. I think this should be possible because Invent already redirects my URLs which don't end with .git to .git ones. I might be wrong about my assumption that both things can work similarly. Best Piyush Aggarwal >
Re: Information regarding upcoming Gitlab Migration
On 4/27/20 4:38 AM, Aleix Pol wrote: Does this mean that to clone it we'll have to go "git clone kde:games/knetwalk" or something along the lines? If that's the case I'd much prefer if we didn't do this, at the moment it's already uncomfortable for me to remember the URL for some of the repos (e.g. is it sysadmin/ or not?), this will only increase the problem and I personally don't see the advantage. e.g. Is okular graphics or office? Is gwenview plasma or graphics? Is krita graphics or its own thing? Trying to categorize everything into a single group cannot succeed because many projects could logically belong to multiple groups (e.g plasma-framework is a framework that's a part of Plasma; Discover is an app that's a part of Plasma; kdenetwork-filesharing and kio-extras are libraries that are distributed via the apps release service). I foresee endless pointless arguments about the best group for something to live in. Let's step back: do we have to put every repo inside a group in the first place? Is it solely so you can look at a nice list of all open merge requests for PIM/Frameworks/etc? If so, perhaps this workflow could be approximated with tags instead or group assignments instead We create many very granular groups for the purposes of organizing teams and and performing code review (e.g. Plasma, KWin, Frameworks, PIM, Krita, Dolphin, Okular, VDG, etc.) and then every new merge request could receive a tag or assignee corresponding to its relevant code review groups (e.g. merge requests for kio and kio-extras could get get tagged with both "Frameworks", and "Dolphin"; plasma-frameworks MRs could get tagged with both "Plasma" and "Frameworks", and so on). So +1 for a single top-level group I suppose. Nate
Re: Information regarding upcoming Gitlab Migration
In part I am mostly re-iterating what Ben already mentioned in different messages. On Mon, Apr 27, 2020 at 12:38:42PM +0200, Aleix Pol wrote: > Does this mean that to clone it we'll have to go "git clone > kde:games/knetwalk" or something along the lines? Yes [Rest of message is with sysadmin hat off and as a developer] > If that's the case I'd much prefer if we didn't do this, at the moment > it's already uncomfortable for me to remember the URL for some of the > repos (e.g. is it sysadmin/ or not?), this will only increase the > problem and I personally don't see the advantage. I do agree that it maybe small inconvience, but let's be honest, most of us have been using kdesrc-build or some kind of automated tooling for building everything, apart from very rare case we never have to manually clone any of KDE repository, at least it is true for me personally. I am not sure about others. [Very non-scientific test, I did "history | grep 'git clone kde:'" on my machine and only instances were 4, websites/conf-kde-in, kde-build-metadata, sysadmin/irc-notifications, sysadmin/binary-factory-tooling, rest was automatically downloaded by the kdesrc-build] Anyway, getting back on topic, while this option gives some initial setbacks in our own personal workflow, let's look at bigger picture. Let's say I am the new developer who wants to contribute to frameworks. One of reason we are switching to gitlab is better onboarding, current state is that we have cgit.kde.org as a repository browser. By default I open it, I get the sorting by name, first repository is abakus. Commits as old as 14 years(!), after that some more mix of unmaintained repositories and scrolling almost 1.5 page, I get greeted with baloo, first framework in whole list. Let's just assume that name based sorting is bad idea, and we sort by activity instead. Here I get much better results, first framework is solid. But at same time if I was looking for SDK, kdevelop would appear at 3rd scroll-page. Here cgit is able to show many items in single scroll page, you can be assured that on gitlab it would not show kdevelop in first 6-7 pages. You might wonder why search does not help here? So problem with search is you need to know what you are looking for[*], but drive-by contributors, or users who are simply browsing our repositories won't know what they are looking for, they are simply trying to find a thing that interests them. Giving them categories/groups allows them to focus on topic they like and they can contribute to. > e.g. Is okular graphics or office? Is gwenview plasma or graphics? Is > krita graphics or its own thing? I agree that categories are something which we can improve upon, but this is something which we can improve upon, rejecting idea of categories just because 7-10 repos are at wrong place is ultimately not going to do anything good. > I really prefer when I don't have to guess this kind of things when > fetching a repository. [*] Ironically, in your case search would be helpful as you know you are looking for knetwalk so you can just add it and search it -- Bhushan Shah http://blog.bshah.in IRC Nick : bshah on Freenode GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D signature.asc Description: PGP signature
Re: Information regarding upcoming Gitlab Migration
On Mon, Apr 27, 2020 at 11:12 PM Olivier Churlaud wrote: > > Hi, > > Le lundi 27 avril 2020, 12:38:42 CEST Aleix Pol a écrit : > > On Mon, Apr 27, 2020 at 3:41 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 > > > > > Thank you for having options and talking to us before implementing it. > > > > 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 > > > > Does this mean that to clone it we'll have to go "git clone > > kde:games/knetwalk" or something along the lines? > > > > If that's the case I'd much prefer if we didn't do this, at the moment > > it's already uncomfortable for me to remember the URL for some of the > > repos (e.g. is it sysadmin/ or not?), this will only increase the > > problem and I personally don't see the advantage. > > > > e.g. Is okular graphics or office? Is gwenview plasma or graphics? Is > > krita graphics or its own thing? > > > > I really prefer when I don't have to guess this kind of things when > > fetching a repository. > > > > I 100% agree with Aleix and I think it would also be detrimental for > discoverability, exactly for the examples Aleix just gave. > > We came back from this subgroups ideas some times ago : wiki pages were hard > to find because hidden under layers of groups. The same was true for api > documentations. Now everything is flat and I think it's easier to find. > > Another bad message could also be sent by this: instead of exposing Konsole > or Ark as two applications under the KDE umbrella, it would look like Utils > for KDE, bringing back the KDE Desktop idea (where every application is > already store in a submenu). > > As someone wrote later, if I'm looking for a given application, there is > always the search function... That requires that you know it exists. We have 1,043 mainline repositories at the moment, which translates to 53 pages of projects under a flat structure system. Reality is nobody is going to page through that looking for something. Please also see my point regarding listing merge requests at the group level - you can see an example of what a flat structure ends up looking like at https://gitlab.gnome.org/GNOME For those projects that span multiple repositories, you have just denied them any chance or ability to see a listing of everything related to their wider project. > > Best regards, > Olivier > > Aleix > > Cheers, Ben
Re: Information regarding upcoming Gitlab Migration
On Mon, Apr 27, 2020 at 12:55 PM Ben Cooksley wrote: > > On Mon, Apr 27, 2020 at 10:39 PM Aleix Pol wrote: > > > > On Mon, Apr 27, 2020 at 3:41 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 > > > > Does this mean that to clone it we'll have to go "git clone > > kde:games/knetwalk" or something along the lines? > > Yes. > > > > > If that's the case I'd much prefer if we didn't do this, at the moment > > it's already uncomfortable for me to remember the URL for some of the > > repos (e.g. is it sysadmin/ or not?), this will only increase the > > problem and I personally don't see the advantage. > > So you'd rather that we have no way to easily see a list of just > Plasma / Frameworks / PIM / etc reviews? > (See https://invent.kde.org/groups/kde/-/merge_requests for an example > of the problem) > > Not to mention the fact that there will be several hundred > repositories all in one group, so they will be completely > undiscoverable to anyone outside of our community. > > > > > e.g. Is okular graphics or office? Is gwenview plasma or graphics? Is > > krita graphics or its own thing? > > > > I really prefer when I don't have to guess this kind of things when > > fetching a repository. > > There is always the search on Gitlab, and you can keep a checkout of > sysadmin/repo-metadata for grepping on. I don't know, I've always felt that the nesting we have nowadays stemmed from svn's tree structure more than convenience. I don't have the feeling I'd use that feature and I'm happy to convinced otherwise. While discoverability would be an incentive, I don't know if it will make a difference since it would be especially useful to see how repositories relate one to another, but it's something we generally split explicitly through frameworks so I don't see that will help much, other than for the very big suites (kdepim, plasma, etc). I know you don't like it when I do this, but: https://gitlab.gnome.org/explore/groups < gnome kept all the programs under the same group https://gitlab.freedesktop.org/explore/groups < didn't, but they have projects that have very little overlap of contributors Aleix
Re: Information regarding upcoming Gitlab Migration
On Mon, Apr 27, 2020 at 10:50 PM Piyush Aggarwal wrote: > > > > On Mon, 27 Apr, 2020, 4:09 pm Aleix Pol, wrote: >> >> On Mon, Apr 27, 2020 at 3:41 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 >> >> Does this mean that to clone it we'll have to go "git clone >> kde:games/knetwalk" or something along the lines? >> >> If that's the case I'd much prefer if we didn't do this, at the moment >> it's already uncomfortable for me to remember the URL for some of the >> repos (e.g. is it sysadmin/ or not?), this will only increase the >> problem and I personally don't see the advantage. >> >> e.g. Is okular graphics or office? Is gwenview plasma or graphics? Is >> krita graphics or its own thing? >> >> I really prefer when I don't have to guess this kind of things when >> fetching a repository. >> >> Aleix > > > This is technical so I would love to hear Sysadmin team's thoughts on this: > Probably there can be a redirect system that lets us do git clone > kde:knotifications and manages to redirect it to > kde/frameworks/tier3/knotifications.git > So we can clone and tinker with stuff as we normally do while the sysadmin > team goes with the recommended system of setting up the repos. > I think this should be possible because Invent already redirects my URLs > which don't end with .git to .git ones. I might be wrong about my assumption > that both things can work similarly. That would require modifications to Gitlab, which may not even be technically possible. It is likely a rewrite script will be provided to smooth the transition. Please note that knotifications would go to https://invent.kde.org/frameworks/knotifications under this proposal, not the longer path you've referred to above. > > Best > Piyush Aggarwal Cheers, Ben
Re: Information regarding upcoming Gitlab Migration
On Mon, Apr 27, 2020 at 10:39 PM Aleix Pol wrote: > > On Mon, Apr 27, 2020 at 3:41 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 > > Does this mean that to clone it we'll have to go "git clone > kde:games/knetwalk" or something along the lines? Yes. > > If that's the case I'd much prefer if we didn't do this, at the moment > it's already uncomfortable for me to remember the URL for some of the > repos (e.g. is it sysadmin/ or not?), this will only increase the > problem and I personally don't see the advantage. So you'd rather that we have no way to easily see a list of just Plasma / Frameworks / PIM / etc reviews? (See https://invent.kde.org/groups/kde/-/merge_requests for an example of the problem) Not to mention the fact that there will be several hundred repositories all in one group, so they will be completely undiscoverable to anyone outside of our community. > > e.g. Is okular graphics or office? Is gwenview plasma or graphics? Is > krita graphics or its own thing? > > I really prefer when I don't have to guess this kind of things when > fetching a repository. There is always the search on Gitlab, and you can keep a checkout of sysadmin/repo-metadata for grepping on. > > Aleix Cheers, Ben
Re: Information regarding upcoming Gitlab Migration
On Mon, Apr 27, 2020 at 3:41 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 Does this mean that to clone it we'll have to go "git clone kde:games/knetwalk" or something along the lines? If that's the case I'd much prefer if we didn't do this, at the moment it's already uncomfortable for me to remember the URL for some of the repos (e.g. is it sysadmin/ or not?), this will only increase the problem and I personally don't see the advantage. e.g. Is okular graphics or office? Is gwenview plasma or graphics? Is krita graphics or its own thing? I really prefer when I don't have to guess this kind of things when fetching a repository. Aleix
Re: Information regarding upcoming Gitlab Migration
On Mon, Apr 27, 2020 at 7:26 PM Ilya Bizyaev wrote: > > Hello Bhushan! > > Thank you for you work on the Gitlab migration! > > The lists look good! Here are some ideas that I have, in case you think they > can be considered before we transition: > • The "applications" category is somewhat misleading to me: it does not > include all KDE applications, and not all repositories in that category are > applications either. Looking through the list of projects in there, I think > they can be safely distributed across other categories. Most complicated > there are IMO kate, dolphin, klook, konqueror, konsole and yakuake. Somehow > terminal emulators, file managers and text editors feel like they belong to > the same category, but I don't know how to call it; maybe "files"? We are aware that the name is not ideal yes, and alternative names would definitely be welcome for this group of projects. Alternatively, they could be transferred into other categories (as it looks like most of them would fit within 'utilities' even if they are rather essential ones) > • Tentative, but I think a category called "science" might make sense > creating. Since KDE regularly attempts to promote usage of our software in > scientific institutions, that wouldn't hurt either. E.g. Mark (an app for > data science) doesn't really belong in "education", and I think is also true > for labplot and rkward. > • I see a category named "others". Looking at its contents, maybe it can be > renamed to "community"? Most of these will in the long run be archived, so this category may not end up being included in the final structure. > > Looking forward to the move! > > Cheers, > Ilya. Thanks, Ben > > > Дата: Пн, 27 апр 2020 04:40:01 +0300 Bhushan Shah > написал(а) > > [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 > > -- > Bhushan Shah > http://blog.bshah.in > IRC Nick : bshah on Freenode > GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D > > >
Re: Information regarding upcoming Gitlab Migration
On Mon, Apr 27, 2020 at 6:33 PM Rolf Eike Beer wrote: > > Bhushan Shah wrote: > > > 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. > > No objection, just a request for clarification: it looks like everything > in extragear or playground was merged into there, right? That is correct - the Extragear/Playground/"KDE" modules aren't represented in this. > > Eike Cheers, Ben
Re: Information regarding upcoming Gitlab Migration
Bhushan Shah wrote: 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. No objection, just a request for clarification: it looks like everything in extragear or playground was merged into there, right? Eike
Information regarding upcoming Gitlab Migration
[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 -- Bhushan Shah http://blog.bshah.in IRC Nick : bshah on Freenode GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D signature.asc Description: PGP signature
