Summary of tasks

Putting this at the top for ease of reading.

• Find and implement a solution for running tests on macOS and Windows. → Keep a GitHub action that runs on the mirror for testing Windows.
• Create pull requests that change the URL of reuse-tool to https://codeberg.org/fse/reuse-tool.
  • https://github.com/fsfe/reuse-website
  • https://git.fsfe.org/reuse/api
  • https://git.fsfe.org/reuse/api-worker
  • https://github.com/fsfe/reuse-action
  • https://git.fsfe.org/FSFE/fsfe-website
• Add the necessary people to the https://codeberg.org/fsfe organisation.
• (OPTIONAL) Get FSFE's system hackers to spin up a runner so I don't have to.
• Set up a proof-of-concept for pushing to Docker from Codeberg.

After migration

• Turn https://github.com/fsfe/reuse-tool into a read-only mirror.
• Merge the URL-rename pull requests.
• Tell Docker about our new URL.
• Fix the job that uploads images to Docker.
• Tell Weblate about our new URL.
• Fix the job that pushes/pulls to/from Weblate.
• Add a Forgejo runner to the new repository/organisation.
• Set up the repository settings. Protect the main branch.

2025-10-29 - Switch to Codeberg

We have chosen to move to Codeberg. I have been quietly working on this between other tasks. Unless super important bugs appear, this switch has highest priority.

I did some testing on moving this repository. Here is a summary of what I've done, and what I've learnt from this process

Migrating a repository

I created a repository https://github.com/carmenbianca/codeberg-demo with an issue, a pull request, some tags, and a release. I used Codeberg's importer (with a GitHub token) to create https://codeberg.org/carmenbianca/codeberg-demo. It migrated everything correctly, re-creating comments with a 'migrated from GitHub' tag on each comment.

Nothing seems out of place, and the importer handles all the functionality we use (issues, PRs, releases).

Running workflows

I cloned reuse-tool on Codeberg, and created a pull request at https://codeberg.org/carmenbianca/reuse-tool/pulls/1. This cloned repository will be deleted eventually. In the pull request, I edited all the .github/workflows files to run on Forgejo. I created my own runner, and I will forward my config of this runner to FSFE's system hackers.

Forgejo Actions is very similar to GitHub actions, and it can re-use some of GitHub's actions. However, the actions/setup-python action uses a lot of bandwidth because there is no caching. So instead, I did things a little differently:

• For the test job, where I run pytest against multiple versions of Python, I use the nikolaik/python-nodejs Docker images. Node is needed to use actions like actions/checkout I create a user in the container and run the tests as not-root for some filesystem permission shenanigans.
• For creating a Docker image, I use docker:cli (and install Node to be able to use actions).
• For all other jobs, I use node:24-trixie, and apt-get install python3-poetry. I could feasibly use nikolaik/python-nodejs instead, but the image is very heavy (even though it is cached), and it's honestly fine and consistent.

What doesn't translate

Some stuff doesn't make the cut to the switch to Codeberg.

• I disabled the close_inactive_actions workflow. I'm not certain it integrates into Forgejo, and it'll be a pain to test. I also sort of don't really like it.
• I don't have macOS and Windows runners. It's technically possible to have such runners (but I don't believe Forgejo actively supports Windows runners), but I don't have the budget or infrastructure for this. And more likely than not, FSFE's system hackers won't spin up proprietary servers. This is kind of a big deal. I did catch Windows bugs with GitHub Actions, and according to pypistats, 10–20% of our downloads are from Windows and macOS—5–10% respectively. I have no good solution for this. Maybe keep these workflows running on GitHub Actions via a mirror?

What doesn't work yet

• I haven't set up the tokens for Weblate and Docker integration. Experience teaches me that this'll be a lot of fiddling after migration. I don't know how to get this right in one go. It looks to be set up correctly at the moment, though. But I am especially doubtful about the Docker integration because it requires qemu. I have no idea if qemu will run in my Docker container of Forgejo Runner.

Everything else

After the migration is done, more work will need to be done:

• Change links in all other repositories to the new Codeberg home.
• Turn https://github.com/fsfe/reuse-tool into a read-only mirror.
• … Migrate the other repositories, too. Out of scope of this issue.

2023-11-21 - original proposal

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