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: 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: 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: 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
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
