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 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 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 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
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 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
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: 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: 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
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 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 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
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 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
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: clarifications
+1 Those proposals seems sensible to me -- Marco Martin 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. > > - 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 E11
Re: Information regarding upcoming Gitlab Migration
On Thu, Apr 30, 2020 at 4:17 AM Nicolás Alvarez wrote: > > > > El 29 abr. 2020, a la(s) 11:19, Boudewijn Rempt escribió: > > > > On woensdag 29 april 2020 15:16:12 CEST Adriaan de Groot wrote: > >>> On 2020 prilula d. 29id 06:46:55 CEST Bhushan Shah wrote: > >>> We have gotten a request for namespacing from projects on multiple > >>> occassion, in cgit our workaround has always been that we prefix the > >>> repo name with namespace- (i.e wikitolearn-courses-backend). > >>> > >>> While this works out with our current workflow, it is not really > >>> optimal. I've also mentioned various new contributor focused > >>> requirements which lead us to this proposal for structuring in previous > >>> emails. > >> > >> > >> Your mention of namespaces reminds me that there was **also** a discussion > >> in > >> this thread about workboards and reviews. > >> > >> GitLab can have **one** workboard per group. So depending on how the > >> categories / namespaces work out, we have choices in the overall number of > >> workboards: > >> > >> - one big one (flat) > >> - one per (sub)group / namespace > >> > >> We should look at this as well. Arguments I've seen in this thread > >> > >> - one big one is unmanageably large > >> - (sub)communities have asked for smaller (split) workboards > >> - split workboards make it harder to work over group boundaries > >> - one big one allows moving reviews and tasks to where they belong > > > > Outch, that's a nasty one. I thought there was a workboard per > > repository... And most of the proposed groups actually aren't really > > subcommunities in any case, just bags of holding for vaguely similar > > projects. > > My understanding is that there is a workboard per repository *and* another > per group. > Correction: there is the possibility to do multiple workboards at the project/repository level, which should suit most projects fine. There is however a limitation of one workboard at the group level, although it is anticipated that this should be sufficient for planning and tracking for most grouped projects. > Now, how big do we make the group workboard? All of KDE? A smaller category? > That is the question. > > -- > Nicolas Cheers, Ben
Re: Information regarding upcoming Gitlab Migration
On Thu, Apr 30, 2020 at 6:16 AM Boudewijn Rempt wrote: > > On woensdag 29 april 2020 18:17:05 CEST Nicolás Alvarez wrote: > > > > My understanding is that there is a workboard per repository *and* another > > per group. > > > > Now, how big do we make the group workboard? All of KDE? A smaller > > category? That is the question. > > Ah, that makes more sense. I guess that there should be groups for > repositories that really fit together, like all the split-up pim stuff, and a > generic holding thing for the projects that are more on their own, like Krita > or Kdenlive. > Which is why we have proposed the structure that we have, because it allows for module level task boards, allows easy visibility of the merge requests related to the contained repositories, and makes projects contained within that group easy to list. Those projects that are standalone are put into groups based on what they're for (Krita = graphics, Kdenlive = multimedia) for ease of discoverability by those not familiar with them. Cheers, Ben > -- > https://www.valdyas.org | https://www.krita.orgh > > > >
Re: Information regarding upcoming Gitlab Migration
On woensdag 29 april 2020 18:17:05 CEST Nicolás Alvarez wrote: > > My understanding is that there is a workboard per repository *and* another > per group. > > Now, how big do we make the group workboard? All of KDE? A smaller category? > That is the question. Ah, that makes more sense. I guess that there should be groups for repositories that really fit together, like all the split-up pim stuff, and a generic holding thing for the projects that are more on their own, like Krita or Kdenlive. -- https://www.valdyas.org | https://www.krita.orgh
Re: Information regarding upcoming Gitlab Migration
Ok after a small chat with the Bhushan I learned that the plan is to use gitlab-triage instead of project labels. This should be way more powerful :D Sorry for the trouble Carl ‐‐‐ Original Message ‐‐‐ Le mercredi, avril 29, 2020 2:37 PM, Carl Schwan a écrit : > Hi Sysadmins, > > since we are speaking about workboard for groups, what is the plan for groups > that don't work on a single project but on all of the KDE projects (e.g. VDG, > documentation, localization, websites)? > > I experimented a bit with project tags > (https://invent.kde.org/groups/kde/-/labels). This would allow subscribing to > only a certain sort of issue and code review. The problem with project tags > is that it only works if all the projects share the same root (e.g kde) but > we can still have a hierarchy kde/graphics, kde/plasma, kde/frameworks. > > This is already a problem since at the moment there is no way to ping VDG > and/or Promo in a merge request concerning the websites. I guess it is fine > for KDE Web because we are a small group and I can ask a review in > Matrix/Telegram. But I'm not sure it will work well for VDG and Promo who are > already bigger groups. > > So maybe we should go with the option to go with namespaces having all the > same root? > > Sorry for complaining so late. I still think the GitLab migration is a good > thing and there are more advantages than disadvantages in the migration. So > if you think project tags are not the way to go and there is a better way, I > will trust you. > > Thank you sysadmins for all the works you are doing making KDE infrastructure > better. :D > > Cheers, > Carl > > Le mercredi, avril 29, 2020 1:16 PM, Adriaan de Groot gr...@kde.org a écrit : > > > On 2020 prilula d. 29id 06:46:55 CEST Bhushan Shah wrote: > > > > We have gotten a request for namespacing from projects on multiple > > > occassion, in cgit our workaround has always been that we prefix the > > > repo name with namespace- (i.e wikitolearn-courses-backend). > > > While this works out with our current workflow, it is not really > > > optimal. I've also mentioned various new contributor focused > > > requirements which lead us to this proposal for structuring in previous > > > emails. > > > Your mention of namespaces reminds me that there wasalso a discussion in > > this thread about workboards and reviews. > > > GitLab can have one workboard per group. So depending on how the > > categories / namespaces work out, we have choices in the overall number of > > workboards: > > > - one big one (flat) > > - one per (sub)group / namespace > > > We should look at this as well. Arguments I've seen in this thread > > > > > - one big one is unmanageably large > > - (sub)communities have asked for smaller (split) workboards > > - split workboards make it harder to work over group boundaries > > - one big one allows moving reviews and tasks to where they belong > > > (The last point is "because there are no group boundaries"). > > > > > From the sound of it (without re-reading this entire thread today) it's > > a > > distinction between generalists and specialists and a good workflow > > depends on > > what it is you're trying to coordinate (drat, another "it depends" > > issue). > > > > > [ade] > > publickey - carl@carlschwan.eu - 0x7F564CB5.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: Information regarding upcoming Gitlab Migration
> El 29 abr. 2020, a la(s) 11:19, Boudewijn Rempt escribió: > > On woensdag 29 april 2020 15:16:12 CEST Adriaan de Groot wrote: >>> On 2020 prilula d. 29id 06:46:55 CEST Bhushan Shah wrote: >>> We have gotten a request for namespacing from projects on multiple >>> occassion, in cgit our workaround has always been that we prefix the >>> repo name with namespace- (i.e wikitolearn-courses-backend). >>> >>> While this works out with our current workflow, it is not really >>> optimal. I've also mentioned various new contributor focused >>> requirements which lead us to this proposal for structuring in previous >>> emails. >> >> >> Your mention of namespaces reminds me that there was **also** a discussion >> in >> this thread about workboards and reviews. >> >> GitLab can have **one** workboard per group. So depending on how the >> categories / namespaces work out, we have choices in the overall number of >> workboards: >> >> - one big one (flat) >> - one per (sub)group / namespace >> >> We should look at this as well. Arguments I've seen in this thread >> >> - one big one is unmanageably large >> - (sub)communities have asked for smaller (split) workboards >> - split workboards make it harder to work over group boundaries >> - one big one allows moving reviews and tasks to where they belong > > Outch, that's a nasty one. I thought there was a workboard per repository... > And most of the proposed groups actually aren't really subcommunities in any > case, just bags of holding for vaguely similar projects. My understanding is that there is a workboard per repository *and* another per group. Now, how big do we make the group workboard? All of KDE? A smaller category? That is the question. -- Nicolas
Re: Information regarding upcoming Gitlab Migration
If your looking for an example of a project/repo level workboard look here. https://invent.kde.org/kde/kdiff3/-/boards. Just did a quick check this is indeed specific to kdiff3. Labels can also be created at this level. The board is completely customizable. On Wed, Apr 29, 2020, 11:21 AM Michael Reeves wrote: > > > On Wed, Apr 29, 2020, 10:19 AM Boudewijn Rempt wrote: > >> On woensdag 29 april 2020 15:16:12 CEST Adriaan de Groot wrote: >> > On 2020 prilula d. 29id 06:46:55 CEST Bhushan Shah wrote: >> > > We have gotten a request for namespacing from projects on multiple >> > > occassion, in cgit our workaround has always been that we prefix the >> > > repo name with namespace- (i.e wikitolearn-courses-backend). >> > > >> > > While this works out with our current workflow, it is not really >> > > optimal. I've also mentioned various new contributor focused >> > > requirements which lead us to this proposal for structuring in >> previous >> > > emails. >> > >> > >> > Your mention of namespaces reminds me that there was **also** a >> discussion in >> > this thread about workboards and reviews. >> > >> > GitLab can have **one** workboard per group. So depending on how the >> > categories / namespaces work out, we have choices in the overall number >> of >> > workboards: >> > > Not sure what your referring to but kdiff3 has a workboard setup that is > not group level. I'll have another look at how this is setup. > > > >> > - one big one (flat) >> > - one per (sub)group / namespace >> > >> > We should look at this as well. Arguments I've seen in this thread >> > >> > - one big one is unmanageably large >> > - (sub)communities have asked for smaller (split) workboards >> > - split workboards make it harder to work over group boundaries >> > - one big one allows moving reviews and tasks to where they belong >> >> Outch, that's a nasty one. I thought there was a workboard per >> repository... And most of the proposed groups actually aren't really >> subcommunities in any case, just bags of holding for vaguely similar >> projects. >> >> -- >> https://www.valdyas.org | https://www.krita.org >> >> >>
Re: Information regarding upcoming Gitlab Migration
On Wed, Apr 29, 2020, 10:19 AM Boudewijn Rempt wrote: > On woensdag 29 april 2020 15:16:12 CEST Adriaan de Groot wrote: > > On 2020 prilula d. 29id 06:46:55 CEST Bhushan Shah wrote: > > > We have gotten a request for namespacing from projects on multiple > > > occassion, in cgit our workaround has always been that we prefix the > > > repo name with namespace- (i.e wikitolearn-courses-backend). > > > > > > While this works out with our current workflow, it is not really > > > optimal. I've also mentioned various new contributor focused > > > requirements which lead us to this proposal for structuring in previous > > > emails. > > > > > > Your mention of namespaces reminds me that there was **also** a > discussion in > > this thread about workboards and reviews. > > > > GitLab can have **one** workboard per group. So depending on how the > > categories / namespaces work out, we have choices in the overall number > of > > workboards: > Not sure what your referring to but kdiff3 has a workboard setup that is not group level. I'll have another look at how this is setup. > > > - one big one (flat) > > - one per (sub)group / namespace > > > > We should look at this as well. Arguments I've seen in this thread > > > > - one big one is unmanageably large > > - (sub)communities have asked for smaller (split) workboards > > - split workboards make it harder to work over group boundaries > > - one big one allows moving reviews and tasks to where they belong > > Outch, that's a nasty one. I thought there was a workboard per > repository... And most of the proposed groups actually aren't really > subcommunities in any case, just bags of holding for vaguely similar > projects. > > -- > https://www.valdyas.org | https://www.krita.org > > >
Re: Information regarding upcoming Gitlab Migration
Hi Sysadmins, since we are speaking about workboard for groups, what is the plan for groups that don't work on a single project but on all of the KDE projects (e.g. VDG, documentation, localization, websites)? I experimented a bit with project tags (https://invent.kde.org/groups/kde/-/labels). This would allow subscribing to only a certain sort of issue and code review. The problem with project tags is that it only works if all the projects share the same root (e.g kde) but we can still have a hierarchy kde/graphics, kde/plasma, kde/frameworks. This is already a problem since at the moment there is no way to ping VDG and/or Promo in a merge request concerning the websites. I guess it is fine for KDE Web because we are a small group and I can ask a review in Matrix/Telegram. But I'm not sure it will work well for VDG and Promo who are already bigger groups. So maybe we should go with the option to go with namespaces having all the same root? Sorry for complaining so late. I still think the GitLab migration is a good thing and there are more advantages than disadvantages in the migration. So if you think project tags are not the way to go and there is a better way, I will trust you. Thank you sysadmins for all the works you are doing making KDE infrastructure better. :D Cheers, Carl Le mercredi, avril 29, 2020 1:16 PM, Adriaan de Groot a écrit : > On 2020 prilula d. 29id 06:46:55 CEST Bhushan Shah wrote: > > > We have gotten a request for namespacing from projects on multiple > > occassion, in cgit our workaround has always been that we prefix the > > repo name with namespace- (i.e wikitolearn-courses-backend). > > While this works out with our current workflow, it is not really > > optimal. I've also mentioned various new contributor focused > > requirements which lead us to this proposal for structuring in previous > > emails. > > Your mention of namespaces reminds me that there wasalso a discussion in > this thread about workboards and reviews. > > GitLab can have one workboard per group. So depending on how the > categories / namespaces work out, we have choices in the overall number of > workboards: > > - one big one (flat) > - one per (sub)group / namespace > > We should look at this as well. Arguments I've seen in this thread > > - one big one is unmanageably large > - (sub)communities have asked for smaller (split) workboards > - split workboards make it harder to work over group boundaries > - one big one allows moving reviews and tasks to where they belong > > (The last point is "because there are no group boundaries"). > > From the sound of it (without re-reading this entire thread today) it's a > distinction between generalists and specialists and a good workflow > depends on > what it is you're trying to coordinate (drat, another "it depends" issue). > > [ade] > publickey - carl@carlschwan.eu - 0x7F564CB5.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: Information regarding upcoming Gitlab Migration
On 2020 prilula d. 29id 06:46:55 CEST Bhushan Shah wrote: > We have gotten a request for namespacing from projects on multiple > occassion, in cgit our workaround has always been that we prefix the > repo name with namespace- (i.e wikitolearn-courses-backend). > > While this works out with our current workflow, it is not really > optimal. I've also mentioned various new contributor focused > requirements which lead us to this proposal for structuring in previous > emails. Your mention of namespaces reminds me that there was **also** a discussion in this thread about workboards and reviews. GitLab can have **one** workboard per group. So depending on how the categories / namespaces work out, we have choices in the overall number of workboards: - one big one (flat) - one per (sub)group / namespace We should look at this as well. Arguments I've seen in this thread - one big one is unmanageably large - (sub)communities have asked for smaller (split) workboards - split workboards make it harder to work over group boundaries - one big one allows moving reviews and tasks to where they belong (The last point is "because there are no group boundaries"). >From the sound of it (without re-reading this entire thread today) it's a distinction between generalists and specialists and a good workflow depends on what it is you're trying to coordinate (drat, another "it depends" issue). [ade] signature.asc Description: This is a digitally signed message part.
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
Hello Johan, On Tue, Apr 28, 2020 at 06:18:14PM +0200, Johan Ouwerkerk wrote: > I would like to propose that the sysadmin team pick the layout that is > easiest to *implement*, which I suspect is also the most like what we > have now, and that we live with that. Unless there is a pressing need, > like real hard data that we're losing contributors because they can't > find our repos or a sysadmin burden that would be excessively higher > than otherwise... let's keep things as simple and straightforward for > syadmin and tooling maintainers to implement during the Gitlab > migration. > > Let's worry about the perfect project layout once we've identified the > need. That way it's a lot easier to garner consensus for a practical > solution that isn't just a wishlist of all the features we would like > but which Gitlab may or may not have and which tooling is probably > completely unprepared for. Going with flat namespace right now and then making whole thing non-flat means double amount of work for sysadmins, once to migrate everything on invent, and then later to their final home. It is equal amount of work for contributors, once to migrate to invent URL and then migrate to new grouping. If setups needs changing, I'd rather change it now at once then later. > By all means disregard this stuff if the pressing need has already > been identified and I've either neglected to read e-mails properly or > wasn't aware for some other, possibly historical, reason. We have gotten a request for namespacing from projects on multiple occassion, in cgit our workaround has always been that we prefix the repo name with namespace- (i.e wikitolearn-courses-backend). While this works out with our current workflow, it is not really optimal. I've also mentioned various new contributor focused requirements which lead us to this proposal for structuring in previous emails. -- 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 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
On Tue, Apr 28, 2020 at 1:09 PM Adriaan de Groot wrote: > > 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. > To some extent, yes, but some assumptions are baked in at a quite fundamental level for e.g. kdesrc-build (if I understand the Perl correctly): - Uniqueness of project names. Cannot have two "documentation" projects being advertised through kde-build-metadata - There must be a single shared root prefix for all projects. This prefix may be the empty string, but the point is that repo paths advertised in kde-build-metadata must work from this single root prefix Any solution that wishes to preserve tooling must take these fundamental constraints as given or else risk that you cannot move until the whole world is fixed first. I'm obviously biased as someone who invested some time and effort in kdesrc-build, but the busfactor is a real concern here. E.g.: Michael clearly just hasn't had the time lately to spend on kdesrc-build and I don't think it's such a great idea for me to merge in major changes without him reviewing it first. > > 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 think that this is a bit of a lost cause. I think there's going to be some level of annoyance all around until the pain has finally died away because everybody made the upgrade. We can have a script to help with that but that will inherently assume quite a bit about how you set up your projects manually to begin with and it will still piss off a lot of people because we break their workflow no matter what. The main problem is not technical here, the main problem is that people who use that manual git clone workflow do so because they don't want to use the layers of tooling. So adding layers of tooling to "fix" the manual work flow is defeating the point, and therefore the pain is here to stay I think. At a fundamental the only way to avoid the pain is for the URLs to continue to work somehow, but I gather that is a completely unfeasible solution in terms of not driving sysadmin crazy. A fairly big one is that the fingerprint of the host's SSH key will be different. > > 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. > Yep. And I think for the exact same reason why a porting/transitioning script is probably not going help all that much -- too much diff in setup/config/versions/tools on the other end to deal with in a reasonable script. It's the main source of complexity in a tool like kdesrc-build and that has lot's of Perl to hammer systems into submission... :) > > Turning to human actors, who are the more interesting ones, > I think we're in a situation that this migration is going to cause pain for the human element no matter what. I also think that ultimately from a technical pov it mostly doesn't really matter. As someone else already mentioned: the Internet has search engines for that. What exact flavour of labeling/grouping/hierarchy we use, I think it is mostly bikeshedding: I would predict that at first this is going to be annoying for many if not nearly all contributors. After a while we've all made the upgrade (just a matter of tweaking your ~/.gitconfig & git remote set-url per repo) and then it's business as usual. So yes this is about the social aspect. Personally I think the pain is unavoidable for the individual contributor, but what seems to be getting lost in this discussion is that there *is* also an amount of pain that can be avoided. We can avoid pain for the sysadmin team by choosing whatever is easiest to maintain long term here. We can avoid pain for the maintainers of tooling by choosing whatever fits the tooling most easily. In particular we can avoid choosing an option that imposes additional parallel sysadmin work indefinitely, like e.g. dedicated mirror services to redirect stuff. I would like to propose that the sysadmin team pick the layout that is easiest to *implement*, which I suspect is also the most like what we have now, and that we live with that. Unless there is a pressing need, like real hard data that we're losing contributors because they can't find our repos or a sysadmin burden that would be excessively higher than
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
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
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
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
On Tue, Apr 28, 2020 at 12:04 AM 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. Sorry, but cgit.kde.org will be gone once we have moved to Gitlab. > > 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. > Also note that Gitlab search spans across group boundaries. > > > 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. > That is unfortunate, but you will never get a perfect solution. > 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. > > The sad truth is that, AFAIK, GitLab lacks an n-to-m association of repos to > user groups (e.g. dev teams). GitLab's 1-to-n association of repos to a single > group is insufficient for us (while it's sufficient for most users of > gitlab.com). > > Regards, > Ingo Regards, 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
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, Apr 27, 2020 at 2:32 PM Piyush Aggarwal wrote: > > How long do redirects like this one work? If they will keep working > indefinitely, then maybe we can have all the repos at flat URLs for once and > then move them to respective subgroups? I don't think this works if you want $repo to appear in *both* A and B subgroups. A move is a one-way operation. If I understand the docs [1] correctly then the multi-group thing is mostly labeling with aliases in our case. There would be one KDE structure and a bunch of groups which are basically an ACL with a name to selectively grant access to a project via the "sharing" mechanism. So projects in such a group are in fact aliases for projects in the main KDE namespace similar to symlinks. The trick is therefore basically: make everybody a member of every group so you see $repo under both A and B groups because KDE/$repo is shared from the KDE group with both A and B. Regards, - Johan [1]: https://docs.gitlab.com/ee/user/group/
Re: Information regarding upcoming Gitlab Migration
On Mon, Apr 27, 2020 at 3:30 PM Luigi Toscano wrote: > > Bhushan Shah ha scritto: > > > - But most importantly, this breaks with the non-unique leaf repository > > names feature offered by the proposed structure. So, There could be > > maui/documentation and wikitolearn/documentation. But we would have > > single KDE/documentation redirect > > > > Just to clarify: are we going towards a non-unique leaf repository name? I > thought we were going to maintain the leaf uniqueness regardless. > > -- > Luigi AFAIK `kdesrc-build` cannot cope wth non-unique repo names: it needs $repo.git to be unique. In fact, things need to be slightly more unique than just within the KDE namespace: names must also be unique over the set of 3rd party names referenced in the dependency data (and the other modules that a `kdesrc-build.rc` might refer to, but that is also on the user). So people had better avoid "common" names if they want their project to build with `kdesrc-build` (or brush up their Perl 5 skills to fix it). I guess for most projects this won't matter too much, but I can imagine how this could bite translations & related tooling as well. Regards, - Johan
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
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
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
Bhushan Shah ha scritto: > - But most importantly, this breaks with the non-unique leaf repository > names feature offered by the proposed structure. So, There could be > maui/documentation and wikitolearn/documentation. But we would have > single KDE/documentation redirect Just to clarify: are we going towards a non-unique leaf repository name? I thought we were going to maintain the leaf uniqueness regardless. If this is the case, I'd really like to express my disappointment: we are basically forcing back the namespaces as part of the application name. Dolphin is going to be referred to application/dolphin or application_dolphin, kstars as education/kstars and so on, because we can have duplicates. This is a huge step back, also because the namespaces are mixed: we have subproject types (wikitolearn, maui, plasma-mobile) and category types (education, pim, graphics, etc). What if plasma-mobile want to distinguish their projects by categories? That's inconsistent. We don't know where we will be in 10 years in terms of tooling, maybe gitlab itself will introduce better filtering capabilities, let's keep at least the uniqueness of leaves. I suspect we need some compromise decision (not win-win, sadly) here, but I feel that having both (mixed) subcategories (non-flat) and no uniqueness of repository names is going to be the worst combination. -- Luigi
Re: Information regarding upcoming Gitlab Migration
On Mon, Apr 27, 2020 at 06:02:19PM +0530, Piyush Aggarwal wrote: > How long do redirects like this one work? If they will keep working > indefinitely, then maybe we can have all the repos at flat URLs for once > and then move them to respective subgroups? That way we will have access to > our simple URLs through a redirect as I mentioned before, and also the > ability to manage the Invent as recommended by sysadmins. Documentation says that redirect will stay as long as original name is not claimed by the new group, user or project. However there's multiple problems with the workflow of moving something to the KDE/ namespace first and then to respective group. - There will be empty KDE/ group visible which would be confusing for visitors - Workflow of the importing repository becomes complicated without any advantage IMO. For instance to import bshah/kframework into frameworks/ I've to first transfer it's ownership to KDE and then transfer it's ownership to frameworks/ group. - But most importantly, this breaks with the non-unique leaf repository names feature offered by the proposed structure. So, There could be maui/documentation and wikitolearn/documentation. But we would have single KDE/documentation redirect -- 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, 27 Apr, 2020, 5:57 pm Bhushan Shah, wrote: > Hello > > On Mon, Apr 27, 2020 at 02:10:11PM +0200, Boudewijn Rempt wrote: > > On maandag 27 april 2020 03:40:01 CEST Bhushan Shah wrote: > > > > > [1] > https://cgit.kde.org/sysadmin/repo-metadata.git/tree/projects-invent?h=bshah/invent > > > > Maybe it would make sense to keep a kde top-level group for some of the > bigger projects that really don't fit in a category -- I don't think Krita > fits in the graphics group, since we never ever do anything with any of the > other repositories in that category. > > Slightly off-topic, but, in general idea is that we want to get away > from the KDE is software, and more towards KDE is community and people, > having a KDE/ namespace is step backward IMHO. > > > I have to admit, I also dread updating instructions and checkouts > everywhere from invent.kde.org/kde/krita to invent.kde.org/graphics/krita. > .. > > You don't really have to update the URL, since this project was already > on invent.kde.org we would be doing a move, which would automatically > add a redirect, so while if you want to update, it is fine, it won't be > breaking any of existing links/setups. > How long do redirects like this one work? If they will keep working indefinitely, then maybe we can have all the repos at flat URLs for once and then move them to respective subgroups? That way we will have access to our simple URLs through a redirect as I mentioned before, and also the ability to manage the Invent as recommended by sysadmins. Best Piyush Aggarwal
Re: Information regarding upcoming Gitlab Migration
On maandag 27 april 2020 14:26:16 CEST Bhushan Shah wrote: > > I have to admit, I also dread updating instructions and checkouts > > everywhere from invent.kde.org/kde/krita to invent.kde.org/graphics/krita... > > You don't really have to update the URL, since this project was already > on invent.kde.org we would be doing a move, which would automatically > add a redirect, so while if you want to update, it is fine, it won't be > breaking any of existing links/setups. Ah, then everything is fine :-) -- https://www.krita.org
Re: Information regarding upcoming Gitlab Migration
Hello On Mon, Apr 27, 2020 at 02:10:11PM +0200, Boudewijn Rempt wrote: > On maandag 27 april 2020 03:40:01 CEST Bhushan Shah wrote: > > > [1] > > https://cgit.kde.org/sysadmin/repo-metadata.git/tree/projects-invent?h=bshah/invent > > Maybe it would make sense to keep a kde top-level group for some of the > bigger projects that really don't fit in a category -- I don't think Krita > fits in the graphics group, since we never ever do anything with any of the > other repositories in that category. Slightly off-topic, but, in general idea is that we want to get away from the KDE is software, and more towards KDE is community and people, having a KDE/ namespace is step backward IMHO. > I have to admit, I also dread updating instructions and checkouts everywhere > from invent.kde.org/kde/krita to invent.kde.org/graphics/krita... You don't really have to update the URL, since this project was already on invent.kde.org we would be doing a move, which would automatically add a redirect, so while if you want to update, it is fine, it won't be breaking any of existing links/setups. -- 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
[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. > The sad truth is that, AFAIK, GitLab lacks an n-to-m association of repos to > user groups (e.g. dev teams). GitLab's 1-to-n association of repos to a > single > group is insufficient for us (while it's sufficient for most users of > gitlab.com). > > Regards, > Ingo -- 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 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. The sad truth is that, AFAIK, GitLab lacks an n-to-m association of repos to user groups (e.g. dev teams). GitLab's 1-to-n association of repos to a single group is insufficient for us (while it's sufficient for most users of gitlab.com). Regards, Ingo signature.asc Description: This is a digitally signed message part.
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
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 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
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 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, 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 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
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 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
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
