Bugzilla 15th anniversary
This week, Bugzilla turns 15! On September 18, 1998, Terry Weissman released Bugzilla 2.0, the first version written in Perl. A few days before, on August 25, 1998, the Bugzilla source code was committed to CVS for the first time, and was written in Tcl (Terry decided to rewrite it in Perl to attract more contributors). Since this first public release, Bugzilla changed a lot, though some of its original features are still clearly recognizable. You may wonder how Bugzilla looked like 15 years ago? Well, I’m going to tell you all.
Installing Bugzilla 2.0 wasn’t as easy as it is today. You had to manually run six(!) scripts to create DB tables and to populate them (checksetup.pl only replaced them in Bugzilla 2.8). The tarball was very small, only 52 KB (compared to 2.4 MB for Bugzilla 4.4), and you needed MySQL 3, Perl 5.4 and a web server. The home page was pretty…. simple:
So what do we see? A link to the search page, another link to file a new bug, and a text box to enter the ID of an existing bug. Oh, and a huge picture of an ant. You can see that there is no link to create a new account. That’s because there is no UI for that! To create an account, you had to click on "Enter a new bug", and Bugzilla would ask your credentials. As you have none, you had to click the "Forgot password" button, and Bugzilla would send you an email with your password in it. This had the side-effect to automatically create an account for you with the email address you just gave and the password included in the email you just received. This page has evolved a lot, and it now looks like this in Bugzilla 4.4:
Big icons help users to more easily find what they are looking for, and the page header and footer also make navigation through pages much easier.
Once you pass this first page, the next step is the search page:
Yes, the page says "Bugzilla 1.2", but it’s really 2.0 minus one minor string change in the parameters page (1.2 is only 70 minutes older than 2.0). As you can see, the search page is not very different from what we have today:
The product, component, bug status, resolution, severity and priority fields are still here. The main difference is that we greatly improved search capabilities of Bugzilla, and all the sections above are expandable to offer more search criteria:
And many new bug fields appeared, such as the target milestone, keywords, the status whiteboard, attachments and flags.
The buglist didn’t change a lot either:
Note that I had to fix the code to correctly display <table> in the bug summary. Bug summaries weren’t HTML-escaped, and so it was trivial to inject arbitrary code in the buglist. But this shouldn’t be a surprise to anyone as we had to wait 8 years for Bugzilla 2.18 to see correct HTML-escaping.
To file a bug, you had to first select the product…
… and then enter details of the bug report:
If these pages look familiar to you, that’s because they didn’t change a lot in the last 15 years:
The main difference is that the product description has been added to help users select the right product.
This is the simple form to report new bugs. If you click the "Show advanced fields" link, more fields are displayed. You now also have the possibility to attach a file and to set flags when reporting a new bug. Attachments and flags didn’t exist in Bugzilla 2.0. Attachments have been implemented in 1999 in Bugzilla 2.4, and flags in 2002 in Bugzilla 2.18. And you had to wait for 2006 and Bugzilla 3.0 to be able to attach files and set flags on bug creation.
Bug reports in Bugzilla 2.0 had very few fields and, of course, were not customizable:
You probably recognize knobs which have been removed in 2008 in Bugzilla 3.2 in favor of a better UI. Also, you will note that comments were all concatenated into a single comment, making it impossible to track who commented in the bug, and when.
On the backend, things have changed a lot. First of all, the number of DB tables exploded. In Bugzilla 2.0, there were only 7 tables:
In Bugzilla 4.4, there are more than 70 tables (the output is truncated):
The exact number of tables will depend on the number of custom fields. The reason for so many tables is because Bugzilla now has many new features which didn’t exist in previous releases, and admins now have the ability to edit mostly everything to customize Bugzilla as desired. In Bugzilla 2.0, everything was static:
You couldn’t customize bug statuses, resolutions, bug severities, priorities, etc… Now admins have a nice UI to edit them:
Same goes about the list of products, components and assignees:
The list was hardcoded, and you had to manually edit the DB to add/edit/remove entries. Now this can be done from the UI:
The list of parameters also increased a lot, and the ugly old UI…
… became a well organized list of tabs:
Maybe you wonder how other pages looked like in Bugzilla 2.0? Well, there are no other pages. They are all listed above. No preferences page, no tabular and graphical reports, and… no groups! Which means no admins, no editbugs nor canconfirm privileges, no way to restrict the visibility of bugs and comments. Frightening, isn’t it?
Happy birthday, Bugzilla!