[Nautilus-list] On Bugzilla and defect herding

["Jeffrey W. Baker" <jwbaker acm org>]

Howdy,

My name is Jeff Baker and I follow Nautilus development loosely.  I am an
active Mozilla developer.  I believe that Nautilus can take advantage of
the lessons learned from the Mozilla project in the area of defect
tracking.  I believe this because:

1) Both Mozilla and Nautilus have in-house professional development staffs
and volunteer contributors
2) Both Mozilla and Nautilus have or are likely to develop a ton of bugs
(sorry)
3) Mozilla's defect tracking software and process have performed extremely
well in the 2.5+ years of the project.

By way of reference, Mozilla has over 52,100 bug reports to date and about
150 bugs are reported every day.

Three things make Mozilla's defect tracking system extremely useful: the
keyword system, the status whiteboard, and a defined bug workflow.

The keyword system works by adding one or more words from a defined list
to a bug's keyword field.  These keywords are things like crash, patch,
and testcase.  The full list is at
http://bugzilla.mozilla.org/describekeywords.cgi .  These keywords are
useful because they allow a contributor, whether paid or volunteer, to
narrowly define the work they wish to do and get a work assignment from
bugzilla.

For example, many people do not have the system resources to run Mozilla
under gdb, which requires more than 300 MB of RAM on a 32-bit system.  
Often this means that a crash is reported without a stack trace.  I can go
to bugzilla, search for all bugs with a "stackneeded" keyword, and go down
the list adding stack traces and removing the stackneeded keyword.  Often
this also leads to more accurate assignment of the bug and less time to
create a fix.  Another example would be getting a list of all unresolved
bugs with the keyword crash and without the keyword testcase.  Then a
contributor could make a testcase for the bug.

The status whiteboard is similar, in that it gives Mozilla developers key
information about how the bug is being fixed.  The status whiteboard is
free-form, but by using some conventions, very useful queries can be run
against the status whiteboard.  Currently, the status whiteboard is used
mainly by Netscape management to indicate whether the bug is slated to be
fixed in the next release.

The Mozilla project also has a good process for bug triage and resolution.  
Many, many bugs are duplicates or invalid.  Generally these are resolved
as such within one day of the report.  However, duplicate bugs are always
checked again whenever the "real" bug is marked fixed.  This little bit of
process is key to making sure that a dupe was really a dupe.

Also, cross platform bugs are never verified unless they have been tested
on all supported platforms.  This translates to Eazel as testing on
Slackware, SuSE, Red Hat, et al.  This process ensures that one
platform/distribution does not get hopelessly behind the other platforms.

One last bit of process is the way that Bugzilla affects Mozilla.org's
day-to-day operations.  New bugs which are marked as blocker severity get
immediate attention, and if they are valid, the CVS tree is closed until
there is an acceptable resolution.  New bugs with the keyword smoketest
also garner immediate attention.  The nsbeta[123] and dogfood keywords are
an effective way to put a defect on the product development team's daily
radar.

In short, I hope that Eazel's open development process can scale as well
as Mozilla's.  There are many lessons to be learned from the Mozilla
project, and many already-corrected mistakes that don't need to be
repeated.

Regards,
Jeffrey Baker