Forge choice #4

pat-s commented 2026年02月12日 14:37:31 +01:00

As mentioned, I wouldn't recommend to use Codeberg for a new package at the moment as the CICD is barely usable without custom agents and I don't see any motivation/funding to use such.

I am saying this as the person which has managed CB CI (Woodpecker) for several years and experiencing/dealing with all these issues and user questions before. CICD is running on low-powered hardware and is (on purpose) using HDDs, which makes all file-based operations super slow.
This is unlikely going to change in the foreseeable future and it's really not fund when developing.

This was part of the reason why I created another Forgejo-based instance to get around this issue (and also have a general more performant Git UI in the first place as CB is also painfully slow in that regard).
On CodeFloe you have bare metal servers backed by an NVME and also have arm64 runners available by default.
(Problem with recommending that one is that I am obviously biased as the initial founder)

As mentioned, I wouldn't recommend to use Codeberg for a new package at the moment as the CICD is barely usable without custom agents and I don't see any motivation/funding to use such. I am saying this as the person which has managed CB CI (Woodpecker) for several years and experiencing/dealing with all these issues and user questions before. CICD is running on low-powered hardware and is (on purpose) using HDDs, which makes all file-based operations super slow. This is unlikely going to change in the foreseeable future and it's really not fund when developing. This was part of the reason why I created another [Forgejo-based instance](https://codefloe.com/) to get around this issue (and also have a general more performant Git UI in the first place as CB is also painfully slow in that regard). On CodeFloe you have bare metal servers backed by an NVME and also have arm64 runners available by default. (Problem with recommending that one is that I am obviously biased as the initial founder)

dgkf commented 2026年02月12日 18:24:12 +01:00

First. CodeFloe looks awesome and I'm happy to see more ecosystem diversity here. Whichever platform we settle on, having two forgejo instances involved will also help us ensure we're building something agnostic.

However, I think I'm still partial to codeberg.

1. Codeberg is run by a non-profit foundation whereas CodeFloe is run by a private consultancy. It sounds like CodeFloe has wonderful intentions, but I think that if we're making any recommendation about where open-source packages should live, it's encumbamt on us to steer people to platforms that are similarly divested interests.
2. For a majority of R packages testing is pretty light, fast, and OS-portable. There are certainly edge cases, but I don't think they need to be the deciding factor for new package repos. I think even the early public Codeberg runners for Forgejo Actions cover a lot of the use cases for R packages.
3. Forgejo is supported by many of the same developers as Codeberg, so it has a tighter feedback loop for issues.

First. CodeFloe looks awesome and I'm happy to see more ecosystem diversity here. Whichever platform we settle on, having two forgejo instances involved will also help us ensure we're building something agnostic. However, I think I'm still partial to codeberg. 1. Codeberg is run by a non-profit foundation whereas CodeFloe is run by a private consultancy. It sounds like CodeFloe has wonderful intentions, but I think that if we're making any recommendation about where open-source packages should live, it's encumbamt on us to steer people to platforms that are similarly divested interests. 1. For a majority of R packages testing is pretty light, fast, and OS-portable. There are certainly edge cases, but I don't think they need to be the deciding factor for new package repos. I think even the early public Codeberg runners for Forgejo Actions cover a lot of the use cases for R packages. 1. Forgejo is supported by many of the same developers as Codeberg, so it has a tighter feedback loop for issues.

mpadge commented 2026年02月13日 10:23:55 +01:00

@pat-s My vision is to develop something where there is no need for anybody to choose. Forgeojo APIs are largely generic. I'd really like a package with a simple local ~/.config/R/<pkgname>/config.(toml/json) (or whatever) that can be edited to specify whichever code-hosting services people want. That'd also be great for you, as no service would need to be hard-coded, and so everything could be make to be maximally compatible with CodeFloe anyway.

The biggest problem I see there is reconciling Rest vs GraphQL APIs, especially given

• Foregejo = exclusively REST API
• SourceHut = exclusively GraphQL API

And writing generic GraphQL config is ... a huge challenge. If this package could expose a few truly generic GraphQL API interfaces, that alone would be a huge boost! Sufficiently generic REST interfaces for common Forgejo services should in comparison be pretty straightforward. I'll wait to see what folk think before opening more issues ...

---

And @pat-s Great work on CodeFloe btw - I'll start mirroring there today. Thanks!!

