Re: Update on Status of Gitlab Migration

[Ivan Čukić]

Hi all,

While I do like the invent name, I agree there should be a redirect of some 
sort from git.kde.org to it.

The aforementioned Debian salsa server has one as well - https://
git.debian.org/ - a message stating that the new server is 'salsa.debian.org'

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: Update on Status of Gitlab Migration

[Ben Cooksley]

On Tue, Apr 14, 2020 at 2:37 PM Nate Graham  wrote:
>
> On 4/13/20 6:59 PM, Ben Cooksley wrote:
> > Why do we need to mimic them?
> >
> > If you Google "KDE Gitlab" then the first hit is invent.kde.org
> > .
>
> To flip it around: why do we need to do something different? I don't
> think it's about mimicking anyone else, but rather using the most
> intuitively obvious domain name rather than some arbitrarily different one.
>
> No matter what, we're all going to be talking about "KDE GitLab" or
> "KDE's GitLab instance". The title of the relevant documentation page is
> "GitLab" (much as the Phabricator documentation page was named
> "Phabricator"). And when the migration is complete, we're all going to
> announce that "KDE is now using GitLab!" So the cat's out of the bag on
> using the word "GitLab" and avoiding some number of people looking for
> our stuff at gitlab.com and not finding it there. invent.kde.org doesn't
> avoid that at all.
>
> Given that, which is more confusing: explaining to people that we have a
> GitLab instance at invent.kde.org, or explaining to people that we have
> a GitLab instance at gitlab.kde.org?

There is no difference to be honest, the amount of explaining is
exactly the same.

We're also not alone in giving ours a different name - Debian did as
well (theirs is at salsa.debian.org). They didn't see fit to setup a
compatibility "gitlab.debian.org" hostname either.

>
> I know that over the next few years I'm going to be directing hundreds
> of people towards our infrastructure, and I would rather be able to say
> "please submit a pull request at gitlab.kde.org" rather than "please
> submit a pull request at KDE's GitLab instance at invent.kde.org."

Sorry, but the "KDE's Gitlab instance" in your second sentence is superfluous.
You could just as easily say "please submit a pull request on
invent.kde.org", not sure why you need to explicitly mention it is
Gitlab.

If people have already found the source code, chances are they will
have already found invent.kde.org anyway - as they will have probably
found it via a web browser, and Gitlab will be the only web interface
to our repositories (CGit is being discontinued)

>
> I know this probably feels like annoyingly extreme bikeshedding, but, I
> dunno, names are important.
>
> Nate

Cheers,
Ben

Re: Update on Status of Gitlab Migration

[Ben Cooksley]

