undefined | Better HN

0 pointsgsaslis2y ago0 comments

Yes, this is how radicle stores this data. ; )

https://app.radicle.xyz/nodes/seed.radicle.xyz/rad:z3trNYnLW...

0 comments

https://docs.radicle.xyz/guides/protocol is probably a better resource (but this guide is still Work In Progress)

est2y ago

> Radicle’s predefined COB types are stored under the refs/cobs hierarchy. These are associated with unique namespaces, such as xyz.radicle.issue and xyz.radicle.patch, to prevent naming collisions.

This looks like an interesting approach. I have question, to avoid copy a large .git project, we have partial cloning and cloning depth. If `cobs` grows too large, how can we partially clone it? Like select issues by time range?

sebastinez2y ago

The COB types are located in the Stored Copy, you would still be able to partial clone the working copy repo without the issues and patches, with your current git commands. There is a better explainer here: https://docs.radicle.xyz/guides/protocol#storage-layout

account422y ago

> a standard way of storing project management metadata alongside version control data

Emphasis mine. Doesn't seem to be it seening as this is yet another home grown issue storage.

9dev2y ago

Yeah, exactly. Radicle doing it this way, Fossil another - see here why that is a problem: https://xkcd.com/927/

avgcorrection2y ago

And Fossil is an entirely different VCS.

What’s the alternative? That at least N projects cooperate and agree on a common design before they do the implementation? (Then maybe someone can complain about design-by-committee.)

chriswarbo2y ago

I use Artemis, which was originally written for Mercurial but also supports Git. It stores issues inside a repo, so it doesn't care about where it's hosted and works completely offline without needing a Web browser. Issues are stored in Maildir format, which is widely supported standard that can be processed using off-the-shelf tools. For example, I write and comment on Artemis issues using Emacs message-mode (which was designed for Email), and I render issues to HTML using MHonArc (which was designed for mailing list archives).

I'm not claiming these tools are the best, or anything. Just that existing standards can work very well, and are a good foundation to build up UIs or whatever; rather than attempting to design something perfect from scratch.

My fork of Artemis, patched for Python3: http://www.chriswarbo.net/git/artemis

Emacs config to trigger message-mode when emacsclient is invoked as EDITOR on an Artemis issue: http://www.chriswarbo.net/git/warbo-emacs-d/git/branches/mas...

An example of HTML rendered from Artemis issues: http://www.chriswarbo.net/git/nix-config/issues/threads.html

account422y ago

> What’s the alternative? That at least N projects cooperate and agree on a common design before they do the implementation?

That would be ideal, yes. You should solicit comments from the greater community before setting the format in stone. But the very minimum would be to build on existing attempts at issues-in-git like [0] instead of reinventing the wheel unless you have a very very very good reason.

[0] https://github.com/MichaelMure/git-bug

9dev2y ago

Yes! That's exactly what I would like to see - come together as a working group, create a PR on git itself, and implement standard support for issues, PRs, discussions, projects, votings, project websites, what-have-you. The community will take it from there.

The alternative to that would be the git project itself coming up with an implementation. They have reasonable experience working with the Kernel, and the creation of git itself seems to have worked reasonably well -- although I'm not sure I would want to use something Linus considers ergonomic :)

2 more replies

vinnyhaps2y ago

I'd like to note here that Radicle has defined our own version of issue and patch management, but they're not necessarily required to be used as part of the protocol. The protocol only defines that any and all COBs will be stored and replicated under the `refs/cobs` hierarchy.

If someone wanted to come along and define a way to embed Fossil wikis/issues as a COB then they could be replicated on the Radicle network and it's then up to application developers to load and interpret that data.

I think this is cool because it essentially allows developers to extend the Radicle ecosystem easily and define new workflows! However, that does not avoid our XKCD problem stated above ;P But hey, sometimes that's the beauty of these things -- we're given the power to define our own workflows and not locked into something everyone complains about coughGitHub branches PR flowcough

j / k navigate · click thread line to collapse

0 comments

gsaslisOP2y ago

https://docs.radicle.xyz/guides/protocol is probably a better resource (but this guide is still Work In Progress)

est2y ago

sebastinez2y ago

account422y ago

> a standard way of storing project management metadata alongside version control data

Emphasis mine. Doesn't seem to be it seening as this is yet another home grown issue storage.

9dev2y ago

Yeah, exactly. Radicle doing it this way, Fossil another - see here why that is a problem: https://xkcd.com/927/

avgcorrection2y ago

And Fossil is an entirely different VCS.

What’s the alternative? That at least N projects cooperate and agree on a common design before they do the implementation? (Then maybe someone can complain about design-by-committee.)

chriswarbo2y ago

My fork of Artemis, patched for Python3: http://www.chriswarbo.net/git/artemis

Emacs config to trigger message-mode when emacsclient is invoked as EDITOR on an Artemis issue: http://www.chriswarbo.net/git/warbo-emacs-d/git/branches/mas...

An example of HTML rendered from Artemis issues: http://www.chriswarbo.net/git/nix-config/issues/threads.html

account422y ago

> What’s the alternative? That at least N projects cooperate and agree on a common design before they do the implementation?

[0] https://github.com/MichaelMure/git-bug

9dev2y ago

2 more replies

vinnyhaps2y ago

j / k navigate · click thread line to collapse