@pat-s My vision is to develop something where there is no need for anybody to choose. Forgeojo APIs are largely generic. I'd really like a package with a simple local `~/.config/R/<pkgname>/config.(toml/json)` (or whatever) that can be edited to specify whichever code-hosting services people want. That'd also be great for you, as no service would need to be hard-coded, and so everything could be make to be maximally compatible with CodeFloe anyway. The biggest problem I see there is reconciling Rest vs GraphQL APIs, especially given - Foregejo = exclusively REST API - SourceHut = exclusively [GraphQL API](https://man.sr.ht/graphql.md) And writing generic GraphQL config is ... a huge challenge. If this package could expose a few truly _generic_ GraphQL API interfaces, that alone would be a huge boost! Sufficiently generic REST interfaces for common Forgejo services should in comparison be pretty straightforward. I'll wait to see what folk think before opening more issues ... --- And @pat-s Great work on CodeFloe btw - I'll start mirroring there today. Thanks!!

pat-s commented 2026年02月13日 10:46:59 +01:00

Thanks for the kind words.
Please take my below replies as food for thought and don't let them prevent you from moving forward.

Codeberg is run by a non-profit foundation whereas CodeFloe is run by a private consultancy. It sounds like CodeFloe has wonderful intentions, but I think that if we're making any recommendation about where open-source packages should live, it's encumbamt on us to steer people to platforms that are similarly divested interests.

Fair enough. For me personally the values (theoretical and applied) of a platform count more than the legal entity behind it (especially when everything is open source and can also be continue in the very worst case).
CF will never have any monetization goals and will always run on donations only. Yet these will also actively be invested into the infrastructure stack and its costs to improve platform performance and robustness instead of providing a low-performance product due to ethical reasons ala "we don't want to use SSD for CI as we think this is not a good eco approach".

I am convinced that associations often face issues related to leadership and overall quality (aka "it's good enough and we don't have more time etc."). I am not OK with this for tools that I interact with on a daily base.
I can say that I've tried for multiple years to change things to the better before attempting something new. Looking back, I should have done it earlier.
That being said, I don't expect anybody else to share this opinion as a large share is also based on personal opinions/happenings over a stretched duration of time.

For a majority of R packages testing is pretty light, fast, and OS-portable. There are certainly edge cases, but I don't think they need to be the deciding factor for new package repos. I think even the early public Codeberg runners for Forgejo Actions cover a lot of the use cases for R packages.

It just depends. Once you have a proper testing and linting suite in place, this also won't be "light" anymore for this discussed package. However, the definition of "light" is also subjective here. It will surely "work" and if you don't care about time and snappiness in the first place, the whole discussion is of course not much meaningful.

Forgejo is supported by many of the same developers as Codeberg, so it has a tighter feedback loop for issues.

That is an advantage and an issue at the same time. My personal opinion is that both should be split more as people already have a hard time distinguishing between them (and think CB = Forgejo). It is the same problem over and over again (see R vs RStudio). If you look at Mastodon and other SM you see people creating CB-specific tooling and talk about CB as if it would be the same approach as GH and GL (which is just wrong). I can't point that out often enough as I think it's important.
While that sounds a bit rageous, I'd like to again point out that I am a (strong) supporter of the project and general idea, I just think it should be handled a lot different in many details to avoid many (potential) pain points on the meta level.
To me, Forgejo shouldn't be hosted on CB, especially as they also have their own infrastructure for almost everything else than the main repo (code.forgejo.org).
But all of this is actually off-topic.

---

Overall, CB is of course much better than GH, so I am still happy this discussion/project has started.
Though I think it also poses a risk and loosing people which are frustrated interacting with an instance that doesn't provide a good dev experience.
I assume all of you are from Europe, from where the latency is somewhat acceptable. If people from the US try to interact with CB, loading times takes 6s+ for certain pages. This is not just "a bit slower" but painfully slow up to the point that one can't really take it. While there's always the possibility this improves at some point, this hasn't changed in years and I am not sure CB will ever reach a point where it's actually reasonably usable from outside of Europe. Even in Europe, latency outside of a x00km circle is quite high already.
The reason for this is, against popular believe, not the amount of users and general load but the overall DB setup and configuration. CB was already slow (and even slower) a few years ago when load was a fraction of today. Also I am stating this as a professional being responsible for (performant) platforms on a daily base.

The point behind this criticism is that it is actually not so hard to provide a "performant" instance and that even a small community-focused instance could easily provide a better experience for both devs and consumers.

Given the federated approach of Forgejo, I think much more "major" instances would be a healthy addition for the project as they would avoid putting all eggs into another single bucket (again). Luckily, migrating between instances is somewhat easy as they are based on the identical base software and just differ WRT to asset storage, DB configuration and proxy handling, which isn't related to the technical user experience related to repository/org management.
Sadly, federation isn't really pushed much in FJ and will likely take many years to become effective (which is really a pity).

Thanks for the kind words. Please take my below replies as food for thought and don't let them prevent you from moving forward. > Codeberg is run by a non-profit foundation whereas CodeFloe is run by a private consultancy. It sounds like CodeFloe has wonderful intentions, but I think that if we're making any recommendation about where open-source packages should live, it's encumbamt on us to steer people to platforms that are similarly divested interests. Fair enough. For me personally the values (theoretical and applied) of a platform count more than the legal entity behind it (especially when everything is open source and can also be continue in the very worst case). CF will never have any monetization goals and will always run on donations only. Yet these will also actively be invested into the infrastructure stack and its costs to improve platform performance and robustness instead of providing a low-performance product due to ethical reasons ala "we don't want to use SSD for CI as we think this is not a good eco approach". I am convinced that associations often face issues related to leadership and overall quality (aka "it's good enough and we don't have more time etc."). I am not OK with this for tools that I interact with on a daily base. I can say that I've tried for multiple years to change things to the better before attempting something new. Looking back, I should have done it earlier. That being said, I don't expect anybody else to share this opinion as a large share is also based on personal opinions/happenings over a stretched duration of time. > For a majority of R packages testing is pretty light, fast, and OS-portable. There are certainly edge cases, but I don't think they need to be the deciding factor for new package repos. I think even the early public Codeberg runners for Forgejo Actions cover a lot of the use cases for R packages. It just depends. Once you have a proper testing and linting suite in place, this also won't be "light" anymore for this discussed package. However, the definition of "light" is also subjective here. It will surely "work" and if you don't care about time and snappiness in the first place, the whole discussion is of course not much meaningful. > Forgejo is supported by many of the same developers as Codeberg, so it has a tighter feedback loop for issues. That is an advantage and an issue at the same time. My personal opinion is that both should be split more as people already have a hard time distinguishing between them (and think CB = Forgejo). It is the same problem over and over again (see R vs RStudio). If you look at Mastodon and other SM you see people creating CB-specific tooling and talk about CB as if it would be the same approach as GH and GL (which is just wrong). I can't point that out often enough as I think it's important. While that sounds a bit rageous, I'd like to again point out that I am a (strong) supporter of the project and general idea, I just think it should be handled a lot different in many details to avoid many (potential) pain points on the meta level. To me, Forgejo shouldn't be hosted on CB, especially as they also have their own infrastructure for almost everything else than the main repo (code.forgejo.org). But all of this is actually off-topic. --- Overall, CB is of course **much better than GH**, so I am still happy this discussion/project has started. Though I think it also poses a risk and loosing people which are frustrated interacting with an instance that doesn't provide a good dev experience. I assume all of you are from Europe, from where the latency is somewhat acceptable. If people from the US try to interact with CB, loading times takes 6s+ for certain pages. This is not just "a bit slower" but painfully slow up to the point that one can't really take it. While there's always the possibility this improves at some point, this hasn't changed in years and I am not sure CB will ever reach a point where it's actually reasonably usable from outside of Europe. Even in Europe, latency outside of a x00km circle is quite high already. The reason for this is, against popular believe, not the amount of users and general load but the overall DB setup and configuration. CB was already slow (and even slower) a few years ago when load was a fraction of today. Also I am stating this as a professional being responsible for (performant) platforms on a daily base. The point behind this criticism is that it is actually not so hard to provide a "performant" instance and that even a small community-focused instance could easily provide a better experience for both devs and consumers. Given the federated approach of Forgejo, I think much more "major" instances would be a healthy addition for the project as they would avoid putting all eggs into another single bucket (again). Luckily, migrating between instances is somewhat easy as they are based on the identical base software and just differ WRT to asset storage, DB configuration and proxy handling, which isn't related to the technical user experience related to repository/org management. Sadly, federation isn't really pushed much in FJ and will likely take many years to become effective (which is really a pity).

pat-s commented 2026年02月13日 10:58:21 +01:00

@pat-s My vision is to develop something where there is no need for anybody to choose. Forgeojo APIs are largely generic. I'd really like a package with a simple local ~/.config/R//config.(toml/json) (or whatever) that can be edited to specify whichever code-hosting services people want. That'd also be great for you, as no service would need to be hard-coded, and so everything could be make to be maximally compatible with CodeFloe anyway.

You are speaking of "largely" generic - I don't quite understand what you mean with this exactly. Any instance running Forgejo has the identical API (at least for all core operations) unless they are a soft fork (as of today I am only aware of CF) and have built additional distinct endpoints (due to a custom Pages integration). Yet even if, these don't matter as we'd only interact with the core API endpoints.

As mentioned (and so far I thought this was already agreed on), I'd personally put a hard veto against any instance-specific branding. The term to use is "Forgejo" (as the underlying Forge implementation) and this means it is compatible with any Forgejo instance out there. I wouldn't mention either CB or CF in any way in the package. (Maybe provide a link to the awesome Forgejo page listing public instances to interact with.)

The biggest UX challenge will be how to "easily" support multi-instance configurations/tokens. The best approach would likely to do it similar as the fj-cli by using/looking for different tokens locally and probing the git remote URL against specific FJ API endpoints (like api/forgejo/v1/version).

The biggest problem I see there is reconciling Rest vs GraphQL APIs, especially given
Foregejo = exclusively REST API
SourceHut = exclusively GraphQL API

That is an issue yes, but I am also not sure if SourceHut should/must be supported right away from the start. I think community effort is required from people which want to have SH supported.
The important point would be to stay open to accept contributions for additional forges and don't respond like Posit in not being interested as they don't use it themselves. This is how it all started in the end.

And @pat-s Great work on CodeFloe btw - I'll start mirroring there today. Thanks!!

Welcome.

> @pat-s My vision is to develop something where there is no need for anybody to choose. Forgeojo APIs are largely generic. I'd really like a package with a simple local ~/.config/R/<pkgname>/config.(toml/json) (or whatever) that can be edited to specify whichever code-hosting services people want. That'd also be great for you, as no service would need to be hard-coded, and so everything could be make to be maximally compatible with CodeFloe anyway. You are speaking of "largely" generic - I don't quite understand what you mean with this exactly. *Any* instance running Forgejo has the identical API (at least for all core operations) unless they are a soft fork (as of today I am only aware of CF) and have built additional distinct endpoints (due to a custom Pages integration). Yet even if, these don't matter as we'd only interact with the core API endpoints. As mentioned (and so far I thought this was already agreed on), I'd personally put a hard veto against any instance-specific branding. The term to use is "Forgejo" (as the underlying Forge implementation) and this means it is compatible with any Forgejo instance out there. I wouldn't mention either CB or CF in any way in the package. (Maybe provide a link to the awesome Forgejo page listing public instances to interact with.) The biggest UX challenge will be how to "easily" support multi-instance configurations/tokens. The best approach would likely to do it similar as the `fj-cli` by using/looking for different tokens locally and probing the git remote URL against specific FJ API endpoints (like `api/forgejo/v1/version)`. > The biggest problem I see there is reconciling Rest vs GraphQL APIs, especially given > Foregejo = exclusively REST API > SourceHut = exclusively GraphQL API That is an issue yes, but I am also not sure if SourceHut should/must be supported right away from the start. I think community effort is required from people which want to have SH supported. The important point would be to *stay open* to accept contributions for additional forges and don't respond like Posit in not being interested as they don't use it themselves. This is how it all started in the end. > And @pat-s Great work on CodeFloe btw - I'll start mirroring there today. Thanks!! Welcome.

rkrug commented 2026年05月05日 10:57:06 +02:00

I am coming late to the discussion, it seems - and pardon my ignorance if I am missing the point completely, but I would consider going one step further and use a DBI type approach. Having one package which is just a contract for functions and API access, and additional functions in additional packages for different providers.

So the contract would stay identical, and it would be extremely easy to(well - mainly and in theory) to switch backends - just initialise the package with the new backend package, and the same function names and same signatures (hopefully) now just work on a different backend. It might involve more planning, but open many supported backends with (hopefully) minimal work. Also partial implementations would be possible.

I am coming late to the discussion, it seems - and pardon my ignorance if I am missing the point completely, but I would consider going one step further and use a DBI type approach. Having one package which is just a contract for functions and API access, and additional functions in additional packages for different providers. So the contract would stay identical, and it would be extremely easy to(well - mainly and in theory) to switch backends - just initialise the package with the new backend package, and the same function names and same signatures (hopefully) now just work on a different backend. It might involve more planning, but open many supported backends with (hopefully) minimal work. Also partial implementations would be possible.