Comment by teddyh

10 hours ago

Just for those people for whom this might be a new concept: There is actually a fair number of these distributed bug trackers: <https://news.ycombinator.com/item?id=22833037>

7 comments

teddyh

Reply
mcepl  10 hours ago

And none of them actually work really well. This blog post is over ten years old, but the situation didn’t improve much https://matej.ceplovi.cz/blog/current-state-of-the-distribut...

  • iamnothere  8 hours ago

    No mention of Fossil, which works great and proves that the difficulty is in gathering dev interest.

    It may be that the presence of Fossil as a mature option is enough to dissuade people from choosing/working on alternatives. I’m pleased to see git-bug slowly making progress though, maybe it will get there in time.

    • vips7L  6 hours ago

      Thanks for reminding me of Fossil. I've been developing something locally and keeping track of things in a text file.

  • gritzko  9 hours ago

    Hits hard.

    I looked into them. Most of them use some CRDT-ish machinery to merge concurrent ticket changes. (Fixing merge conflicts in tickets would be too disappointing.) As a CRDT person, I noticed that implementing CRDT merges in git itself mostly makes that machinery unnecessary. Then you can keep your tickets in plain Markdown, having CRDT merges for both code and metadata. I have it working here btw

    https://replicated.live/blog/meta

    • xeubie  5 hours ago

      There is an alternative to auto-resolution or fixing low-level git merge conflicts. In my git forge Haxy, I am detecting conflicts in local-first metadata and allowing you to fix them in the UI. This is possible because I am not doing a line-based merge; the issues are stored as a data structure, so I can see what specific parts are in conflict. This allows a much nicer form of conflict resolution than conflict markers in a text file. I demoed this here: https://www.youtube.com/watch?v=kkGUARj5Wdw and here's the project: https://github.com/xit-vcs/haxy