3 ms·

Have you considered using a source code repo as the store for issues? So that "git pull" syncs issues too, issues can exist on (to describe) branches, etc?

ProfDreamer 11y ago
This is exactly what Bugs Everywhere does: http://www.bugseverywhere.org/ http://www.bugseverywhere.org/
zem 11y ago
I tried using that sort of setup for a while (with ditz), and it really doesn't work as well as you'd think it might. Issues mostly want to refer to the global state of the project, and be accessible independent of where in the revision tree you have navigated. One interesting compromise would be to tag issues with branches or commit hashes, and have a view filter for the tracker where you could search for all issues that applied to a given point in the tree.
TheTon 11y ago
(james here) There are a few tools that do this already. I think it's an interesting approach, and probably makes sense for some people. However, I feel like tying issues to closely to the code can be problematic. For example, for the product Ship itself there are multiple repositories, there's the server, the client, the web site, and a few libraries that we built along the way and open sourced. We want to be able to file issues on our product without having to first determine in which repo the problem actually resides. We also want to be able to file umbrella issues or features that require us to make cross cutting code changes across multiple repositories.
- zokier 11y ago
  I imagine that sort of issues would (mostly) be solved by a monorepo approach. Of course that is also drastically different in many other ways too.
  - CodyReichert 11y ago
    That was my thought too. It sounds like having an issue tracker tightly coupled with the code/repo structure would be extremely useful in monorepo's. The problem might not be that it's hard to figure out which issue a repo would belong too, but rather, having multiple (separate) repositories that have things in common.

ProfDreamer 11y ago

This is exactly what Bugs Everywhere does: http://www.bugseverywhere.org/ http://www.bugseverywhere.org/

zem 11y ago

I tried using that sort of setup for a while (with ditz), and it really doesn't work as well as you'd think it might. Issues mostly want to refer to the global state of the project, and be accessible independent of where in the revision tree you have navigated. One interesting compromise would be to tag issues with branches or commit hashes, and have a view filter for the tracker where you could search for all issues that applied to a given point in the tree.

TheTon 11y ago

(james here) There are a few tools that do this already. I think it's an interesting approach, and probably makes sense for some people. However, I feel like tying issues to closely to the code can be problematic. For example, for the product Ship itself there are multiple repositories, there's the server, the client, the web site, and a few libraries that we built along the way and open sourced. We want to be able to file issues on our product without having to first determine in which repo the problem actually resides. We also want to be able to file umbrella issues or features that require us to make cross cutting code changes across multiple repositories.

zokier 11y ago
I imagine that sort of issues would (mostly) be solved by a monorepo approach. Of course that is also drastically different in many other ways too.
- CodyReichert 11y ago
  That was my thought too. It sounds like having an issue tracker tightly coupled with the code/repo structure would be extremely useful in monorepo's. The problem might not be that it's hard to figure out which issue a repo would belong too, but rather, having multiple (separate) repositories that have things in common.