Planet Bugzilla

August 13, 2015

Byron Jones

happy bmo push day!

the following changes have been pushed to bugzilla.mozilla.org:

discuss these changes on mozilla.tools.bmo.


Filed under: bugzilla

August 13, 2015 06:27 AM

August 07, 2015

Bugzilla Tips

New Modal UI for show_bug on BMO

For the past few months, a new experimental modal bug view has been available on bugzilla.mozilla.org. This hides a lot of complexity both through being read-only initially, and also through having expandable and collapsible sections. It is also quicker and less resource-intensive to load. It requires you to click an “Edit” button, which reveals much more UI, when you want to do more than the common operations – add a comment, CC/NI people, or change the Status or Resolution. It is also more dynamic – for example, there are no more interstital pages when moving bugs between Products, because when you change the Product, the new lists of Components, Milestones etc. load into the widgets automatically.

A picture is worth a thousand words. Here’s the initial view:

new-bug-ui

And here’s the Edit view:

new-bug-view-2

You can enable it in the Preferences – change “Use experimental user interface” to “On”.

Thanks to glob for doing the hard work on making this happen. This view has not yet made it upstream to Bugzilla itself.


August 07, 2015 02:35 PM

July 30, 2015

Bugzilla Update

Bugzilla 4.2 will be EOL on 2015/11/30

As discussed on the Bugzilla developers mailing list/newsgroup and confirmed by project leads, Bugzilla’s new release policy is to end-of-life the oldest supported major version four months after a new major release. Since this is the first time we’re enacting this policy, we’ve extended the date to be 4 months from today rather than from Bugzilla 5.0’s exact release date (July 7th).

Thus Bugzilla 4.2 will be end-of-lifed on 30 November 2015. This means no fixes of any kind will be issued for Bugzilla 4.2 from that date onwards. As usual, all Bugzilla admins are encouraged to upgrade to the latest version of Bugzilla as soon as possible, especially those running 4.2 or earlier.

To expand a bit further on our new EOL process, after a new major release, we will support three major releases (including the new one) for four months.  After four months, we will drop support for the oldest one.  We will continue to support the remaining two until four months after the next release.

For example, currently we support 4.2, 4.4, and 5.0.  In four months’ time we will drop support for 4.2 and support only 4.4 and 5.0.  When the next major version comes out, perhaps 5.2*, we will support 4.4, 5.0, and 5.2.  Four months later, we will drop support for 4.4 and support only 5.0 and 5.2.

Mark Côté
Assistant Project Lead, Bugzilla

* It may be 6.0 if there are major and/or breaking changes.


July 30, 2015 06:13 AM

July 07, 2015

Bugzilla Update

Release of Bugzilla 5.0

Today the Bugzilla Project is extremely proud to announce the release of Bugzilla 5.0!

It has been slightly over two years since we released Bugzilla 4.4 on May 2013. This new major release comes with many new features and improvements to WebServices and performance.

We hope that you enjoy and appreciate the results of the past two years of hard work by our entirely-volunteer community.

EOL for 4.0.x

Please note that the release of Bugzilla 5.0 also marks End Of Life for the Bugzilla 4.0 series, meaning that there will be no further updates for the 4.0.x series, even if there are serious security
issues found in that series. We recommend that all installations running the 4.0 series upgrade as soon as possible to 5.0.


July 07, 2015 09:20 PM

April 21, 2015

Bugzilla Update

VCS updates: bzr moving, cvs ending

At the Bugzilla project meeting on 2015-03-25 the project lead and assistant leads agreed on two major changes to Bugzilla’s source-code hosting:
  1. CVS support is officially dropped as of now. 4.0 is the last version that was released on CVS, and it will be EOLed when 5.0 comes out (very soon; rc3 was just released). In the event of a release on the 4.0 branch before it is EOLed, any Bugzilla installations that have not migrated to bzr or git will have to apply patches to upgrade, which will continue to be distributed as usual. Bugzilla site admins are strongly encouraged to migrate to pulling from git.mozilla.org as soon as possible.
  2. Bazaar hosting has been officially switched from bzr.mozilla.org to bzr.bugzilla.org. bzr.bugzilla.org is already active and syncing changes from git.mozilla.org. bzr.mozilla.org is no longer syncing changes and will soon be shut down. Any sites upgrading from bzr.mozilla.org must do one of the following to apply any future upgrades, in order of preference:

bzr.bugzilla.org will continue to mirror changes from git.mozilla.org for the 4.0, 4.2, and 4.4 branches as long as they are supported. Note that, at the moment, master/trunk is being mirrored as well, but no other branches, including and subsequent to 5.0, will be mirrored to bzr.bugzilla.org, and trunk mirroring may cease at any time.

Note that bzr.bugzilla.org is waiting on a proper certificate; please use plain http until this is resolved.

The Bugzilla team apologizes for any inconvenience. Please see our support options if you have trouble migrating.

Mark Côté
Assistant Project Lead, Bugzilla


April 21, 2015 09:13 PM

April 15, 2015

Bugzilla Update

Release of Bugzilla 5.0rc3, 4.4.9, 4.2.14, and 4.0.18

Today we have several new releases for you!

Bugzilla 5.0rc3 is our third Release Candidate for Bugzilla 5.0. 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 5.0 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.4.9 is our latest stable release. It contains various useful bug fixes:

Bugzilla 4.2.14 is a bugfix update for the 4.2 branch:

Bugzilla 4.0.18 is a bugfix update for the 4.0 branch:


April 15, 2015 08:22 PM

April 14, 2015

Byron Jones

changing the default platform and operating-system on bugzilla.mozilla.org to all / all

bugzilla has a set of fields, “hardware” and “operating system”, that i’ll collectively call “platform” in this post.  their default values are detected from the reporter’s user-agent string when a bug is created.

unfortunately on bmo, the platform fields have two distinctly different meanings: the reporter’s platform and the platform a bug applies to. for too long have these two conflicting meanings coexisted within the same field, leading to confusion and a field that on many bugs is wrong or useless.

thanks to bug 579089 we plan on making the following changes early next week:


Filed under: bugzilla

April 14, 2015 03:19 PM

February 18, 2015

Gervase Markham

R.I.P. api-dev.bugzilla.mozilla.org

Complaining about bugzilla.mozilla.org (BMO) is a Mozilla project activity as old as the hills. Back in 2009, it was realised by the Foundation that to make everyone happy was (and still is) an impossible task, and I was given a mandate to “help people solve their own problems”. So around September 2009, I released the first version of my Bugzilla API proxy software, BzAPI. This software presented a clean, well-documented RESTful interface on the front end, and did all sorts of things on the back end (XML, CSV, RPC, HTML scraping) that developers no longer had to worry about. We made a dev server VM for it so people could try it out – api-dev.bugzilla.mozilla.org.

It was popular. Extremely popular. People started building things, and then more things, all of which depended on this server for Bugzilla data. For various reasons, IT never got around to building a production instance, and so over the last five years, I’ve been maintaining this core piece of Mozilla project infrastructure, which was depended on by TBPL and many, many other tools which interfaced with Bugzilla. At its peak, it serviced 400,000 requests per day.

Over the intervening years, BMO itself acquired a REST API which slowly became more capable, and then a BzAPI-compatible API shim was implemented on top of it by the excellent dkl, so people could change their code to access BMO directly just by updating the endpoint URL. After a few false starts, requests to api-dev.bugzilla.mozilla.org are now served directly by BMO, via that shim code. Earlier today, the api-dev VM was finally powered down.

Here’s to you, api-dev. Good job.

February 18, 2015 04:04 PM

Bugzilla Tips

Bugzilla Has New Documentation

The Bugzilla team recently finished a big project to update, rewrite, improve and centralize Bugzilla’s documentation. You can find it at http://bugzilla.readthedocs.org/. In particular, there’s a User Guide which will be useful to, er, Bugzilla users.

If you have suggestions for further improvements to the documentation, please let the team know.


February 18, 2015 02:36 PM

January 27, 2015

Bugzilla Update

Release of Bugzilla 5.0rc2, 4.4.8, 4.2.13, and 4.0.17

Sorry for the new release so soon, but we found a regression in the release last week and felt it would be best to get the fix out now rather than wait.

Bugzilla 5.0rc2 is our second Release Candidate for Bugzilla 5.0. This release has receive 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 5.0 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.4.8 is our latest stable release. It contains an important bug fix:

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

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


January 27, 2015 08:23 PM

January 21, 2015

Bugzilla Update

Release of Bugzilla 4.4.7, 4.2.12, 4.0.16, and 5.0rc1

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 5.0rc1 is our first Release Candidate for Bugzilla 5.0. 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 5.0 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.4.7 is our latest stable release. It contains various useful bug fixes and security improvements:

Bugzilla 4.2.12 is a security and bugfix update for the 4.2 branch:

Bugzilla 4.0.16 is a security and bugfix update for the 4.0 branch:


January 21, 2015 11:00 PM

January 19, 2015

Mark Côté

BMO 2014 Statistics

Everyone loves statistics! Right? Right? Hello?

tap tap

feedback screech

Well anyway, here are some numbers from BMO in 2014:

BMO Usage:

33 243 new users registered
45 628 users logged in
23 063 users performed an action
160 586 new bugs filed
138 127 bugs resolved
100 194 patches attached

BMO Development:

1 325 bugs filed
1 214 bugs resolved

Conclusion: there are a lot of dedicated Mozillians out there!

January 19, 2015 01:09 AM

January 08, 2015

Byron Jones

changing the face of bugzilla.mozilla.org

background

bugzilla.mozilla.org presents some interesting problems when it comes to UX; while it has a singular view of bug data, most teams use bugzilla in slightly different ways.  some of these differences surface in fields used to track work (keywords, flags, whiteboard, summary), how bugs are prioritised (whiteboard, custom fields, priority fields), and even how inter-bug dependancies are tracked.

the net result is trying to design an user interface for viewing bugs optimised for how people use bugzilla is a near impossible task.  in light of this, we’ve been working on a framework which allows us to deploy multiple experimental alternative view of bugs.

goals

the goals are to enable alternative bug views in a way which enables rapid development and doesn’t force incomplete or broken implementations upon users.

implemented as a bugzilla extension, alternativeUI provides a harness for alternative bug views, and implements the view selection – currently as a simple user preference.  in the future we expect bugzilla to be able to automatically change view depending on the bug or your relationship to it.  for example, we could present a slightly (or radically!) different view of a bug to the assignee vs. the reviewer vs. someone not involved in the bug.

generic show_bug alternative

of course a framework for alternative bug views would be useless without an actual alternative.  i’ve been working on one which will likely be the basis of future experiments.  show/edit modality is at the core of this design — a bug is loaded with most fields as static text and switching to “edit mode” is required to make changes.

ideas we’re throwing around:

hiding fields

if a field doesn’t have a value set there’s no need for that field to be displayed by default.  removing those fields from the initial display greatly reduces the noise and complexity generally associated with bugzilla.

we can also use the user’s group membership or involvement in the bug as a cue to which data should be initially visible.  an example would be hiding the QE flags from users who are not associated with the bug or members of a the QE team.

performance

when a bug is loaded right now in bugzilla, it has to load all the alternatives for many fields (products, components, versions, milestones, flags, …).  in most cases bugzilla’s fine-grained security model results in a measurable cost to generating these alternatives — you can see the difference yourself by logging out of bugzilla or opening a bug in a private tab and comparing the page load times against a logged-in request.

by loading a bug as read-only initially, we can defer loading the alternatives until after the user clicks on ‘edit’.

selected “editable by default”

requiring a mode switch to perform any change to a bug isn’t an ideal situation either – operations that are frequently performed should be easy to do with minimal extraneous steps.

the current implementation allows you to comment, CC, or vote for a bug without switching to edit mode.  this can be extended to, for example, allow the bug’s assignee to change a bug’s status/resolution without needing to switch to edit mode.

screenshots

bmo-modal-1

bmo-modal-2


Filed under: bmo, bugzilla, mozilla

January 08, 2015 02:46 AM

January 07, 2015

Mark Côté

BMO 2014 update part II

The second half of 2014 was spent finishing up some performance work and shifting into usability improvements, which will continue into 2015.

More performance!

By the end of 2014, we’d managed to pick most of the low-to-medium-hanging fruit in the world of Bugzilla server-side performance. The result is approximately doubling the performance of authenticated bug views. Here are graphs from January 2014 and October 2014:

The server now also minifies and concatenates JavaScript and CSS files. This affects cold loads mostly, since these files are cached, but even on reload it saves a few round trips.

As mentioned above, we’re shifting focus away from performance work and towards usability/work-flow improvements, but there will still be perf benefits, both by reducing and delaying loading of content and by making it easier for users to accomplish common tasks.

New, better documentation

We’ve converted the upstream Bugzilla documentation to reStructuredText, massively updated and reorganized it, and, perhaps of most interest to anyone reading this, completely rewrote the API docs, which were very hard to grok.

For BMO specifically, we’ve fixed up the wiki page. We’ve also started a user guide, but it’s just a skeleton at the moment. There are lots of users out there who know the ins and outs of BMO, so feel free to contribute a section!

GMail support

To support Mozilla’s transition to GMail, we added two features. First, we now limit the number of emails sent to a user per minute and per hour, since GMail will temporarily disable accounts that receive too much mail, and some BMO users receive a lot of bugmail. Second, since GMail’s ability to filter mail by headers is limited compared to other email servers, users can now include the X-Bugzilla-* headers in the body via General Preferences.

Other things

2015!

As I’ve said a few times now, in 2015 we’re going to do a lot of work on improving general BMO-user productivity: usability, UX, work flows, whatever you want to call it. I’ll write more about this later, but here are a few things we’re looking into:

As usual, if you have questions or comments, you can leave them here, but an even better place is the mozilla.tools.bmo mailing list, also available as a Google Group and via NNTP.

January 07, 2015 07:31 PM

December 17, 2014

Mark Côté

Searching Bugzilla

BMO currently supports five—count ‘em, five—ways to search for bugs. Whenever you have five different ways to perform a similar function, you can be pretty sure the core problem is not well understood. Search has been rated, for good reason, one of the least compelling features of Bugzilla, so the BMO team want to dig in there and make some serious improvements.

At our Portland get-together a couple weeks ago, we talked about putting together a vision for BMO. It’s a tough problem, since BMO is used for so many different things. We did, however, manage to get some clarity around search. Gerv, who has been involved in the Bugzilla project for quite some time, neatly summarized the use cases. People search Bugzilla for only two reasons:

That’s it. The fact that BMO has five different searches, though, means either we didn’t know that, or we just couldn’t find a good way to do one, or the other, or both.

We’ve got the functionality of the first use case down pretty well, via Advanced Search: it helps you assemble a set of criteria of almost limitless specificity that will result in a list of bugs. It can be used to determine what bugs are blocking a particular release, what bugs a particular person has assigned to them, or what bugs in a particular Product have been fixed recently. Its interface is, admittedly, not great. Quick Search was developed as a different, text-based approach to Advanced Search; it can be quicker to use but definitely isn’t any more intuitive. Regardless, Advanced Search fulfills its role fairly well.

The second use of Search is how you’d answer the question, “what was that bug I was looking at a couple weeks ago?” You have some hazy recollection of a bug. You have a good idea of a few words in the summary, although you might be slightly off, and you might know the Product or the Assignee, but probably not much else. Advanced Search will give you a huge, useless result set, but you really just want one specific bug.

This kind of search isn’t easy; it needs some intelligence, like natural-language processing, in order to give useful results. Bugzilla’s solutions are the Instant and Simple searches, which eschew the standard Bugzilla::Search module that powers Advanced and Quick searches. Instead, they do full-text searches on the Summary field (and optionally in Comments as well, which is super slow). The results still aren’t very good, so BMO developers tried outsourcing the feature by adding a Google Search option. But despite Google being a great search engine for the web, it doesn’t know enough about BMO data to be much more useful, and it doesn’t know about new nor confidential bugs at all.

Since Bugzilla’s search engines were originally written, however, there have been many advances in the field, especially in FLOSS. This is another place where we need to bring Bugzilla into the modern world; MySQL full-text searches are just not good enough. In the upcoming year, we’re going to look into new approaches to search, such as running different databases in tandem to exploit their particular abilities. We plan to start with experiments using Elasticsearch, which, as the name implies, is very good at searching. By standing up an instance beside the main MySQL db and mirroring bug data over, we can refer specific-bug searches to it; even though we’ll then have to filter based on standard bug-visibility rules, we should have a net win in search times, especially when searching comments.

In sum, Mozilla developers, we understand your tribulations with Bugzilla search, and we’re on it. After all, we all have a reputation to maintain as the Godzilla of Search Engines!

December 17, 2014 03:37 PM

December 06, 2014

Bugzilla Tips

Making Bugzilla Searches Faster

People often wonder how to make searches in Bugzilla faster on large installations. Two things will give you the most bang for the buck:

Do those two things, and your searches will be much faster.

Coincidentally enough, Bugzilla’s “Simple Search” (BMO version) allows you to specify precisely those two things.


December 06, 2014 10:14 PM

December 01, 2014

Gervase Markham

Search Bugzilla with Yahoo!

The Bugzilla team is aware that there are currently 5 different methods of searching Bugzilla (as explained in yesterday’s presentation) – Instant Search, Simple Search, Advanced Search, Google Search and QuickSearch. It has been argued that this is too many, and that we should simplify the options available – perhaps building a search which is all three of Instant, Simple and Quick, instead of just one of them. Some Bugzilla developers have sympathy with that view.

I, however, having caught the mood of the times, feel that Mozilla is all about choice, and there is still not enough choice in Bugzilla search. Therefore, I have decided to add a sixth option for those who want it. As of today, December 1st, by installing this GreaseMonkey script, you can now search Bugzilla with Yahoo! Search. (To do this, obviously, you will need a copy of GreaseMonkey.) It looks like this:

In the future, I may create a Bugzilla extension which allows users to fill the fourth tab on the search page with the search engine of their choice, perhaps leveraging the OpenSearch standard. Then, you will be able to search Bugzilla using the search engine which provides the best experience in your locale.

Viva choice!

December 01, 2014 12:01 AM

November 28, 2014

Gervase Markham

Bugzilla for Humans, II

In 2010, johnath did a very popular video introducing people to Bugzilla, called “Bugzilla for Humans“. While age has been kind to johnath, it has been less kind to his video, which now contains several screenshots and bits of dialogue which are out of date. And, being a video featuring a single presenter, it is somewhat difficult to “patch” it.

Enter Popcorn Maker, the Mozilla Foundation’s multimedia presentation creation tool. I have written a script for a replacement presentation, voiced it up, and used Popcorn Maker to put it together. It’s branded as being in the “Understanding Mozilla” series, as a sequel to “Understanding Mozilla: Communications” which I made last year.

So, I present “Understanding Mozilla: Bugzilla“, an 8.5 minute introduction to Bugzilla as we use it here in the Mozilla project:

Because it’s a Popcorn presentation, it can be remixed. So if the instructions ever change, or Bugzilla looks different, new screenshots can be patched in or erroneous sections removed. It’s not trivial to seamlessly patch my voiceover unless you get me to do it, but it’s still much more possible than patching a video. (In fact, the current version contains a voice patch.) It can also be localized – the script is available, and someone could translate it into another language, voice it up, and then remix the presentation and adjust the transitions accordingly.

