Re: Information regarding upcoming Gitlab Migration: clarifications
On Fri, May 1, 2020 at 4:38 PM Nate Graham wrote: > > > > On 4/30/20 5:59 PM, Aleix Pol wrote: > > El jue., 30 de abr. de 2020 a la(s) 18:15, Albert Astals Cid > >> Am I the only person that just has all the repos on the same folder? I > >> thought it was the common thing to do :? > > > > I do too > > Same here. kdesrc-build's default settings do this, and download all > repos into ~/kde/src without any of the levels of hierarchy. This would > seem to require unique repo names, no? Not necessarily. Git allows you to override the name that the local folder is called when cloning, so there is no reason why we can't specify something in the metadata to override the local name that the folder gets called in your local checkout folder. This would allow for example: - frameworks/kcoreaddons on Gitlab continues to be called 'kcoreaddons' in your local checkout folder - maui/dialer on Gitlab gets called 'maui-dialer' in your local checkout folder This allows for the URLs on Gitlab to make sense, while simultaneously allowing your local source checkout folders to continue to work in the manner in which they do currently. Note that we do not expect people to hit this in many cases - this is about giving us the flexibility for the long term without imposing unnecessary bureaucracy and limits on projects within the KDE umbrella. Automated tooling such as kdesrc-build and the proposed clone script (that searches in namespaces) should be able to handle this without much issue. In the case of manually done clones, it is reasonable to expect people to know what they're doing with their clones, and name them appropriately in the event they have a collision. Does this sound acceptable? > > The group categorization we've been discussing may be useful on the web > UI for newcomers, but it has no value for your source checkout folder > IMO, where it just makes it slightly more annoying to navigate from one > repo to another. > > Nate Cheers, Ben
Re: Information regarding upcoming Gitlab Migration
On Fri, May 1, 2020 at 2:46 AM Nate Graham wrote: > > If I'm understanding things, we have solutions to most or all of the > objections raised so far: > > - Projects will be allowed to live in--or at least appear in--multiple > top-level groups (e.g. plasma-framework could appear in both the > Frameworks top-level group and also the Plasma top-level group) Projects will have the option to appear in multiple groups yes. > > - kdesrc-build and other scripts can be updated to allow people to > easily check out repos using git prefixes (e.g. so that something like > `git clone kde:dolphin` will still work regardlyss of a project's > underlying group) The syntax will probably be slightly different to that, but the concept is correct yes. > > - cgit will continue to exist for three weeks to provide some transition > time Correct. > > - Each repo can have its own workboard in addition to the single > group-level workboard Correct, just one small clarification: each project (repository) can have multiple workboards, there is no limit to this. Groups are limited to a single workboard. > > If the above are accurate, then I firmly support the proposal. > > As for the actual grouping, I think it makes sense to have top-level > groups for Frameworks, Plasma, PIM, etc. as originally proposed. I can > support putting apps into category-specific groups (e.g. Multimedia, > Office, Graphics, Games, etc) as long as apps could appear in multiple > groups if needed for the case of apps that logically span boundaries > (e.g. repos for PlaMo apps could appear in both the Plasma Mobile > top-level group and also the relevant app group). > > > Nate Cheers, Ben
Re: Information regarding upcoming Gitlab Migration: clarifications
On 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
