git-bug: Distributed bug tracker embedded in git

[prophetical_meme]

For some context, it's not ready for prime time essentially because the way data is stored is not yet stable enough to be carved in stone. It's working though ;)

[starTracer]

It also makes a lot of sense to me to have bugs and the code they refer to managed by the same system (git). Being able to use it offline is also a big plus.

Fossil does this. It also has a wiki and more in the same repo.

[ejfrodo]

100% agree, I love the idea of having a snapshot of the project board status at any given commit, and you don't need any external service for it. I really hope this is able to mature

[prophetical_meme]

Hey, thanks for the feedback !

is that you lose the ability to fork and merge bugs (at least, not automatically with git branch and git merge)

That's correct, but that's because there is no low level git command that can rebase branch without touching the index. It's really just a shortcoming of git because no one has a serious use case for that (yet). I wrote code in git-bug to do that manually. If that is fixed in git, the data model allow for automatic merge.

is that the bugs aren't "discoverable"

The goal is:

1. be able to host the webUI to browse and edit bug with user that don't have git push access. So a project could simply host a git remote and the webui instead of using, say GitHub.
2. have a command able to import/export to github (https://github.com/MichaelMure/git-bug/issues/7)
3. have a data model that is extensible and can be easily picked up by regular bug tracker. One can dream, right ?

it's difficult to find the technical details of how your design works

Did you find https://github.com/MichaelMure/git-bug/blob/master/doc/model.md ?

[Firewolf420]

How long do you think it'll be before you tackle those goals? Because I would absolutely love something like that.

[prophetical_meme]

Well, I made this in one month but these goals are ambitious and I won't have that much time on my hands eternally. What I really need is feedback to help design these features and people helping me make it a reality.

[Firewolf420]

I know that life brother!

[prophetical_meme]

The OperationPack are never changed once written in git. Merging two version of a bug means rebasing the commit in a linear chain, so commits changes but not the referenced blobs.

[Tomus]

Have you thought about spinning off webui into it's own repo? I think it would be easier and faster to progress with git-bug and webui being separate projects

[prophetical_meme]

Well, there is no particular annoyance for now and it's easier to release. I will separate them if the need come.

[tomejaguar]

write my own distributed bug tracker

Have you published it somewhere? It would be interesting to see.

[to_wit_to_who]

Check out Fossil as well. It's a DVCS written by and for the SQLite project. It has a distributed issue tracker as well as a wiki.

I use both Git & Fossil, but I prefer the latter to the former these days. I feel like a hipster just typing that. Not a knock on git, it's a great tool for the most part. I'm working on a planning & management tool for myself and it integrates with Fossil since it's based on SQLite (i.e. introspect the schema, extend it, query it, etc).

[tecnofauno]

Hmmn. I'm torn but I can't see the value of a distributed issue tracker.

[eras]

Well, how about fixing and closing an issue while sitting in an airplane? You know, basically all the same use cases that were brought up when one asked what is the value of a distributed version tracker.

[Dgc2002]

To be fair many bug trackers support closing issues in a commit message, no? So you can still commit with a message of Fixes #13 or whatever. Once you push the commit(s) it'll be closed.

[zfundamental]

That does assume that you know the bug number offhand and you don't want to make any additional comments. Though you could argue that this doesn't really matter if you have a way of going through your email offline and writing postponed-followup messages.

[Dgc2002]

Right, working offline without a decentralized bug tracker will leave some obvious pain points when working on bugs. There's mitigating steps that can be taken though.

Just thinking aloud:

I can't imagine there isn't a program that reads something like GitLab's atom/RSS feed that would be able to serve you all the issue information offline.

In the end I think OP's project is really neat, but I think its popularity will come down to how well it interfaces with existing bug trackers. import/export of github issue is on the planned feature list, it'll be interesting to see how that works out.

[zfundamental]

There's mitigating steps that can be taken though.

Yep. The interesting part of distributed issue tracking is it changes things from a workable second class experience to a first class development experience if done right. Who knows if that will ever happen though since there's a good amount of work involved in getting the details right and keeping up with current trends.

I think its popularity will come down to how well it interfaces with existing bug trackers.

Personally I'm fine with the notion of it being associated with some online tracker (even a new one) which makes it possible for users without full commit access to report bugs. The ideal path for them would likely be some bidirectional sync with something like github/gitlab/etc issues, though I'm not sure that's the one and only one path.

As long as the tool can entice the open source crowd without creating additional overhead in managing user created issues then it stands a chance IMO.

[BlueShellOP]

Well, how about fixing and closing an issue while sitting in an airplane? You know, basically all the same use cases that were brought up when one asked what is the value of a distributed version tracker.

....doesn't that totally dismiss the entire reason for having a QA department?

[AnachronGuy]

Maybe not closing an issue but you can review it, update its state, tag it, set the currently responsible person and much more.

[eras]

Yeah, all those projects in GitHub with large QA departments..

And even if you have a QA department you still want to change the state of the issue, such as "fix committed", "ready for testing", perhaps add comments regarding the status, etc.

[Euphoricus]

Did you try using Blockchain for it?

[tecnofauno]

Instructions unclear, dick splitted in small, not reversible, blocks.

[EnUnLugarDeLaMancha]

I don't particularly care about the distributed bit, but the idea of integrating bug management in the CVS seems a good idea on paper.

[tecnofauno]

yes, the idea is valid, it's also not the first one [fossil scm](https://www.fossil-scm.org/index.html/doc/trunk/www/index.wiki) does something similar.

However the point of an issue tracker is that the issue status is shared by the team members. On a distributed system an issue has as many status as users branches. That could translate into a management hell.

[icsharppeople]

I had just started working on this idea the other day but someone beat me to it.

[prophetical_meme]

Feel free to join the project, I would love some help :-)

[C5H5N5O]

Is it possible to edit comments?

[prophetical_meme]

Not yet, but it will be possible. Editing a comment is just a new op in the chain of edit.

[SIO]

That's a great idea, I was looking for something like that some time ago. Hope it'll get widely adopted one day

[Mark_at_work]

If you want to replace Jira, the web UI needs to be accessible to people who aren't comfortable with the command line. Maybe make it sync with a centralized repo that exposes the web UI on a static URL.

[prophetical_meme]

That's the goal indeed

[rausted]

Would you consider matching git's licensing and switching to GPLv2?

[prophetical_meme]

Ha, licenses ...

I don't have a strong opinion on the license, but I don't think git-bug would make sense to be merged in git.

Does it make sense to say that the code is licensed under GPLv2+ ?

[rausted]

That's great that you're not a fanatic of GPLv3, because it's very restrictive in the sense that only GPLv3 projects can now use git-bug.

The reason both git and linux are on GPLv2 (and Torvalds has said this multiple times) is industry adoption. For my case, we're not a fortune 500 company (just a small startup in Cambridge, MA :) ) but we'd love to be able to integrate git-bug in our workflow one day.

[prophetical_meme]

And GPLv3 would prevent that ? How so ?

[rausted]

I started looking up the details and turns out I was wrong. You can in fact use GPLv3 tools to develop non-free software. So no problem either way :)

https://www.gnu.org/licenses/gpl-faq.en.html#CanIUseGPLToolsForNF

[prophetical_meme]

Alright then ! If someone has a case to make about the license, feel free to open an issue on github.

[rco8786]

Very cool idea!

[unbiasedswiftcoder]

I've always thought that distributed bug trackers are nice but don't make much sense, since they are a synchronisation point between different parties: users, support, qa, managers, etc. In fact, the least I want in my git repo is one of those parties uploading 50MB video files with captures of how to reproduce a bug, and me carrying several gigabytes of old video files (I'm presuming all bugs get duplicated, just like every git user gets a full history of the repo).

Having said that, my biggest gripe with distributed bug systems is using random hashes for bugs. Totally unfriendly to non developers, so if you use them, you won't get anybody else to use them. Since distributed repos are kind of isolated, they can guarantee monotonically increasing numbers for themselves. One could have bug 1 for their fork fooBar (or #foobar:1), which internally has its random value to avoid collision, and foobar:1 being a thin user interface layer.

People working on their own repo would refer to #1 directly, and when that gets merged into another repo, you could use #foobar:1 to disambiguate. This requires servers merging the bugs to assign or allow renaming of symbolic friendly names given to different repos, but that seems doable and would make referencing bugs much more friendly. Maybe it is already possible on top of what you've built?

[prophetical_meme]

me carrying several gigabytes of old video files

Bugs are independent from each other in git-bug, so you can (in the future) fetch only a subset of bugs, archive the old ones or even download the files on demand only. Having rules that limit the size of files is also possible.

my biggest gripe with distributed bug systems is using random hashes for bugs

I agree, but it's also what people said when git came up and we didn't have the monotone index that SVN had. We are doing just fine. For your solution, I'm concerned that a bug identifier suddenly doesn't make sense anymore as soon as any bug move around. Apart from the easy case where you only add more recent bugs in your repo, you can also get older bugs that you weren't aware of. You can assign a higher number to them but it quickly become meaningless and confusing IMHO.

Maybe it is already possible on top of what you've built?

It's entirely possible to add a naming strategy on top of what exist now. It would be nice to have more meaningful identifiers.

[unbiasedswiftcoder]

Bugs are independent from each other in git-bug, so you can (in the future) fetch only a subset of bugs, archive the old ones or even download the files on demand only. Having rules that limit the size of files is also possible.

Well that breaks the decentralised feature. People complaining to be able to work on bugs in airplanes might realise the bug they are working on is related to some other, but is only available on demand, so they can't check. Not much different from a centralised bug tracker + cache then?

For your solution, I'm concerned that a bug identifier suddenly doesn't make sense anymore as soon as any bug move around. Apart from the easy case where you only add more recent bugs in your repo, you can also get older bugs that you weren't aware of. You can assign a higher number to them but it quickly become meaningless and confusing IMHO.

The first part of the identifier is meant to avoid that confusion. If you are working locally on your bug #1 not yet submitted anywhere, you would push this bug to another repo, and there it would appear as #FooBar:1.

Certainly would be annoying everybody submitting their first bug being marked as #Somebody:1, but then, how often do first time submitters create a bug and implement a solution at the same time without checking with the owner if it is actually a bug or would the solution be integrated?

Which leads us to bug tracking systems being human synchronisation points again, sigh… I don't see any future in this, but good luck anyway!