Props go to the Popcorn team for making such a great tool, and the Developer Tools team for Responsive Design View and the Screenshot button, which makes it trivial to reel off a series of screenshots of a website in a particular custom size/shape format without any need for editing.

November 28, 2014 11:52 AM

November 25, 2014

Bugzilla Tips

Email Filtering on bugzilla.mozilla.org

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 bugzilla.mozilla.org. 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 19, 2014

Gervase Markham

BMO show_bug Load Times 2x Faster Since January

The load time for viewing bugs on bugzilla.mozilla.org has got 2x faster since January. See this tweet for graphical evidence.

If you are looking for a direction in which to send your bouquets, glob is your man.

November 19, 2014 10:42 AM

November 13, 2014

Byron Jones

database refresh of bugzilla-dev.allizom.org – monday 17th november

on monday 17th november the database on bugzilla-dev.allizom.org will be refreshed with a recent database dump from bugzilla.mozilla.org.

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

Gervase Markham

New Class of Vulnerability in Perl Web Applications

We did a Bugzilla security release today, to fix some holes responsibly disclosed to us by Check Point Vulnerability Research, to whom we are very grateful. The most serious of them would allow someone to create and control an account for an arbitrary email address they don’t own. If your Bugzilla gives group permissions based on someone’s email domain, as some do, this could be a privilege escalation.

(Update 2014-10-07 05:42 BST: to be clear, this pattern is most commonly used to add “all people in a particular company” to a group, using an email address regexp like .*@mozilla.com$. It is used this way on bugzilla.mozilla.org to allow Mozilla Corporation employees access to e.g. Human Resources bugs. Membership of the Mozilla security group, which has access to unfixed vulnerabilities, is done on an individual basis and could not be obtained using this bug. The same is true of BMO admin privileges.)

These bugs are actually quite interesting, because they seem to represent a new Perl-specific security problem. (At least, as far as I’m aware it’s new, but perhaps we are about to find that everyone knows about it but us. Update 2014-10-08 09:20 BST: everything old is new again; but the level of response, including changes to CGI.pm, suggest that this had mostly faded from collective memory.) This is how it works. I’m using the most serious bug as my example. The somewhat less serious bugs caused by this pattern were XSS holes. (Check Point are going to be presenting on this vulnerability at the 31st Chaos Communications Congress in December in Hamburg, so check their analysis out too.)

Here’s the vulnerable code:

my $otheruser = Bugzilla::User->create({
    login_name => $login_name, 
    realname   => $cgi->param('realname'), 
    cryptpassword => $password});

This code creates a new Bugzilla user in the database when someone signs up. $cgi is an object representing the HTTP request made to the page.

The issue is a combination of two things. Firstly, the $cgi->param() call is context-sensitive – it can return a scalar or an array, depending on the context in which you call it – i.e. the type of the variable you assign the return value to. The ability for functions to do this is a Perl “do what I mean” feature.

Let’s say you called a page as follows, with 3 instances of the same parameter:

index.cgi?foo=bar&foo=baz&foo=quux

If you call param() in an array context (the @ sigil represents a variable which is an array), you get an array of values:

@values = $cgi->param('foo');
-->
['bar', 'baz', 'quux']

If you call it in a scalar context (the $ sigil represents a variable which is a scalar), you get a single value, probably the first one:

$value = $cgi->param('foo'); 
-->
'bar'

So what context is it being called in, in the code under suspicion? Well, that’s exactly the problem. It turns out that functions called during hash value assignment are evaluated in a list context. However, when the result comes back, that value or those values are assigned to be part of uthe hash as if they were a set of individual, comma-separated scalars. I suspect this behaviour exists because of the close relationship of lists and hashes; it allows you to do stuff like:

my @array = ("foo", 3, "bar", 6);
my %hash = @array;
-->
{ "foo" => 3, "bar" => 6 }

Therefore, when assigning the result of a function call as a hash value, if the return value is a single scalar, all goes as you would expect, but if it’s an array, the second and subsequent values end up being added as key/value pairs in the hash as well. This allows an attacker to override values already in the hash (specified earlier), which may have already been validated, with values controlled by them. In our case, real_name can be any string, so doesn’t need validation, but login_name most definitely does, and it already has been by the time this code is called.

So, in the case of the problematic code above, something like:

index.cgi?realname=JRandomUser&realname=login_name&realname=admin@mozilla.com

would end up overriding the already-validated login_name variable, giving the attacker control of the value used in the call to Bugzilla::User->create(). Oops.

We found 15 instances of this pattern in our code, four of which were exploitable to some degree. If you maintain a Perl web application, you may want to audit it for this pattern. Clearly, CGI.pm param() calls are the first thing to look for, but it’s possible that this pattern could occur with other modules which use the same context-sensitive return feature. The generic fix is to require the function call to be evaluated in scalar context:

my $otheruser = Bugzilla::User->create({
    login_name => $login_name, 
    realname   => scalar $cgi->param('realname'), 
    cryptpassword => $password});

I’d say it might be wise to not ever allow hash values to be assigned directly from functions without a call to scalar.

October 06, 2014 07:13 PM

August 28, 2014

Bugzilla Update

Landfill.bugzilla.org 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 landfill.bugzilla.org, this does not affect bugzilla.mozilla.org email addresses or passwords.

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

Thanks,

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.

response-times-may-2013response-times-may-2014

tl;dr bugzilla is faster

memcached

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 bugzilla.mozilla.org (bmo) since february 2014.

instrumentation

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 bugzilla.mozilla.org since may 2014.

database

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 bugzilla.mozilla.org’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:

SELECT DISTINCT groups.id 
  FROM groups, 
       user_group_map, 
       group_group_map 
 WHERE user_group_map.user_id = 3881 
       AND (
           (user_group_map.isbless = 1 AND groups.id=user_group_map.group_id)
           OR (groups.id = 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:

SELECT DISTINCT group_id
  FROM user_group_map
 WHERE user_id = 3881
       AND isbless = 1
UNION
SELECT DISTINCT grantor_id
  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 bugzilla.mozilla.org:

bug993894


Filed under: bmo, bugzilla

May 08, 2014 05:06 PM

May 03, 2014

Gervase Markham

Bugzilla 1,000,000 Bug Sweepstake Results

Milestone bugzilla.mozilla.org bug 1,000,000 was filed on 2014-04-23 at 01:10 ZST by Archaeopteryx (although rumour has it he used a script, as he also filed the 12 previous bugs in quick succession). The title of the bug was initially “Long word suggestions can move/shift keyboard partially off screen so it overflows” (a Firefox OS Gaia::Keyboard bug, now bug 1000025), but has since been changed to “Celebrate 1000000 bugs, bring your own drinks.”

The winner of the sweepstake to guess the date and time is Gijs Kruitbosch, who guessed 2014-04-25 05:43:21 – which is 2 days, 4 hours, 33 minutes and 5 seconds out. This is a rather wider error, measured in seconds, than the previous sweepstake, but this one had a much longer time horizon – it was instituted 9 months ago. So that’s an error of about 0.95%. The 800,000 bug winner had an error of about 1.55% using the same calculation, so in those terms Gijs’ effort is actually better.

Gijs writes:

I’m Dutch, recently moved to Britain, and I’ll be celebrating my 10th “mozversary” sometime later this year (for those who are counting, bugs had 6 digits and started with “2” when I got going). Back in 2004, I got started by working on ChatZilla, later the Venkman JS debugger and a bit of Firefox, and last year I started working on Firefox as my day job. Outside of Mozilla, I play the piano every now and then, and try to adjust to living in a nation that puts phone booths in its cycle paths.

The two runners-up are Håvard Mork (2d 14h 50m 52s out) and Mark Banner (8d 8h 24m 36s out). Håvard writes:

My name is Håvard Mork. I’m a Java software developer, working with Firefox and web localization to Norwegian. I’ve been involved with localization since 2003. I think localization is rewarding, because it is a process of understanding the mindset of the users, and their perception of IT.

I’m surprised that my estimate came that close. I spent almost an hour trying to figure out how much bug numbers grow, and estimate the exponential components. Unfortunately I lost the equation, so need to start over for the 2,000,000 sweepstakes…

Mark writes:

I’m Mark Banner, also known as Standard8 on irc, I work from home in the UK. I came to Mozilla through volunteering on Thunderbird, and then working at Mozilla Messaging. I still manage Thunderbird releases. Alongside those, I am working on the Loop project (formally Talkilla), which is aiming to provide a real time communications service for Mozilla products, built on top of WebRTC.

Gijs will get a Most Splendid Package, and also a knitted thing from Sheeri as a special bonus prize! The other winners will receive something a little less splendid, but I’m sure it’ll be worth having nevertheless.

May 03, 2014 07:57 PM

April 28, 2014

Gervase Markham

bugzilla.mozilla.org Stats At 1,000,000

Thanks to glob, we’ve got some interesting stats from BMO as it crosses the 1M bug mark.

Statuses

UNCONFIRMED   23745
NEW          103655
ASSIGNED       8826
REOPENED       3598
RESOLVED     640326
VERIFIED     220235
CLOSED         1628

Resolutions

RESOLVED

DUPLICATE    119242
EXPIRED       10677
FIXED        303099
INCOMPLETE    30569
INVALID       58096
MOVED            27
WONTFIX       36179
WORKSFORME    82437

VERIFIED

DUPLICATE     64702
EXPIRED          27
FIXED        108935
INCOMPLETE     1746
INVALID       17099
MOVED           150
WONTFIX        6105
WORKSFORME    21471

Bugs Filed Per Day (April)

2014-04-01    519
2014-04-02    531
2014-04-03    620
2014-04-04    373
2014-04-05    133
2014-04-06    132
2014-04-07    544
2014-04-08    622
2014-04-09    597
2014-04-10    571
2014-04-11    467
2014-04-12    156
2014-04-13    170
2014-04-14    573
2014-04-15    580
2014-04-16    574
2014-04-17    619
2014-04-18    356
2014-04-19    168
2014-04-20    118
2014-04-21    445
2014-04-22    635
2014-04-23    787
2014-04-24    562
2014-04-25    498
2014-04-26    173

Busiest Days Ever

2013-12-30    1360 (bulk import from another tracker)
2013-12-29    1081 (bulk import from another tracker)
2008-07-22    1037 (automated security scanner filing bugs)
2012-10-01    1013 (Gaia bugs import)
2014-02-11    805
2014-04-23    787
2014-02-04    678
2013-01-09    675
2013-11-19    647
2014-04-22    635

User Activity

(You can find these stats about yourself by going to your own user profile. If you are logged in, you can search for other users and see their stats.)

Top 10: Assignees

nobody@mozilla.org         349671
mscott@mozilla.org          16385
bugzilla@blakeross.com      15056
asa@mozilla.org             13350
sspitzer@mozilla.org        11974
bugs@bengoodger.com         10995
justdave@mozilla.com         4768
sean@mozilla.com             4697
oremj@mozilla.com            4672
mozilla@davidbienvenu.org    4273

Top 10: Reporters

jruderman@gmail.com          8037
timeless@bemail.org          6129
krupa.mozbugs@gmail.com      5032
pascalc@gmail.com            4789
bzbarsky@mit.edu             4351
philringnalda@gmail.com      4348
stephen.donner@gmail.com     4038
dbaron@dbaron.org            3680
cbook@mozilla.com            3651
bhearsum@mozilla.com         3528

Top 10: Commenters

tbplbot@gmail.com          347695
bzbarsky@mit.edu           148481
philringnalda@gmail.com     65552
dbaron@dbaron.org           58588
ryanvm@gmail.com            50560
bugzilla@mversen.de         48840
gerv@mozilla.org            48704
roc@ocallahan.org           47453
hskupin@gmail.com           43596
timeless@bemail.org         42885

Top 11: Patches Attached

bzbarsky@mit.edu             8080
dbaron@dbaron.org            4879
ehsan@mozilla.com            4502
roc@ocallahan.org            4397
masayuki@d-toybox.com        4079
neil@httl.net                3930
mozilla@davidbienvenu.org    3890
timeless@bemail.org          3739
brendan@mozilla.org          3659
bugs@pettay.fi               3530
wtc@google.com               3411

Top 11: Reviews

roc@ocallahan.org           15581
bzbarsky@mit.edu            14869
neil@httl.net                9424
jst@mozilla.org              8352
dbaron@dbaron.org            8103
benjamin@smedbergs.us        7272
mozilla@davidbienvenu.org    6198
dveditz@mozilla.com          5983
asa@mozilla.org              5499
mark.finkle@gmail.com        5346
gavin.sharp@gmail.com        5126

April 28, 2014 12:38 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 04, 2014

Mark Côté

Bugzfeed: Bugzilla push notifications

A large number of external applications have grown up around Bugzilla serving a variety of purposes. One thing many of these apps have in common is a need to get updates from Bugzilla. Unfortunately, the only way to get notifications of changes was, until recently, to poll Bugzilla. Everyone knows that polling is bad, particularly because it doesn’t scale well, but until recently there was no alternative.

Thus I would like to introduce to the world Bugzfeed, a WebSocket app that allows you to subscribe to one or more bugs and get pushed notifications when they change. It’s rather a small app, based on Tornado, and has a very simple interface, so it should scale quite nicely. It relies on a few moving parts to work, but I’ll start with the basics and explain the whole system later.

The production version is at ws://bugzfeed.mozilla.org. I also made a very simple (and ugly) example app for you to use and examine. A development version of Bugzfeed is available at ws://bugzfeed-dev.allizom.org; it’s tied to the development Bugzilla server, so it’s a good place to experiment if you’re a Mozilla contributor; you can make whatever changes you need to bugzilla-dev without worrying about messing with production data. You’ll need to get someone in #bmo on irc.mozilla.org to reset your password, since we periodically refresh and sanitize the database on bugzilla-dev, and email is disabled so you can’t reset it yourself.

(This makes me think that there should probably be a Bugzfeed instance tied to Landfill; maybe I’ll look into that, in particular if we implement middleware other than Pulse (see below).)

Client commands, responses, and notifications are all in JSON format. The project wiki page has the full list of commands. Here’s a little example of what you need to send to subscribe to bugs 1234 and 5678:

{"command": "subscribe", "bugs": [1234, 5678]}

The server will send a simple response, including a list of all the bugs you are (now) subscribed to:

{"command": "subscribe", "result": "ok", "bugs": [1234, 5678]}

Now you can just wait for notifications to be pushed from the server to your app:

{"command": "update", "bug": 1234, "when": "2014-04-03T21:13:45"}

Wait, you are probably asking, that’s it? That’s all I get?

The short answer is yup, that’s it. You can now use the regular REST API to get further details about what changed.

The longer answer is yup, that’s it, because security. Bugzilla has evolved a very fine-grained security system. We have bugs, attachments, and even comments that can only be seen by a privileged few, due to security, legal, and other considerations. Furthermore, many of the variables involved in determining whether a particular user can see a particular bug/attachment/comment can change at any time: not only can elements of a bug shift between public and confidential, but so can a user’s groups, and the groups themselves. Monitoring for all those possible changes would make this app significantly more complex and brittle, so we opted for the most secure notification, which is also the simplest: just a bug ID and a timestamp. All the other work is handled by the standard Bugzilla APIs.

(You might also be asking “why is ‘update’ considered a command?” and, to be honest, I’m not sure, so maybe that’ll change.)

There are other commands, and some limited caching of changes in case your client disconnects; see the project wiki page for more.


So how does it work? Here’s a system diagram created by contributor musingmario:

Bugzfeed system diagram

The four main pieces (with links to source) are

On the Bugzilla side, the BMO team created an extension which writes the bug ID and timestamp to a table when any bug changes. A simple Python app polls this table and sends all the updates to Pulse, cleaning up the table as it does so.

Pulse is a Mozilla RabbitMQ server with a specific configuration and message format implementing the publish/subscribe pattern. The usage is somewhat Mozilla specific, but it would be pretty easy to set up a similar system or even modify Bugzfeed and the Bugzilla shim to use RabbitMQ directly, or a different AMQP system like ØMQ.

Notifications from all bugs flow through Pulse; it is Bugzfeed, the WebSocket server, that does the filtering for its clients to notify only on subscribed bugs. Subscribing to individual notifications from Pulse is possible via topics, but this requires one channel per bug, so I doubt it would be any more efficient if hundreds of clients are connected to Bugzfeed.

While you could have the Bugzfeed server read directly from the Bugzilla database, eliminating the shim and the queuing system, having an intermediary allows us to easily stand up more Bugzfeed servers if load gets too high, as each Bugzfeed instance would see the stream of changes via its own subscriber queue. We can also easily interface new applications to the notification stream, such as the BMO Elastic Search cluster.

Enough technicalities; go out and play with it! And if you want to adapt it for your own Bugzilla installation, I’d be more than willing to help out.

April 04, 2014 04:13 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:

Enjoy!

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 bugzilla.mozilla.org. 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 https://mozillians.org/en-US/u/mcote/ or his LinkedIn profile at https://www.linkedin.com/profile/view?id=27908882 or find him in the #bugzilla channel on IRC as mcote.


March 27, 2014 03:12 AM

March 25, 2014

Mark Côté

Moving Bugzilla from Bazaar to Git

Or, how to migrate to git using only three programming languages

Another aspect of Bugzilla has been dragged, kicking & screaming, into the future! On March 11, 2014, the Bugzilla source moved to git.mozilla.org. We’re still mirroring to bzr.mozilla.org (more on that later), but the repository of record is now git, meaning it is the only place we accept new code.

Getting over there was no small feat, so I want to record the adventure in the hopes that it can benefit someone else, and so I can look back some day and wonder why I put myself through these things.

Background

The rationale isn’t the focus of this post, but suffice it to say that Bazaar isn’t very widely used, and many projects are abandoning it. Eric S. Raymond wrote a good post on the Emacs dev list about why they need to move from Bazaar to git. The same rationale applies to Bugzilla: “Sticking to a moribund version-control system will compound and exacerbate the project’s difficulty in attracting new talent.”

So, moving on, I started off scouring the Internet to find the best way to perform this migration. One major complication is the fact that we want to keep mirroring (one-way) to Bazaar for at least a while, since the main suggested way to upgrade Bugzilla is from bzr.mozilla.org. It was deemed unreasonable to require existing installations to switch to git to obtain a small security fix, so we’ll continue to mirror changes to Bazaar for some time.

Initial migration

I found a few posts here and there about people who had done migrations like this, but the most useful was a post by David Roth from last year that detailed how to preserve Bazaar’s commit metadata, specifically bug-tracker metadata, which Bugzilla has used on virtually every commit since switching from CVS. It involves using the --no-plain option with bzr fast-export and then translating the output to something git understands.

Interestingly, Roth’s translation script was written in C#, not my personal first choice for such a task (or any, really, since I don’t generally develop for Windows). However it compiled fine under Mono, so I could run it on a Linux box. Something I learned, though, is to not try this kind of thing on OS X, where, by default, the filesystem is case-insensitive.

As much as I’d prefer to deal with a language with which I am more comfortable, I dislike duplicated effort even more. I used Roth’s C# script as a basis, modifying it a bit for our needs. The metadata is in the form <bug URL> <resolution>. Rather than editing existing commit messages, I just took that string and pasted it to the bottom of the commit message, but only if the bug number was not already in the commit message. This actually revealed a few typos in the “Bug 123456” strings that generally start commit messages.

There turned out to a few other subtle bugs, like the fact that a file which is both renamed and modified in the same commit shows up, in the output from bzr fast-export, as being modified under the original name. Thus if the delete is processed first, it looks like bzr has modified an nonexistent file. Those were easy to see by comparing the contents of every file before and after migration (admittedly just for the last revision).

Since there are a lot of branches on bzr.mozilla.org, I created a bash script to record them all and make sure none were missed. It output the pre-/postmigration diff of md5 sums as well as doing a git repack for each repo, after all branches were migrated.

One thing I forgot was pushing tags via the --tags option to git push; I had to do that manually after the migration. That’s also when I discovered that the same tag existed in several related bzr branches which were all combined into one git repo. This is, of course, not allowed in git. It made me think more about how Bugzilla uses certain tags, like current-stable, which are moved after each release. In git this requires the --force option to git push and is a big no-no if the remote repo is shared. I learned that, in fact, this is also the case in bzr, though perhaps it’s regarded as less of a sin than it is in git. Anyway, I’ve since realized that those should be branches, named appropriately (per branch). Despite them not being branches in the standard sense—they’ll always point to somewhere at or behind a version branch and never fork—it’s perfectly acceptable to move them, as opposed to tags, and since they’ll always be fast-forwarded, they won’t take any more space than a lightweight tag.

Mirroring

This was a harder problem. Originally, I tried to use the bzr-git extension, and it failed when I tried to pull in changes from git. I exchanged some emails with bzr-git’s author, Jelmer Vernooij, and he said that to keep an existing bzr branch in sync with a newly formed git repo is impossible at the moment: “This is essentially the ‘roundtripping’ support that we’ve been trying to achieve with bzr-git for a while. It’s a nontrivial problem (since it requires all semantics from bzr to be preserved when pushing to git).” Considering bzr-git hasn’t had a new release in two years, I won’t be holding my breath.

Luckily (and perhaps somewhat unfortunately) Bugzilla has jumped VCSes before, as I hinted above. With the old bzr-to-cvs script as a starting point, I created a git-to-bzr script—in, of course, Perl, as the original.

This script is essentially an automated way of applying individual commits from a git branch to a bzr branch. For each commit, the entire file tree is copied from a local git clone to a local bzr checkout, bzr add and remove are executed where needed, and the changes committed with the original author, contributor, and date preserved. The script also parses out the standard “Bug X:” commit-message format and passes it to bzr’s --fixes commit option. A file called .gitrev in the bzr repo tracks the associated git commit ID for each bzr commit.

To avoid excessive disk activity, since the script polls git and bzr for changes, the script uses bzr cat to check the contents of the .gitrev file and git ls-remote to get the ID of the last git commit. If they are equal, no further actions are performed.

Summing up

And that, folks, is how you can migrate from bzr to git! The initial migration is pretty straightforward, more so if you don’t care about any bzr commit metadata. It was unfortunate that there was no off-the-shelf way to sync the repos afterwards, but the basic idea isn’t too complicated.

For more, there’s the project page on our wiki, and all the scripts used are in a GitHub repo for your perusal. I’m no VCS expert—I’ve never heavily used bzr, and I’m constantly learning new things about git—but feel free to ask me questions if you want our process further clarified.

March 25, 2014 12:39 AM

February 17, 2014

Bugzilla Update

Git Migration Scheduled

A migration of Bugzilla and related code from bzr.mozilla.org to git.mozilla.org will be perfomed on Tuesday, 11 March 2014, starting at 17:00 UTC.  At this time, all Bazaar branches on bzr.mozilla.org will be made read-only (aside from a few admin accounts), and the migration to git repos on git.mozilla.org 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 bzr.mozilla.org.  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 git.mozilla.org. git.mozilla.org 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 bzr.mozilla.org, will be unidirectional.

We’ve already done one test migration; see http://git.mozilla.org.  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 bzr.mozilla.org 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 https://wiki.mozilla.org/Bugzilla:Migrating_to_git.

Post reprinted from Mark  Côté’s post on mozilla.dev.apps.bugzilla.


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.

Download

Bugzilla is available at:

http://www.bugzilla.org/download/

MD5SUMS

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:

4.4.2: http://www.bugzilla.org/releases/4.4.2/release-notes.html

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: http://www.bugzilla.org/status/changes.html

The Bugzilla Update

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

https://bugzillaupdate.wordpress.com/

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:

http://twitter.com/#!/bugzilla

Report Bugs

If you find a bug in Bugzilla, please report it! Instructions are at this URL: http://www.bugzilla.org/developers/reporting_bugs.html

Support

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: http://www.bugzilla.org/support/
Paid Support: http://www.bugzilla.org/support/consulting.html

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 http://www.bugzilla.org/about/ for more details.


January 28, 2014 04:53 AM

January 22, 2014

Gervase Markham

BzAPI App Author?

Have you written an app or system of some sort which uses the Bugzilla REST API (BzAPI)? If so, please do as the docs have long recommended and make sure you are a member of the mozilla.tools discussion forum. There are several upcoming announcements in the next few weeks and months which you will need to be aware of, and that is where they are going to be posted.

January 22, 2014 02:24 PM

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

doctor_who

 


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.

Download

Bugzilla is available at:

http://www.bugzilla.org/download/

MD5SUMS

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:

http://www.bugzilla.org/security/4.0.10/

Release Notes & Changes

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

4.4.1: http://www.bugzilla.org/releases/4.4.1/release-notes.html
4.2.7: http://www.bugzilla.org/releases/4.2.7/release-notes.html
4.0.11: http://www.bugzilla.org/releases/4.0.11/release-notes.html

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:

http://www.bugzilla.org/status/changes.html


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 (checksetup.pl only replaced them in Bugzilla 2.8). The tarball was very small, only 52 KB (compared to 2.4 MB for Bugzilla 4.4), and you needed MySQL 3, Perl 5.4 and a web server. The home page was pretty…. simple:

index13

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:

index44

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:

query13

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:

query44

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:

buglist13

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…

enter_bug13

… and then enter details of the bug report:

enter_bug13_2

If these pages look familiar to you, that’s because they didn’t change a lot in the last 15 years:

enter_bug44

The main difference is that the product description has been added to help users select the right product.

enter_bug44_2

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:

show_bug13

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:

db_schema13

In Bugzilla 4.4, there are more than 70 tables (the output is truncated):

db_schema44

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:

values13

You couldn’t customize bug statuses, resolutions, bug severities, priorities, etc… Now admins have a nice UI to edit them:

values44

Same goes about the list of products, components and assignees:

products13

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:

products44

The list of parameters also increased a lot, and the ugly old UI…

params13

… became a well organized list of tabs:

params44

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

August 01, 2013

Gervase Markham

Bugzilla 1,000,000 Bug Sweepstake

[Note: The closing date for entries was midday ZST on Thursday 5th September 2013, i.e. a long time ago :-).]

Some of you may have noticed that, after a long history of contests, there was no competition to predict the time of arrival of the 900,000th bug on bugzilla.mozilla.org. This was because we were preparing for the big 1M.

Now we are over 9000,00 (can that really be right?), I can reveal that the prize for the Millionth Bug Sweepstake will be the top-of-the-range Most Splendid Package from the Mozilla Gear Store, which includes a black hoodie, a drawstring tote bag, a Moleskine notebook, and a Rickshaw laptop bag, all Firefox or Mozilla-branded.

The aim of the contest is simple – you need your guess to be the closest to the actual filing date of the one millionth bug in our Bugzilla installation.

To enter, email me a plain text email at gerv@mozilla.org, ideally using this link, filling in the date and time you think the one millionth bug will be filed, along with your Bugzilla ID or email address. As the link suggests, your entry should be on the first line of your email, and formatted as follows:

2010-09-08 06:54:32 bugzilla-id@example.com

All times are in ZST (‘Zilla Standard Time, a.k.a. Pacific Time, as displayed in Bugzilla timestamps unless you’ve changed a pref). If you prefer to be contacted on a different address, add that as well, in brackets on the end of the same line. We have ample graphs and charts (requires editbugs) to help you with your assessment. But if you can’t be bothered to do any research and analysis, just guess optimistically and hope!

This is a Mozilla community event. To keep it that way, entrants must have either a Bugzilla account on bugzilla.mozilla.org created before the end of July 2013, and which has done something useful in the past six months, or a Mozillians account vouched for before the same date. Anyone who meets those criteria can (and is encouraged to) enter, including Mozilla employees. Once the bug is filed, I’ll check those entries who are closest, and keep discarding them until I find one which meets these criteria. Therefore, there’s no point posting this to Slashdot or any other non-Mozilla-focussed news source. But please do post it in Mozilla news sources!

Badly-formatted entries may be discarded. The judge’s decision is final, and any funny business regarding the filing of bugs on or around the one million mark will be frowned upon. The closing date for entries is midday ZST on Thursday 5th September 2013.

August 01, 2013 11:26 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 https://wiki.mozilla.org/Bugzilla:Meetings.  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!

-Max


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.

-Max


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.

Search

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!

WebServices

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.

Miscellaneous

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), checksetup.pl 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!

