The Wayback Machine - https://web.archive.org/all/20060830044452/http://www.bugzilla.org:80/status/roadmap.html

Skip to main content

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.

Major work items and where we need help

These are the tasks before us. Any help on these will help.

  • Database modularity. Bugzilla should be able to talk to any database, free or commercial. This requires:

    • Removal of mySQL specifics in the codebase. This includes mySQL specific function calls and use of mySQL specific data types.
  • Implement a better method of maintaining installation specific features and preferences. The current Params structure is too large and too unwieldy to support any additional, optional features. We need a better way of storing, fetching, and then acting on preferences information.
  • Easier configuration and installation of Bugzilla. While checksetup.pl has helped a ton, we still have a ways to go.
  • Documentation needs a lot of work. Documentation exists for installation, but very little exists in the way of either user documentation or administration documentation. Documentation of the database schema and how the various .cgi's interact with each other would greatly help getting more people up to speed.
  • Modularity in terms of feature set and user interface. Almost every installation of Bugzilla has been hacked to fit a particular development environment and engineering culture. Additional features have been added to fit each installation that has required a fork of the code. This makes the task of folding those additional features back into the trunk very difficult and slows the rate of development.
  • Implement a more finely-grained security system so administrators can determine their own local policy.
  • Testing. Up to this point, Bugzilla's primary installation and test bed has been the mozilla.org installation. As the number of Bugzilla installations increases and the product gets more complex, we will need testers and testing infrastructure to support the development effort. We currently have a Bugzilla test server at landfill.bugzilla.org, and a tinderbox report tree on tinderbox.mozilla.org, however we are still in need of basic test plans, test scripts, and testing tools to make sure we don't break anything.

Milestone plans

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