Planet Bugzilla

November 25, 2014

Bugzilla Tips

Email Filtering on

Vanilla Bugzilla lets you decide which bugmail you receive based on what changed about a bug. But there are a couple of extensions which give you even more control, and both are installed on So the new email filtering pipeline is as follows:

Firstly, ComponentWatching, as the name implies, lets you “watch” particular products or components, so you get put on the list to receive bugmail for all changes to any bugs in those products or components. This is very useful if you have an interest in a particular area of the project. You can also watch particular users – that function is built-in.

Secondly, the normal email filters run, which exclude or include you from emails based on the particular fields which have been changed in the bug update.

Lastly, the BugmailFilter extension allows you to define “include” or “exclude” rules based on any one of:

Using these three capabilities in tandem, it should be possible to carefully control how much bugmail you receive, even if you are using a system like Gmail which does not have good client-side filtering.

November 25, 2014 05:40 PM

November 13, 2014

Byron Jones

database refresh of – monday 17th november

on monday 17th november the database on will be refreshed with a recent database dump from

if you have an account on bugzilla-dev its password will be deleted, and you will have to contact the BMO team to get a password reset.

you can contact us on irc in #bmo: glob, dkl, or dylan.

Filed under: bugzilla

November 13, 2014 02:41 PM

October 06, 2014

Bugzilla Update

Release of Bugzilla 4.4.6, 4.2.11, 4.0.15, and 4.5.6

Today we have several new releases for you!

All of today’s releases contain security fixes. We recommend that all Bugzilla administrators read the Security Advisory that was published along with these releases.

Bugzilla 4.4.6 is our latest stable release. It contains various useful bug fixes and security improvements:

Bugzilla 4.2.11 is a security update for the 4.2 branch:

Bugzilla 4.0.15 is a security update for the 4.0 branch:

Bugzilla 4.5.6 is an unstable development release. This release has not received QA testing from the Bugzilla Project, and should not be used in production environments. Development releases exist as previews of the features that the next major release of Bugzilla will contain. They also exist for testing purposes, to collect bug reports and feedback, so if you find a bug in this development release (or you don’t like how some feature works) please tell us.

October 06, 2014 07:33 PM

August 28, 2014

Bugzilla Update Disclosure

UPDATE: We have reset all passwords on all Landfill test Bugzilla systems. All users will be required to set a new password the next time they access the test Bugzilla systems.

One of our developers discovered that, starting on about May 4th, 2014, for a period of around 3 months, during the migration of our testing server for test builds of the Bugzilla software, database dump files containing email addresses and encrypted passwords of roughly 97,000 users of the test build were posted on a publicly accessible server.  As soon as we became aware, the database dump files were removed from the server immediately, and we’ve modified the testing process to not require database dumps.

Generally, developers who use our test builds have told us they understand that these builds are insecure and may break, so they do not use passwords they would reuse elsewhere.  However, because it is possible that some users could have reused their passwords on other websites or authentication systems, we’ve sent notices to the users who were affected by this disclosure and recommended that they change any similar passwords they may be using. It’s important to note that, unless users reused the password they used on, this does not affect email addresses or passwords.

We are deeply sorry for any inconvenience or concern this incident may cause you.


Mark Côté

Assistant Project Lead, Bugzilla

August 28, 2014 08:11 PM

July 24, 2014

Bugzilla Update

Release of Bugzilla 4.0.14, 4.2.10, 4.4.5, and 4.5.5

Today we have several new releases for you!

All of today’s releases contain a security fix. We recommend that all Bugzilla administrators read the Security Advisory that was published along with these releases.

Bugzilla 4.4.5 is our latest stable release and contains a security fix.

Bugzilla 4.2.10 is a security update for the 4.2 branch:

Bugzilla 4.0.14 is a security update for the 4.0 branch:

Bugzilla 4.5.5 is an unstable development release. This release has not received QA testing from the Bugzilla Project, and should not be used in production environments. Development releases exist as previews of the features that the next major release of Bugzilla will contain. They also exist for testing purposes, to collect bug reports and feedback, so if you find a bug in this development release (or you don’t like how some feature works) please tell us.

July 24, 2014 09:40 PM

July 04, 2014

Byron Jones

bugzilla and performance, 2014

bugzilla is a large legacy perl application initially developed at the birth of the world wide web. it has been refactored significantly in the 15 years since its release; however, some design decisions made at the start of the project carry significant technical debt in today’s modern web.

while there have been a large number of micro-optimisations over the course of bugzilla’s life (generally as a result of performance profiling), there are limits to the benefits these sorts of optimisations can provide.

this year has seen a lot of focus on improving bugzilla’s performance within mozilla, centred around the time it takes to display a bug to authenticated users.


tl;dr bugzilla is faster


the design of a modern large web application is generally centred around caches, between the business logic layer and the data sources, as well as between the users and the user interface. while bugzilla has been refactored to use objects, database abstraction, templates, etc, it had zero caching capabilities. this coupled with completely stateless processing of each request meant that every byte of html returned to the user was regenerated from scratch, starting with a new connection to the database.

towards the end of 2013 i worked on implementing a memcached framework into bugzilla [bug 237498].

retrofitting a caching mechanism into a large extendible framework proved to be a significant challenge. bugzilla provides the ability for developers to extend bugzilla’s functionality via extensions, including but not limited to adding new fields, user interface, or process. the extensions system conflicts with caching as it’s possible for an extension to conditionally alter an object in ways that would render it impossible to cache (eg. add a new field to an object only if the current user is a member of a particular group).

some compromises had to be made. instead of caching fully constructed objects, the cache sits between the object’s constructor and the database. we avoid a trip to the database, but still have to construct objects from that data (which allows extensions to modify the object during construction).

code which updated the database directly instead of using bugzilla’s objects had to be found and rewritten to use the objects or updated to manually clear the cache entries. extra care had to be taken as returning stale data could silently result in data loss. to placate concerns that these errors would be impossible to detect, the caller of an object’s constructor must pass in a parameter to “opt-in” to caching.

in 2014 i built upon the memcached framework to support most of bugzilla’s objects [bug 956233], with the “bugs” object being the only notable exception. memcached also caches bugzilla’s configuration parameters (classifications, products, components, groups, flags, …) [bug 987032]. although caching the “bugs” object would be beneficial given its central role in all things bugzilla, it is highly likely that enabling this by default would break bugzilla extensions and customisations as a high proportion of them update the database directly instead of using bugzilla’s object layer. this would manifest as data which is silently stale, making undetectable dataloss a high probability.

memcached support will be released with bugzilla 5.0, but has been live on (bmo) since february 2014.


while profilling tools such as nytprof have often been pointed at bugzilla, bmo’s high number of concurrent requests and usage patterns time and time again resulted in performance optimisations performing worse than expected once deployed to production.

we took the decision to deploy instrumentation code into bugzilla itself, reporting on each http request, database query, and template execution. as bugzilla is written in perl, support was absent for off-the-shelf instrumentation tools such as new relic, so we had to roll our own data collection and reporting system [bug 956230].

the collector wraps specific Bugzilla::DB, Bugzilla::Memcached and Bugzilla::Template calls via subclassing, then reports data to an elasticsearch cluster. currently all reporting solutions are ad-hoc and involve running of scripts which identify the most costly database queries and templates.

this data identified areas of bugzilla which require optimisation or caching. examples include the optimisation of a single query which shaved 200ms (~15%) off page load times for most users [bug 993894], caching of all queries which read an entire table [part of bug 987032], and caching of user groups [bugs 993939] and settings [bug 993926].

we continue to revisit the instrumentation reports in order to guide further improvements.

stylesheet concatenation and minification

improving the performance of a web applications isn’t limited to focusing on server-side execution speed.

due to bugzilla’s extensions we ended up in a situation where bugzilla was serving multiple small css files – on bmo we loaded 17 stylesheets as part of show_bug in comparison with 5 for an installation of bugzilla without any extensions installed.

similar to the issue encountered with memcached, extensions have complete control with regards to optionally loading stylesheets, which means any css concatenation and minification solution needed to be implemented at run-time.

[bug 977969] does exactly that – the template passes an array of stylesheets to load to bugzilla’s global header, where a hash of the array is used to find a unified stylesheet. simple minification is performed which dropped the stylesheet size from 54kb to 43kb on show_bug on bmo.

stylesheet concatenation and minification support will be released with bugzilla 5.0, and has been live on since may 2014.


in order to address performance issues caused by bugzilla’s use of the myisam table type, in march our DBAs upgraded our database cluster to mysql version 5.6. this was the result of analysis by the DBAs into replication and stability issues around our myisam table.

as mysql 5.6 adds support for fulltext indexing to its innodb table type, bugzilla was able to switch away from myisam. this immediately fixed the database replication issues, and provided a noticeable performance boost to searches involving comments.

looking forward

the next large project is to update bugzilla so the bug object can use memcached on an unmodified installation without any non-default extensions enabled. for reasons previously covered it’s unlikely we’ll ship a version of bugzilla with this enabled by default, however this will allow sites to audit their own code (if any) and enable caching of the bug object if required.

we will build on the css concatenation and minification work to provide the same benefits to javascript files.

we periodically enable instrumentation and use it to identify the next set of targets for optimisation. this will continue for the foreseeable future.

Filed under: bmo, bugzilla

July 04, 2014 07:50 AM

May 08, 2014

Byron Jones

a tale of bugzilla performance

a high-level goal across multiple teams this year is to improve’s performance, specifically focusing on the time it takes to load a bug (show_bug.cgi).

towards this end, in q1 2014 i focused primarily on two things: implementing a framework for bugzilla to use memcached, and deep instrumentation of bmo in our production environment to help identify areas which require optimisation and could leverage memcached.

i’ll talk more about memcached in a later blog post.  today i’ll talk about a single little query.

the data gathered quickly identified a single query used to determine a user’s group membership was by far the slowest query, averaging more than 200 ms to complete, and was executed on every page:

  FROM groups, 
 WHERE user_group_map.user_id = 3881 
       AND (
           (user_group_map.isbless = 1 AND
           OR ( = group_group_map.grantor_id
               AND group_group_map.grant_type = 1
               AND group_group_map.member_id IN (20,19,10,9,94,23,49,2,119,..))

in bug 993894 i rewrote this query to:

  FROM user_group_map
 WHERE user_id = 3881
       AND isbless = 1
  FROM group_group_map
 WHERE grant_type = 1
       AND member_id IN (20,19,10,9,94,23,49,2,119,..)

which executes almost instantly.

the yellow bar on the following graph shows when this fix was deployed to


Filed under: bmo, bugzilla

May 08, 2014 05:06 PM

April 19, 2014

Bugzilla Update

Release of Bugzilla 4.5.4, 4.4.4, 4.2.9, and 4.0.13

There are four new releases today. All of today’s releases contain an important bug fix discovered since the last release.

Bugzilla 4.4.4 is our latest stable release. It is a bug fix update for the 4.4 branch:

Bugzilla 4.2.9 is a bug fix update for the 4.2 branch:

Bugzilla 4.0.13 is a bug fix update for the 4.0 branch:

Bugzilla 4.5.4 is an unstable development release. This release has not received QA testing from the Bugzilla Project, and should not be used in production environments. Development releases exist as previews of the features that the next major release of Bugzilla will contain. They also exist for testing purposes, to collect bug reports and feedback, so if you find a bug in this development release (or you don’t like how some feature works) please tell us.

April 19, 2014 02:08 PM

April 18, 2014

Bugzilla Update

Release of Bugzilla 4.5.3, 4.4.3, 4.2.8, and 4.0.12

Today we have several new releases for you!

All of today’s releases contain security fixes. We recommend that all Bugzilla administrators read the Security Advisory that was published along with these releases.

Bugzilla 4.4.3 is our latest stable release. It contains various useful bug fixes and security improvements:

Bugzilla 4.2.8 is a security update for the 4.2 branch as well as contains several bug fixes:

Bugzilla 4.0.12 is a security update for the 4.0 branch:

Bugzilla 4.5.3 is an unstable development release. This release has not received QA testing from the Bugzilla Project, and should not be used in production environments. Development releases exist as previews of the features that the next major release of Bugzilla will contain. They also exist for testing purposes, to collect bug reports and feedback, so if you find a bug in this development release (or you don’t like how some feature works) please tell us.

April 18, 2014 02:34 AM

April 01, 2014

Frédéric Buclin

Bugzilla 5.0 moved to Python (bye bye Perl!)

This discussion took place three years ago, and we have been working very hard to make it happen. But we are now done: Bugzilla 5.0, the next major release of Bugzilla which will be released later this month on April 31, will be based on Python 3.4, meaning that Bugzilla 4.4 was the last major release to be based on Perl. We hope this migration to Python will trigger more contributors and will increase the development rate of Bugzilla.

Bugzilla 5.0 comes with many major changes. Just to name a few:


Note: For the ones who didn’t notice when I wrote this post (April 1): yes, it was an April fool!

April 01, 2014 10:23 AM

March 27, 2014

Bugzilla Update

(re)introducing Mark Côté, Bugzilla Assistant Project Lead

I’ve invited Mark Côté to step up to fill the Assistant Project Lead position vacated by Simon Green two months ago. He’ll also be taking on a role as a “Community Coordinator” to try to step up efforts to make new community members feel welcome and encourage more involvement.

You probably all know him most recently for his leadership in the project to move our source control from bzr to git. He’s a long-time developer outside of Bugzilla, and has been heavily involved with Bugzilla the last year or so via his participation in maintaining He’s mainly been in the role of a project manager for BMO, and that’s really what Bugzilla needs right now. We haven’t had a really good project manager or community coordinator in a long time, and the state of the project kinda shows it. In another first (in recent history), “approval” rights aren’t initially coming with the job. Any patches that need commit approval can continue to be directed towards Byron (glob) or myself (justdave).

I’ve had a long-standing policy of trying to avoid having the entire senior leadership team being employed by Mozilla, in order to try to keep it a real community project and not feel like it was being controlled by Mozilla, but the reality is that nobody else from outside of Mozilla has been involved enough to step into this kind of role in the recent past, and it’s better to have it filled and get things done than to leave it vacant and let the project stagnate even further. If he’s an effective community builder, that problem will probably solve itself eventually.

We’re going to try to set up another real-time project meeting soon either on IRC or Air Mozilla or in Google Hangouts again (that wasn’t too bad when we did it) so we can regroup on where we are and where we plan to go. Expect to be hearing from Mark on that soon.

For more information about Mark, see his Mozillians profile at or his LinkedIn profile at or find him in the #bugzilla channel on IRC as mcote.

March 27, 2014 03:12 AM

February 17, 2014

Bugzilla Update

Git Migration Scheduled

A migration of Bugzilla and related code from to will be perfomed on Tuesday, 11 March 2014, starting at 17:00 UTC.  At this time, all Bazaar branches on will be made read-only (aside from a few admin accounts), and the migration to git repos on will commence.  It should take around 1.5 hours to migrate everything, after which point write access will be enabled on the git repos for all users previously authorized on  A script will periodically mirror changes from git to bzr for all currently supported Bugzilla branches (4.0, 4.2, and 4.4).  Changes will not be mirrored for any other branches of Bugzilla nor any other related branches (extensions, misc, etc.).

We will start mirroring changes to read-only repos on GitHub at some point (to be determined) after the migration to will remain the repository of record, meaning the only place to which changes should be committed by developers.  All mirroring, e.g. to GitHub and, will be unidirectional.

We’ve already done one test migration; see  It was successful aside from some missed file deletions, resulting in extra files on a handful of git repos after the migration.  I manually deleted the superfluous files after migration, and I also fixed the migration script to account for this oddity in Bazaar’s fast-export output, so it won’t happen during the real migration.

I would like to open up testing to all developers, starting with another complete, fresh migration, on Tuesday, 18 February 2014, around 17:00 UTC.  To test the git-to-bzr mirroring script, we’ll create a new branch, “migration-test”, off of Bugzilla trunk and run the mirroring script on it after the migration.  We’ll leave it running until the real migration, and I invite anyone with commit access to to commit changes to the test-migration branch on git and ensure that they are mirrored properly to bzr.

The full migration and testing plan, along with other details, is at

Post reprinted from Mark  Côté’s post on

February 17, 2014 08:23 AM

January 28, 2014

Bugzilla Update

Release of Bugzilla 4.5.2 and 4.4.2

Today we are releasing 4.4.2 and the unstable development snapshot 4.5.2.

Bugzilla 4.4.2 is our latest stable release. It contains various useful bug fixes for the 4.4 branch.

Note that 4.5.2 is an unstable development release and should not be used in production environments. We are not yet feature-frozen at this time so the features you see in 4.5.2 might not accurately represent the behavior that 5.0 will have.

Note that when Bugzilla 5.0 is released, the Bugzilla 4.0.x series will reach end of life. If you are using that series, we encourage you to upgrade to 4.4.2 now.


Bugzilla is available at:


982ef341c55795e02388bb15bdc07ccf    bugzilla-4.5.2.tar.gz
4aae9730d8187d13a133874f3dd5cc2b    bugzilla-4.4.2.tar.gz

Release Notes & Changes

Before installing or upgrading, you should read the Release Notes for the new version of Bugzilla:


It is VERY IMPORTANT to read the Release Notes if you are upgrading from one major version to another (like 3.6.x to 4.4.x).

To see a list of all changes between your version of Bugzilla and the current version of Bugzilla, you can use the chart at:

The Bugzilla Update

You can see the latest updates from the Bugzilla Project and the status of Bugzilla development on The Bugzilla Update:

Also, you can follow the Bugzilla Project on Twitter for frequent updates on new features being developed in Bugzilla, our current release plans, and much more:!/bugzilla

Report Bugs

If you find a bug in Bugzilla, please report it! Instructions are at this URL:


You can ask questions for free on the mailing lists (or in IRC) about Bugzilla, or you can hire a paid consultant to help you out:

Free Support:
Paid Support:

About Bugzilla

Bugzilla is a “Defect Tracking System” or “Bug-Tracking System.” Defect Tracking Systems allow individuals or groups of developers to keep track of outstanding bugs in their product effectively. Most commercial defect-tracking software vendors charge enormous licensing fees. Despite being “free”, Bugzilla has many features its expensive counterparts lack. Consequently, Bugzilla has quickly become a favorite of thousands of organizations across the globe, and is widely regarded as one of the top defect-tracking systems available.

See for more details.

January 28, 2014 04:53 AM

January 08, 2014

Frédéric Buclin

Bugzilla 5.0 moved to HTML5

A quick note to let you know that starting with Bugzilla 4.5.2, which should be released soon (a few weeks at most), it now uses the HTML5 doctype instead of the HTML 4.01 Transitional one. This means that cool new features from HTML5 can now be implemented in the coming Bugzilla 5.0. A lot of cleanup has been required to remove all obsolete HTML elements and attributes, and to move all hardcoded styles into CSS files, and to replace many <table> by <div> where appropriate. There are still many places to fix to be fully HTML5 compliant as HTML 4.01 was more lenient with some code, but we did a great jump toward the HTML5 world.

January 08, 2014 11:19 PM

November 26, 2013

Bugzilla Update

Bugzilla considering moving to git

The Bugzilla Project is currently considering moving our source code repository from Bazaar (bzr) to git.  Part of the impetus for this is that Mozilla is trying to get out of the business of hosting every version control system known to man (which they currently do, or close to it anyway) and bzr is one of the low-hanging fruit (Bugzilla is the only Mozilla project using it).  There’s also a lot of feeling out there that mirroring to github may make contributions easier for new contributors. The general consensus on the thread so far is that we should do it; the main point of contention is how long to keep it mirrored in bzr after it moves.

What’s your take on it?  We’d appreciate anyone who currently works on Bugzilla or is contemplating it to join in on the discussion.

The main discussion thread is in a thread on our developers list, and the metabug to track it is bug 929685.

November 26, 2013 03:18 AM

November 20, 2013

Frédéric Buclin

Want to fix a bug before it exists? Enter the TARDIS



November 20, 2013 05:44 PM

October 17, 2013

Bugzilla Update

Release of Bugzilla 4.5.1, 4.4.1, 4.2.7, and 4.0.11

Today we are releasing 4.4.1, 4.2.7, 4.0.11, and the unstable development snapshot 4.5.1.

Initially, we released new tarballs and diffs for these releases to the download site but found a new bug shortly after. New tarballs and diffs have been uploaded to the site which we recommend everyone update to if you downloaded the first version. To make sure you have the fixed version, md5sum values are provided further down in the announcement.

All of today’s releases contain security fixes. We recommend all Bugzilla administrators to read the Security Advisory linked below.

Bugzilla 4.4.1 is our latest stable release. It contains various useful bug fixes, performance improvements and security fixes for the 4.4 branch.

Bugzilla 4.2.7 and 4.0.11 are security updates for the 4.2 branch and the 4.0 branch, respectively.

Note that 4.5.1 is an unstable development release and should not be used in production environments. We are not yet feature-frozen at this time so the features you see in 4.5.1 might not accurately represent the behavior that 5.0 will have.

Note that when Bugzilla 5.0 is released, the Bugzilla 4.0.x series will reach end of life. If you are using that series, we encourage you to upgrade to 4.4.1 now.


Bugzilla is available at:


53d0bffc3055f7d5af1c754f177de4ad  bugzilla-4.5.1.tar.gz
fd9d6dcc85bb359536be52e34ad20dfd  bugzilla-4.4.1.tar.gz
ebf0a75d1037f09994660d3958fc66fb  bugzilla-4.2.7.tar.gz
48402a4a105de3f00962dca244cd7569  bugzilla-4.0.11.tar.gz

Security Advisory

There is a security advisory describing the security issues fixed in these releases, at:

Release Notes & Changes

Before installing or upgrading, you should read the Release Notes for
the new version of Bugzilla:


It is VERY IMPORTANT to read the Release Notes if you are upgrading from one major version to another (like 3.6.x to 4.4.x).

To see a list of all changes between your version of Bugzilla and the current version of Bugzilla, you can use the chart at:

October 17, 2013 03:36 PM

September 16, 2013

Frédéric Buclin

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 ( 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:

query44_2 query44_3

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!


September 16, 2013 02:02 AM

July 13, 2013

David Miller

Bugzilla Project Meeting Wednesday, July 17th, at 14:00 UTC

Much of this post is taken from a message I posted to the developers list a few days ago, so my apologies in advance to anyone reading it again. I’ve expanded on a few things and added the information about the upcoming meeting, so it’s probably worth re-reading.

For those unaware of the context, Frédéric Buclin last week announced that he was stepping down from his Assistant Project Manager position after 9 years.

To Frédéric: Thanks again (and again!) for all your hard work over the years! As stretched as I’ve been for time myself it has been a true godsend to have you picking up my slack the last few years. You will be missed!

To everyone else: For the time being, I’ll be handling approval requests, so if you have something up for approval and it’s not getting attention, I’m the one to pester.

This is sort of the end of an era for the Bugzilla project… Both Frédéric and Max (who left to work at Google a couple years ago and stepped down from his position earlier this year for lack of time) have been with the project for much longer than most people ever stick with a single employer in IT-related jobs (of which an open source project of this magnitude has a lot of similarities). For an open source project, that’s outright amazing, as people tend to come and go a lot in most projects. It’s kind of surprising that I’ve been around longer than them, but I’m kind of a “lifer” in some ways, and in reality I’ve had a good break from the project for the last few years because Max and Frédéric have been mostly taking care of everything while I’ve been busy with other things.

So it’s time to begin a new era. Since I’ve had a good break to clear the monotony I’m going to be trying to get more involved myself again (which I’ve been saying ever since Max left, but I have a lot more incentive now). I’d also like to kickstart a new team to lead the project, and kind of re-organize if you will. We have a number of positions within the project for various functions, which we’ve never really paid attention to as people moved on. So some questions we’ll be asking at our upcoming meeting are:

We also have some other “reinventing the project” type topics while we’re at it. There’s a number of things we’ve been talking about doing for a long time that we never really moved on, and some of the big elusive dreams (the big UI overhaul!) have actually been making progress as well, lately. When we’re in the middle of big changes like this, I think it’s a good time to review where we are, get everyone on the same page, and tackle some of these things we keep talking about.

We also have a lot of new useful technology at our disposal since the last time we had a project meeting.  We’re going to experiment with using Google Hangouts for the meeting this time, and using their feature to stream the Hangout via YouTube for those who want to watch without participating.  We’ll also keep our usual meeting IRC channel open so people who don’t have a Google+ account and don’t want to get one can still participate and ask questions via IRC.

The preliminary agenda and participation instructions have been posted at  The meeting will be held on Wednesday, July 17th, at 14:00 UTC. And before anyone complains about the time, this was the best time to avoid inconveniencing the largest number of people.  The Bugzilla Project has a global pool of contributors, and we have active contributors in a wide variety of time zones.  The time chosen puts the meeting in the middle of the night for the fewest number of people.  Those on the west coast in the US will probably have to get up a little early, and those in eastern Australia will be up a little later.

A lot of the emails and comments I’ve gotten since Frédéric’s announcement have been really positive, so I’m encouraged by the number of people who are still committed to keeping Bugzilla vibrant!  We’ll see you at the meeting on Wednesday!

July 13, 2013 02:06 AM

July 08, 2013

Frédéric Buclin

It’s time for me to leave the Bugzilla project

"Everything that has a beginning has an end". I joined the Bugzilla project in August 2004 (already 9 years ago) and fixed more than 1600 bugs (including a few bugs in Bonsai, Doctor and Testopia). I became an official reviewer in December 2004, only 4 months after my first contribution, and reviewed patches in more than 2000 bugs. I also got approval privileges in January 2007, meaning that I had the responsibility to grant/deny approval for the last 6.5 years, and approved no less than 1500 patches to be committed into the source code. I’m also the QA manager for the Bugzilla project since July 2005 and so I am responsible to make sure Bugzilla quality is good enough before each new release. That’s a lot of work, and takes a lot of my free time and energy.

In the last few months, my free time was pretty limited and so my contributions to the project were mostly to triage new bugs, set blockers for the next releases, approve (or reject) reviewed patches, and help fixing blockers and security bugs. But now that my free time increased a bit again, I realized that my motivation to write new patches, either bug fixes or new features, and my motivation to review patches in my too long review queue are gone. And to lead a project correctly (I’m actually an assistant project lead, the project lead being justdave), you need to put time and energy into it to not be the bottleneck in the development of the application. And so without enough motivation and energy anymore it’s time for me to resign my role as assistant project lead. This means that decisions about the direction Bugzilla should take no longer belong to me. So please stop marking bugs as WONTFIX because LpSolit (me) said he didn’t agree with such or such new feature; my opinion is no longer relevant. :)

Those who know me shouldn’t be too surprised by my decision. Two years ago, I was very close from taking the same decision. The only reason I didn’t was because mkanat left the Bugzilla project to go work for Google, and it wasn’t the right time to also leave the project. So I stayed involved two additional years to help with the release of Bugzilla 4.2 and 4.4, but now it’s really time for me to say goodbye. This also means you shouldn’t ask me to review your patches anymore. Those should be addressed to another reviewer (glob, dkl, justdave). I will keep my reviewer and QA manager hats for now, but really stop asking me for review (unless it’s a security or critical bug which requires my skills).

It was a really great and fantastic experience to work with other Bugzilla developers and contributors, and I wish all the best for the future of Bugzilla. :)

July 08, 2013 07:47 PM

May 24, 2013

Bugzilla Update

Bugzilla 4.4 and 4.2.6 released

(cross-posted from LpSolit’s Blog)

We released Bugzilla 4.4 and 4.2.6 today. Bugzilla 4.2.6 is a bugfix release, and contains no security fixes. It adds support for MySQL 5.6 and fixes a crash with Oracle.

Bugzilla 4.4 contains many new features:

This release also means the End Of Life (EOL) of Bugzilla 3.6, which was the last series for Bugzilla 3.x. This branch is no longer supported, and any new security bug found on this branch will remain unfixed. Installations still running Bugzilla 2.x or 3.x are urged to upgrade to Bugzilla 4.4 or 4.2.6.

So, what’s next? Well, the main focus for Bugzilla 5.0 will be usability and user experience. Bugzilla sometimes (often?) looks old-fashioned because we wanted to support old browsers and browsers with JavaScript disabled. But we decided to move to a more interactive interface where JavaScript will help accomplish some tasks with less page reloads, such as submitting changes to a bug or adding an attachment. We also plan to add a new skin to Bugzilla which should look like this. Some pages will also be entirely redesigned, such as the Group Controls page to administrate access to bugs which was considered too complex for the average admin. More information will come with the release of development snapshots.

May 24, 2013 04:14 PM

May 23, 2013

Bugzilla Update

Release of Bugzilla 3.2.7, 3.4.7, 3.6.1, and 3.7.1

(Translation available: Belorussian provided by PC)

So, today we had a bunch of releases. They are good. They fix stuff! Fixed stuff is good. :-)

Now, I could pretty much end the blog post there, but there is one…tiny…extra…thing to talk about. If you were paying attention, you might have noticed that the 3.7.1 release says that it’s leading up to Bugzilla 4.0! Yes, that’s right, the next major release of Bugzilla will be 4.0, and here’s a bit about it:

Why 4.0?

So what is it that makes this release worthy of being called 4.0? Well, the biggest thing is that there have been major UI improvements. The biggest one is that the Advanced Search page has been fully redesigned. You can see it at our test site. It’s going to get better than that, too. Also, if you review a lot of patches, you will probably appreciate the new attachment details UI (log in to see the full feature set).

Bugzilla 4.0 will also have cross-domain WebServices support, via JSONP. As a part of that, the JSON-RPC WebServices interface can also now be accessed using HTTP GET and a simple query string in the URL, instead of having to POST a JSON object.

Also in the area of WebServices, we’re planning to have our most-requested WebService function implemented, Bug.update, so that you can update all the attributes of a Bug via the WebServices. There may be other good WebServices improvements which make 4.0, too.

Also, a great feature for installations that get a lot of bugs is the new Automatic Duplicate Detection. To try it out, go to file a bug on our test installation, type a few (real) words in to the Summary field, and then click out of it.

We are also planning on changing the default statuses, based on our 12 years of experience since Bugzilla was first open-sourced. The current status workflow is simple and broadly applicable, but it is ambiguous or less-than-useful in some ways: for example, a NEW bug may not actually be NEW–it’s just not being worked on. And then what does ASSIGNED really mean? Does it mean that somebody is working on the bug, or just that it’s been assigned to somebody (which you can already tell from the Assigned To field)? So, to resolve these issues, the new workflow will be even simpler: UNCONFIRMED -> CONFIRMED -> IN_PROGRESS -> RESOLVED -> VERIFIED. Installations that are upgrading will keep the old workflow by default, although there will be a script included to convert them to the new workflow, if they want.

Features Already In 3.7.1

3.7.1 already has the new Search UI and the new Attachment Details UI, although further improvements to the Search UI are coming in later development releases. 3.7.1 also has automatic duplicate detection and JSONP support for the JSON-RPC WebService.

Some of the other new features and changes in 3.7.1 are:

Do remember, though, that this is an unstable release. It may have bugs. They might be really bad bugs. We have no idea, because we haven’t tested this release at all. If it pokes your best friend in the face when you file a new bug, don’t blame us–we warned you. :-)

The Plan

Right now we expect the 4.0 release to happen some time around the end of this year. To make this target, we’ll definitely need help with QA, so if you want to help out with Bugzilla, see if you can find/fix some bugs in 3.7.1, and also if you want, you can help out the QA Team write automated tests for 4.0!


May 23, 2013 12:26 AM

Release of Bugzilla 3.2.10, 3.4.10, 3.6.4, and 4.0rc2

We just released Bugzilla 3.2.10, 3.4.10, 3.6.4, and 4.0rc2. Mostly, these contain a lot of very important security fixes. One of the fixes in particular took over 100 hours of work from the Bugzilla team as a whole and a host of external contributors, and we’ll be blogging about that in more detail in the coming days or weeks. Right now, what’s important to know is that these issues are pretty serious and you should update as soon as possible.

Older versions of Bugzilla are also affected, even though they haven’t been patched because they have reached End Of Life. If you are running a version of Bugzilla earlier than 3.2, it is now very important that you upgrade so that you can remain secure.

Most of the issues that were fixed today were discovered as a result of Mozilla expanding their security bug bounty program to include web applications. We’d like to thank Mozilla for funding this initiative and helping us significantly improve the security of Bugzilla in various areas.

Progress Toward Bugzilla 4.0

With the release of Bugzilla 4.0rc2, we’re that much closer to Bugzilla 4.0! This second Release Candidate has a fully-tested Bug.update WebService method, so we don’t expect its API to change any more (although it has changed quite a bit since 4.0rc1 thanks to testing and bug fixes). The other new WebService methods may still change before the final release of 4.0, as we haven’t tested all of them yet.

4.0rc2 also contains a lot of bug fixes over rc1, and should be relatively stable. Now is the time to start trying out deployments of it to see if everything is okay in your environment. Our current plan is to release Bugzilla 4.0 on Tuesday, February 15, 2011 if everything goes well with this release.


May 23, 2013 12:26 AM

Bugzilla 4.0 Released!

So, last week we released Bugzilla 4.0, which was pretty exciting. It had some awesome major new features, like the redesigned search page, automatic duplicate detection, autocomplete for user and keyword fields, and an enormously-enhanced WebServices interface.

In addition to all of these huge features, though, there were a lot of smaller improvements that were pretty awesome in and of themselves. The major, major features are so huge that it’s easy to miss how great some of the other changes were, so I wanted to take some time in this blog to talk about some of those “smaller” improvements that can be pretty significant for some users.

UI Improvements

In addition to the redesigned search page, one of the biggest UI improvements is the new “attachment details” page (log in to see the full functionality). If you do a lot of code review in your Bugzilla, or if you open up attachments frequently to comment on them, you’ll appreciate the new full-size comment box and the enormous textarea space available for commenting inline on text attachments.

Also, another really nice change is that when you forget to set a required field on bug entry, you’re notified before you leave the page, instead of having to submit the form and then go back to add any missing data. Bugzilla highlights the fields you missed and puts a clear message in bold red letters on the page so that you can see what you need to fill out. It even puts the page focus on the first box you need to fix, now.

On the Search page and the bug entry page, you can hover over the label of any field to get a description of what that field does. Your mouse cursor will even change to indicate the availability of help. This should be particularly useful to people who are new to Bugzilla.

When you do a “quicksearch” using the box in the header or footer, your search will still be there when you see the search results, now. This makes editing the search you just did a lot easier.

There is a “Calendar” widget for every single date/time field in Bugzilla now.

You can choose to have the “Add a new comment” box above or below the existing comments, when viewing a bug, now. (See your Preferences.)

Every command-line script of Bugzilla now prints any error in red (if this is possible in your terminal), to make it really clear that running the script did not succeed.

And of course, this is pretty obvious, but there are great new icons for the Home page, now.

Custom Fields

People have long asked for the ability to make certain custom fields “mandatory”–that is, when filing a bug, you have to fill those fields out, and after the bug is filed, those fields can never be empty. Bugzilla 4.0 now supports this–all you have to do is check a single checkbox in the Administration UI, and your custom field becomes mandatory!

You can see “Multi-Select” custom fields as a column in your search results (the bug list) now!

Almost every custom field in your system will now be available as an axis for Graphical Reports and Tabular Reports. (Actually, a whole lot of other built-in fields are now available, too!)

You can now represent relationships between bugs when using the “Bug ID” field.

You can now display custom fields only in a certain Component or only in a certain Classification.


Some people make really heavy use of the “Show my last search results” link, or the “First/Previous/Next/Last” links at the top of the bug page. In past versions of Bugzilla, doing a new search would entirely replace your “last search results”, meaning that “Show my last search results” and the “First/Previous/Next/Last” links would suddenly be working with a whole new set of bugs. Now Bugzilla “remembers” the last five search results for all logged-in users and does its best to give you the right list whenever you’re trying to navigate using those links on the bug page.

You can now search for attachments with specific flags on them, when using the Boolean Charts (which are now called “Custom Search”). Just specify a criteron for an attachment and a criterion for a flag in the same Chart.

Since almost the very first version of Bugzilla, you haven’t been able to search for a Product, Component, Target Milestone, etc. if its name contained a comma. Now you can!


You can get data from the Bugzilla JSON-RPC WebService using HTTP GET, now, which is a lot easier in many situations. Also, you can even call the JSON-RPC WebServices from another domain using JSONP, meaning that you can use data from an external Bugzilla on your webpage, straight from JavaScript!

Also, there are a ton of new WebService functions and parameters available. See the full list of WebService improvements for details. Probably the biggest one is the new Bug.update function that allows you to update existing bugs.


Loading pages in Bugzilla should now be much faster, particularly if it’s your first time visiting Bugzilla, since we have eliminated the need for the browser to download a large number of unnecessary CSS files.

If you’re using time-tracking, you don’t have to enter a comment just to enter Hours Worked anymore!

If you’re setting up the Inbound Email interface, you can set defaults for certain fields using command-line switches.

If you are using a localized version of Bugzilla and your terminal does not understand Unicode, all of Bugzilla’s command-line scripts will now attempt to output their messages in your terminal’s character set.

If you are running Bugzilla under suexec (usually meaning that you’re on shared hosting), now properly sets permissions on everything, meaning that all functionality of Bugzilla should now be working (including graphs and dependency trees).

Bugzilla now optionally supports sending the Strict-Transport-Security HTTP header for improved security on HTTPS installations.

If you are writing extensions, there are a ton of new hooks. The Extensions system is now capable of implementing the vast majority of possible extensions, particularly if you know a few tricks.

Future Plans

Now that 4.0 is released, we’re working on 4.2! Actually, we’ve been working on 4.2 for quite some time, and it already has some great new features, such as HTML bugmail and a new “tags” system that we’re implementing. We also expect to have a fully-redesigned Search backend that behaves consistently and intelligently for all searches while also performing considerably better than the current system does. There are already 100 enhancements marked as FIXED for 4.2, in fact! Check out that full list for details.

Currently our plan is to freeze for 4.2 on April 20, which would put our likely release date at some point in Q4 of 2011. Of course, depending on how many contributors we get, we could possibly release even earlier than that! Finding and fixing bugs in the trunk code is the fastest way to speed up our release process, so if you want to do that, see our development process for information on how to get our code and submit patches!


May 23, 2013 12:26 AM

Bugzilla 4.1.1 Development Release

Less than a month after our release of 4.0, we have our first development snapshot, Bugzilla 4.1.1 available for you! This is our first release towards what will eventually be 4.2, and it’s got a bunch of new features. Here’s a really quick overview of what’s new in 4.2:

Those are most of the major new changes that are in 4.1.1 over 4.0. We also have many other features planned for 4.2.

We hope that you enjoy testing Bugzilla 4.1.1 and we would love to hear your feedback, both on how the new features work and any bugs that you may find!


May 23, 2013 12:26 AM

Release of Bugzilla 4.1.2, 4.0.1, 3.6.5, and 3.4.11

Hey Bugzilla users! We just released four new versions of Bugzilla. There were a lot of cool bug fixes in 3.6.5 and 4.0.1, but most importantly, if you had trouble installing Bugzilla 4.0, you should try again now with Bugzilla 4.0.1. There was a problem with the way that our script installed the Math::Random::Secure module–basically, it would install the module even though the module’s prerequisites failed to install. Then when you tried to run, Math::Random::Secure would throw a cryptic error about “Math::Random::Secure::irand.”

Now, in 4.0.1 and 3.6.5, won’t install the module if installing it would break your system. Basically, following the standard installation instructions should work fine, now. Bugzilla 3.4.11 took this a step further and no longer uses Math::Random::Secure at all for this older branch (although don’t worry, Bugzilla 3.4.x is still secure).

For 4.1.2, we made this protection even more extreme– now completely refuses to operate if you don’t have a compiler installed somewhere on your system (because so many CPAN modules require a compiler, and CPAN throws very confusing error messages when there is no compiler available on your system).

New Features in 4.1.2

All right, with all that out of the way, let’s talk about new features in 4.1.2! Here’s a quick list of important new things:

The Plan For Pretty

So, as you may have read, the “Make Bugzilla Pretty” contest is over, and Jonathan Wilde has won. The current plan is for his UI to be the new official UI for Bugzilla 5.0, which will come some time after 4.2.

Basically, the way that it will work is this: After we branch for 4.2, we will create a new “pretty” branch. The Bugzilla team will work on implementing the new UI in this branch, while simultaneously doing new feature development on the normal Bugzilla trunk. Once the “pretty” branch is ready, it will be merged back into the trunk. We can do this all fairly efficiently thanks to bzr.

Now, there is a chance that the “pretty” branch won’t be ready by the time we want to do the release that follows 4.2. In this case, that release will be called 4.4 and the release after that will have the new UI. However, we very much want to release the new UI as soon as possible, so our goal is for 5.0 to be the release after 4.2.

Get Involved

As always, we love new contributors in every area. There are a lot of ways to contribute to Bugzilla–you don’t just have to be a programmer. In particular, we’d really love to have somebody to be in charge of our documentation. If you know anybody who’s a great documenter (including yourself!) who wants to help out an open-source project, please send them our way!


May 23, 2013 12:26 AM

Release of Bugzilla 4.2rc2, 4.0.4, 3.6.8, and 3.4.14

Today we are announcing the second Release Candidate for Bugzilla 4.2, in addition to one new stable release and two security-only updates for the 3.4.x and 3.6.x series.

Bugzilla 4.2rc2 is our second Release Candidate for Bugzilla 4.2. This release has received QA testing, and should be considerably more stable than the development releases before it. It is still not considered fully stable, and so you should understand that if you use it, you use it at your own risk. This will most likely be the last release candidate before 4.2 final.

Bugzilla 4.0.4 is our latest stable release. It contains various useful bug fixes and security improvements for the 4.0 branch.

Bugzilla 3.6.8 and 3.4.14 are security updates for the 3.6 branch and the 3.4 branch, respectively.

All the gory details and download links and the security advisory are available on our website.

Get Involved

As always, we love new contributors in every area. There are a lot of ways to contribute to Bugzilla–you don’t just have to be a programmer. In particular, we’d really love to have somebody to be in charge of our documentation. If you know anybody who’s a great documenter (including yourself!) who wants to help out an open-source project, please send them our way!

May 23, 2013 12:26 AM

Release of Bugzilla 4.3.2, 4.2.2, 4.0.7, and 3.6.10

Today we have several new releases for you!

All of today’s releases contain security fixes. We recommend that all Bugzilla administrators read the Security Advisory that was published along with these releases.

Bugzilla 4.2.2 is our latest stable release. It contains various useful bug fixes and security improvements:

Bugzilla 4.0.7 is a security update for the 4.0 branch:

Bugzilla 3.6.10 is a security update for the 3.6 branch:

Bugzilla 4.3.2 is an unstable development release. This release has not received QA testing from the Bugzilla Project, and should not be used in production
environments. Development releases exist as previews of the features that the next major release of Bugzilla will contain. They also exist for testing purposes, to collect bug reports and feedback, so if you find
a bug in this development release (or you don’t like how some feature works) please tell us.

May 23, 2013 12:26 AM

Release of Bugzilla 4.3.3, 4.2.3, 4.0.8, and 3.6.11

Today we have several new releases for you!

All of today’s releases contain security fixes. We recommend that all Bugzilla administrators read the Security Advisory that was published along with these releases.

Bugzilla 4.2.3 is our latest stable release. It contains various useful bug fixes and security improvements:

Bugzilla 4.0.8 is a security update for the 4.0 branch:

Bugzilla 3.6.11 is a security update for the 3.6 branch:

Bugzilla 4.3.3 is an unstable development release. This release has not received QA testing from the Bugzilla Project, and should not be used in production environments. Development releases exist as previews of the features that the next major release of Bugzilla will contain. They also exist for testing purposes, to collect bug reports and feedback, so if you find a bug in this development release (or you don’t like how some feature works) please tell us.

May 23, 2013 12:26 AM

Release of Bugzilla 4.4rc1, 4.2.4, 4.0.9, and 3.6.12

Today we have several new releases for you!

All of today’s releases contain security fixes. We recommend that all Bugzilla administrators read the Security Advisory that was published along with these releases.

Bugzilla 4.4rc1 is our first Release Candidate for Bugzilla 4.4. This release has received QA testing, and should be considerably more stable than the development releases before it. It is still not considered fully stable, and so you should understand that if you use it, you use it at your own risk.

If feedback from this release candidate indicates that it is mostly stable, then Bugzilla 4.4 will be released in a few weeks. If feedback indicates that more extensive fixes are needed, there may be another release candidate after this one.

Bugzilla 4.2.4 is our latest stable release. It contains various useful bug fixes and security improvements:

Bugzilla 4.0.9 is a security update for the 4.0 branch:

Bugzilla 3.6.12 is a security update for the 3.6 branch:

May 23, 2013 12:26 AM

May 22, 2013

Frédéric Buclin

Bugzilla 4.4 and 4.2.6 released

We released Bugzilla 4.4 and 4.2.6 a few minutes ago. Bugzilla 4.2.6 is a bugfix release, and contains no security fixes. It adds support for MySQL 5.6 and fixes a crash with Oracle.

Bugzilla 4.4 contains many new features:

This release also means the End Of Life (EOL) of Bugzilla 3.6, which was the last series for Bugzilla 3.x. This branch is no longer supported, and any new security bug found on this branch will remain unfixed. Installations still running Bugzilla 2.x or 3.x are urged to upgrade to Bugzilla 4.4 or 4.2.6.

So, what’s next? Well, the main focus for Bugzilla 5.0 will be usability and user experience. Bugzilla sometimes (often?) looks old-fashioned because we wanted to support old browsers and browsers with JavaScript disabled. But we decided to move to a more interactive interface where JavaScript will help accomplish some tasks with less page reloads, such as submitting changes to a bug or adding an attachment. We also plan to add a new skin to Bugzilla which should look like this. Some pages will also be entirely redesigned, such as the Group Controls page to administrate access to bugs which was considered too complex for the average admin. More information will come with the release of development snapshots.

May 22, 2013 09:56 PM

February 20, 2013

Bugzilla Update

Bugzilla 4.4rc2 and 4.2.5 released (and also 4.0.10 and 3.6.13)

(mirrored from LpSolit’s Blog)

So, Bugzilla 4.4rc2 is finally here! It took us more time than expected, but the performance bugs are all fixed and we also fixed two security bugs which are described in the security advisory. Bugzilla 4.2.5, 4.0.10 and 3.6.13 also contain these two security fixes, so you should definitely upgrade.

Compared to 4.4rc1, the new release candidate contains the last feature which we wanted for 4.4: the ability to add several criteria in a query against the same field. In Bugzilla 4.2,

"Flags changed to approval+" AND "Flags changed by"

were disconnected, which means that these criteria would match all bugs which had the approval+ flag set and which had a flag changed by In Bugzilla 4.4, you can now force these two criteria to match the same field, i.e. that you only want bugs where the approval+ flag has been set by Thanks to Byron Jones (glob) for this great feature. :) Of course, this feature is not limited to flags, but works with all fields. See the release notes for more details. Also, 4.4rc2 should in most cases be much faster than 4.2 to run some complex queries. In my testing, some queries which took several minutes to complete now run in a few (tens of) seconds only. This is especially noticable with many columns displayed in the buglist. Another good reason to test it! ;)

The next release should be 4.4 final as I don’t think a 4.4rc3 is needed.

February 20, 2013 03:47 AM

Frédéric Buclin

Bugzilla 4.4rc2 and 4.2.5 released (and also 4.0.10 and 3.6.13)

So, Bugzilla 4.4rc2 is finally here! It took us more time than expected, but the performance bugs are all fixed and we also fixed two security bugs which are described in the security advisory. Bugzilla 4.2.5, 4.0.10 and 3.6.13 also contain these two security fixes, so you should definitely upgrade.

Compared to 4.4rc1, the new release candidate contains the last feature which we wanted for 4.4: the ability to add several criteria in a query against the same field. In Bugzilla 4.2,

"Flags changed to approval+" AND "Flags changed by"

were disconnected, which means that these criteria would match all bugs which had the approval+ flag set and which had a flag changed by In Bugzilla 4.4, you can now force these two criteria to match the same field, i.e. that you only want bugs where the approval+ flag has been set by Thanks to Byron Jones (glob) for this great feature. :) Of course, this feature is not limited to flags, but works with all fields. See the release notes for more details. Also, 4.4rc2 should in most cases be much faster than 4.2 to run some complex queries. In my testing, some queries which took several minutes to complete now run in a few (tens of) seconds only. This is especially noticable with many columns displayed in the buglist. Another good reason to test it! ;)

The next release should be 4.4 final as I don’t think a 4.4rc3 is needed.

February 20, 2013 02:10 AM

December 26, 2012

Frédéric Buclin

There will be a 2nd release candidate for Bugzilla 4.4

You may wonder what’s going on since we released Bugzilla 4.4rc1 on November 13. Well, very few bugs have been reported which seems to indicate that 4.4rc1 is pretty stable. But we also found that running some queries were very slow since Bugzilla 4.2. Bugzilla 4.2 got a major rewrite of its search code (Bugzilla::Search), where the focus was readability, maintainability and the removal of some hacks, but this new code had some severe performance impact for some queries, especially those involving subselects in MySQL. That’s why several bugs related to performance have been filed since we released 4.4rc1 and we decided that they were critical enough to fix them in the 4.4 branch rather than waiting another year to include them in Bugzilla 5.0 only. As it’s unclear if these recent changes can have negative impact on some queries, or break some other ones, we decided that a 2nd release candidate was necessary to give admins and developers some time to test the new code and give us feedback before 4.4 final. There is no ETA for 4.4rc2 yet, but it will probably be somewhere in January 2013.

If you have some queries which you consider as being very slow, I would be interested in hearing you about them: which criteria did you use, which columns are displayed in buglists, which Bugzilla installation did you use for your testing, are you logged in or logged out, etc…? Please don’t run your queries on Bugzilla 3.x or older. I’m really not interested in such old installations (and the code changed too much anyway with what we have in 4.4). In my own testing, I found that some queries which were previously timing out now run in a few seconds only. Of course, the time taken to execute these queries highly depends on the data you have in your DB and so only relative timing matters.

December 26, 2012 03:30 PM

December 21, 2012

Bugzilla Tips

Quicksearch Reference

“Quicksearch” is a way of searching Bugzilla using simple yet powerful syntax. The search box at the top of every page supports it.

Jesse Ruderman has written a wonderful Quicksearch Reference – a must-read if you search Bugzilla a lot.

December 21, 2012 11:25 AM

December 07, 2012

Bugzilla Tips

Even Faster Quicksearches

To speed up quicksearches, limit the search by product or component. Add “comp: <string>” to your query to limit it to components whose names contain that string. As an abbreviation, you can simply use “:” instead of “comp:”, although that also searches in products whose names which contain the string.

By analogy with the use of “:”, there are abbreviations for some other common fields as well.

(Thanks to Ben Hearsum and Ed Morley)

December 07, 2012 06:20 PM

December 06, 2012

Bugzilla Update

Upgrading your Bugzilla? Don’t forget to Sanity Check first.

When planning on upgrading your Bugzilla to a newer version, it’s always a good idea to read the release notes in case of special instructions that need to be done to handle certain situations in upgrades.  Our script has gotten pretty good at handling a lot of situations automatically for you these days, but nothing is ever perfect.

One instruction in the upgrade procedure for every release that often gets overlooked is to run the Sanity Check function from the Admin page on your Bugzilla site before upgrading.  It checks the integrity of the data in your database and will alert you to a number of possible problems with your data.  Sometimes bugs in Bugzilla or even people manually messing with the database will cause something to not be how Bugzilla expects it, and every so often one of these problems can cause issues for an upgrade.  Fixing any problems reported by Sanity Check before each upgrade can save you a lot of headaches.

In a recent example: newer versions of Bugzilla allow you to edit the available statuses and resolutions on bugs.  Older versions didn’t.  One of the steps performed by the upgrade script is to examine your database, take whatever current statuses you’ve been using (even if you hacked your Bugzilla to allow different ones before we actually let you customize them), and convert them to the way the new customizable ones are stored.  The new custom status system has a flag to distinguish between statuses that are allowed to have resolutions and those that aren’t.  When upgrading, it decides whether to set that flag on a status or not by looking in your database to see if there are any bugs with that status that have resolutions on them.  If it finds any, the status is set up to use them.

A long time ago there was Bug 107229 which caused duplicate bugs to get the wrong status if you midaired while marking it a duplicate.  This caused bugs to exist in an “ASSIGNED DUPLICATE” state that should have been “RESOLVED DUPLICATE”.  A side effect is if it was left that way, when you later upgraded to a version of Bugzilla that included the custom statuses, your ASSIGNED status became a “closed” type instead of an “open” one, and would require a resolution.  Sanity Check most likely would have caught this, as it checks for things like resolutions where there shouldn’t be any. :)

December 06, 2012 10:58 PM

December 01, 2012

Bugzilla Tips

Faster Quicksearches

Another guest post from Stefan Arentz:

“If you do a lot of quick searches to find bugs by summary and you don’t care about also looking into the comments of those bugs, flip the “Include comments when performing quick searches (slower)” to NO in your preferences.

A search for ‘radio antenna’ just went down from 30+ seconds to just a few seconds.”

December 01, 2012 02:12 PM

November 29, 2012

Bugzilla Tips

HTML Email

Guest tip from Stefan Arentz:

“Bugzilla actually does have HTML emails! [As of version 4.2, but it’s been backported to’s 4.0 installation – Ed.] I always though that it did not because I did not look further than the “Email Preferences” tab. But there actually is a “Preferred email format” under the “General Preferences” tab.

This makes Bugzilla emails 100x easier to read on a phone.”

November 29, 2012 02:08 PM

November 14, 2012

Frédéric Buclin

Bugzilla 4.4rc1, 4.2.4, 4.0.9 and 3.6.12 released

Last night, we released Bugzilla 4.2.4, 4.0.9 and 3.6.12 to fix several security issues. Bugzilla 4.2.4 also notably fixes some crashes with Oracle when viewing buglists. Oracle support in 4.2.4 is definitely much better than in previous 4.x or 3.x releases.

We also released the first release candidate of Bugzilla 4.4, which we expect to release near the end of the year, though it will depend on the feedback we get. If a second release candidate is needed, we will delay 4.4 final. Now is a good time to test its new features, including the new tagging system (which replaces the previous tagging system which you could see in the footer of pages), the ability to save tabular and graphical reports in the same way you can save your searches (no need to bookmark them in your browser anymore), customizable columns displayed in emails sent by the whining system, many new and updated WebService methods, real auto-detection of the MIME type of attachments uploaded to Bugzilla (currently only if the browser is unable to determine the MIME type itself, else we still trust what the browser says), etc… Do not forget to fix your Apache configuration file (httpd.conf) when upgrading as explained in the release notes, else Bugzilla 4.4 won’t work. Have fun! :)

November 14, 2012 01:40 PM

November 09, 2012

Frédéric Buclin

Using GMail as SMTP server from Bugzilla to send email notifications is supported natively

I saw several requests about how to use GMail as server to send bugmails from Bugzilla. I also saw too many (bad) articles about how to hack Bugzilla to make it work. Most were suggesting to install 3rd-party applications and to badly hack the source code, especially when installed on Windows. Forget all that! What you must know is that Bugzilla supports GMail as SMTP server for more than a year (!), and Bugzilla 4.4rc1, which is going to be released next Tuesday, supports it natively!

When running, make sure that Net::SMTP::SSL is installed:

Checking for         Net-SMTP-SSL (v1.01)     ok: found v1.01

Then edit the following parameters (under Administration > Parameters > Email):

mail_delivery_method = SMTP
mailfrom =
smtpserver =
smtp_username =
smtp_password = your_gmail_password
smtp_ssl = on

Do not forget to save your changes, and that’s all, Bugzilla is now able to use GMail to send bugmails.

If you are running Bugzilla 4.2 or older, then you should apply this patch. That’s the patch which is now part of Bugzilla 4.4, but it also applies cleanly to all supported branches. And the good news is that the upgrade to 4.4 will run smoothly as that’s the exact same code as for 4.4. ;) Once applied, you can follow the steps above.

November 09, 2012 12:02 PM

October 17, 2012

Frédéric Buclin

Anyone familiar with Oracle (the DB)? I need your help!

Bugzilla installations running Oracle as their database server fail to display flags, tags and keywords in buglists. Oracle crashes with:

DBD::Oracle::db prepare failed: ORA-30482: DISTINCT option not allowed
for this function (DBD ERROR: error possibly near <*> indicator at char 313

..., group_concat(<*>T_CLOB_DELIM(DISTINCT, ', ')) tag

All the details are in bug 780053. The group_contact() function is defined in Bugzilla/DB/ The maintainer of the Oracle DB module, who was an Oracle employee, disappeared, leaving us in the dust. The code in is totally obscure to us and I have no idea how to fix it. I would like to have this bug fixed on time for Bugzilla 4.4, which should be released before the end of the year, and so I need your help as soon as possible to fix this problem. Someone already made a suggestion in the bug, but I need a second review or another sugggestion as I don’t understand anything about the cryptic internals of Oracle.

So if you are familiar with Oracle or use Oracle as your DB server, please give it a look. Many thanks! :)

October 17, 2012 01:11 PM

October 06, 2012

Frédéric Buclin

New UI to manage products in Bugzilla

All those of you who are administrators of a Bugzilla installation already had to configure products in the past. Most of you probably found it was pretty hard to configure security correctly on these products: Entry, MemberControl, OtherControl, Canedit, editbugs, canconfirm, editcomponents. What’s all this and how do they interact with each other?

I made a proposal to rewrite this page entirely, and you can see the result here (it’s a html page). If you are a Bugzilla administrator or have privileges to edit product settings on your Bugzilla installation, please give me your feedback, ideally as a comment in the bug itself, in the worse case here as a comment. If this new UI is accepted, it will be part of Bugzilla 5.0.

October 06, 2012 03:20 PM

September 18, 2012

Frédéric Buclin

Changes to httpd.conf required before upgrading to Bugzilla 4.3.3 (and 4.4)

I saw several admins being confused about why their Bugzilla installation stopped working after upgrading to Bugzilla 4.3.3. First of all, remember that 4.1, 4.3, 4.5, etc.. are developement releases, not stable releases! Stable releases are of the form 4.0, 4.2, 4.4, etc… Now, the reason for this specific issue is because we added  "Options -Indexes" to bugzilla/.htaccess to prevent directory browsing, but this requires that your httpd.conf configuration file allows the usage of Options in .htaccess. Till now, you probably had:

Bugzilla 4.2 and older:

<Directory /var/www/html/bugzilla>
    AddHandler cgi-script .cgi
    Options +Indexes +ExecCGI
    DirectoryIndex index.cgi
    AllowOverride Limit FileInfo Indexes

Now, you must have:

Bugzilla 4.4 and newer:

<Directory /var/www/html/bugzilla>
    AddHandler cgi-script .cgi
    Options +ExecCGI
    DirectoryIndex index.cgi index.html
    AllowOverride Limit FileInfo Indexes Options

Note that +Indexes has been removed from the Options line, that index.html has been added to DirectoryIndex (for the doc) and more importantly that we added Options to AllowOverride. This last change is the one required to make Bugzilla work again.

September 18, 2012 11:33 AM

August 21, 2012

Frédéric Buclin

Bugzilla 4.2.3 is very close, and Bugzilla 4.4rc1 is not too far away

I think now is a good time to give you some news about the current development of Bugzilla. First of all, we are very close from releasing Bugzilla 4.2.3 and 4.3.3. There is one blocker left which needs its patch to be reviewed, and we can start the release process. Hopefully this will happen this week. Both releases will work with Perl 5.16 (uploading attachments was broken due to a change in Perl 5.16), databases created with PostgreSQL will now be encoded with UTF8 (the encoding wasn’t enforced, and was entirely depending on how initdb created template1), Oracle will be able to display buglists again instead of crashing (unless you try to display keywords, flags or tags. I have no idea how to fix this problem, help welcome), the obsolete -moz-border-radius CSS property which was no longer understood by Firefox 13 and newer has been replaced by -border-radius (meaning that other browsers will take advantage of it too), and a regression in 4.2.2 about the keyword auto-completion feature has been fixed. There are a few more fixes included in 4.2.3, but you will read them in the release notes. :)

About 4.3.3, we can also mention that the "Browse" link in the page header and footer now correctly sorts products by classification, you can now save your tabular and graphical reports (till now, you could only save your searches), the User.get WebService method now returns your saved searches too (and only yours!), PATH_INFO is now removed by default from all URLs, graphical reports are automatically resized based on the size of your window, if you type the alias of a bug you cannot see, Bugzilla no longer tells you which bug ID has this alias (it just tells you that this alias is already in use), flags which you cannot set/edit are now hidden instead of being disabled only, there is now a "(take)" link besides the QA contact (till now, only the assignee had such a link), and we now use HMAC-SHA256 to generate tokens instead of MD5. More WebServices methods are expected before 4.4rc1; they are currently being worked on (and some patches already in the review queue).

Once Bugzilla 4.2.3 and 4.3.3 are out (hopefully this week), we will create a branch for 4.4. On the 4.4 branch, we will limit changes to new WebServices methods, bug fixes and some not too invasive patches. The plan is to release 4.4rc1 next month or the month after, and 4.4 final before the end of the year.

On the trunk, we will immediately start the development cycle for Bugzilla 4.6/5.0 (we didn’t decide its version yet, but this is not the most important part of the story). One of the main goals will be to improve its User Interface (yeah, that’s not a joke). We are currently using YUI2, and I hope that using YUI3 or jQuery (the choice isn’t made yet, see bug 453268) will help to reach this goal. We will also need feedback and suggestions from the community to improve things (this is way better than waiting for the next version to be released and start complaining at that time that you don’t like the new UI. Try to be constructive, though). We will also bump the min version of Perl from 5.8.1 to 5.10.1 so that we can use some new features implemented in 5.10.1. New contributors are always welcome! ;)

August 21, 2012 12:03 AM

July 12, 2012

Byron Jones

bugzilla 4.2 – what’s new – searching

a major change between bugzilla 4.0 and bugzilla 4.2 comes in the form of changes to searching. the searching implementation in 4.2 was rewritten from scratch, removing some seriously convoluted code and adding a large amount of test cases.

notable differences include:

search results limiting

search results are initially limited to 500 bugs, with an additional click required to show up to 10,000 bugs.  it is no longer possible to generate a query which results in massive bug lists.

searching via APIs remains unlimited.

changes to relative dates

when using relative dates and times, -1w is now a synonym for -7d and means exactly 7 days.

previously, -1w meant the beginning of the week, which was confusing some users. the same confusion existed for -1d which was different from -24h, and for -1m which was different from -30d. now if you really want the beginning of the day, week or month, you must use -1ds, -1ws, and -1ms respectively, where “s” means “start of”.

this change will affect existing saved searches using relative dates.

improved custom search builder

the custom search builder on the advanced search tab has been improved; it’s now easier and quicker to construct queries.

predictable results

complex queries built by the custom search interface are easier to build and have more sensible results, as they are built using a more intuitive logic.

Filed under: bmo, bugzilla, mozilla

July 12, 2012 04:37 PM

May 30, 2012

Frédéric Buclin

Testopia 2.5 released! Works with Bugzilla 4.2.1

I got an email this morning from the maintainer of Testopia to inform me that Testopia 2.5 is finally released! This is the first version to work with Bugzilla 4.2.1 (if you are still running Bugzilla 4.0.x or 4.2, upgrade to 4.2.1 first). The announcement has not be made official yet, but this should be done in the coming hours, hopefully. Meanwhile, you can already download Testopia 2.5. Note that there is no need to apply any patch anymore to make it work (which is why you need Bugzilla 4.2.1 instead of e.g. 4.2, because 4.2.1 has some changes included in it to avoid to patch the core code to make Testopia work). And if you find any problem which hasn’t been reported yet, feel free to file a new bug (bugs only, no support questions). Have fun!

UPDATE: The announcement has finally been made here.

May 30, 2012 01:05 PM

May 15, 2012

Frédéric Buclin

How to require high code quality without discouraging new or occasional contributors?

During the week-end, I received a pertinent email from a former Bugzilla developer who replied to an email I sent to all reviewers about the pretty low activity in the Bugzilla project during the current development cycle. He argued that one of the reasons which made him go away, and which probably took some other contributors away as well, is our high code quality standards we have in this project. The point is that we deny review if submitted patches do not follow our guidelines or are poorly written compared to what we expect in our codebase. He suggested that reviewers should accept and commit lower quality patches, and file follow-up bugs to clean up the new code. I then brought this discussion on IRC with other core developers, and we realized how hard it is to define the right level of code quality. The problems are:

So what’s the right threshold to not make new and occasional contributors go away without badly impacting our codebase? Which rules do other Mozilla and non-Mozilla projects use to solve this problem? Please share your experience with us. :)

May 15, 2012 05:56 PM

April 19, 2012

Frédéric Buclin

Bugzilla 4.3.1, 4.2.1, 4.0.6 and 3.6.9 released

We released Bugzilla 4.3.1, 4.2.1, 4.0.6 and 3.6.9 a few hours ago, and they all contain 2 security fixes. All installations are highly encouraged to upgrade to these new releases. Bugzilla 3.6.9 and 4.0.6 only contain the two security fixes mentioned in the security advisory. Bugzilla 4.2.1 also contains a pretty large list of bug fixes, which makes it a good candidate to upgrade to the 4.2.x series if you didn’t upgrade to 4.2 yet. Note that Bugzilla 4.2.1 is also the first release to work with Testopia without needing to be patched first. A new release of Testopia should be available soon, which will take advantage of the improvements and new hooks available in 4.2.1.

We also released Bugzilla 4.3.1 which is the first development snapshot of the 4.4 series. I’m going to list some of the new features and improvements available:

We are one month away from the freezing date for new features in Bugzilla 4.4. So if some of you really want something for 4.4, you have exactly one month left to submit patches, or find a kind developer to write the patch for you. Also note that Bugzilla 4.4 will be the last release to support Perl 5.8.x. The next major release, Bugzilla 4.6, will require Perl 5.10.1 or better.

April 19, 2012 01:10 AM

April 09, 2012

Frédéric Buclin

Testopia 2.5 will work with Bugzilla 4.2.1 pretty decently

You probably noticed that there has been no activity related to the development of Testopia, a Bugzilla extension, for more than a year. The reason is that its maintainer, who was the single contributor to this project, had a new job and has no time to work on it anymore. Consequently, the latest version of this extension, Testopia 2.4, which was released in October 2010 (!), only works with Bugzilla 3.6, but not 4.x.

You will be happy to hear that with the help of some new contributors wanting to make Testopia work with Bugzilla 4.2, I committed several patches to the bzr repository which make it work pretty decently with Bugzilla 4.2.1 (probably also with Bugzilla 4.0.x, but I didn’t test). There is no official release yet (it should be named Testopia 2.5), but you can download updated files using bzr. Make sure to revert changes made to the core code of Bugzilla first before applying the new code.

To make things clear: I’m not the new maintainer of this extension, and I have no plan to take this role. I’m busy enough with my roles as assistant project lead + reviewer + QA lead + bug triager + developer for the Bugzilla project. I simply decided to help the new contributors who jumped in these last few days and used my commit access to the Testopia repository to commit some patches. The Testopia maintainer is still alive, and emailed me this morning. So he is still the one who will take the decision to release 2.5 when it’s ready. :)

Update: Starting with Bugzilla 4.2.1, you no longer need to patch the source code of Bugzilla to make it work with Testopia 2.5! If you are upgrading from Testopia 2.4 or older, make sure to revert the changes made to the source code first.

April 09, 2012 05:58 PM

March 29, 2012

Frédéric Buclin

Bugzilla 4.5 will require Perl 5.10.1

This is just a quick note to let you know that once we branch for Bugzilla 4.4 in May, I will commit a patch which will make Bugzilla 4.5 and newer to require Perl 5.10.1 as a minimum. This means Bugzilla won’t support Perl 5.8.x anymore. So Bugzilla 4.4 will be the last release to support the oldish Perl 5.8.x. This new requirement is tracked in bug 655477.

March 29, 2012 09:24 PM

March 25, 2012

Emmanuel Seyman

Cleaning up Bugzilla

RPMFusion's Bugzilla has gathered a number of bugs over the years and, for lack of maintainance, bugs filed against EOL-ed versions of Fedora have never been closed. The result is a number of open bugs:

Fedora 8 2
Fedora 9 2
Fedora 10 13
Fedora 11 8
Fedora 12 10
Fedora 13 6
Fedora 14 45

I've added a new resolution, EXPIRED, in and I'll be using it over the next few weeks to close bugs filed against Fedora 8 through 14. Once a week, I'll be taking one version's bugs and closing them with the EXPIRED resolution and adding a comment on the next version's bugs warning that they will be closed a week later. Once we're done with those, it will probably be time to do the same thing to the Fedora 15 bugs. At that point, we'll probably join the Fedora bug triage cycle, doing this every 6 months.

March 25, 2012 08:44 AM

March 02, 2012

Frédéric Buclin

Upgrading from Bugzilla 4.0 or older using CVS to Bugzilla 4.2 or newer using Bzr

There has been some complains these last few days on IRC and in the support mailing-list/newsgroup that admins couldn’t upgrade their Bugzilla installation to 4.2 due to the lack of a CVS mirror for this branch. As announced 3 years ago in the developers mailing-list and on b.m.o., and 1.5 years ago on the website, the Bugzilla team switched from the old CVS to the more modern Bazaar (or bzr for short) VCS. If you use our tarballs to download Bugzilla, then you don’t really care about this change, and the process to upgrade won’t change for you. If you use CVS and you wonder how to upgrade using Bzr, here is how you can do it:

  1. For now, there is no need to shut down Bugzilla. We will do this when we start the upgrade process itself. If you made changes to the Bugzilla code itself (instead of using its extension system), you will have to port these changes to the new version, else they will be lost. If you made no changes, or all changes are contained into extensions, you can jump to step 2 directly. To generate a patch with all the changes you made, go into your bugzilla/ directory and run this command:
    cvs diff -puN > patch.diff
    The file patch.diff will contain all the changes you made to your current installation.
  2. Let’s download the new version of Bugzilla into a separate directory, to not mess with the current installation. Now you will need bzr. All Linux installations have it; have a look at your package manager. For instance, Fedora 16 has bzr-2.4.2-1.fc16.i686.rpm. On Windows, you can download it from The standalone application is recommended; for instance: bzr-2.4.2-1-setup.exe. Once bzr is installed, run this command to download Bugzilla 4.2:
    bzr co bzr:// bugzilla42
    Here, bzr co means "checkout", i.e. it’s the first download of 4.2 with bzr. Then you have the URL to our Bugzilla 4.2 repository, and finally you have the name of the local directory into which to dowload the source code. If you don’t like the name bugzilla42, feel free to choose another one. :)
  3. Now go into the new bugzilla42/ directory and run the following command:
    ./ –check-modules
    The –check-modules part is important for two reasons. First of all, we didn’t copy the configuration files from the old bugzilla/ directory into the new one. The advantage to do so is to prevent Bugzilla 4.2 from finding where your DB is located and start interacting with it. Remember that we did no backup of your DB yet! :) And the second reason is that we first want to make sure that we have all the required Perl modules installed. Between major releases of Bugzilla, the requirements may change, either by requiring new Perl modules, or by requiring a newer version of an existing Perl module. If you have missing or too old Perl modules, you will have to install or upgrade them, ideally using your package manager. On Windows, ActivePerl 5.12 and newer have all the required modules available, so that’s not a problem. On Linux, only old distros may have some missing or too old Perl modules. If this happens, you can use the script which is in the same directory as to install them. The commands you need to execute are given by –check-modules itself. So open your eyes. :) Note that you don’t need to install all the optional Perl modules. The reason is that they are…. optional! Only install those which are relevant to your installation.
  4. If you made changes to your current Bugzilla installation, then you have to apply patch.diff you created at step 1 to your new installation. If you made no changes, you can jump to step 5 directly. If you are on Windows and you don’t have patch.exe, you can download it from Once downloaded, you must copy patch.exe into the Windows directory. At this point, it’s very likely that your changes will conflict with the new code, unless you are lucky or your changes are very minor. So we first check if there are conflicts or not. To do that, copy patch.diff into your new bugzilla42/ directory, and run this command from here:
    patch -p0 –dry-run < patch.diff
    –dry-run means that we made no changes to files; it was only a test. If all you get are messages such as "Hunk #1 succeeded at 79 (offset -26 lines)" or "Hunk #1 succeeded at 31 with fuzz 1 (offset 2 lines)", then you are fine. But if you get messages such as "Hunk #1 FAILED at 27" and "1 out of 2 hunks FAILED", then you are in trouble. And don’t blame the Bugzilla team and Bzr, you would get the same errors with CVS! If the conflicts are minor, you can easily fix them manually, else you probably will have to rewrite your changes directly into the new code. If you have no conflicts, you can drop the –dry-run argument and apply your patch for real:
    patch -p0 < patch.diff
  5. Now we are ready to start the upgrade process itself. The first thing to do is to shut down Bugzilla, because the DB must not be accessed by anyone but you during the upgrade process. To do that, go to Administration > Parameters > General > shutdownhtml, and add some explanation of what’s happening. For instance: "This installation is being upgraded to Bugzilla 4.2. The downtime should last approximatively 2 hours.", and click the "Save Changes" button at the bottom of the page. I recommend that you don’t leave this page during the upgrade process, because all other pages will be deactivated besides this one. At this point, when someone tries to access Bugzilla during the downtime, this message will be displayed to them instead, so that you can upgrade your installation without having some users still interacting with it.
  6. Then, and this rule applies all the time when upgrading to a newer major version: do a backup of your database! The reason is that once you start the upgrade process (i.e. when you run, there is NO way to downgrade later. So if the upgrade process fails for some reason (most of the time because someone hacked the source code or the DB schema) and you made no backup, you are lost. To backup your DB with MySQL, run the following command, where you must replace $db_user and $db_name by their value set in your bugzilla/localconfig file (by default: $db_user = bugs; $db_name = bugs):
    mysqldump -u $db_user -p $db_name > db_backup.sql
  7. Copy the whole data/ directory and the localconfig file from your old bugzilla/ directory into the new bugzilla42/ one. data/ contains your parameters in the data/params file, your local attachments in data/attachments/ as well as data for Old Charts in data/mining/. And localconfig contains all the parameters to access the DB, including its password, the name of the web server group, and some other useful configuration information. If you wrote some extensions, now is a good time to also copy them into bugzilla42/extensions/. Only copy the ones you wrote, not the existing ones such as BmpConvert, Example, OldBugMove or Voting, which are maintained by the Bugzilla team.
  8. It’s now time to upgrade your DB to work with Bugzilla 4.2. From the bugzilla42/ directory, run ./ with no arguments (so no –check-modules anymore) and let it run the upgrade process for you. As you copied the configuration and parameters files, it knows where the DB is, its password, and everything else it should know about. Depending on the size of your DB and from which version you are upgrading, this may take from a few minutes to several hours. But typically, it’s of the order of a few tens of minutes for a DB with several tens of thousands of bugs. If everything went well, the last message displayed by must be " complete" displayed in green. Else this means something went wrong at some point. If half of the messages are in red, then there is no doubt about this. ;)
  9. The upgrade is now complete, and it’s time to let your users admire this new version. Replace your old bugzilla/ directory by the new one, and re-enable Bugzilla. To do that, you must remove the text you wrote for the shutdownhtml parameter. As we replaced the old directory by the new one, the URL pointing to Bugzilla remains unchanged. You now have a fully-working bzr-based Bugzilla installation. :)


March 02, 2012 03:04 PM

Performance improvements in Bugzilla 4.4

Now that Bugzilla 4.2 is released, I could finally focus on enhancements instead of fixing blockers and doing QA. This week, I decided to spend some time to improve the performance of Bugzilla. My main focus was show_bug.cgi, i.e. bug reports. I plan to look at other CGI scripts soon, hopefully within 2 weeks.

You will be happy to hear that in the last 3 days, I managed to divide the time spent to load large bug reports such as bmo bug 38862 (235 comments, 32 attachments and 55 CC’ed users) or bmo bug 18574 (760 comments, 63 attachments and 170 CC’ed users!!) by a factor of 2 when using mod_cgi (-50%), and by 30% with mod_perl. The exact load time in seconds depends on the bugs being viewed and on your hardware, but these percentages seem pretty consistent with the different tests done this week. All my patches have been checked in upstream (see rev. 8133 – 8142), and Bugzilla 4.3.1 will be the first release to benefit from them all. Two of them have been backported to 4.2.1 as they are well contained and fix obvious problems, and the other ones are either too invasive for a stable branch or have unclear benefits (the perf win varies between a few 1/1oth of second to 2-3 seconds depending on the test installation).

Now talking about bmo specifically, I gave a look at the InlineHistory extension for the first time, and I proposed a patch which highly decreases the load time of bug reports. dkl did some testing for me with and without mod_perl, and he found these results:

for bug 38862: 5.18 s (unpatched) -> 3.01 s (patched)

for bug 18574 + mod_cgi: 8.01 s (unpatched) -> 4.57 s (patched)

for bug 18574 + mod_perl: 5.76 s (unpatched) -> 4.06 s (patched)

Now I hope the same gain will be visible once these patches are applied to bmo, but the hardware + software configurations of bmo are so different from our test environments that it’s hard to say for sure till the changes are committed and pushed to production. Fingers crossed! :)

March 02, 2012 12:49 AM

February 22, 2012

Frédéric Buclin

Bugzilla 4.2 released!

We released Bugzilla 4.2 today, exactly one year after our previous major release, 4.0! Bugzilla 4.2 now supports SQLite, lets you create attachments simply by pasting text into a text field, can send bug changes notifications in HTML format, supports more complex queries, lets you disable old target milestones, versions and components (so that you don’t need to delete them, but also don’t let users report new bugs to them), has accessibility improvements, and much more

This release also means that Bugzilla 3.4.x is no longer supported. Installations still running 3.4.14 or older are highly encouraged to upgrade to 4.2, especially to benefit from the security improvements made in newer versions. This also means that Bugzilla 4.0.x will now only get security fixes, and other bug fixes won’t be accepted on this branch anymore, unless they fix critical flaws, such as upgrade issues or dataloss.

The Bugzilla team will now focus on the next major release, Bugzilla 4.4, which we expect to release before the end of the year. We expect to release the first development snapshot (4.3.1) in a few weeks. New features will be accepted for the next two months, till the end of April. Then we will focus on stabilization to prepare Bugzilla 4.4rc1.

If you are interested in helping with the development of Bugzilla, now is a good time to join the team and contribute with new features and/or bug fixes. Due to other activities and because life can sometimes make you very busy, some core developers had to stop their contributions to the Bugzilla project in the last few months and so we would be very happy to see new faces. Bugzilla needs to be faster, nicer, more user friendly, and all this is only possible with your help, your ideas and your feedback. So even if you aren’t a Perl expert, there is a lot of place for everyone (you  can do a lot with HTML + JS + CSS only, think about the User Interface!). If you are not sure about how to contribute or help, feel free to join us on IRC in the #bugzilla channel. There is always someone around to answer your questions. :)

February 22, 2012 11:50 PM

February 01, 2012

Frédéric Buclin

Bugzilla 4.2rc2, 4.0.4, 3.6.8 and 3.4.14 released

We released Bugzilla 4.2rc2, 4.0.4, 3.6.8 and 3.4.14 a few minutes ago. They all contain various security fixes which are described in the Security Advisory. 4.2rc2 should be our last release candidate before 4.2 final, which we expect to release in the 2nd half of February. On the other end, 3.4.14 is very likely our last release for the 3.4 branch. Once 4.2 final is released, we won’t support 3.4 any longer. This means that admins still running 3.4.x or older are highly encouraged to upgrade. Users should pester their admins to upgrade if they don’t do it themselves. ;)

Now is a good time to explain (again) why upgrading is not only about getting new features and bug fixes, but also to keep your installation secure. Below are some security fixes and/or enhancements made to various releases:

X-XSS-Protection header

Since Bugzilla 4.4, the X-XSS-Protection header is used to block simple XSS attacks.

CSRF vulnerabilities in attachment.cgi and post_bug.cgi

Till recently, no token check was done before accepting new bug submissions or before uploading an attachment to an existing bug. The rationale behind this was that in older versions of Bugzilla there was no easy way to do it from the WebServices API, and we didn’t want to break existing 3rd-party tools which were legitimately interacting with Bugzilla. As the lack of token validation could be used by attackers to submit unwanted new bugs or attachments, it has been decided that a token was required in these cases too, and not only when updating a bug or an attachment. But to not break 3rd-party tools, these token checks have been implemented in Bugzilla 4.2 only, meaning that Bugzilla 4.0 and older are still vulnerable to these attacks. If you want your installation to be protected against this kind of vulnerabilities, upgrade to 4.2!

Configurable password complexity for user accounts

Bugzilla 4.2 has a new parameter which lets admins decide how complex a password must be to be accepted by Bugzilla. Up to 4.0, Bugzilla accepted all passwords which were long enough (min 6 characters by default). Now you can enforce the complexity: uppercase + lowercase characters, letters + numbers, etc… If you want this feature, upgrade to 4.2!

Clickjacking in attachments with the text/html MIME type

As Bugzilla accepts all attachments independently of their MIME type, it was possible to attach HTML files which could try to abuse users using a method known as clickjacking. To prevent this, the "Details" page of attachments now display the source code of these HTML files instead of rendering them. This security enhancement has been implemented in Bugzilla 4.0.4 and newer (including 4.2). If you want it, upgrade!

X-Frame-Options: sameorigin header

Since Bugzilla 4.0, the X-Frame-Options: SAMEORIGIN header is sent for all pages (besides attachments when delivered from their alternate host). This prevents to load a Bugzilla page from within a frame outside Bugzilla itself. This, combined with the clickjacking protection above, prevents an attacker to create an HTML page with malicious code in it to force a user to make undesired changes to Bugzilla. If you want this, upgrade!