-Max


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!

-Max


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 install-module.pl 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 checksetup.pl, Math::Random::Secure would throw a cryptic error about “Math::Random::Secure::irand.”

Now, in 4.0.1 and 3.6.5, install-module.pl 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–install-module.pl 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!

-Max


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

March 08, 2013

Gervase Markham

Bugzilla API 1.3 Released

I am proud to announce the release of version 1.3 of the Bugzilla REST API. This maintenance release has a bug fix or two, and fully supports the version of Bugzilla 4.2 which has just been deployed on bugzilla.mozilla.org. For smooth interaction with BMO, you should be using this version.

The installation of BzAPI 1.1 on api-dev.bugzilla.mozilla.org will go away in 4 weeks, on 4th April. There is a limit to the number of old versions we can support on the server, particularly as the older ones can put a larger load on Bugzilla and may not work correctly. Please use either the /1.3 or the /latest endpoints. Now that BzAPI has been stable for some time, tools which earlier rejected using the /latest endpoint may want to reconsider.

File bugs | Feedback and discussion

March 08, 2013 11:47 AM

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 foo@bar.com"

were disconnected, which means that these criteria would match all bugs which had the approval+ flag set and which had a flag changed by foo@bar.com. 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 foo@bar.com. 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 foo@bar.com"

