Your browser doesn't support the features required by impress.js, so you are presented with a simplified version of this presentation.
For the best experience please use the latest Chrome, Safari or Firefox browser.
Distributed Bug Tracking in the 21st Century
A Presentation By Dave MacFarlane
(Apologies for getting carried away with the CSS3.)
What is Distributed Bug Tracking?
- A way of leveraging distributed version control systems (ie. Git, Mercurial) to track issues
- Technically, any form of database stored in a DVCS can be considered a distributed bug tracker as long as it's stored in a plaintext-ish format (JSON, XML, plain text) so that conflicts can be resolved.
- Go can find comments with a format like "//BUG(name): description" and include them in the go doc of the package. (ie. bytes package)
Why Distributed Bug Tracking (BE)
Bugs and code that live on branches are tracked together—when a branch is merged, both the code changes and bug changes that the branch contains are merged alongside each other. We no longer have to be confused about whether a fix that is applied to the development branch but not yet present in the production branch means that our bug is "fixed".
Users can fully modify bug state while offline, unlike with many centralized bugtrackers.
When a user checks out your source code, she gets the current bug state for free.
-- Bugs Everywhere website
Why Distributed Bug Tracking (Dave)
By combining source control and issues on the same branch, bug lists become context sensitive, offline capable, and very fast.
It's much easier to drop things off and pick them up knowing all you need to do is run "bug list" to see what's unresolved on a branch.
Centralized bug trackers are good for tracking user problems with released products, but ill-suited to tracking the state of unreleased feature branches.
By being offline and commandline based, the tools are more flexible and scriptable.
But first.. why didn't distributed bug tracking take off?
- Vendor lock-in (files are stored in a hidden directory that's difficult to access without the be client)
- Hashes are hard to use
- Pitched as a replacement for centralized bug tracking, but that's not feasible unless entire team is commited (and also not
necessary to get the benefits of distributed bug tracking).
How is Dave's Distributed Bug Tracker ("bug") different?
- Bugs are stored in a non-hidden organized directory structure of plaintext files
- Bug titles are their identifiers, not hashes
- Unstable identifier numbers can be used to reference things on the command line for simplicity (stable identifiers can also
be manually assigned for long lasting issues.)
/* Integrating With A Go App */
import (
"fmt"
"github.com/driusan/bug/bugs"
)
func main() {
b := bugs.New("I am a bug report")
fmt.Fprintf(b, "I am detail, here me roar!\n");
fmt.Fprintf(b, "More details!\n");
}
/* Recovering In An HTTP Handler Function*/
func handlerFunc(w ResponseWriter, r *http.Request) {
defer func() {
if r := recover(); r != nil {
b := bugs.New(fmt.Sprintf(
"Crash on %s from %s",
r.URL.Path,
r.RemoteAddr
))
fmt.Fprintf(b, "There was a 500 error")
fmt.Fprintf(b, "on %s\n", r.URL.Path)
fmt.Fprintf(b, "The request was: %s", r)
}
}()
/* Normal handler code goes here */
}
Thanks for your time!
(Sorry again about the gratuitous animations.)