Roadmap

Brief History

When mozilla.org first came online in 1998, one of the first products that was released was Bugzilla, an open source bug system implemented using freely available open source tools. Bugzilla was originally written in TCL by Terry Weissman for use at mozilla.org to replace the in-house system then in use at Netscape. Before mozilla.org released it as open source, Terry decided to port Bugzilla to Perl, with the hopes that more people would be able to contribute to it, since Perl seemed to be a more popular language. Bugzilla 2.0 was the result of that port to Perl, and the first version released to the public via anonymous cvs. Since then a large number of projects, both commercial and free have adapted it as their primary method of tracking software defects. In April of 2000, Terry handed off control of the Bugzilla project to Tara Hernandez. Under Tara's leadership, some of the regular contributors were coerced into taking more responsibility, and Bugzilla began to truly become a group effort. In July of 2001, facing lots of distraction from her "real job," Tara handed off control to Dave Miller, who is still in charge as of this writing.

Where We're Going

Bugzilla has been installed in enough places that Bugzilla's focus has changed from being a mozilla.org centered tool to a more generalized bug tracking system. As such, we need to make installation of Bugzilla easier, have it support more databases and make it easier to optionally enable and disable features. It also needs modularity in terms of features and in the UI so that forking of the code base at individual installations will no longer be a necessity to fit the local engineering culture. We also need to allow customization of other previously hardcoded features, like resolutions and statuses.

Re-introduction

This document then, will serve as the roadmap and outline for Bugzilla development. It isn't a schedule by any means. It's more an articulation of where we want to go, the list of things that need to get done, and if you want to think of it, a long winded plea for help.

Nothing in this document is set in stone. We're open to criticism about where you think we screwed up and what things you think we left off this list. Take your ideas and suggestions to the netscape.public.mozilla.webtools newsgroup on news.mozilla.org to help facilitate discussion.

Design Principles

Bugzilla's development should concentrate on being a bug system. While the potential exists in the code to turn Bugzilla into a technical support ticket system, task management tool, or project management tool, we should focus on the task of designing a system to track software defects. While development occurs, we should stick to the following design principles:

  • Bugzilla must run on freely available, open source tools. Bugzilla support should be widened to support commercial databases, tools, and operating systems, but not at the expense of open source ones.
  • Speed and efficiency should be maintained at all costs. One of Bugzilla's major attractions is its lightweight implementation and speed. Minimize calls into the database whenever possible, don't generate speed sucking HTML, don't fetch more data than you need to, etc, etc.
  • ANSI SQL calls and data types must be used in all new queries and tables. Avoid database specific calls and datatypes whenever possible. Existing SQL calls and data types should be converted to ANSI SQL.
  • This should be obvious, but we should be browser agnostic in our HTML and form generation, which means cleaning up the HTML output of Bugzilla, and following all applicable standards.

Milestone plans

The Milestone plans portion of our roadmap is now maintained on the Bugzilla Wiki.