Move this repository to to the eclipse-dash organisation

[waynebeaton]

My first thought is to move this to our GitLab instance, but I think that would be too big of a change for our adopters and I assume that it would break the GitHub integrations that we have in place.

Let's just move this to https://github.com/eclipse-dash.

FYI @HannesWell

[HannesWell]

My first thought is to move this to our GitLab instance, but I think that would be too big of a change for our adopters and I assume that it would break the GitHub integrations that we have in place.

Yes, I also don't think it is possible to have GH workflows defined somewhere else.
If you prefer gitlab much more, you could just move the code to gitlab and have the workflows here at GH or in the eclipse-dash organization. But now that we have the organization, I think it is the consequent next step to use it. :)

Github is often quite good in redirecting, so if this repository is transferred (and not re-created) existing users of the license-workflow may even continue to work without changes. If the repo has to be re-created I think it would be good to keep this as archived (at least for some time) to allow migration of all users.

[waynebeaton]

Let's take GitLab off the table. That was just me mumble-typing.

Moving the repository will be sooo much easier than copying or re-creating. It would be good if we can verify in advance whether or not moving the repository will impact our existing users. If that something you can sort out @HannesWell ?

Does it make sense to factor out the GH workflows into a separate GitHub project? (later)

[HannesWell]

Absolutely that's much simpler.

Moving the repository will be sooo much easier than copying or re-creating. It would be good if we can verify in advance whether or not moving the repository will impact our existing users. If that something you can sort out @HannesWell ?

I did some research and did not found any doc about this. So maybe it works or not.
I suggest we simply announce the move shortly before it happens and the necessary changes on the Cross-Project mailing list.
It's easy to fix and just used 'internally' so I think a short downtime would be ok.

I can take care of it if you tell me when it will happen and the extact target.
And can then also fix the repos I'm involved.

Does it make sense to factor out the GH workflows into a separate GitHub project? (later)

I neither see an advantage nor a drawback in this since it just happily co-exists.
Therefore I would just keep it simple and in this repo.

[waynebeaton]

I have committer office hours scheduled next week. I'll include this in the notice that precedes that an in the agenda.

The EF will be in shutdown from December 22 to Jan 2, and while I'll likely play with this during that time, it would be better if we didn't have anybody blocked while we're out. I'm thinking that we schedule the move for the first week of January.

I neither see an advantage nor a drawback in this since it just happily co-exists.
Therefore I would just keep it simple and in this repo.

+1

[HannesWell]

I have committer office hours scheduled next week. I'll include this in the notice that precedes that an in the agenda.

OK, good. Thanks.

The EF will be in shutdown from December 22 to Jan 2, and while I'll likely play with this during that time, it would be better if we didn't have anybody blocked while we're out. I'm thinking that we schedule the move for the first week of January.

Changing the calling workflows doesn't need anybody from the EF, just any committer that can adjust the calling workflow. So from that point of view you can do it at any time. But I'm not sure if transferring a repo into another organization can be done without one from the infra-team.

[marcdumais-work]

Hi!

Moving the repository will be sooo much easier than copying or re-creating. It would be good if we can verify in advance whether or not moving the repository will impact our existing users.

I can confirm that this should all work transparently for the users, if/when the repository is moved: Several years ago, we moved repositories from the old theia-ide org to the Eclipse Foundation org eclipse-theia, and the re-directions are still in place and working:

HTTP:
https://github.com/theia-ide/theia -> takes you to the repo under the new org

GIT: git operations using the old remote name still work, and transparently give access to the new repo:

$ git clone https://github.com/theia-ide/theia.git
Cloning into 'theia'...
remote: Enumerating objects: 129601, done.
remote: Counting objects: 100% (4161/4161), done.
remote: Compressing objects: 100% (2112/2112), done.
remote: Total 129601 (delta 2746), reused 3037 (delta 2030), pack-reused 125440
Receiving objects: 100% (129601/129601), 167.68 MiB | 3.50 MiB/s, done.
Resolving deltas: 100% (97367/97367), done.
$ cd theia
theia$ git remote -v
origin	https://github.com/theia-ide/theia.git (fetch)
origin	https://github.com/theia-ide/theia.git (push)

theia$ git log
commit 29aa6359ea47e5fd7de72df465527e46f659b139 (HEAD -> master, origin/master, origin/HEAD)
Author: Jonah Iden <jonah.iden@typefox.io>
Date:   Mon Mar 25 17:02:44 2024 +0100

I quickly tried and it also works the same with a ssh-type git remote (e.g. git clone git@github.com:theia-ide/theia.git)

[waynebeaton]

I've moved the repository to the eclipse-dash organisation.

If anything breaks, please let me know ASAP and I'll undo the change.

[marcdumais-work]

I was able to do a "git pull" from my existing clone, that still points to the old org, and it worked as expected.

[HannesWell]

I've moved the repository to the eclipse-dash organisation.

Thanks.

If anything breaks, please let me know ASAP and I'll undo the change.

It indeed broke the license-check workflows, but it can be fixed by a simple change like in eclipse-platform/eclipse.platform.releng.aggregator#2184.
But to help all users it would be good to announce the move on cross-project mailing list.
I don't see this as a reason to revert the move.

[netomi]

we noticed failing workflows as well in the eclipse-cbi project after the transfer (see https://github.com/eclipse-cbi/org.eclipse.cbi/actions/runs/9974391371). A bit surprising that the redirect is not followed by GitHub itself.
Something to keep in mind also for other cases, e.g. go libraries. Maybe that will also not work anymore after a transfer.