To start, most problems with bug trackers are social, not technical. They all offer the same base functionality, which is to let idiots tell you that you’re an idiot, or whatever. The hard part is maintaining and pruning the database. This is where it often goes into the weeds, with 72 different categories being created (css, html, mobile, …) end then you never know where the “looks funny on iPhone” bug is.
Tools can offer some assistance in this. Fogbugz tried harder than most I think to make common two step operations one step, but I would also find myself frustrated by “do what I mean not what I say” guesswork.
For every system out there, I’ve heard people say it’s either the best or worst, so I conclude they’re all about the same, but people’s experiences are shaped by their organization use and configuration more than the tool itself.
For OpenBSD, email does work pretty well. Most issues are either fixed or forgotten. Keeping forgotten issues in a database doesn’t seem to inspire much effort to fixing them, based on observing other projects. Preemptive bug bankruptcy. And there are archives if people really need them.
Good bug trackers do make it easy to interface and interleave between general support requests, bug reports, code review, etc. Mailing lists are perfect for that. :)
Now you know why OpenBSD doesn’t have a bug database! :) (not quite true.)
Funny comment from someone who actually worked on bug database software in the past :)
Care to drop your opinion on software in that space (not related to your past job) at all?
To start, most problems with bug trackers are social, not technical. They all offer the same base functionality, which is to let idiots tell you that you’re an idiot, or whatever. The hard part is maintaining and pruning the database. This is where it often goes into the weeds, with 72 different categories being created (css, html, mobile, …) end then you never know where the “looks funny on iPhone” bug is.
Tools can offer some assistance in this. Fogbugz tried harder than most I think to make common two step operations one step, but I would also find myself frustrated by “do what I mean not what I say” guesswork.
For every system out there, I’ve heard people say it’s either the best or worst, so I conclude they’re all about the same, but people’s experiences are shaped by their organization use and configuration more than the tool itself.
For OpenBSD, email does work pretty well. Most issues are either fixed or forgotten. Keeping forgotten issues in a database doesn’t seem to inspire much effort to fixing them, based on observing other projects. Preemptive bug bankruptcy. And there are archives if people really need them.
Good bug trackers do make it easy to interface and interleave between general support requests, bug reports, code review, etc. Mailing lists are perfect for that. :)
Ouch. Sounds rather familiar. Thanks for the insights. :)
I’m likewise highly interested in hearing that, but I don’t want to tempt you into talking about stuff you feel it would be wrong to.