Radicle 1.0 released [LWN.net]

Version 1.0 of the Radicle development platform has been released.

Radicle 1.0 represents the culmination of years of experimentation and hard work from our team and community, where we set out to ensure that free and open source software ecosystems can flourish without having to rely on the whims of Big Tech. We designed Radicle with a first-principles approach, as a natural extension to Git, expanding it to work in a collaborative, local-first, peer-to-peer setting.

LWN looked at Radicle in March.

I wish for the best

Posted Sep 10, 2024 22:26 UTC (Tue) by 0xilly (subscriber, #172315) [Link] (1 responses)

While I am extremely skeptical of the project and its duplicative efforts to federate git I sincerely hope that they are successful we need more git forges

I wish for the best

Posted Sep 10, 2024 22:29 UTC (Tue) by 0xilly (subscriber, #172315) [Link]

Err s/federate git/decentralize git/

Seems unfinished

Posted Sep 11, 2024 7:59 UTC (Wed) by taladar (subscriber, #68407) [Link] (4 responses)

Just from a casual read of the documentation they still seem to have some major open design issues such as

* no node and user distinction so if you use multiple devices others will have a hard time identifying you as a single individual easily
* duplicate copy of the repository locally required, doubling the required disk space
* the possibility of multiple copies with different identifiers of the same repository being created on the network if multiple users rad init independently on that repo
* no canonical state for anything but the default branch
* their documentation is hyper-focused on irrelevant implementation details in the introductory sections where you just want to know "is this useful to me" and "how is the workflow to use this"
* I didn't really find any details but it seems they completely forgot about the use case of people without code write access creating and working with issues
* Their concept of patches seems extremely primitive compared to even just patch series on mailing lists but especially compared to pull/merge requests on forges or code review tools

I really wonder why they consider this a 1.0 when it looks more like a 0.3 or something similar. The low level mechanisms seem workable (except for the node and user distinction and the primitive patches and the lack of external user issues) but it is missing an actual frontend that could be used by anyone who can currently use a forge.

Seems unfinished

Posted Sep 11, 2024 8:45 UTC (Wed) by spacefrogg (subscriber, #119608) [Link] (3 responses)

> * no node and user distinction so if you use multiple devices others will have a hard time identifying you as a single individual easily

Yes, this is a problem about key sharing. Your identity doubles as the access key.

> * duplicate copy of the repository locally required, doubling the required disk space

True for everybody self-hosting (1 copy in the server, one on each client). There are ways around it with git but nothing that works without user help. So, it is not the default. Not an issue for the majority of people.

> * the possibility of multiple copies with different identifiers of the same repository being created on the network if multiple users rad init independently on that repo

These are two different repositories. What does "same repository" in your context even mean? If we create the "same" repositories on each our github accounts, are they truly the same or just share the same name?

> * no canonical state for anything but the default branch

that is being worked on and is a mere implementation effort than an architectural question. It was a conscious decision to not let this feature defer the release.

> * their documentation is hyper-focused on irrelevant implementation details in the introductory sections where you just want to know "is this useful to me" and "how is the workflow to use this"

Good point.

> * I didn't really find any details but it seems they completely forgot about the use case of people without code write access creating and working with issues

You misunderstand the concept, then, which, again hints at unclear documentation. Write access is managed separately from your ability to participate with issues and patches. UX is similar to any other forge.

> * Their concept of patches seems extremely primitive compared to even just patch series on mailing lists but especially compared to pull/merge requests on forges or code review tools

Again, misconception. Patches are much stronger than git PR's, because they, too, are revisioned, giving you access to old states of a patches. So everybody can trace its evolution and go back and test it locally with normal git commands. Try checking out and old state of a PR from github.

Looks like the documentation would benefit from some updates. Thanks for your insights.

Seems unfinished

Posted Sep 12, 2024 15:41 UTC (Thu) by mupuf (subscriber, #86890) [Link] (2 responses)

> Again, misconception. Patches are much stronger than git PR's, because they, too, are revisioned, giving you access to old states of a patches. So everybody can trace its evolution and go back and test it locally with normal git commands. Try checking out and old state of a PR from github.

Hmm, in Gitlab's UI, you definitely can see the development's history of a patch series, and even get diffs between revisions. Sure, not from the commandline without a CLI client, but the forge exposes the data.

So, what's the rationale with using patches rather than dealing with refs (which enables merging a list of commits)? One could create a pull request by pushing to refs/mergerequest/myfeature, and the unique ID for the MR would be the tuple between user ID and their wanted chosen name. The history could be preserved in the same way as you do for patches, no?

In any case, this looks super promising! Can't wait to try it... but I'll need refs as merge request support to make use of it for public repos.

Seems unfinished

Posted Sep 12, 2024 17:13 UTC (Thu) by spacefrogg (subscriber, #119608) [Link] (1 responses)

Patches is just a name. They are branches/refs with internal management to track revisions of merge requests. From what I understand from your text, they are exactly what you want.

Seems unfinished

Posted Sep 12, 2024 18:26 UTC (Thu) by mupuf (subscriber, #86890) [Link]

I see, that's great then! I did read the documentation but I was really confused with what I saw. On the one hand it looked great that users would push a ref... but on the other hand the patches terminology and showing a single commit was implying only a single commit was supported.

If I may propose changes to the documentation,
I would try to emphasize that patch in this context isn't the same meaning as a git format-patch or a patch series, but instead more akin to a pull request for GitHub, or merge request for GitLab (in the sense that it is a ref). Also, please show more than one commit in your "patch show" exemple, along with the merge base used.

Eventually, when you add support for more than one canonical branch (super important for projects forking before releases), the Dev proposing a patch should be able to select the target branch so that the stats of "patch show" are accurate and not confusing :)

In any case, I just want to say this is FANTASTIC work! It seems to me a much more credible option than mailing lists or the fediverse for a truly decentralised workflow. I may be partial to this solution because of the time I've spent in Git's internals and how I used notes to attach test results to a commit and distribute them in a CI environment... and that made me think about using notes to attach any sort of tag (reviewed/acked/tested-by, bugs, fixes, stable...) rather than having to modify commits to manually add tags. This seems like a more complete solution and I can't wait to try it and to see it grow... especially for CI, simpler identity, and merging automation!

Radicle 1.0 released

FOSS, take back hosting!

I wish for the best

I wish for the best

Seems unfinished

Seems unfinished

Seems unfinished

Seems unfinished

Seems unfinished