On Mon, Apr 13, 2020 at 9:29 AM Johan Ouwerkerk  wrote:
>
> On Sun, Apr 12, 2020 at 12:49 AM Johan Ouwerkerk  
> wrote:
> >
> > >
> > > We may need to do on-the-fly conversion of the kde: repo paths if they
> > > won't be expressible as 'kde:foo' in the future, but we should have the
> > > information needed to do this in kdesrc-build to make this happen
> > > on-the-fly.
> > >
> >
> > Yes, this should be fairly straight forward: we could do a `git remote
> > set-url` based on what the repo metadata tells us before updating a
> > local clone. In fact: we could build this right now and sell it as
> > "automagically recover your upstream".  :)
> >
> > I might try to hack something up tomorrow or monday for that.
> >
>
> A basic version of this is now available via:
> https://invent.kde.org/kde/kdesrc-build/-/merge_requests/27
> With this feature sysadmin should now be free to change the repopath
> value in the metadata YAML and kdesrc-build will reconfigure the
> remote URL appropriately automatically. This works as long as the same
> `kde:$path` expression works for both fetch and push, i.e. the layout
> on the anongit.kde.org network must match with the layout of
> git.kde.org/invent.kde.org. If necessary a simple path prefix change
> could still work with a minor update to the pushInsteadOf mapping,
> e.g. when repos on invent are mapped to kde/   instead of
> /.
>
> You can also experiment with setting invent.kde.org as the push URL by
> setting x-invent-kde-push-urls to true in your rc file. The effect
> should be visible through git remote -vv afterwards. (Disable the
> setting and re-run again afterwards because this will obviously break
> your push URLs as long as the Gitlab migration hasn't completed yet).

Many thanks for sending this patch through Johan, it's appreciated.

As one of the options we are looking at involves grouping
repositories, having the ability for kdesrc-build to seamlessly handle
this transition is definitely appreciated.


>
> Regards,
>
> - Johan

Cheers,
Ben

Re: Update on Status of Gitlab Migration

[Nate Graham]

On 4/13/20 6:59 PM, Ben Cooksley wrote:

Why do we need to mimic them?

If you Google "KDE Gitlab" then the first hit is invent.kde.org 
.


To flip it around: why do we need to do something different? I don't 
think it's about mimicking anyone else, but rather using the most 
intuitively obvious domain name rather than some arbitrarily different one.


No matter what, we're all going to be talking about "KDE GitLab" or 
"KDE's GitLab instance". The title of the relevant documentation page is 
"GitLab" (much as the Phabricator documentation page was named 
"Phabricator"). And when the migration is complete, we're all going to 
announce that "KDE is now using GitLab!" So the cat's out of the bag on 
using the word "GitLab" and avoiding some number of people looking for 
our stuff at gitlab.com and not finding it there. invent.kde.org doesn't 
avoid that at all.


Given that, which is more confusing: explaining to people that we have a 
GitLab instance at invent.kde.org, or explaining to people that we have 
a GitLab instance at gitlab.kde.org?


I know that over the next few years I'm going to be directing hundreds 
of people towards our infrastructure, and I would rather be able to say 
"please submit a pull request at gitlab.kde.org" rather than "please 
submit a pull request at KDE's GitLab instance at invent.kde.org."


I know this probably feels like annoyingly extreme bikeshedding, but, I 
dunno, names are important.


Nate

Re: Update on Status of Gitlab Migration

[Ben Cooksley]

On Tue, 14 Apr 2020, 11:45 am Aleix Pol,  wrote:

> On Mon, Apr 13, 2020 at 8:30 PM Ben Cooksley  wrote:
> >
> > On Tue, Apr 14, 2020 at 3:35 AM Nate Graham  wrote:
> > >
> > > On 4/13/20 4:44 AM, Albert Vaca Cintora wrote:
> > > > Regarding this: is the subdomain going to stay invent.kde.org once
> we
> > > > have officially moved? I find it's a bit confusing to use that
> instead
> > > > of gitlab.kde.org
> > >
> > > I agree. gitlab.kde.org would make more sense to me, mirroring
> > > phabricator.kde.org.
> > >
> >
> > There is no intention to change the name from invent.kde.org.
> >
> > We have a long precedent of not using the name of the software for the
> > name in DNS, and Gitlab is continuing with this, for example:
> > - bugs.kde.org is run by Bugzilla
> > - dot.kde.org is run by Drupal
> > - techbase.kde.org is run by Mediawiki
> > - conf.kde.org is run by Frab
> > - reimbursements.kde.org is run by travel-support-program
> > - websvn.kde.org is run by ViewVC
> > - build.kde.org and binary-factory.kde.org are both run by Jenkins
> > - stats.kde.org is run by Matomo (formerly Piwik)
> > - survey.kde.org is run by Limesurvey
> >
> > For essentially all of the above, calling it after the software
> > running it makes no sense, and given that in some cases we have
> > multiple instances would have made things more confusing
> > (jenkins1.kde.org and jenkins2.kde.org anyone?)
> >
> > Phabricator and Reviewboard were the only ones to not follow this
> > rule, and that was an error on our part.
> >
> > Given that there is a popular instance at Gitlab.com, referring to
> > ours as "KDE Invent" is more likely to ensure newcomers are not
> > confused (as they may not be aware that you can setup an instance of
> > Gitlab on your own systems)
> >
> > Regards,
> > Ben
>
> We also use git.kde.org and svn.kde.org.
>

The name git.kde.org will be retired as part of the move to Gitlab.

The SSH host keys for the two machines are different, so it would cause
more issues than it doesn't to keep the hostname active.

We've also never supported HTTP access to the master copy of the
repositories so there isn't anything to keep alive there either.


> It would too mimic what others are doing at gitlab.gnome.org and
> gitlab.freedesktop.org. So at the very least we'll want a redirect.
>

Why do we need to mimic them?

If you Google "KDE Gitlab" then the first hit is invent.kde.org.


> Aleix
>

Cheers,
Ben

>

Re: Update on Status of Gitlab Migration

[Aleix Pol]

On Mon, Apr 13, 2020 at 8:30 PM Ben Cooksley  wrote:
>
> On Tue, Apr 14, 2020 at 3:35 AM Nate Graham  wrote:
> >
> > On 4/13/20 4:44 AM, Albert Vaca Cintora wrote:
> > > Regarding this: is the subdomain going to stay invent.kde.org once we
> > > have officially moved? I find it's a bit confusing to use that instead
> > > of gitlab.kde.org
> >
> > I agree. gitlab.kde.org would make more sense to me, mirroring
> > phabricator.kde.org.
> >
>
> There is no intention to change the name from invent.kde.org.
>
> We have a long precedent of not using the name of the software for the
> name in DNS, and Gitlab is continuing with this, for example:
> - bugs.kde.org is run by Bugzilla
> - dot.kde.org is run by Drupal
> - techbase.kde.org is run by Mediawiki
> - conf.kde.org is run by Frab
> - reimbursements.kde.org is run by travel-support-program
> - websvn.kde.org is run by ViewVC
> - build.kde.org and binary-factory.kde.org are both run by Jenkins
> - stats.kde.org is run by Matomo (formerly Piwik)
> - survey.kde.org is run by Limesurvey
>
> For essentially all of the above, calling it after the software
> running it makes no sense, and given that in some cases we have
> multiple instances would have made things more confusing
> (jenkins1.kde.org and jenkins2.kde.org anyone?)
>
> Phabricator and Reviewboard were the only ones to not follow this
> rule, and that was an error on our part.
>
> Given that there is a popular instance at Gitlab.com, referring to
> ours as "KDE Invent" is more likely to ensure newcomers are not
> confused (as they may not be aware that you can setup an instance of
> Gitlab on your own systems)
>
> Regards,
> Ben

We also use git.kde.org and svn.kde.org.

It would too mimic what others are doing at gitlab.gnome.org and
gitlab.freedesktop.org. So at the very least we'll want a redirect.

Aleix

Re: Update on Status of Gitlab Migration

[Ben Cooksley]

On Tue, Apr 14, 2020 at 3:35 AM Nate Graham  wrote:
>
> On 4/13/20 4:44 AM, Albert Vaca Cintora wrote:
> > Regarding this: is the subdomain going to stay invent.kde.org once we
> > have officially moved? I find it's a bit confusing to use that instead
> > of gitlab.kde.org
>
> I agree. gitlab.kde.org would make more sense to me, mirroring
> phabricator.kde.org.
>

There is no intention to change the name from invent.kde.org.

We have a long precedent of not using the name of the software for the
name in DNS, and Gitlab is continuing with this, for example:
- bugs.kde.org is run by Bugzilla
- dot.kde.org is run by Drupal
- techbase.kde.org is run by Mediawiki
- conf.kde.org is run by Frab
- reimbursements.kde.org is run by travel-support-program
- websvn.kde.org is run by ViewVC
- build.kde.org and binary-factory.kde.org are both run by Jenkins
- stats.kde.org is run by Matomo (formerly Piwik)
- survey.kde.org is run by Limesurvey

For essentially all of the above, calling it after the software
running it makes no sense, and given that in some cases we have
multiple instances would have made things more confusing
(jenkins1.kde.org and jenkins2.kde.org anyone?)

Phabricator and Reviewboard were the only ones to not follow this
rule, and that was an error on our part.

Given that there is a popular instance at Gitlab.com, referring to
ours as "KDE Invent" is more likely to ensure newcomers are not
confused (as they may not be aware that you can setup an instance of
Gitlab on your own systems)

Regards,
Ben

Re: Update on Status of Gitlab Migration

[Nate Graham]

On 4/13/20 4:44 AM, Albert Vaca Cintora wrote:

Regarding this: is the subdomain going to stay invent.kde.org once we
have officially moved? I find it's a bit confusing to use that instead
of gitlab.kde.org


I agree. gitlab.kde.org would make more sense to me, mirroring 
phabricator.kde.org.


Nate

Re: Update on Status of Gitlab Migration

[Albert Vaca Cintora]

On Sat, Apr 11, 2020 at 11:36 AM Ben Cooksley  wrote:
>
> Good morning Community,
>
> I'm pleased to report that this week we reached a major milestone,
> with all the necessary technical components now being in place on our
> side for our migration to Gitlab to take place.

Regarding this: is the subdomain going to stay invent.kde.org once we
have officially moved? I find it's a bit confusing to use that instead
of gitlab.kde.org

Albert

Re: Update on Status of Gitlab Migration

[Johan Ouwerkerk]

On Sun, Apr 12, 2020 at 12:49 AM Johan Ouwerkerk  wrote:
>
> >
> > We may need to do on-the-fly conversion of the kde: repo paths if they
> > won't be expressible as 'kde:foo' in the future, but we should have the
> > information needed to do this in kdesrc-build to make this happen
> > on-the-fly.
> >
>
> Yes, this should be fairly straight forward: we could do a `git remote
> set-url` based on what the repo metadata tells us before updating a
> local clone. In fact: we could build this right now and sell it as
> "automagically recover your upstream".  :)
>
> I might try to hack something up tomorrow or monday for that.
>

A basic version of this is now available via:
https://invent.kde.org/kde/kdesrc-build/-/merge_requests/27
With this feature sysadmin should now be free to change the repopath
value in the metadata YAML and kdesrc-build will reconfigure the
remote URL appropriately automatically. This works as long as the same
`kde:$path` expression works for both fetch and push, i.e. the layout
on the anongit.kde.org network must match with the layout of
git.kde.org/invent.kde.org. If necessary a simple path prefix change
could still work with a minor update to the pushInsteadOf mapping,
e.g. when repos on invent are mapped to kde/   instead of
/.

You can also experiment with setting invent.kde.org as the push URL by
setting x-invent-kde-push-urls to true in your rc file. The effect
should be visible through git remote -vv afterwards. (Disable the
setting and re-run again afterwards because this will obviously break
your push URLs as long as the Gitlab migration hasn't completed yet).

Regards,

- Johan

Re: Update on Status of Gitlab Migration

[Johan Ouwerkerk]

On Sun, Apr 12, 2020 at 1:06 AM Ben Cooksley  wrote:
>
> On Sun, Apr 12, 2020 at 11:04 AM Johan Ouwerkerk  
> wrote:
> >
> > On Sun, Apr 12, 2020 at 12:49 AM Johan Ouwerkerk  
> > wrote:
> > >
> > > Yes the only reason why a cleanup script might be needed is if the
> > > logical path used to express the repo in dependency information
> > > changes at the same time. E.g. suppose a `frameworks/kf5foo` gets
> > > remapped to `frameworks/kf5/foo` or something like that. In that case
> > > unless you use the flat repository layout, kdesrc-build would try to
> > > clone a new `frameworks/kf5/foo` repo, leaving your old
> > > `frameworks/kf5foo` to consume some wasted disk space.
> > >
> >
> > This is obviously a poor example, but the same problem occurs if
> > something moves from playground to extragear. Basically if the
> > `projectpath` YAML key changes.
>
> I had been considering adding the Gitlab Project ID number to the YAML
> metadata files as a way of allowing us to track projects through their
> whole lifetime.
>

That would be very nice, because then `kdesrc-build` could implement
an `arc patch` type feature in a more straightforward fashion. So
people could type things like `kdesrc-build juk!55` as a shorthand for
checkout remote HEAD of whatever branch MR 55 is for `juk`.

Regards,

- Johan

Re: Update on Status of Gitlab Migration

[Ben Cooksley]

On Sun, Apr 12, 2020 at 11:04 AM Johan Ouwerkerk  wrote:
>
> On Sun, Apr 12, 2020 at 12:49 AM Johan Ouwerkerk  
> wrote:
> >
> > Yes the only reason why a cleanup script might be needed is if the
> > logical path used to express the repo in dependency information
> > changes at the same time. E.g. suppose a `frameworks/kf5foo` gets
> > remapped to `frameworks/kf5/foo` or something like that. In that case
> > unless you use the flat repository layout, kdesrc-build would try to
> > clone a new `frameworks/kf5/foo` repo, leaving your old
> > `frameworks/kf5foo` to consume some wasted disk space.
> >
>
> This is obviously a poor example, but the same problem occurs if
> something moves from playground to extragear. Basically if the
> `projectpath` YAML key changes.

I had been considering adding the Gitlab Project ID number to the YAML
metadata files as a way of allowing us to track projects through their
whole lifetime.

>
> Regards,
>
> - Johan

Cheers,
Ben

Re: Update on Status of Gitlab Migration

[Johan Ouwerkerk]

On Sun, Apr 12, 2020 at 12:49 AM Johan Ouwerkerk  wrote:
>
> Yes the only reason why a cleanup script might be needed is if the
> logical path used to express the repo in dependency information
> changes at the same time. E.g. suppose a `frameworks/kf5foo` gets
> remapped to `frameworks/kf5/foo` or something like that. In that case
> unless you use the flat repository layout, kdesrc-build would try to
> clone a new `frameworks/kf5/foo` repo, leaving your old
> `frameworks/kf5foo` to consume some wasted disk space.
>

This is obviously a poor example, but the same problem occurs if
something moves from playground to extragear. Basically if the
`projectpath` YAML key changes.

Regards,

- Johan

Re: Update on Status of Gitlab Migration

[Johan Ouwerkerk]

On Sat, Apr 11, 2020 at 11:03 PM Michael Pyne  wrote:
>
> On Sat, Apr 11, 2020 at 09:25:11PM +0200, Johan Ouwerkerk wrote:
>
> >
> > A cleanup script could be handy. I think kdesrc-build will
> > automatically pick up new repo paths from metadata and that should
> > work transparently, but the old clones may get left behind as well.
> > People who use the kdesrc-build option to ignore KDE repo structure
> > shouldn't be affected at all.
>
> (...)
>
> All of the kde: repositories use the kde:foo syntax, where the 'foo'
> comes from the 'repopath' parameter of the sysadmin/repo-metadata YAML
> files.
>

Yes the only reason why a cleanup script might be needed is if the
logical path used to express the repo in dependency information
changes at the same time. E.g. suppose a `frameworks/kf5foo` gets
remapped to `frameworks/kf5/foo` or something like that. In that case
unless you use the flat repository layout, kdesrc-build would try to
clone a new `frameworks/kf5/foo` repo, leaving your old
`frameworks/kf5foo` to consume some wasted disk space.

>
> We may need to do on-the-fly conversion of the kde: repo paths if they
> won't be expressible as 'kde:foo' in the future, but we should have the
> information needed to do this in kdesrc-build to make this happen
> on-the-fly.
>

Yes, this should be fairly straight forward: we could do a `git remote
set-url` based on what the repo metadata tells us before updating a
local clone. In fact: we could build this right now and sell it as
"automagically recover your upstream".  :)

I might try to hack something up tomorrow or monday for that.

Regards,

- Johan

Re: Update on Status of Gitlab Migration

[Michael Pyne]

On Sat, Apr 11, 2020 at 09:25:11PM +0200, Johan Ouwerkerk wrote:
> On Sat, Apr 11, 2020 at 8:39 PM Ben Cooksley  wrote:
> >
> > Yes, the hostname git.kde.org will be fully retired as part of this 
> > transition.
> >
> > From my understanding kdesrc-build will automatically pick this up
> > once we update sysadmin/repo-metadata to show the new repository
> > paths.
> > This is something we'll confirm with mpyne though to ensure we can
> > make the cutover as smooth as possible.
> >
> 
> Just to be clear, my understanding based on reading the
> `Updated/Git.pm` module is that KDE repo paths are abstracted via
> ~/.gitconfig URL remapping using `insteadOf`and `pushInsteadOf`.
> Currently the code manipulates the user's ~/.gitconfig to bind the
> correct mappings to the `kde:` prefix (this happens even before
> cloning sysadmin repos for metadata).
> 
> So if my understanding of the code is correct, the entire switch over
> is transparent provided that kdesrc-build is updated beforehand to set
> the updated value for `pushInsteadOf`. We already have the same
> mechanism in place in kdesrc-build for ensuring that people use
> https://anongit.kde.org instead of git://anongit.kde.org when
> cloning/fetching.

