between codeberg, sourcehut, and disroot, and ecosystem of stuff-that-isn't-github is just so good. different service providers fitting different niches, all backed by some good software and lovely people. i hope they're all able to keep it up!!!
@jacqueline I was interested in trying out #Radicle, but after a good two hours reading docs and trying to figure out their decentralization model I'm just more confused than when I started. Plus, call it superstitious, but any project that embraces .eth is a project I'm fine staying away from.
I'll just self-host #sourcehut and call it a day. Figuring out how git-email works will be my next project.
working on sketching a few different git workflows I've seen people use. what am I missing?
(I'm less interested in minor variations on these like how you manage tags or the exact details of how the feature branches work and more interested in completely different workflows)
@b0rk@radicle yes, I think there is always a need for a “canonical” main, so new users don’t have to fully grasp the governance model in order to read the code / contribute.
By “governance model” I basically mean the workflow process by which code gets merged to the canonical main branch.
Technical differences of a p2p network like #radicle aside, I think the same social structure is in projects that request X reviewers (from Y different orgs) to approve before merge.
I've started a new job earlier this month. I now work on and for #Radicle , a distributed git hosting system and peer-to-peer code collaboration system. I'll be working on continuous integration support.
It's open source and written in Rust, and is making git be #distributed again.
I am waiting for #gitea#forgejo to implement support for #ActivityPub. Once that is available and every ActivityPub account can open issues without needing to open a local gitea/forgejo account, I will spin up my own instance of forgejo to host my git repos. Moar #decentralisation :) (I have already moved my repos from GitHub to #CodeBerg a year ago)
@jwildeboer not sure if you’ve come across https://radicle.xyz yet - it’s a peer-to-peer forge that tries to solve a similar problem to what you’re describing.
Being p2p it has an additional “resiliency” advantage because projects (including their issues, patches, etc) can be seeded by any node in the network - meaning the project stays online even if the maintainer’s instance is (taken) down for any reason.
When there's only one implementation it tends towards a platform (or in the case of a distributed exchange, it WANTS to be the platform).
When there's multiple stable implementations... It can tend to stay a protocol
Even things like #ssb (manyverse) or #radicle (distributed git) go through periods where the spec gets such a huge overhaul that the single reference client isn't usable.
Vs having a normal http server mode, compatible with a browser.
Matrix straddles the line.... It still does unhealthy stuff for the potential survival or expansion of the protocol and clients I can't fit into the simple heuristic.