Exploring forgejo as alternative to salsa ? (Was Re: Private code: to forge, or not to forge?)
Hi Otto, > > On 5/21/25 03:23, Otto Kekäläinen wrote: > > It would be nice to
read a writeup of what you plan is, and how the Go > team or other DDs
in general are expected to relate to this. > > I'm packaging forgejo
(currently ~21 golang packages are waiting in NEW, another ~10 soon to
be finished) to be eventually included in Debian. > To eat my own
dogfood, I've setup forgejo.d.n and pushed my own packages there. > Once
forgejo is in Debian, I intend to keep using forgejo.d.n as a
test-environment for the forgejo packages before an upload happens to
Debian, tested with my own "production data" (= my other packages hosted
on it). Hi Daniel,
thanks for working on getting forgejo into Debian. I believe this is
currently the forge which IMVHO aligns best with the projects' values.
Let me explain why I hold this belief.
forgejo was created as fork of Gitea following their venture into
commercialization. The community behind forgejo is actively developing a
forge for the broader free software community itself. I assume (hope!)
they won't enshittfy the software. The development itself is hosted on
their forge (dogfooding) [0], which IMO attributes to their dedication
to actively test things.
The source code is also completly open, which can't be said for Github
and enterprise Gitlab.
While it is not that mature yet and some features are still being worked
on, I think it already suitable to host small, non-key packages.
On the techical side of things:
It's mostly written in Go, whereas Gitlab uses ruby + JS.
Nifty IMO as you can technically browse a forgejo instance (e.g
codeberg.org without JS) (which is relevant for weaker devices, and
privacy).
The CI runners use a yml format [1], which would allow (almost) a
seamless similar salsa ci setup.
I think the following features are worth looking into before we might
consider it as alternative:
- How much effort is the setup of CI runners (i.e salsa-ci)?
- Can roles / teams easily be set up ? [2]
- Does SSO with Gitlab work yet (integration for other Debian services)
? [3]
- How does the UI customization work ?
- How would security support work for stable ?
- How would it scale for all salsa users ?
- Can we mirror repos/users/teams ?
I think the runners might be the least trouble to get up and running,
while the teams/users concept might need some exploration and upstream
implementation, first of all.
I might look into this once the offical packages are ready.
> your plan regarding gains from Forgejo in Debian Personally, I think
having an offical forgejo package is great. Furthermore, given the trend
by other forges to enshittify things [4]
I think at the very least it's worth exploring its use parallel to
salsa, so we aren't negatively surprised one day.
Ideally, even as offical alternative in the future.
Just for the record: I am not stating we should switch to forgejo *right
now*, as I believe it's still not there, feature wise. I also want to
thank DSA and the salsa admins for maintaining our current setup; really
grateful to have a hosting for (most) of our packages.
I'd like to hear some input what other people think about having a
forgejo instance for packages.
Especially the questions raised above might warrant some discussion.
IMO this would err on the safe side on things should Gitlab ever decide
to become hostile (which I hope not).
best,
Matthias Geiger <werdahias>
PS: Please CC me for listmail as I am not subscribed
Links:
[0]: https://codeberg.org/forgejo/forgejo
[1]: https://forgejo.org/docs/latest/admin/runner-installation/
[2]: https://codeberg.org/forgejo/forgejo/issues/902
[3]: https://codeberg.org/forgejo/forgejo/issues/7160
[4]:
https://pivot-to-ai.com/2025/05/20/github-wants-to-spam-open-source-projects-with-ai-slop/
Reply to: