Move main dev to Codeberg

[6543]

(Long term goal - wont rush of course)

• able to migrate issues & pulls
• able to push updates to github (push mirrors)
• bot to mirror github interactions to codeberg (like gopherbot do on golang repos ...)

You can react on this issue to vote?

To avoid spamming the issue please refrain from commenting.

👍 = move to codeberg; 😆 = don't care; 👎 = no

Some background

The main difference between Github and codeberg.org is who is operating the SCM systems and the fact that the software which is used for Github is not FOSS. While Github is operated by Microsoft and using Github as SCM, codeberg.org is operated by the Codeberg e.V. (non profit org based in Germany) and is using Gitea a FOSS software as SCM. In the end, the question is who you want to trust / support and which software (Github vs Gitea) you prefer.

[anbraten]

Should we ask the community to vote (just yes or no without reasons / comments)?

[6543]

I would say 👍 = yes; 😆 = dont care; 👎 = no

[jolheiser]

As part of this (potential) move, we should consider using a vanity URL for imports.

[BracketJohn]

Can you go a bit more into detail about the expected benefits and downsides of a move to codeberg? What was the reason this idea was brought up? (:

[anbraten]

The main difference is who is operating the SCM systems and the fact that the software which is used for Github is not FOSS.
While Github is operated by Microsoft and using Github as SCM, codeberg.org is operated by the Codeberg e.V. (non profit org based in Germany) and is using Gitea a FOSS software as SCM. In the end, the question is who you want to trust / support and which software (Github vs Gitea) you prefer.

(Correct me if I am wrong)

[6543]

Also I'm hoping for federation (forgefed) and github will be the last to implement this

[pat-s]

@6543 @anbraten Could you share the current status here with everyone? I would be interested to help.

Seeing the pains Gitea has with migration meanwhile due to the repo size etc. makes me think that an "early" switch would simplify things a lot. Not sure though if "early" still applies 😄

[johnandersen777]

@6543 I think we should be able to just translate webhook events into the federated events to onramp data directly, an online mirror / online clone.

---

Cross-post from: go-gitea/gitea#23072 (comment)

It looks like we might be able to mirror the live event stream off the webhook events and translate into federated events for what is effectively an "online clone", some sketch work on the CI/CD front follows (translation flow is in the linked OpenSSF Metrics use case). This would of course be after the initial pull import but wanted to paste here for sake of propagating aligned discussion.

GitHub Webhook -> Forge Federation could enable users to more seamlessly migrate as they could maintain state both places after initial migration while they switch over.

Leveraging setting a URL within either security.txt/md as an AcitivtyPub Actor enables rebroadcast and mapping of repos to their event streams in a way agnostic to hosting provider (in file). This is all very WIP right now.

Related: forgejo Contrib Discussions: CI/CD Event Federation: https://codeberg.org/forgejo-contrib/discussions/issues/12