Yeah, when Ben asked me a couple of months back about it, this was the
same conclusion I reached after reviewing the existing code.

But I need to note that the way this works right now is that a module is
cloned via a URL such as 'kde:juk' (not kde:kde/kdemultimedia/juk!).
This is transparent to how git operates when setup with ~/.gitconfig, so
you won't notice it in `git remote -v`, you need to actually look at the
repository's .git/config, or run `git config --local --get
remote.origin.url` in the source directory, to see whether it uses a
kde: URL or a full URL.

Either way, once the switchover happens, then *in theory* it can be as
easy as running kdesrc-build once (to update ~/.gitconfig) and from
there Git will rewrite to the updated URL automatically.

We could add the switchover logic before that and guard it with a date
check, that way we can do some testing early.

> > Depending on how things look we may also make available a script that
> > will update the configuration of a repository to reflect both the
> > change in hostname as well as the change in path.
> >
> 
> A cleanup script could be handy. I think kdesrc-build will
> automatically pick up new repo paths from metadata and that should
> work transparently, but the old clones may get left behind as well.
> People who use the kdesrc-build option to ignore KDE repo structure
> shouldn't be affected at all.

I don't know that we'll even necessarily need a cleanup script (though
it couldn't hurt).

In my case, my entire source repository contains only one repository
directly referencing anongit (or git.kde.org), all others are non-KDE or
kde:

  1 git://anongit.kde.org/scratch/
  1 git://cmake.org/
 16 git://code.qt.io/
  1 git://git.freedesktop.org/
  1 git://git.gnupg.org/
  3 git://github.com/
 23 https://code.qt.io/
  7 https://github.com/
  1 https://gitlab.com/
344 kde:

All of the kde: repositories use the kde:foo syntax, where the 'foo'
comes from the 'repopath' parameter of the sysadmin/repo-metadata YAML
files.

We may need to do on-the-fly conversion of the kde: repo paths if they
won't be expressible as 'kde:foo' in the future, but we should have the
information needed to do this in kdesrc-build to make this happen
on-the-fly.

Regards,
 - Michael Pyne

Re: Update on Status of Gitlab Migration

[Nicolás Alvarez]

El sáb., 11 de abr. de 2020 a la(s) 16:26, Johan Ouwerkerk
(jm.ouwerk...@gmail.com) escribió:
>
> On Sat, Apr 11, 2020 at 8:39 PM Ben Cooksley  wrote:
> >
> > Yes, the hostname git.kde.org will be fully retired as part of this 
> > transition.
> >
> > From my understanding kdesrc-build will automatically pick this up
> > once we update sysadmin/repo-metadata to show the new repository
> > paths.
> > This is something we'll confirm with mpyne though to ensure we can
> > make the cutover as smooth as possible.
> >
>
> Just to be clear, my understanding based on reading the
> `Updated/Git.pm` module is that KDE repo paths are abstracted via
> ~/.gitconfig URL remapping using `insteadOf`and `pushInsteadOf`.
> Currently the code manipulates the user's ~/.gitconfig to bind the
> correct mappings to the `kde:` prefix (this happens even before
> cloning sysadmin repos for metadata).
>
> So if my understanding of the code is correct, the entire switch over
> is transparent provided that kdesrc-build is updated beforehand to set
> the updated value for `pushInsteadOf`. We already have the same
> mechanism in place in kdesrc-build for ensuring that people use
> https://anongit.kde.org instead of git://anongit.kde.org when
> cloning/fetching.

Changing .gitconfig won't be enough, per-repo changes will still be
needed (although kdesrc-build could be updated to do those for you
too).

Currently if a project moves to gitlab, you need to change
g...@git.kde.org:kdenlive to g...@invent.kde.org:kde/kdenlive (note the
kde/ addition). If that was all, in principle you could use insteadOf
to map kde: to "g...@invent.kde.org:kde/". But depending on future
discussions about structure, it's possible that eg. kcoreaddons will
end up moving to frameworks/kcoreaddons rather than kde/kcoreaddons.

-- 
Nicolás

Re: Update on Status of Gitlab Migration

[Johan Ouwerkerk]

On Sat, Apr 11, 2020 at 8:39 PM Ben Cooksley  wrote:
>
> Yes, the hostname git.kde.org will be fully retired as part of this 
> transition.
>
> From my understanding kdesrc-build will automatically pick this up
> once we update sysadmin/repo-metadata to show the new repository
> paths.
> This is something we'll confirm with mpyne though to ensure we can
> make the cutover as smooth as possible.
>

Just to be clear, my understanding based on reading the
`Updated/Git.pm` module is that KDE repo paths are abstracted via
~/.gitconfig URL remapping using `insteadOf`and `pushInsteadOf`.
Currently the code manipulates the user's ~/.gitconfig to bind the
correct mappings to the `kde:` prefix (this happens even before
cloning sysadmin repos for metadata).

So if my understanding of the code is correct, the entire switch over
is transparent provided that kdesrc-build is updated beforehand to set
the updated value for `pushInsteadOf`. We already have the same
mechanism in place in kdesrc-build for ensuring that people use
https://anongit.kde.org instead of git://anongit.kde.org when
cloning/fetching.

>
> Depending on how things look we may also make available a script that
> will update the configuration of a repository to reflect both the
> change in hostname as well as the change in path.
>

A cleanup script could be handy. I think kdesrc-build will
automatically pick up new repo paths from metadata and that should
work transparently, but the old clones may get left behind as well.
People who use the kdesrc-build option to ignore KDE repo structure
shouldn't be affected at all.

Regards,

- Johan

Re: Update on Status of Gitlab Migration

[Nicolás Alvarez]

El 11 abr. 2020, a la(s) 08:31, Johan Ouwerkerk  
escribió:
> 
> On Sat, Apr 11, 2020 at 11:36 AM Ben Cooksley  wrote:
>> Should anyone have any questions on the above, please let us know.
> 
> Does the migration also mean that `git.kde.org` push URL will be
> retired and would need to be remapped to `invent.kde.org`?
> 
> In that case, it would be good to have a grace period after the
> initial migration to Gitlab so kdesrc-build (etc.) could be updated
> before the cut off date to perform this migration automatically for
> the user. I expect such a grace period would not need to last very
> long because the feature would be trivial to implement.

How would it work during the "grace period"? Keeping an outdated read-only 
mirror on the old URL? I have done some research into redirecting or remapping 
from the old URL to the new one so we can keep it working for a longer period 
of time, and it's harder than it seems... It can be done but I need to be 
convinced that it's actually necessary / worth the effort.

-- 
Nicolás
KDE Sysadmin Team

Re: Update on Status of Gitlab Migration

[Ben Cooksley]

On Sat, Apr 11, 2020 at 11:31 PM Johan Ouwerkerk  wrote:
>
> On Sat, Apr 11, 2020 at 11:36 AM Ben Cooksley  wrote:
> >
> > Should anyone have any questions on the above, please let us know.
> >
>
> Does the migration also mean that `git.kde.org` push URL will be
> retired and would need to be remapped to `invent.kde.org`?

Yes, the hostname git.kde.org will be fully retired as part of this transition.

>From my understanding kdesrc-build will automatically pick this up
once we update sysadmin/repo-metadata to show the new repository
paths.
This is something we'll confirm with mpyne though to ensure we can
make the cutover as smooth as possible.

Depending on how things look we may also make available a script that
will update the configuration of a repository to reflect both the
change in hostname as well as the change in path.

>
> In that case, it would be good to have a grace period after the
> initial migration to Gitlab so kdesrc-build (etc.) could be updated
> before the cut off date to perform this migration automatically for
> the user. I expect such a grace period would not need to last very
> long because the feature would be trivial to implement.
>
> Regards,
>
> - Johan

Cheers,
Ben

Re: Update on Status of Gitlab Migration

[Johan Ouwerkerk]

On Sat, Apr 11, 2020 at 11:36 AM Ben Cooksley  wrote:
>
> Should anyone have any questions on the above, please let us know.
>

Does the migration also mean that `git.kde.org` push URL will be
retired and would need to be remapped to `invent.kde.org`?

In that case, it would be good to have a grace period after the
initial migration to Gitlab so kdesrc-build (etc.) could be updated
before the cut off date to perform this migration automatically for
the user. I expect such a grace period would not need to last very
long because the feature would be trivial to implement.

Regards,

- Johan

Re: Update on Status of Gitlab Migration

[Johan Ouwerkerk]

On Sat, Apr 11, 2020 at 11:36 AM Ben Cooksley  wrote:
>
> To help assist with this, it would be appreciated if all holders of a
> KDE Developer account could please login on our Gitlab instance (at
> https://invent.kde.org/) and ensure they are listed as a 'Developer'
> of the KDE group. You can do this by checking the 'Groups' tab of your
> Profile on Gitlab.
>

This is a more direct URL that goes straight to the members page of
the KDE group: https://invent.kde.org/groups/kde/-/group_members

If you are logged in on invent.kde.org you should be able to use the
search box to find yourself (by identity.kde.org name, in my case).

Regards,

- Johan

Re: Update on Status of Gitlab Migration

[Christoph Cullmann]

Hi,

I just want to express my big thanks for all the work that went into 
this!


Thanks to all people involved in making this happen and 
maintaining/improving all

our other infrastructure.

Besides, happy Easter and become/stay healthy!

Greetings
Christoph

On 2020-04-11 11:35, Ben Cooksley wrote:

Good morning Community,

I'm pleased to report that this week we reached a major milestone,
with all the necessary technical components now being in place on our
side for our migration to Gitlab to take place.

This includes the replacement of the tooling that supports the anongit
network, as well as implementation of a system to sync changes from
Identity to Gitlab in real time.

As part of this, the anongit network following the migration to Gitlab
should pick up new repositories, along with changes to default
branches, project descriptions, repository names and their path, and
the deletion of repositories within 10 seconds of the change taking
place on Gitlab (effectively making it real time)

We are currently looking to confirm how repositories will be organised
on Gitlab, after which we should be able to confirm how and when we
perform the migration.

Please note that only code hosting and code review will be
transitioning at this time - CI and tasks will follow later on.
Existing reviews on Phabricator will not be imported to Gitlab as part
of this process and will need to be closed out on Phabricator.

To help assist with this, it would be appreciated if all holders of a
KDE Developer account could please login on our Gitlab instance (at
https://invent.kde.org/) and ensure they are listed as a 'Developer'
of the KDE group. You can do this by checking the 'Groups' tab of your
Profile on Gitlab.

Should you not be listed as a Developer of the group, and you have
previously logged into Gitlab, please visit KDE Identity and make a
change to your details there, which will trigger a sync of your
account to Gitlab.

Should anyone have any questions on the above, please let us know.

Thanks,
Ben Cooksley
KDE Sysadmin


--
Ignorance is bliss...
https://cullmann.io | https://kate-editor.org