Distributed Bug Tracking Avoids Out-of-Sync Bugs and Code
Chipping away at my Veracity tasks today, I ran across an issue that’s common in DVCS + Centralized Bug Tracking scenarios, but unnecessary and easily-avoided in Veracity.
In a nutshell, it’s this:
- I commit some changes, locally, to fix a bug.
- I mark the bug fixed, on our one and only bug tracker instance.
- I don’t push my code just yet.
Until that code is pushed to the shared server, QA will have my bug in their to-verify list, but won’t have the code to do so.
I might delay the push for a number of reasons - waiting to finish a couple of related bugs and push as a unit; needing to merge and test someone else’s latest code before pushing the results back; etc. Until I’m done, though, we’re out of sync.
You can keep track via special statuses, tags, stamps, etc. (and remember to reset them once you’ve pushed), but why?
When I’m working on Veracity, I’m usually working against a local instance of the bug tracking / web UI. It’s faster, I’m not competing for resources, and I get to do things like associate commits to bugs right from the command line while I work.
It also avoids the problem above, since my workflow looks like this:
This is normal in the Veracity world, and unremarkable except in those instances, like this afternoon, when someone marks a bug closed without pushing up the associated code. Not naming names. We all make mistakes, and I’m sure writing a book can be pretty distracting.