Move away from GitHub

[carmenbianca]

This has been on the agenda for some time. It is scheduled for some time in 2024 (Q1/Q2, maybe) Some options.

Option 1: Move to git.fsfe.org (Gitea)

This has been the envisioned option for … very long. Basically since the inception of the project. But the blocker has always been the fact that outside participation would be difficult:

• It's non-trivial for people to create FSFE accounts.
• Federation is not yet (still not) implemented for Gitea/Forgejo. It's somewhere on the horizon for Forgejo, but continuing to wait is becoming more and more difficult to justify.
• Allowing GitHub logins on git.fsfe.org would pollute the namespace.

Option 2: Move to Codeberg

Codeberg is "a collaboration platform providing Git hosting and services for free and open source software, content and projects." It is maintained by a Berlin-based e.V. non-profit, and runs on Forgejo (a fork of Gitea).

My impression of Codeberg is that it's trying to become the de facto forge for Free Software projects. As such, if they are successful, we can reasonably assume that people will have an account there. In any case, they allow GitHub logins, so on that basis alone all current contributors to REUSE should be able to continue contributing.

Some notes:

• CI (for testing) isn't readily available and might break at any time.
  • We have to manually request permission to use the CI, which should be totally possible for our project.
  • They currently use Woodpecker, but my impression is that they're trying to move away to another solution. This would imply more work tinkering our CI scripts.
  • "Resource usage must be reasonable". I already did some work in Save the penguins; run fewer tests in CI #849, but our resource usage remains non-trivial. There are some optimisation steps we could do to improve this without losing any tests.
• We should probably become member of Codeberg e.V. to help cover the costs. I do not have control over the budget here, and I don't know how difficult it would be to justify budget spending on this.
• Codeberg is a young initiative. It's not entirely clear to me what the likely lifespan of Codeberg is. I hope it succeeds, but it'd be good to move to a proven reliable forge.

Option 3: Use another project's git forge

Projects like Debian, GNOME, KDE, GNU, and FreeDesktop all host their own git forges (mostly GitLab). We could reasonably request to use their infrastructure, even if REUSE would be slightly out of place.

However, this re-raises the question of how difficult it would be to create accounts for those forges.

Related issues

• Migration to independent platform for provision of source code reuse-website#50

[mxmehl]

Thanks for proposing these options.

Actually, there's a subvariant for option 1. I'm personally to allow logins by third-party providers such as GitHub if we can properly split the namespaces. For this, there's an open issue with Gitea: go-gitea/gitea#7014

This would require that the permissions of these "guests" could somehow be limited to avoid that a malicious actor creates numerous repos/orgs and clutters the instance.

If option 1 cannot be realised, option 2 would be the next natural step. Supporting Codeberg should be possible and I guess we'll somehow manage the CI challenges as well. It's not ideal either though as external contributions would still entail some extra work for first-time contributors in most cases which we need to document properly.

[brlin-tw]

Are there any considerations to moving to GitLab SaSS?

[mxmehl]

Are there any considerations to moving to GitLab SaSS?

No. GitLab.com is a proprietary platform depending on a single vendor as well, so we could also stay on github.com IMHO.

[mxmehl]

Would we like to take the container registry into consideration? DockerHub is notoriously unreliable, as issues like fsfe/reuse-action#30 and the weird emails the FSFE is getting regarding their Open Source project status demonstrate.

Where we head to, we should investigate whether they offer Docker image hosting as well. IIRC Gitea has a container registry included, so this should be at least a fall-back.

[Kladki]

I would like to try address some concerns with switching away from Github. About the self-hosting Gitea (or Forgejo) option, why is it required to make an FSFE account for the forge anyways? Can't it just use the integrated account management system? If not, will there be efforts to make creation of FSFE accounts easier?

And about the concerns with moving to Codeberg:

• For CI, it is possible to host your own runner which can then connect to Codeberg, mitigating that issue
• Have you tried to justify this yet? Because you will never know if it will work if you don't try 😉
• And Codeberg talks about their lifespan on their own website.

[Ryuno-Ki]

Gitea container registry: https://docs.gitea.com/usage/packages/container

(I was involved with Gitea and Forgejo in the past)

[andreashaerter]

Just to get an additional, interesting Point-of-view regarding Forgejo and what kind of tasks might get triggered:

• https://fedoramagazine.org/fedora-moves-towards-forgejo-a-unified-decision/
• https://fedora-arc.readthedocs.io/en/latest/dist-git-comparison/stories.html

[brdjns]

Consider Sourcehut. Their infrastructure is EU-based and their entire stack runs on Free Software.

[fajfer]

What about omnipresence and pushing to GitHub and Codeberg from git.fsfe? Code is very easy to mirror, it could be harder with pull requests and issues but this could also be replicated if we wanted to.

Example: https://codeberg.org/wl/GithubCodebergMirror

[Freso]

FWIW, in case it can push forward the decision to move off of GitHub: the BDS movement is calling for the boycott of Microsoft over Microsoft knowingly assisting in the genocide of Palestinians. (They also say to Consider switching [to] free and open software instead of another, possibly complicit company.)