4 ms·
I think bugs have to be on a central place. That's the only way you can track them reliably. What if someone record a bug, commit his/her own repo, but can't/do
by Walkman 11y ago
I think bugs have to be on a central place. That's the only way you can track them reliably. What if someone record a bug, commit his/her own repo, but can't/don't push? Bugs might "lost" this way.
- qznc 11y agoI agree. I wrote a clone of Bugs Everywhere in 2010 [0]. Since then I have come to the conclusion that an issue tracker is meant to be central. Per-repo issue tracking is ok for personal projects, but then a TODO.txt probably works just as well. There is one other place for bugs: The testsuite. Then your test runner needs to have some concept of "expected to fail" though. [0] http://beza1e1.tuxen.de/articles/later_bug_tracker.html http://beza1e1.tuxen.de/articles/later_bug_tracker.html
- stephenr 11y agoBy that logic, decentralised version control doesn't work, because the developer might commit some code but not push it.
- tenfingers 11y agoThis is a non-issue. Issue tracking would work the same way git forks do: there's at any one time, always a "reference" repostory, implicit or explicit. This same repository will also hold the reference state of bugs. It's really that simple. The thing is, with a distributed bug tracker you can now also record local bugs which are pertitent with your fork only, while also keeping track of the reference with minimal effort.