Planet Bugzilla

April 19, 2014

Bugzilla Update

Release of Bugzilla 4.5.4, 4.4.4, 4.2.9, and 4.0.13

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

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

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

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

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


April 19, 2014 02:08 PM

April 18, 2014

Bugzilla Update

Release of Bugzilla 4.5.3, 4.4.3, 4.2.8, and 4.0.12

Today we have several new releases for you!

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

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

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

Bugzilla 4.0.12 is a security update for the 4.0 branch:

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


April 18, 2014 02:34 AM

April 01, 2014

Frédéric Buclin

Bugzilla 5.0 moved to Python (bye bye Perl!)

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

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

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

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:

http://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 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

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

Byron Jones

globau

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


Filed under: bugzilla

May 23, 2013 06:21 AM

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

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

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

July 31, 2012

Byron Jones

bmo breakage push

today’s push is to address an issue with searching introduced by bug 775726 (fixed in bug 778624).

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


Filed under: bmo, mozilla

July 31, 2012 06:51 AM

July 19, 2012

Byron Jones

happy bmo push day!

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


Filed under: bmo, mozilla

July 19, 2012 07:56 AM

July 12, 2012

Byron Jones

bugzilla 4.2 – what’s new – searching

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

notable differences include:

search results limiting

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

searching via APIs remains unlimited.

changes to relative dates

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

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

this change will affect existing saved searches using relative dates.

improved custom search builder

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

predictable results

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


Filed under: bmo, bugzilla, mozilla

July 12, 2012 04:37 PM

happy bmo push day!

with the qa-contact migration, i forgot to do a bmo push report last week, so this covers both weeks.

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


Filed under: bmo, mozilla

July 12, 2012 08:24 AM

July 09, 2012

Byron Jones

qa contact – changes

there have been a few questions regarding the changes to the qa-contact field…

“i’ve stopped receiving bugmail; where can i go to fix that?”

best effort was made to ensure you continue to receive the same notifications, however you may have to change some of your email preferences due to the change in the trigger for bugmail.

ensure the “component” column and the “product or component changes” row in your email preferences configuration matches your expectations.

“why does bugzilla tell me that i’m not watching any components (yet i’m still receiving bugmail)?”

the decision was made to minimise changes to the system and to not migrate preferences from watching users to watching components directly.

behind the scenes, the component-watching extension adds the watch-user as a property of components, and performs the stitching required to ensure notifications are sent. you can see the watch-user on the component watching preferences tab:

“do i need to change my settings from watching users to watching components?”

no. watching a component’s watch-user and watching a component results in the same notifications being sent. the UI for component watching is much nicer than user watching, so you may want to migrate for that reason.


Filed under: bmo, mozilla

July 09, 2012 08:43 AM

July 05, 2012

Byron Jones

Mozilla Bugzilla 4.2 Upgrade Testing

The BMO team is happy to announce the first test release of the next version of bugzilla.mozilla.org based on the upstream 4.2 code base.

We are aiming to have the upgrade completed by 23rd July, 2012. Please let us know if that date will have any negative impact on development schedules.

Test it drive at https://bugzilla.allizom.org/

The database is a recent, sanitized snapshot of the live database so should be useful for testing to make sure the information is displayed properly and changeable. Being that is it sanitized, private bugs, products, groups, attachments, and comments will not be present, and some features which rely on groups will not function.

Please point your various scripts and third party applications that use the XMLRPC/JSON API at the test server to make sure they continue to function properly.
A test instance of the BzAPI is available for testing your tools that need it – https://api-dev.bugzilla.mozilla.org/allizom/

There are also numerous new features/fixes that are part of the upstream version 4.2. Some more notable updates include enhanced WebService support, UI enhancements, HTML email, and search improvements. For more detailed information on what has changed since the last upstream release, check out the full release notes page at http://www.bugzilla.org/releases/4.2/release-notes.html

The code on the backend supporting search has changed significantly from 4.0 and special attention should be given to verify your saved searches still produce the expected results.

Email is disabled so that unnecessary spam is not sent out; feel free to make changes to bugs to verify proper working order of the UI. We can however enable email delivery to specific email addresses on request to test the new email features of Bugzilla.

We are asking for everyone to get involved as much as possible with testing and feedback.

File any bug reports in the production Bugzilla system in the bugzilla.mozilla.org product.

Thanks,

The BMO Team


Filed under: bmo, mozilla

July 05, 2012 03:28 PM

July 03, 2012

Byron Jones

qa contact reclamation – go live

the “qa contact reclamation” announced in this post is scheduled to go live this wednesday during our july 4th outage:

bugzilla.mozilla.org will be unavailable for 2 hours on Wednesday, July 4th from 8-10pm US/Pacific (3-5am, July 5th UTC)

tl;dr: the “qa contact” field for bugs will now hold the person responsible for the qa of that bug, use “component watching” to watch components.


Filed under: bmo, mozilla

July 03, 2012 05:47 AM

June 28, 2012

Byron Jones

happy bmo push day!

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


Filed under: bmo, mozilla

June 28, 2012 06:30 AM

June 22, 2012

Byron Jones

happy bmo push day!

today’s push is a day later than normal, due to issues with our pre-production staging environment.

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


Filed under: bmo, mozilla

June 22, 2012 06:05 AM

June 14, 2012

Byron Jones

happy bmo push day!

it was a quiet week last week in terms of updates to bmo, with a lot of time spent on project work.

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


Filed under: bmo, mozilla

June 14, 2012 06:55 AM

June 07, 2012

Byron Jones

happy bmo push day!

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


Filed under: bmo, mozilla

June 07, 2012 06:53 AM

May 30, 2012

Frédéric Buclin

Testopia 2.5 released! Works with Bugzilla 4.2.1

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

UPDATE: The announcement has finally been made here.


May 30, 2012 01:05 PM

May 15, 2012

Frédéric Buclin

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

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

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


May 15, 2012 05:56 PM

April 19, 2012

Frédéric Buclin

Bugzilla 4.3.1, 4.2.1, 4.0.6 and 3.6.9 released

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

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

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


April 19, 2012 01:10 AM

April 09, 2012

Frédéric Buclin

Testopia 2.5 will work with Bugzilla 4.2.1 pretty decently

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

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

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

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


April 09, 2012 05:58 PM

March 29, 2012

Frédéric Buclin

Bugzilla 4.5 will require Perl 5.10.1

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


March 29, 2012 09:24 PM

March 25, 2012

Emmanuel Seyman

Cleaning up Bugzilla

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

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

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

March 25, 2012 08:44 AM

March 02, 2012

Frédéric Buclin

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

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

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

 


March 02, 2012 03:04 PM

Performance improvements in Bugzilla 4.4

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

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

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

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

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

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

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


March 02, 2012 12:49 AM

February 22, 2012

Frédéric Buclin

Bugzilla 4.2 released!

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

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

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

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


February 22, 2012 11:50 PM

February 01, 2012

Frédéric Buclin

Bugzilla 4.2rc2, 4.0.4, 3.6.8 and 3.4.14 released

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

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

X-XSS-Protection header

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

CSRF vulnerabilities in attachment.cgi and post_bug.cgi

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

Configurable password complexity for user accounts

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

Clickjacking in attachments with the text/html MIME type

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

X-Frame-Options: sameorigin header

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

Strict-Transport-Security (STS) header

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

X-Content-Type-Options: nosniff header

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

Lockout policy to prevent brute force

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

And much more…

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

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


February 01, 2012 01:40 AM

January 29, 2012

Frédéric Buclin

Google+ est maintenant accessible au moins de 18 ans

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


January 29, 2012 07:48 PM

January 05, 2012

Byron Jones

bugzilla.mozilla.org source

there’s been a few questions recently regarding the location of the source which runs bugzilla.mozilla.org.

you can find it at bzr.mozilla.org/bmo – we’re currently running the 4.0 branch.

timeless has pointed mxr-test to the bmo source: mxr-test.mozilla.org/bugzillamozilla-bzr


Filed under: bmo, bugzilla, mozilla

January 05, 2012 03:17 PM

December 29, 2011

Frédéric Buclin

Bugzilla 4.2rc1 and 4.0.3 released

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

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

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

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

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


December 29, 2011 10:30 AM

November 29, 2011

Bugzilla Tips

User Menu

(If you have tips to share on using Bugzilla, please email them to gerv@mozilla.org.)

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


November 29, 2011 11:59 AM

November 14, 2011

Frédéric Buclin

Bugzilla page on Google+

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


November 14, 2011 05:02 PM

October 11, 2011

Frédéric Buclin

Another website compromised… who is next?

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

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


October 11, 2011 08:52 PM

August 23, 2011

Byron Jones

bugzilla inline history extension

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

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

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

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

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


Filed under: bmo, bugzilla, bugzilla tweaks, mozilla

August 23, 2011 08:30 AM

August 11, 2011

Frédéric Buclin

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

If you are like me and want to compile DBD::Oracle to use with Bugzilla and your installation of Oracle 10g XE, simply type the following command from the bugzilla/ root directory:
ORACLE_SID=XE
ORACLE_HOME=/usr/lib/oracle/xe/app/oracle/product/10.2.0/server
LD_LIBRARY_PATH=$ORACLE_HOME/lib
./install-module.pl DBD::Oracle

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


August 11, 2011 12:37 AM

August 05, 2011

Frédéric Buclin

Bugzilla 4.1.3, 4.0.2, 3.6.6 and 3.4.12 released

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

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

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


August 05, 2011 11:12 AM

June 08, 2011

Frédéric Buclin

Latest news about Bugzilla 4.0.2, 4.2rc1 and 5.0

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

Bugzilla 4.0.2

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

Bugzilla 4.2rc1

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

Bugzilla 5.0

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


June 08, 2011 08:30 PM

May 17, 2011

Frédéric Buclin

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

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

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

OpenOffice bug 24271 comment 1:

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

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

OpenOffice bug 24271 comment 27:

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

LibreOffice bug 37271 comment 1:

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

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

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

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


May 17, 2011 07:09 PM

May 09, 2011

Bugzilla Tips

Change Your Bugzilla Email

Just changed email address?

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

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


May 09, 2011 07:48 PM

May 04, 2011

David Miller

The hardware behind bugzilla.mozilla.org

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

Bugzilla Physical Layout Diagram

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

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

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

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

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

May 04, 2011 06:40 PM

Bugzilla Tips

Search Bugzilla Using Google

For Bugzillas with the Sitemap extension, which now includes bugzilla.mozilla.org, you can search Bugzilla using Google, with site:bugzilla.mozilla.org.


May 04, 2011 04:39 PM

April 01, 2011

Bugzilla Update

Winner of the “Make Bugzilla Pretty” Contest

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

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

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

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

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

Alex Faaborg

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

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

Zeeshan Syed

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

Long Duong

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

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

Jonathan Wilde

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

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

Thanks to Everybody

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

-Max


April 01, 2011 01:18 AM