were disconnected, which means that these criteria would match all bugs which had the approval+ flag set and which had a flag changed by foo@bar.com. 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 foo@bar.com. 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

January 23, 2013

Gervase Markham

Persona Login Now Fully Enabled On bugzilla.mozilla.org

[Update 2013-01-23 18:35 GMT – turns out there are a couple of Persona features we still need to be absolutely certain that this is a good thing. The change has been reverted until we’ve got those. Sorry for any confusion.]

In April last year, we enabled Persona logins on bugzilla.mozilla.org using a Bugzilla extension I wrote. However, we restricted this login method to low-privilege accounts only while Persona and the extension both matured.

I’m pleased to say that, as of now, unless you are a member of the administrative Bugzilla groups “admin”, “editusers” or “editgroups”, or the “legal” group, then you can now use Persona to log in to bugzilla.mozilla.org :-) In particular, this means all Mozilla employees and security group members can now log in this way.

Make sure you use the correct email address; if you pick a different one to your usual one, Bugzilla will auto-create a Bugzilla account for it.

If for some reason you want b.m.o. not to accept Persona logins for your account, you can do so; file a bug to have your account manually added back to the “no-browser-id” group.

January 23, 2013 04:24 PM

January 18, 2013

Gervase Markham

Support for bugzilla.mozilla.org Users

