Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Move away from GitHub #865

Open
carmenbianca opened this issue Nov 21, 2023 · 6 comments
Open

Move away from GitHub #865

carmenbianca opened this issue Nov 21, 2023 · 6 comments
Assignees

Comments

@carmenbianca
Copy link
Member

carmenbianca commented Nov 21, 2023

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

@carmenbianca carmenbianca self-assigned this Nov 21, 2023
@carmenbianca carmenbianca pinned this issue Nov 21, 2023
@mxmehl
Copy link
Member

mxmehl commented Nov 21, 2023

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
Copy link

Are there any considerations to moving to GitLab SaSS?

@mxmehl
Copy link
Member

mxmehl commented Jan 9, 2024

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
Copy link
Member

mxmehl commented Jun 21, 2024

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
Copy link

Kladki commented Jun 28, 2024

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
Copy link

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

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants