Hacker News Reader

Comment by michaelmure | Hacker News Reader

Hi, author here. Happy to answer questions.

Version 0.8 just got out[1]. For the next one, I'll try to focus on making the codebase fully ready for multi-entities and introduce a Project Board. Later we can add support for code review!

If you are looking for how it works, you can have a look at the data model introduction[2].

git-bug is only pushed forward by volunteers so it's taking its time to fully grow, so I'll take the opportunity to welcome everyone to join the fun :-)

[1]: https://github.com/MichaelMure/git-bug/releases/tag/v0.8.0

[2]: https://github.com/MichaelMure/git-bug/blob/master/doc/model...

View on HN

Excellent idea! We need an interoperable format to break the monopoly of the forges like Github, but it will only gain traction if it is integrated in git itself the way it is in Fossil. Have you been in touch with the Git maintainers to see if they are open to the idea?

I haven't but I'm not sure it's really necessary. What needs to happen first is a large enough usage of git-bug, or at least a large enough use case coverage. To do so, I think it needs:

- support for pull-requests

- support for external auth in the webUI, to make it work as a public frontend where anyone can browse and interact with bugs like any other forge

If that happens and people are convinced, I'd think that git-bug would become a natural companion for git. Then it's just a matter of packaging.

I had been doodling ideas about a distributed forge. It would allow for a local-first environment. Updates can be broadcast on something lile ActivityPub, and some automatic way to pull from Githuv. Discussions can go there, though git-bug may be the better way to go.

My main goal is resiliency. A typical Elixir/Phoenix project, for example, will have some dependencies on github. If github or the internet goes down, or even disappears, there would be no way for us to rebuild that from source.

What you are describing is exactly within git-bug's scope, and really not that far away! I'd love to make that happen, but unfortunately I have a demanding day job and rely on contributor's help.

I have many time commitments as well. I would love yt set aside some time on this.

I’d implement this in Elixir though. I enjoy it, and Elixir has some good stuff for dealing with errors in a distributed system. Put some effort into release engineering.

This is part of my broader interest in a resilient internet. On the foundation of a decentralized forge is a way to do community-supported software. With a forge, the next step would be a way for communities to raise capital (bug bounties, features, kickstarter style), but without having to rely on big platforms to do so.

Very cool idea, was it inspired by Fossil? I would totally use this if it had a VSCode extension.

I was aware of fossil but never used it. It's not a new idea, it has been attempted many time before. Hopefully that one is the one reaching large usage :-) Regarding VSCode, the CLI commands are designed to be used for such integration. Hopefully someone makes it.

Quick question: is it known what Linus thinks of the idea of having bug tracker in git? Saying that Linus has a track record of making his design decisions would be an understatement, so I would like to know what he thinks.

I haven't considered myself or git-bug worthy enough to bother him :-|

Are there any plans to create a bridge to Azure issues? I searched for an open issue but couldn't find one.

No plan but it's typically something that is brought by an eternal contributor as I need to focus on the core and I don't use those other tools. If you are up for the task, please do! A "good enough" bridge (config+import+export+tests) like the gitlab one is 1800 LOC.

"Keep reading and writing bugs" sounds a little off. Maybe change that to "writing bug reports"?

Strong disagree. "Keep writing bugs" makes OP sound experienced, self-deprecating, and not self-serious. These are good things.

Yeh it is funny. Even the best will let a bug slip in every now and again. For most of us they're just part of the process

Yeah, if there were no bugs, this application would lose its purpose, lmao.

I recall a quarterly review that fit "actually getting work done" into the fad-of-the-week by breaking it down into

* fix old bugs * write new bugs * ship bugs to customers

(mid 90s, "dash process" I think? it actually reflected good understanding of the methodology and helped kill it off :-)

Reply on news.ycombinator.com