Strict-Transport-Security (STS) header

Since Bugzilla 4.0, a new parameter lets admins enable the Strict-Transport-Security header to force the communication between Bugzilla and the user to be made over SSL only. This prevents data to be sent unencrypted.

X-Content-Type-Options: nosniff header

To prevent Internet Explorer 8 and newer from sniffing the content of attachments, Bugzilla 4.0 and newer now pass the X-Content-Type-Options: nosniff header to avoid some malicious attachments to be rendered as HTML files.

Lockout policy to prevent brute force

Since Bugzilla 3.6, if you try to guess someone else’s password and you fail 5 consecutive times, your IP is blocked for the next 30 minutes. If you still run Bugzilla 3.4 or older, Bugzilla will accept all your attempts to crack the victim’s password, severely increasing the risk that the attacker manages to do it.

And much more…

Those of you who are still running very old versions of Bugzilla (older than 3.2) don’t have their login cookies protected against JavaScript as they don’t have the HttpOnly attribute set. This means a malicious HTML page could steal your login cookies very easily and they could then be used to impersonate your user account. These same cookies also do not have the Secure attribute set which prevents them to be transmitted on unsecure connections. And last but not least, tokens used by Bugzilla 3.2.9 and older are not generated using a cryptographically secure pseudorandom number generator. This means that with some effort, your installation could be abused by an attacker who managed to guess how tokens are generated in your installation.

Now I think you know enough about security features implemented in Bugzilla to decide what you want to do. If security matters to you, you should upgrade to at least Bugzilla 4.0.4, and seriously plan to upgrade to 4.2 once it’s released later this month.

February 01, 2012 01:40 AM

January 29, 2012

Frédéric Buclin

Google+ est maintenant accessible au moins de 18 ans

L’âge minimum pour posséder un compte sur Google+ a été abaissé par Google! Alors qu’il fallait auparavant être âgé d’au moins 18 ans, cette limite a été abaissée à 13 ans (sauf pour l’Espagne et la Corée du Sud: 14 ans, ainsi que les Pays-Bas: 16 ans). Cette limite d’âge est donc maintenant la même que pour Facebook et Twitter. Il y a fort à parier que cela va faire exploser le nombre de comptes Google+ dans les semaines à venir. Reste à savoir si cela sera suffisant pour concurrencer Facebook et ses 800 millions d’utilisateurs.

January 29, 2012 07:48 PM

January 05, 2012

Byron Jones source

there’s been a few questions recently regarding the location of the source which runs

you can find it at – we’re currently running the 4.0 branch.

timeless has pointed mxr-test to the bmo source:

Filed under: bmo, bugzilla, mozilla

January 05, 2012 03:17 PM

December 29, 2011

Frédéric Buclin

Bugzilla 4.2rc1 and 4.0.3 released

After a very long delay due to some nasty blockers, we finally released Bugzilla 4.2rc1 last night! Just to name a few new features or improvements:

Read the complete Release Notes to discover other new features or improvements. As it’s still a release candidate, do not forget to report any regression or broken feature to us, so that we can investigate and fix them before 4.2 final.

IMPORTANT NOTE FOR ORACLE USERS: There is still a bug when upgrading to 4.2rc1 using Oracle. Make sure to apply the patch from bug 715870 before upgrading! This patch will be in 4.2 final (or 4.2rc2, if there is one).

We also released Bugzilla 4.0.3, which is our current stable release, and Bugzilla 3.6.7 and 3.4.13. All these releases contain two security fixes. Bugzilla 4.2rc1 also has some security improvements which have not been backported to stable branches to not break 3rd-party applications.

With the coming release of Bugzilla 4.2, the 3.4.x series will reach End Of Life, meaning that no more security fixes will be released for this series. If you have Bugzilla 3.4.x or older, you are highly encouraged to upgrade to Bugzilla 4.2rc1 or 4.0.3.

December 29, 2011 10:30 AM

November 29, 2011

Bugzilla Tips

User Menu

(If you have tips to share on using Bugzilla, please email them to

Mozilla’s Bugzilla now has a left-click menu whenever you see a user displayed. You can email the user (which was the previous left-click action, or see what they’ve been up to in Bugzilla recently on the Activity screen. Administrators can also jump straight to editing that user’s account.

November 29, 2011 11:59 AM

November 14, 2011

Frédéric Buclin

Bugzilla page on Google+

I just created an "official" Bugzilla page on Google+: Feel free to look at it from time to time to get the latest news about the Bugzilla development.

November 14, 2011 05:02 PM

October 11, 2011

Frédéric Buclin

Another website compromised… who is next?

A few weeks ago, was compromised. Today, it’s the turn of with all its credentials stolen (email addresses and encrypted passwords). Who is next?

Note: I won’t give any price to the winner.

October 11, 2011 08:52 PM

August 23, 2011

Byron Jones

bugzilla inline history extension

Unlike most bug tracking systems, Bugzilla doesn’t display changes made to fields when it displays the comments.  This has been a often requested feature, and is currently targeted for Bugzilla version 5.0.  For some time the Bugzilla Tweaks Firefox add-on has provided this functionality to, and it’s working well for those who have discovered this add-on.

Using the Tweaks implementation as a guide, I have implemented an Inline History Bugzilla extension:

This extension has just been deployed to BMO and is currently disabled by default.  To enable you have to be logged in, then go your User Preferences, and set When viewing a bug, show all bug activity to on.

Once we’re happy with it it will be enabled by default for all logged-in users.  [Edit: Now enabled by default]

The latest version of Bugzilla Tweaks (v1.11) will detect when this Bugzilla extension is active, and will disable its inline history implementation.  The option to disable the extension will always be available should someone perfer Bugzilla Tweaks’ formatting over the extension’s.

Filed under: bmo, bugzilla, bugzilla tweaks, mozilla

August 23, 2011 08:30 AM

August 11, 2011

Frédéric Buclin

Compile DBD::Oracle with Oracle 10g XE + Bugzilla

If you are like me and want to compile DBD::Oracle to use with Bugzilla and your installation of Oracle 10g XE, simply type the following command from the bugzilla/ root directory:
./ DBD::Oracle

Of course, you must have installed oracle-xe-univ- already. This should save you a few headaches to make it work. :)

August 11, 2011 12:37 AM

August 05, 2011

Frédéric Buclin

Bugzilla 4.1.3, 4.0.2, 3.6.6 and 3.4.12 released

More than 3 months after our last releases, we finally released Bugzilla 4.1.3, 4.0.2, 3.6.6 and 3.4.12 last night. Bugzilla 3.6.6 and 3.4.12 are security releases for our old supported branches. Bugzilla 4.0.2 contains security fixes and several useful bug fixes, including:

I strongly recommend to upgrade to 4.0.2, which is much more stable and usable than 4.0 or 4.0.1!

And for those who love to live dangerously, we also released Bugzilla 4.1.3, our lastest development snapshot. It contains all the security and bug fixes mentioned above. As we don’t accept any new features for Bugzilla 4.2 since we released 4.1.2, we focused on fixing regressions and other nasty bugs. Bugzilla 4.1.3 should be much more usable than 4.1.2, even if it’s not production-quality yet. Depending on how things go and the feedback we get, this could be the last development snapshot before 4.2rc1. Note that once Bugzilla 4.2 is released (probably near the end of this year), Bugzilla 3.4 will reach End Of Life and we won’t support this branch anymore.

August 05, 2011 11:12 AM

June 08, 2011

Frédéric Buclin

Latest news about Bugzilla 4.0.2, 4.2rc1 and 5.0

We had another Bugzilla meeting on IRC yesterday (channel log), and the three topics were about Bugzilla 4.0.2, 4.2rc1 and about Bugzilla 5.0. So I’m going to give you a brief summary of what has been discussed.

Bugzilla 4.0.2

We still have a few blockers for 4.0.2. Due to security bugs being under investigation, we are probably going to release Bugzilla 4.0.2, 4.1.3, 3.6.6 and 3.4.12 before we branch for 4.2rc1. ETA: asap (I cannot be more precise as it all depends on our free time, as we are all volunteers; but this should be done in the coming few days or weeks)!

Bugzilla 4.2rc1

The list of blockers for 4.2rc1 is pretty large. Fortunately, they all have a developer assigned to them, and so we can expect some activity there, at least once the security releases mentioned above are out. ETA: several weeks, maybe July?

Bugzilla 5.0

What will come after Bugzilla 4.2 depends on the progress made to redo the UI of Bugzilla, especially about show_bug.cgi, see bug 662605. Once the new UI is complete, we will call Bugzilla 5.0. Meanwhile, we will release Bugzilla 4.4, 4.6, … till the new UI (which is developed in its own branch) is merged with the main tree. Besides the new UI, we defined some main goals for the next release (independently of its version being 4.4 or 5.0), and we will try to fix as many of them during the next development cycle. As major Bugzilla releases are time-based, instead of feature-based, probably not all these enhancements will be implemented on time for the next release. If there is one you really cannot live without, feel free to join us and help implement them. New contributors are always welcome! ;)

June 08, 2011 08:30 PM

May 17, 2011

Frédéric Buclin

Excel, OpenOffice, LibreOffice, or when developers think rules do not apply to them

Before programming, programmers usually go to school at least till the age of 16 (and then there is also high school and university for some of them). During the secondary school, pupils all learn the order of operations in mathematics. In particular, they all learn that -4^2 = -16, because exponents always take precedence over +, -, * and /. There is no exception to this rule, except in the world of spreadsheets, including Excel, OpenOffice and LibreOffice. Here, there are some developers (I hope not all of them) who either never went to school, or preferred to sleep during maths classes. Why? Because in their world, -4^2 = 16. Arghh! In the world of spreadsheets, only Gnumeric developers seem to have gone to school and remember what their maths teachers told them, and Gnumeric works just fine. Oh, and guess what? Scientific tools like Gnuplot and Mathematica also return -16, as well as Perl and Python and probably mostly everything else which exists in the world.

But when you report this bug to the OpenOffice (see also here) and LibreOffice Bugzilla installations, you are considered as being completely dumb:

OpenOffice bug 24271 comment 1:

"you're wrong. The function works according to the
 mathematical rules.

 -4^2 is -4*-4 or 16"

OpenOffice bug 24271 comment 27:

"Result of input '=-2^4' can't be anything else than (-2)^4!
 Here the '-' can't be anything else than an algebraic sign,
 interpretation as a subtraction operator for  '-(2^4) is
 completely useless like a mathematical expression '/3'"

LibreOffice bug 37271 comment 1:

"Imho LibO "intuitively" correctly recognizes the difference
 between a "Sign of a number" ant the subtraction operator. 

 I disagree with reporter's interpretation. [...]
 Please provide information concerning public available
 mathematical sources supporting your thesis."

These last two comments are from the same developer (one who definitely never went to school). The OpenOffice bug has been marked as INVALID, and the LibreOffice bug has been marked as NOTABUG (a synonym but more polite bug resolution to say INVALID). It’s just unacceptable that developers intentionally ignore mathematicals rules which are universally accepted across the whole world, and decide to reimplement their own rules, and then treat users who are totally right as if they said that 1+1=3. A more respectful (but still unsatisfying) bug resolution would have been WONTFIX with the comment that the reporters of the bugs are right, but due to the way Excel works, and for compatibility reasons with Excel, they are forced to do this incorrect statement that -X^2 = (-X)^2. Also, the helper assistant should pop up and warn the user about this misbehavior.

I hope the developers who wrote these comments above are not the ones who write the core code of OpenOffice/LibreOffice! Else I wouldn’t be surprised to discover that 1+1=3 is finally correct too. :)

May 17, 2011 07:09 PM

May 09, 2011

Bugzilla Tips

Change Your Bugzilla Email

Just changed email address?

Unlike many sites, it is possible in Bugzilla to change your login name/username/email address. I can be done in the Preferences, on the Email Preferences tab, with the box marked “New Email Address”.

This is much preferred to creating a new account and then trying to migrate all of your CCs and watchlists, or realising you did the wrong thing and asking an admin to ‘merge’ the accounts. If you have created a new account for your new address but not really used it yet, and want to “undo” your mistake, change the address for the new account to something throwaway, and then change the address for the old account to your new real email address. If you have used both accounts significantly, you’ll have to ask the admins to do a merge. Not all Bugzilla admins may be able to do this, as it’s not a supported feature of the software with a UI.

May 09, 2011 07:48 PM

May 04, 2011

David Miller

The hardware behind

I recently did up a diagram of how our Bugzilla site was set up, mostly for the benefit of other sysadmins trying to find the various pieces of it.  Several folks expressed interest in sharing it with the community just to show an example of how we were set up.  So I cleaned it up a little, and here it is:

Bugzilla Physical Layout Diagram

Click the image for a full-size (readable) version

At first glance it looks somewhat excessive just for a Bugzilla, but since the Mozilla Project lives and dies by the content of this site, all work pretty much stops if it doesn’t work, so it’s one of our highest-priority sites to keep operating at all times for developer support.  The actual hardware required to run the site at full capacity for the amount of users we get hitting it is a little less than half of what’s shown in the diagram.

We have the entire site set up in two different datacenters (SJC1 is our San Jose datacenter, PHX1 is our Phoenix datacenter).  Thanks to the load balancers taking care of the cross-datacenter connections for the master databases, it’s actually possible to run it from both sites concurrently to split the load.  But because of the amount of traffic Bugzilla does to the master databases, and the latency in connection setup over that distance, it’s a little bit slow from whichever datacenter isn’t currently hosting the master, so we’ve been trying to keep DNS pointed at just one of them to keep it speedy.