BMO is a core tool in the Mozilla project. There is now a shared, curated space for people’s tips, ideas, best practices, FAQs and so on relating specifically to BMO: https://wiki.mozilla.org/BMO/Support.

This includes Things Every BMO User Really Should Do, and a BMO FAQ (currently in its infancy).

Suggestions for additional content would be very welcome.

January 18, 2013 01:27 PM

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 checksetup.pl 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 bugzilla.mozilla.org’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 21, 2012

Gervase Markham

Bugzilla API 1.2 Released

I am proud to announce the release of version 1.2 of the Bugzilla REST API. This maintenance release has a bug fix or two, and some features useful to the admins of Bugzillas which BzAPI is pointed at.

The installation of BzAPI 1.0 on api-dev.bugzilla.mozilla.org will go away in 4 weeks, on 19th December. There is a limit to the number of old versions we can support on the server, particularly as the older ones can put a larger load on Bugzilla. Please use either the /1.2 or the /latest endpoints. Now that BzAPI has been stable for some time, tools which earlier rejected using the /latest endpoint may want to reconsider.

File bugs | Feedback and discussion

November 21, 2012 04:16 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 checksetup.pl, 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 = your_email_address@gmail.com
smtpserver = smtp.gmail.com:465
smtp_username = your_email_address@gmail.com
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 map_tag.name, ', ')) tag

All the details are in bug 780053. The group_contact() function is defined in Bugzilla/DB/Oracle.pm. The maintainer of the Oracle DB module, who was an Oracle employee, disappeared, leaving us in the dust. The code in Oracle.pm 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
</Directory>

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
</Directory>

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