LWN.net Logo

Baron: The bug system I wish I had

On his blog, Mozilla's David Baron describes a number of changes he would like to see in Bugzilla functionality, including several ideas about tracking bug metadata (such as what needs to be done next, workarounds, and assessing the expected behavior). "One of the difficult aspects of designing something like this, however, is the tradeoff between the cost of maintaining metadata and the desire to get work done quickly. There are currently many bugs in Bugzilla that have a bunch of fields that are just left at their defaults (e.g., severity, priority), and in many cases that's fine because we don't have a need to maintain these fields. But once a bug gets complicated enough, it's useful to be able to keep the discussion organized."


(Log in to post comments)

Bug systems

Posted Aug 18, 2012 10:41 UTC (Sat) by man_ls (subscriber, #15091) [Link]

In my experience metadata is nice to have, but nobody cares to enter it. That is because the point of diminishing returns is reached very quickly once the basic information is entered. I don't think that Bugzilla needs more metadata, honestly.

Github's minimalistic approach is probably better: a very simple issue tracker with tags and a few good points. However github becomes impossible to manage just with a few bugs. I don't know where the balance is but it does not lie the way of adding metadata.

Bug systems

Posted Aug 18, 2012 20:51 UTC (Sat) by epa (subscriber, #39769) [Link]

On a big project like Mozilla with squillions of bugs, better metadata may help the bug ttacker scale better, even if it increases the constant factor of the amount of bookkeeping needed for one individual bug. I can well imagine that Mozilla developers will have a different viewpoint from those of us who've only worked on smaller projects.

Bug systems

Posted Aug 18, 2012 21:06 UTC (Sat) by man_ls (subscriber, #15091) [Link]

Truth be told, Baron specifies that the new sections should be optional always. So they would just increase the cognitive overload for bug reporters, but not necessarily the maintenance of bug records. There is some interesting speculation about keeping separate lists of permanent and transient comments. What I feel that the author needs is not more report fields, but some way to organize internal information. I think that the interface for the reporter and for the solver must be differentiated, and allow different things.

There is also speculation about using boolean flags to keep state: instead of the myriad of combinations of status and resolution, keep separated flags for "confirmed", "solved", "verified", etc. In my experience, boolean flags win over status codes every time.

Bug systems

Posted Aug 20, 2012 8:09 UTC (Mon) by dgm (subscriber, #49227) [Link]

> In my experience metadata is nice to have, but nobody cares to enter it.

Using some machine learning algorithms to allow the system to "suggest" the metadata would be a good step into fixing this.

Copyright © 2012, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds