On Thu, 2009-07-09 at 19:39 +0200, Makarius wrote: > On Thu, 9 Jul 2009, Brian Huffman wrote: > > I think it's time to bring up the issue of bug tracking again. [...] > > When this question came up many many years ago, we were a bit reluctant to > manage yet another system (the tracker), so started with an immediate > low-tech solution: a plain file Admin/BUGS. Larry was the first who > entered something, I was second and third, afterwards that file was never > maintained by anybody, so I removed it (after resolving the remaining > issues).
A text file can be edited only by developers, offers no query functions beyond grep (and little sense of accomplishment when you've fixed a bug ;-)). Its failure hardly indicates anything about the potential of a modern bug tracker. But of course a bug tracker is just a tool; in the end its people who have to work with (or without) it. HOL4's bug tracker (which is provided by SourceFourge) is not exactly a blazing success either. > Anyway, "BUGS" is a very misleading name for unclarities in the system, > which are quite often merely a misunderstanding how things could work, > should work, or might work eventually. Some more knowlegeable people > would track "ISSUES", not "BUGS" nor "FEATURES". The boundary between bugs, issues and features is fuzzy. A good bug tracker is useful for all three. Note that the term "issue tracker" typically refers to trouble ticket systems, as used in customer support. > One also needs extreme care when "fixing" problems: unless this is done by > someone with a deep understanding of the component in question (usually > the original author or main maintainer), it is usually introducing more > problems than are resolved. If this is a plea for more maintainable code, one can hardly disagree. Documentation might help, as might unit tests. Regards, Tjark