This still works great as a hot failover, though, which got tested in action this last Sunday when we had a system board failure on the master database server in Phoenix.  Failing the entire site over to San Jose took only minutes, and the tech from HP showed up to swap the system board 4 hours later.  The fun part was that I had only finished setting up this hot failover setup about a week prior, so the timing couldn’t have been any better for that system board failure.  If it had happened any sooner we might have been down for a long time waiting for the server to get fixed.

When everything is operational, we’re trying to keep it primarily hosted in Phoenix.  As you can see in the diagram, the database servers in Phoenix are using solid-state disks for the database storage. The speed improvement when running large queries that is gained by using these instead of traditional spinning disks is just amazing.  I haven’t done any actual timing to get hard facts on that, but the difference is large enough that you can easily notice it just from using the site.

May 04, 2011 06:40 PM

Bugzilla Tips

Search Bugzilla Using Google

For Bugzillas with the Sitemap extension, which now includes, you can search Bugzilla using Google, with

May 04, 2011 04:39 PM

April 01, 2011

Bugzilla Update

Winner of the “Make Bugzilla Pretty” Contest

All the votes are in for the “Make Bugzilla Pretty” contest, and we have a winner!

First off, let me say that every single entry was amazing. Every single person who entered had innovative ideas, and nearly every entry was prettier than our current UI.

There were four candidates who were mentioned in some positive way by almost every voter:

Any of these designers would be a worthwhile addition to any UX team anywhere. Simply the ability to take Bugzilla’s existing UI and turn it into something that nearly everybody finds attractive is an accomplishment that few designers could achieve. In the 13 years of Bugzilla’s history, I’ve never seen it done before these entries. I would be personally happy to write a recommendation for any of the above designers, and they may contact me for that if they wish.

Let’s just say a few words about each of these designs:

Alex Faaborg

There were a ton of positive comments on the usability aspects and organization of Alex Faaborg’s [Bracket] theme, particularly some of the new fields suggested and the brilliant use of color to improve the scanability of the page. It was impressive that everything on the page is basically text or lines, and yet it creates a very readable, clean, simple layout.

We expect future versions of Bugzilla to draw a lot on the usability concepts present in Faaborg’s design, even though it is not the first-place winner.

Zeeshan Syed

There were a lot of positive comments on the use of space in Zeeshan Syed’s design. The color contrast really makes things readable, the tab navigation is very clear, and the section titles really stand out.

Long Duong

Voters were almost overwhelmingly positive about Long Duong’s design. Many people mentioned that they liked the clean lines and very “Bugzilla” feel of the bug page, and that the collapsible sections were a great touch while still being visually appealing. There was also a lot of positive feedback about the header design–people really loved its organization and style. Finally, the home page design was just really cool.

Based on the number of votes and the general amount of positive feedback, Duong is our first runner-up for the Make Bugzilla Pretty contest, and it is very likely that we will end up incorporating some of his UI concepts into our final design.

Jonathan Wilde

This was a stiff competition, and all of the above designs would have worked great as our new UI. However, the winner of the “Make Bugzilla Pretty” contest, and indeed the recipient of the majority of votes, is Jonathan Wilde:

Jonathan’s ability to convert our UI into something beautiful and simple that even new users will find approachable is beyond anything that we had ever imagined could be done with Bugzilla. We are thrilled that Jonathan has won, and excited to implement his design as the official UI of Bugzilla 5.0.

Thanks to Everybody

We would like to thank everybody who entered. Your entries made this contest a fascinating and transformative experience for the Bugzilla Project. We were consistently amazed at the creativity, intelligence, and design sense that so many of you displayed, and wish you great fortune in the future of your careers.


April 01, 2011 01:18 AM

March 31, 2011

Frédéric Buclin

From Bugzilla 2.18 to 4.0 and beyond

Since the release of Bugzilla 4.0 in mid-February, you may have noticed that I strongly reduced my involvement in the Bugzilla project. There are several reasons for this decision:

I think now is a good time to see how much I contributed to the project in these last 7 years, and what I achieved during this time. As I was checking this myself today, I thought you may be curious to know what were my main contributions, and so I decided to share the list below. Note that I fixed 1224 bugs in the Bugzilla product, so I’m not going to list them all. Only the outstanding bug fixes and new features are listed below, ordered by release versions:

Bugzilla 2.16 – 4.0

34 security bugs, across all versions.

Bugzilla 2.18

Bug 206037: There were many places where user data was incorrectly filtered before being displayed in the web browser, which could potentially lead to XSS or break pages entirely. This was a pain to fix all these places, and I had no fun in doing this, but it was necessary to really protect our users.

Other contributions for this release were all bug fixes as Bugzilla 2.18 was already feature frozen when I joined the project.

Bugzilla 2.20

Bug 180879: Till now, everybody could edit flags in bugs. I implemented permissions for flags so that admins could decide who would be allowed to request a flag, and who would be allowed to grant and deny them. Mozilla uses this feature heavily e.g. for their blocking and approval flags.

Bug 319055: If a bug comment had a « . » on its own line, the remaining part of the comment was skipped in bugmails.

In this release, I also helped with the cleanup process to remove all these old %FORM, SendSQL() and other oddities which were in Bugzilla 2.x.

Bugzilla 2.22

Bug 46296: Till now, all parameters were listed in a single page, making the page ridiculously long and parameters hard to find. I refactored this into separate panels, grouped by topic. I also did it in a way that parameter descriptions could be localized.

Bug 301508: was a kind of black hole with tons of subroutines in it, to achieve many unrelated goals. With the help of other developers, we moved these subroutines into modules, grouped logically. This was a required cleanup to be able to develop new features without adding additional mess to the code.

Bug 313020: I implemented the ability to tag bugs individually. These tags then appeared as normal saved searches in the footer of pages, so that you could easily list all bugs with the same tag.

I also helped with removing stuff from, another black hole used in previous releases.

Bugzilla 3.0

Bug 38862: In order to protect users from malicious attachments, I implemented the ability to specify an alternate host for attachments. You can even set it to have one different host per bug, to avoid attachments from one bug to interact with attachments from another bug. That’s the configuration used e.g. by Mozilla.

Bug 44595: I implemented the ability for admins to delete attachments, e.g. malicious ones, or because they contain confidential data which wasn’t supposed to be attached to the bug.

Bug 87795: When creating a new user account, you now get a token by email to confirm that your email address is valid, rather than assuming that it’s the case and sending the password by email directly. This also lets you choose your password yourself rather than generating a random one automatically.

Bug 92515: When the resolution on a bug is wrong, you can now change it without having to first reopen the bug. In some other bugs, I also fixed several such annoying two-steps processes which were not needed and irritating.

Bug 94534: I implemented the ability for admins to customize the list of bug resolutions. Admins can add/edit/remove resolutions from the web UI directly instead of having to hack the source code to make it work.

Bug 174039: When filing a new bug, you can set flags at the same time, instead of having to file the bug first and then edit it.

Bug 189627: I implemented the ability to give canconfirm, editbugs and editcomponents privs on a per-product basis so that installations with many distinct products can better separate user privileges (and only give privileges for products they are working on).

Bug 274802: Previously, when you were moving a bug from one product which has some given flag types to another product which has a different set of flag types, all existing flags set to the bug were deleted. Now, if the target product has a flag type with the same name as the original product, Bugzilla migrate the old flag to the new one.

Bug 282121: is now gone. All subroutines have been moved into their respective modules. At this point, we can say that the old and ugly code has been removed from the source code. Bugzilla 3.0 is born!

Bug 287326: I implemented the ability to add custom single-select fields to bugs. This was the second custom field type being implemented, after free text fields.

Bug 317409: I implemented the ability to hide obsolete attachments in bug reports.

Bug 330487: In Bugzilla 2.x, an admin had to manually check if there were new releases of Bugzilla, or at least watch some mailing-list to get this information. Now, Bugzilla can automatically notify admins when a new release is available.

Bug 340426: It was a pain to be forced to scroll to the bottom of the page to access links such as « New », « Search », « Log in », etc… I duplicated these links to the top of the page to avoid this problem.

Bug 344875: I implemented the ability to create and control custom fields from the web UI. Before that, you had to run a script from the shell.

Bug 354661: I created a search plugin for Firefox 2+ and IE 7+.

Bugzilla 3.2

Bug 101179: Till now, bug statuses were hardcoded in the source code. Admins can now add/edit/remove them from the web UI. I also implemented the ability to control which transitions were allowed.

Bug 218618: When viewing a patch, line numbers are now displayed, greatly helping to locate code and changes in files.

Bug 304005: Bugzilla is now able to authenticate against a SMTP server to send bugmails.

Bugzilla 3.4:

Bug 182238: Till now, the timezone used to display the timestamp of comments was controlled by the admin. Now, each user can select the timezone of his choice.

Bugzilla 3.6

Bug 108243: You can now display bug flags in buglists.

Bug 302542: You can now delete series in new charts, either one by one, or when deleting a product.

Bugzilla 4.0

Nothing exciting from me in this release. I spent most of my time fixing regressions and doing QA. I only implemented minor new stuff.

Bugzilla 4.2

Bug 119703: You can now create an attachment simply by pasting text into a text field, instead of being forced to attach a file.

Bug 142394: You can now sort columns in tabular reports.

Bug 466968: I did a major cleanup of the mail-generation code. It’s now much easier to extend and customize it, and bugmails are now fully localizable.

Bug 529974: Users with local editcomponents privs, i.e having such privs for some products only, can now also edit flag types for these products. Before that, you had to ask someone with global editcomponents privs to do changes for you.

As you can see, I hacked many different parts of the Bugzilla code, implementing various major features. Now, I came to the point where I think I implemented most things I considered important, from my point of view. I still have one last new feature which is in progress, which is the ability to identify the sender of an email sent to, see bug 419203. I hope to have this feature ready for 4.2. After that, it’s unclear what my contributions to the project will be, if any. There are two additional features which would be great to see being implemented:

I think those two features together would be great candidates to define what would be called Bugzilla 5.0. But maybe I won’t be around anymore when this happens, as Bugzilla 5.0 isn’t expected before 2012 at the earliest (Bugzilla 4.2 will be released at the end of 2011, and I suppose there will be a 4.4 before 5.0).

March 31, 2011 11:23 PM

March 04, 2011

Frédéric Buclin

Debian takes security very seriously… but how?

On, I can read:

« Debian takes security very seriously. We handle all security problems brought to our attention and ensure that they are corrected within a reasonable timeframe. »

By default, there is no reason to not believe them. But while talking with the administrator of Samba Bugzilla in bug 7121, I realized this was far from being true! What follows is specific to the Bugzilla case, but I guess there are plenty of other similar examples for other Debian packages.

This security report set the urgency to « High », and despite the corresponding bug report has been reported to Debian more than a month ago asking the maintainer of the Bugzilla package to release new versions, nothing has been done so far. Even Secunia marked this security issue as « moderately critical », which is the third level out of five. And I myself emailed the Bugzilla package maintainer at Debian a few days ago, but got no response so far.

So my question is this: how can Debian honestly argue that they take security very seriously? It looks like it takes ages to get something done, which is usually not a big deal when talking about new features, but is definitely a problem when talking about security.

I wanted to know if there were other older unpatched security bugs relative to Bugzilla packages, and I’m a bit irritated to see that there are many! Some of them are two years old! Yes, very seriously!

Bugzilla developers at Mozilla are in no way in charge to maintain these packages, neither for Debian, nor Fedora, nor Mandriva nor any other Linux distro, so we have no control at all on that. And people often come on IRC asking us for help, because their Bugzilla package provided with their Linux distro is broken or behaves in a weird way (typically a broken configuration or customization). And guess what? Most of the time, they use the Debian package. Yes, very seriously! For comparison, Fedora updated their Bugzilla packages the day after we released 3.6.4, and Mandriva the week after! It looks like they take security a bit more seriously.

March 04, 2011 03:30 PM

February 15, 2011

Frédéric Buclin

Stable Bugzilla 4.0 released

We released Bugzilla 4.0 a few minutes ago! It has many new features and improvements compared to Bugzilla 3.x, and comes almost 4 years after Bugzilla 3.0 (which was released in May 2007). With this major release, Bugzilla 3.2 reached End Of Life (EOL) and is now unsupported. Everybody running a version older than 3.4.10 should upgrade to 4.0 to get future security and stability fixes.

Bugzilla 4.0 got full testing from the QA team, and should be considered stable:

All tests successful.
Files=55, Tests=11621, 2473 wallclock secs ( 1.86 usr  0.23 sys + 21.95 cusr  1.66 csys = 25.70 CPU)
Result: PASS

Enjoy! :)


Update: If you get the error “ExpiresActive not allowed” from Apache when upgrading to Bugzilla 4.0, edit your Apache config file httpd.conf as explained in the Bugzilla documentation. Till now, you probably had:

<Directory /var/www/html/bugzilla>
  AllowOverride Limit

Now the AllowOverride command must be:

  AllowOverride Limit FileInfo Indexes

in order to force the web browser to update its cache with newer CSS and JS files when they change (e.g. when upgrading to a newer release in some months). If Bugzilla 4.0 is working fine without this change, then this means that you either don’t use mod_cgi, or this feature is not enabled in your Apache server.

Update 2: Contrary to what Samuel Gibbs said in his post, we are not dropping support for all versions of Bugzilla 3. As I said above, only support for Bugzilla 3.2 and older is dropped. This means that Bugzilla 3.4 and 3.6 are still supported, at least till the end of the year.

Update 3: Bugzilla 4.2 should be released at the end of this year, if everything goes well.

February 15, 2011 07:21 PM

January 27, 2011

Bugzilla Update

Deadline Approaching for the “Make Bugzilla Pretty” Contest

Hey there, user experience designers! Our deadline for the Make Bugzilla Pretty contest is coming up pretty soon, on February 28. If you were thinking about submitting an entry, now would definitely be the time to start working on it. You have a pretty good chance of winning, becoming famous, and changing the world for all the developers who use Bugzilla!


January 27, 2011 01:39 PM