Comment by Emen15 3 days ago
What really stands out to me in this migration story isn't the technical side at all, but the reminder that "feature parity" isn't the real hurdle here. Codeberg is already good enough for most day to day workflows; what it doesn't have is the gravitational pull GitHub built through network effects, integrations, and plain old inertia.
FWIW, Forgejo (Codeberg) is also building federation capability [0].
[0]: https://codeberg.org/forgejo-contrib/federation/src/branch/m...
Unfortunately it's most ActivityPub-oriented, right? Which means no name portability. That's a major shortcoming compared to an AT protocol-based thing like Tangled appears to be.
I don't think it's relevant to this specific instance, but AFAIK ActivityPub doesn't inherently prevent name portability. It's just that almost all implementations currently don't allow it (and I wouldn't expect Forgejo's either).
Of course, the practical downside of Tangled is also that it only has network effects within the ATmosphere, i.e. you still can't reach GitHub users.
If only we could use something like a gpg key as our identity. Maybe if it had a mechanism to share and revoke keys, upgrade them, cross-sign them with others to develop some sort of like trust system that was web-like. I bet we could like build a whole infrastructure around it to maintain developer identities in a completely decentralized way.
Has any detailed comparision been done between tangled, codeberg and github?
My primary pain point with Codeberg has been that the issue search is worse, so that there are cases where I'm rather certain than issue exists-- because I've triaged it in the past-- but it's hard to find with the keyboard search. Hopefully that can be improved soon.
There were some times were Codeberg's general performance was noticeably worse, but most recently it has been fine.
If you thinking of migrating a project with hundreds of issues, I would do a test migration and practice a few different searches to test the result quality.
And just sheer amount of documentation and examples out there. Everyone uses it, therefore everyone writes about it, the new hire probably knows it, and if they don't they can find it easily.
Then again maybe for stuff like actions and in general CI/CD it's not all that bad, you don't need whole team to know exactly how to write it, you just need to have a person knowing it. and it's generally not all that hard to learn.
This is why CI should be separate from code repository storage and that should be separate from your collaboration tools. They all can speak git if you want.
> This is why CI should be separate from code repository storage
Maybe, but for any complex project you get stuck with dependencies between various code branches and various CI repo branches anyway, so I’m not sure how much easier it really is to manage that complexity rather than just putting the CI code in your repo so that the CI dependencies are explicit.
> Then again maybe for stuff like actions and in general CI/CD it's not all that bad,
CI/CD on github has the npm problem - a lot of tiny stuff gets wrapped in actions people pull in from all over the place. Github does relatively fast deprecations, so actions need to be rewritten and updated even though there's no need for you - in this context I'd argue if it's not a security issue there's no need. So you end up with a lot of work just keeping the existing actions working - and overall would have less effort if you'd have just written your own actions - but not doing that is one of the selling points for github.
I might be biased as I've been doing complex CI/CD for close to two decades now - but github workflows _very_ quickly show their limits when you start seriously using them.
It feels like a <game theory> problem (Tragedy of the commons? First mover? I dunno them well enough). It’s probably a mistake for any one company to not pick GitHub, because it’s likely a higher friction distraction from what the actual goals are of the company. But enough companies paying that price ultimately would benefit everyone by fuelling stronger competition.
Maybe a coordination problem? https://en.wikipedia.org/wiki/Coordination_game
This is partially being addressed by projects like https://tangled.org. It's built on the same protocol as bluesky, meaning your identity is preserved across different platforms so that _where_ your git is hosted is unrelated to how you discover and connect with others.