What makes a good bugtracking system?

Most bug tracking systems have built in reports that give certain views of the data -- all bugs currently in state "Open", for example. And then, it's reasonable to expect those reports to be customizeable: "all bugs currently in state Open that were created in July", for example. However sometimes we need metrics that need a little more digging around.

In a bugtracking system I recently used, it was extraordinarily difficult to create a report that would go back in history: "all bugs that have been moved to state Verified this past week" . (In this system "Verified" was not a terminal state, so there could be and usually were additional state changes after that.) Daily metrics reports of the bug database could reveal motion from one day to the next and could be aggregated to form some pretty charts. But that one missing report meant a lot of careful notetaking while I was fixing bugs so that I could report status on them myself.

For me, one of the marks of a really good bugtracking system is that I can get at the information in it in ways that the authors had not previously thought of but that turn out to be useful in the moment.