Planet Bugzilla

July 20, 2010

Frédéric Buclin

What’s new in Bugzilla 4.0 and 4.2?

I didn’t blog for a long time about new features in the coming Bugzilla 4.0, nor Bugzilla 4.2 whose development just started. So here are some highlights:

Bugzilla 4.0:

Bugzilla 4.2:

As many new, and sometimes invasive, features have landed, we need as much feedback and testing as possible. So do not hesitate to download development snapshots and report bugs if you find something wrong. Remember that these development snapshots are for testing purposes only, and should in no case be used in production (we have a huge list of blockers for 4.0!).


July 20, 2010 01:40 PM

July 15, 2010

Bugzilla Tips

Quicksearch Facelift

With the release of Bugzilla 3.6, the already-awesome Quicksearch got a facelift. That linked page is now a tutorial on all its excellent capabilities. bugzilla.mozilla.org recently upgraded to 3.6, so they can all now be used on that site.


July 15, 2010 10:59 PM

Frédéric Buclin

Please upgrade!

For the third consecutive summer, I wanted to know which version major Bugzilla installations were running. In parentheses is the Bugzilla version they were running one year ago. As you can see, only the half of these installations have been upgraded in the last 12 months, and one third runs a version which is no longer supported and which has unpatched security holes. I know Yahoo! plans to upgrade to 3.6 later this year, but I have no idea about the other ones. Remember that Bugzilla 3.0.9 and older are no longer supported, and that we will stop supporting 3.2.x once Bugzilla 4.0 is released (end of this year/beginning of next year).


July 15, 2010 09:38 AM

July 13, 2010

Bugzilla Update

Bugzilla 4.0: Bug Updating and Adding Attachments Via WebServices

There have been two really big WebService enhancements checked in to the Bugzilla 4.0 tree in the last few days:

These will be available in most Bugzilla installations once they upgrade to 4.0. There are a lot of great possibilities for these, including version-control integration, the ability to automatically attach screenshots to a Bugzilla bug, etc. I wanted to let everybody know about them in advance so that you can start building tools that will integrate well with Bugzilla 4.0!

-Max


July 13, 2010 10:53 PM

Frédéric Buclin

Good bye Windows 2000

… and thank you! Today, Windows 2000 reached End Of Life (EOL). This was a great OS, and I used it till a few months ago when I decided to upgrade to Windows 7, skipping both Windows XP and Vista.


July 13, 2010 08:59 AM

July 10, 2010

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


July 10, 2010 08:56 AM

July 09, 2010

Guy Pyrzak

Prepare yourself for some changes people!

Bugzilla 4.0 has frozen and soon it will be released. There are a bunch of exciting changes that you can expect which I will try to highlight over the next few posts. The big ones that I'm sure will get a lot of attention, for better or worse, are:
  • the autocompletes for user fields and keywords
  • redesigned advanced search page
  • the redesigned attachments page.
  • create page validation
We've also got a patch in the works that will redo the homepage and make it much prettier and professional looking thanks to Jon Pink. You can also look forward to that in 4.0!

I've attached images of the 3 new pages which will hopefully encourage you all to play around with landfill!



As always we'd love to hear your feedback about this and the other changes that are coming in 4.0 (there are a lot of them, jsonp, better extension support, new default workflow, more webservices... it's a long list).

July 09, 2010 06:40 PM

Bugzilla Update

Bugzilla 4.0 Has a New Default Status Workflow

So, as of just a few minutes ago, the trunk Bugzilla code has a new default status workflow that looks like this:

  1. UNCONFIRMED
  2. CONFIRMED
  3. IN_PROGRESS
  4. RESOLVED
  5. VERIFIED

If you upgrade your installation to 4.0 (when it comes out), you will, by default, keep the old workflow, whatever it was. This is okay, except that there are now certain parts of Bugzilla (like, various pieces of text and so on) that assume you are using the new workflow, and we think the new workflow is much nicer, simpler, and clearer. So we’ve also included a script that will convert the old default workflow into the new default workflow, called contrib/convert-workflow.pl. We recommend that everybody convert to the new workflow, if you can.

If you want to see the new workflow in action, check out the bugzilla-tip demo installation.

Why Is There No NEW Status?

You might be asking yourself–why is there no “NEW” status in this new workflow? Well, we think that the status workflow should tell you something about the bug that the other fields don’t tell you about the bug. In particular, you can tell if a bug is new by looking at when the bug was filed, how many comments there are, who the assignee is, etc. In fact, in the past, a bug that had the “NEW” status may not have in fact actually been NEW–it was just not being worked on.

We feel that CONFIRMED and UNCONFIRMED both actually describe something more helpful about the bug and are more accurate than NEW.

-Max


July 09, 2010 05:31 PM

Release of Bugzilla 3.6rc1 and 3.4.6

So, we put out Bugzilla 3.6rc1 today. That’s pretty exciting. We’re currently two months ahead of schedule on our 3.6 releases–the first time we’ve ever been ahead of schedule in Bugzilla’s history. Since this is a Release Candidate, it has Release Notes, which you should read, particularly because they contain the whole list of all the cool new features in 3.6. In addition to all the major new features listed, the Other Enhancements and Changes has a ton of improvements that many Bugzilla users will be very happy about.

We also released Bugzilla 3.4.6, which has some good bug fixes for the 3.4 series, so if you’re running 3.4.x, it’d definitely be good to upgrade to 3.4.6.

Work Towards Bugzilla 3.8

Yep, that’s right, that says 3.8. See, as soon as we freeze for one release, we start working on the next release immediately. So although we’ve been working quite a bit on getting 3.6 out the door, we’ve also been adding some new features for 3.8, since February.

Our focus for 3.8 is still pretty much the same as it was for 3.6–polish up things, finish any “unfinished” features, and generally make everything suck less as much as possible. However, 3.8 is also going to include some major new UI work, thanks to Guy Pyrzak, our User Experience Lead. Already, there is work on a new attachment details UI and a simplification of the Search UI.

Also, a few other features have been implemented recently for 3.8:

Coming up soon, we also will have the following new features:

Bugzilla’s Move To Bzr

So, for day-to-day development, the Bugzilla Project now uses the Bazaar Version-Control System, instead of CVS. Our tarballs and download instructions still use CVS, for now, but internally, for development, we use Bazaar.

Our instructions on using Bazaar are here:

Bugzilla:Bzr
Bugzilla:Patches

There is also a web view of the Bazaar repository for people who want to browse around our code.

CVS is kept fully in-sync with the Bazaar code, so if you checkout or update from CVS, you’ll be getting the same code that’s in Bazaar.

EOL of Bugzilla 3.0.x

When we release Bugzilla 3.6, Bugzilla 3.0.x will reach End Of Life, meaning that no new updates will be released for the 3.0 series, even if there are security issues discovered. We strongly encourage all Bugzilla 3.0.x administrators to upgrade to Bugzilla 3.4.x or 3.6rc1.

-Max


July 09, 2010 05:31 PM

June 26, 2010

Max Kanat-Alexander

Why Is Mozilla Legitimizing Your Mom?

This is a very serious question, and it seems a number (at least 0) of people agree:

Why is Mozilla legitimizing your mom?

Mozilla clearly relies on your mom for services like doing the occasional laundry and making dinner when you go over to her house, and yet clearly your mom stands for everything that Mozilla doesn't. I mean, let's look at the points:

I wonder what the Mozilla Foundation could do with the funds that your mom has received?

So, the question is: why is Mozilla legitimizing your mom?

-Max

P.S. This is a joke that, for the most part, only people subscribed to mozilla.governance will fully get.

June 26, 2010 08:05 PM

June 25, 2010

Bugzilla Tips

Search Comment Additions

It is possible to search for who added comments to Bugzilla and when they did it. In boolean charts,

"Commenter" "is equal to" "<person>"

will find bugs to which that person has added a comment.

"A Comment" "changed before" / "changed after" "<date>"

finds bugs where a comment was added before or after a certain date. You can combine the two (must be in the same boolean chart in order to apply to the same comment) to look for bugs where a particular person added a comment before or after a certain date.

Example: all bugs you have commented on since June 18th 2010 (also uses pronoun substitution)


June 25, 2010 09:41 AM

June 19, 2010

Max Kanat-Alexander

RPC::Any - Simple, Effective XML-RPC and JSON-RPC for Perl

I just uploaded the first stable release of a new library to CPAN, called RPC::Any. It's a simple server framework that presents an object-oriented, unified interface for both XML-RPC and JSON-RPC. It has the following features:

More or less, it's everything that I ever wanted in an RPC library, and had hacked into Bugzilla using some very complex code (more on that below). It's also extremely simple to use, for most cases:

use RPC::Any::Server::JSONRPC::HTTP;
my $server = RPC::Any::Server::JSONRPC::HTTP->new(
  dispatch => { 'Foo' => 'My::Methods' });
print $server->handle_input();

package My::Methods;
use strict;

sub hello {
  my ($class) = @_;
  return $class->type('string', 'Hello World!');
}

The server above will read from STDIN, parse HTTP headers and JSON-RPC input, and return proper HTTP headers and JSON-RPC output (for any version of JSON-RPC, no less! 1.0, 1.1, or 2.0). Sending JSON-RPC input with Foo.hello as the method name would call My::Methods->hello() and return the string "Hello World!", explicitly typed as a string. You'll notice that My::Methods calls $class->type even though it never defines a "type" method--that's a magic method that RPC::Any gives the class immediately before it calls the method (and removes after the method is done being called).

To get XML-RPC support instead of JSON-RPC support, just replace every instance of the string "XMLRPC" with "JSONRPC" in the above code (so, in two places) and you have an XML-RPC server instead! No changes whatsoever required to My::Methods or any other code.

A Little Background

So, you might be wondering--why did I write a whole new WebServices module when there are so many options available on CPAN? Well, in fact, I'm actually using two of them as the backends for RPC::Any--RPC::XML and JSON::RPC::Common. So I'm not re-inventing the wheel for RPC--I'm just giving it all a clean, consistent interface.

Here's the whole story behind what motivated me to start writing RPC::Any:

Many years ago, for Bugzilla 3.0, we added a WebServices interface to Bugzilla. When we started off, it was pretty simple. We were using SOAP::Lite for XML-RPC, and everything seemed to be working okay.

Then, we realized that Unicode support was broken in SOAP::Lite (at the time), and so we had to write a workaround for that. Then we wanted to change how we dealt with null values, and we had to write a complex workaround for that. Then we changed how we dealt with input values--more complex, hackish workaround code. Oh, and then we realized that we wanted to preserve taint on incoming values, for security in Perl's taint mode (because otherwise we might accidentally send unchecked input to the database).

All of this was really tough, because SOAP::Lite was basically a SOAP module, with XML-RPC support tacked on. So all our workarounds involved modifying very convoluted SOAP code, when all we really wanted to do was modify how our XML-RPC support worked. Our XML-RPC Server module became quite a monster. (You might ask--okay, so why not switch to a pure XML-RPC module from CPAN? Ah, I tried--but more on that later.)

And then, we added JSON-RPC support, and we wanted to do it with the same backend code--that is, I didn't want to maintain one whole Bug.get function for JSON-RPC and another, separate Bug.get function for JSON-RPC. I just wanted to have one Bug.get function, with two separate frontends.

Well, this was far, far harder than I anticipated. The biggest problem was that SOAP::Lite called methods like Bugzilla::WebService::Bug->get(@params), but JSON::RPC called methods like $server->Bugzilla::WebService::Bug::get(@params);. (So under XML-RPC, the first argument to our methods was the name of our class, like "Bugzilla::WebService::Bug", but under JSON-RPC the first argument was an instance of JSON::RPC::Server.) So in order to be able to explicitly type return values using $self->type within our WebService code, I had to have one "type" implementation in Bugzilla::WebService::Server (which was the base class for both our XML-RPC and JSON-RPC servers) and another "type" implementation in Bugzilla::WebService (which is the base class for our WebService itself--that is, the base of things like Bugzilla::WebService::Bug and so on).

Then, there were numerous bugs in JSON::RPC--so many that I practically ended up writing my own JSON-RPC implementation on top of JSON::RPC, just to get it working properly for Bugzilla. Oh, and also, remember, I had to do all the same things I did for XML-RPC above, like get taint mode working right and testing/fixing Unicode. Oh, and then we added HTTP GET support to our JSON-RPC interface (which JSON::RPC didn't really support natively) and then we added JSONP support to it. It was crazy--just look at the old Bugzilla::WebSevice::Server::JSONRPC.

So along then comes the day when I have a bit of free time, and I'm looking for a project. I think, "Oh, I know, I've always wanted to move away from SOAP::Lite for our XML-RPC service. Let's see what else I can find on CPAN!" So I looked around at all of the available options, and I found RPC::XML, which, though not exactly what I needed, it was well-maintained, XML-RPC specific, and the maintainer had been really helpful with my requests.

So, I started to write a patch to move Bugzilla from SOAP::Lite to RPC::XML...and started to write a whole other series of workarounds--this time not for bugs (because the RPC::XML maintainer was very responsive about fixing those) but just because RPC::XML worked in a different way than we needed it to work, for Bugzilla.

Finally, at this point, I decided it was time to take the engineer attitude and solve the problem the right way--that is, not just fix the problem with our XML-RPC server, but fix all architectural problems of our WebServices by refactoring.

I looked around CPAN to see if there were any good, unified RPC frameworks that supported both the XML-RPC and JSON-RPC protocols, and didn't find anything. So, I rolled up my virtual sleeves and put the time in to do it really right--to write a module that would be the best, simplest, and most powerful RPC framework available for XML-RPC and JSON-RPC. One that fit the (very complex) needs of the Bugzilla Project, but could be used by anybody. A few weeks later, and I had RPC::Any.

It's really been a surprising amount of work, particularly in the test suite. But I think it was worth it--the new Bugzilla WebServices code is way cleaner, simpler, and actually much more powerful than it was before the RPC::Any.

-Max

June 19, 2010 06:14 PM

June 03, 2010

Bugzilla Tips

Quicksearch Video

Mike Beltzner has made an excellent video on how to use Bugzilla Quicksearch. If you use Bugzilla for more than about ten minutes every day, then this is definitely worth 5 minutes 33 seconds of your time.

Sadly, free WordPress doesn’t seem to allow the <video> tag, so you’ll have to go to all the effort of clicking this link (Theora video).

My favourite part is right at the beginning, where Beltzner says breezily “OK! So, now I’m going to change your life!”, and in the background you can just hear Madhava’s entirely unimpressed “I see.”

[Historical correction: as Jesse has pointed out, although he was a great supporter and inspirer, Andreas Franke made Quicksearch, not him.]


June 03, 2010 08:34 AM

June 02, 2010

Bugzilla Tips

Firefox Search Keywords

This is only sort-of a Bugzilla tip (it’s more a Firefox tip), but it makes searching Bugzilla a lot quicker and easier.

In Firefox, head over to bugzilla.mozilla.org, right click on the Search box and hit “Add a Keyword for this Search…”. Give it the keyword “bug”.

Now, you can search Bugzilla directly from your URL bar using QuickSearch syntax, by typing “bug <terms>”.


June 02, 2010 04:32 PM

May 15, 2010

Frédéric Buclin

Installing DBD::mysql: what a pain!

I wanted to test Bugzilla on Windows 7 using Perl 5.12.0. I first installed ActivePerl 5.12.0. Unfortunately, DBD::mysql is missing from the PPM repository. So I installed Microsoft Visual C++ 2010 express to use nmake.exe and compile DBD::mysql myself, but it keeps throwing errors:

C:\Users\buclin\Downloads\dbd-mysql> »\Program Files\Microsoft Visual Studio 10.0\VC\bin\nmake.exe »

Microsoft (R) Program Maintenance Utility Version 10.00.30319.01
Copyright (C) Microsoft Corporation. Tous droits réservés.

syntax error at -e line 1, near « ’755′) »
Missing right curly or square bracket at -e line 1, at end of line
Execution of -e aborted due to compilation errors.
NMAKE : fatal error U1077: ‘C:\Perl\bin\perl.exe’ : code retour ’0xff’
Stop.

I then installed Strawberry Perl 5.12.0, which already has DBD::mysql, but now I get the following error when accessing Bugzilla from the web browser:

Software error:

install_driver(mysql) failed: Can’t load ‘C:/strawberry/perl/vendor/lib/auto/DBD/mysql/mysql.dll’ for module DBD::mysql: load_file: Le module spécifié est introuvable at C:/strawberry/perl/lib/DynaLoader.pm line 200.
at (eval 938) line 3
Compilation failed in require at (eval 938) line 3.
Perhaps a required shared library or dll isn’t installed where expected
at Bugzilla/DB.pm line 1095

I wasted several hours playing with ActivePerl, Strawberry Perl and Visual C++, with no success. :( Someone, please compile DBD::mysql successfully and put it in the ActivePerl PPM repository! Thanks!


May 15, 2010 10:53 PM

May 05, 2010

Bugzilla Tips

Marking Comments

Just a quick one this week: when linking to bugs, you can highlight particular comments (giving them a green background) by specifying the comment numbers like this:

https://bugzilla.mozilla.org/show_bug.cgi?id=540&mark=63,100

You can combine that with a fragment identifier to jump straight to one of the comments you’ve highlighted:

https://bugzilla.mozilla.org/show_bug.cgi?id=540&mark=63,100#c63


May 05, 2010 02:20 PM

April 23, 2010

Bugzilla Tips

Autolinkification

Bugzilla’s comment autolinkifier will linkify the following things:

These will only linkify if the bug exists – “bug 10000000″ will not autolinkify until you have that many bugs.

Note that it doesn’t linkify bare numbers, so if you are talking about other bugs, please put the word “bug” before each of them. (Note also that the word “bug” is customizable system-wide – everywhere else as well as autolinkification).

Bugzilla also provides the ability to hook into this mechanism using the bug_format_comment hook, so an admin can extend it to autolinkify any text you like. If you have ideas for text you’d like autolinkified on bugzilla.mozilla.org, file a bug about it.


April 23, 2010 01:42 PM

April 14, 2010

Bugzilla Update

Bugzilla 3.6: Harder, Better, Faster, Stronger

Yesterday we released Bugzilla 3.6, which is exciting not just because of all the major new features, but also because of the tremendous number of minor improvements, and the speed with which we have been developing, lately. I’m going to talk a little bit today about some of those features and how we got out this major release so much more quickly than the earlier ones.

Harder: Improved Security in Bugzilla 3.6

In light of the recent attack against the Apache JIRA, I wrote a blog post describing how the same attack would have been impossible against Bugzilla, detailing just a few of Bugzilla’s enormous number of security features. I also figured that this would be an excellent time to talk about some of the new security features that Bugzilla 3.6 brings to the table:

Again, that’s just a few of the new features related to security. The full list of Bugzilla’s existing security features would be so long that nobody would finish reading the blog!

Better: Improved Usability

When you talk about a user interface, there’s a lot more to talk about than just how it looks. One of the most important aspects of UI is how much the user interface just natively makes sense to the people using it, and how easy it is for users to actually perform their tasks with it. In the past, Bugzilla has had a fairly bad reputation for its UI, but all that is starting to change, thanks to some research by Carnegie-Mellon University students, and a survey conducted by the Bugzilla Project with Mozilla’s assistance.

Now, the changes toward usability in Bugzilla 3.6 aren’t yet very dramatic. The huge, significant changes (like some fully-redesigned major UIs) are coming in the next release. But 3.6 does have some really interesting improvements in consistency and basic usability that we think you’ll like:

Faster: Better Performance and Faster Release Cycles!

So, there’s definitely some improved performance in Bugzilla 3.6, especially in show_bug.cgi, the script that displays bugs (and it will be even faster in Bugzilla 3.8). But when I say “faster”, I think what’s most impressive about Bugzilla 3.6 is the speed with which we are releasing new major Bugzilla versions, nowadays.

Here’s the amount of time between Bugzilla versions, each with a summary of the size of changes compared to the previous major release:

As you can see, our last two releases have come out considerably more quickly than the two releases before them, and we’re starting to develop a consistent release-time pattern (about every 8 months, though we’d like to get it down even lower). However, what you can’t see in the above table is that 3.6 has 1.5x more changes than 3.4 had, despite the fact that releasing 3.6 only took half a month longer!

“So,” you might ask, “what’s the secret to these consistent schedules and ever-increasing productivity?” Well, there have definitely been a lot of improvements to Bugzilla’s community processes and infrastructure, and that’s probably the reason for the productivity increase. But the biggest factor in the consistency of our new schedule is that we have a new development policy: never freeze the trunk.

Yep, that’s right. We never freeze. There are no long, two-month periods where nobody can add new features, anymore. Not only was that slowing down our development speed enormously, but it was really killing community enthusiasm–it’s much more fun to write new features than it is to fix bugs, but when your new feature won’t be reviewed for the next two months, it just makes you want to not contribute at all.

So, instead of freezing, we branch immediately at the point where we normally would have frozen. The branch gets stability fixes, and the trunk gets new features. To make this all clearer, let me explain how the whole release process for Bugzilla 3.6 worked:

  1. On November 29, 2008, we released Bugzilla 3.2.
  2. Two months later, we created the 3.4 branch in CVS. Stability fixes for making 3.4 releasable went on to the branch, and work on Bugzilla 3.6 started immediately, on the trunk.
  3. Two months after the release of Bugzilla 3.4, we branched for 3.6, and work started immediately on the trunk for 3.8.

So yes, this means that most of the time, we’re focusing on adding new features to the trunk and improving stability on the branch, so there’s a split of resources. But it turns out that actually, this makes releases go faster, not slower. People fix bugs on the branch, because they have a motivation to see their work released. People develop features on the trunk, because writing new features is fun.

So that’s our new policy: never freeze, just branch. I’d recommend that every project try it out, personally. It’s worked wonders for us.

Stronger: Extensions and Other Improvements

This is definitely the best release of Bugzilla we’ve ever done, and there’s so much to talk about, even with all the stuff that I’ve already covered above. The official release announcement covered the new Extensions system pretty well. I do have to say here, though, that Extensions really are great, and I think that with all the enthusiasm we’re seeing about them from the community, we can pretty much guarantee that Bugzilla Extensions are the future, in terms of seeing massive new functionality for Bugzilla installations everywhere.

In addition to Extensions, I also wanted to talk a bit about some new features that are particularly exciting to me, and that I think you might like as well:

And that’s just the features that I wanted to point out in case you missed them in the release notes! The full list of new features in 3.6 is astounding, go check it out!

-Max


April 14, 2010 11:04 PM

April 13, 2010

Frédéric Buclin

Bugzilla 3.6 released

We released a new major version of Bugzilla today! Bugzilla 3.6 is coming out less than 9 months after Bugzilla 3.4. This release also means that we no longer support Bugzilla 3.0.x, which reached End Of Life. So if you still use Bugzilla 3.0 or older (Bugzilla 2.x, argh), you should really upgrade, not only to use great new features, but also to protect yourself and your users from possible security attacks!

If you are running Windows and you want to try/test/evaluate Bugzilla 3.6, this is now as simple as dowloading Bugzilla-Setup-3.6.exe and execute the installer. It will install Perl, Apache, MySQL and Bugzilla for you (in a separate C:\Program Files\Bugzilla\ directory, so that they do not interfere with your existing copies of Perl & co), and asking you the minimum required information to have it work immediately. And if you want to uninstall it later, just select Bugzilla in the usual « Add/Remove Applications » panel, and installed applications will go away, with no interaction with existing copies (so if you already have e.g. MySQL installed, the Bugzilla uninstaller will leave it alone, and will only remove the copy of MySQL it installed under C:\Program Files\Bugzilla\). Note that the Windows installer is not officially supported by the Bugzilla team, and is only provided by one of the Bugzilla developers to help people install Bugzilla on Windows.

So now that Bugzilla 3.6 is released, what is coming next? Well, we are already working on the next major release, Bugzilla 3.8, which should bring some highly wanted features, such as a WebService API to edit existing bugs (we will call this method Bug.update), so that you can alter them after having used the already implemented Bug.create method. We are also working on a better support for branches, which will better let you know the status of a bug on a per-branch basis. And we also plan to implement the ability to collect information about remote bugs living in other bug trackers (either Bugzilla or Launchpad.net or Google Code, for instance) and display this information in your Bugzilla itself (I’m talking about improving the « See Also » field in show_bug.cgi, for those who know what it is). If we manage to implement all three features on time, i.e. this summer at the latest, we will skip « Bugzilla 3.8 » in the versioning and rename it « Bugzilla 4.0 », as it would be a super-major release. Basically, Bugzilla 4.0 would be able to « talk » to each others and interact together.


April 13, 2010 07:00 PM

Max Kanat-Alexander

Improving Web Security: Six Ways the Apache.org JIRA Attack Could Have Been Prevented by Better Code

Today it was revealed that servers at Apache.org and Atlassian were successfully attacked, leading to thousands of stolen passwords. The attack on apache.org's servers was via JIRA, and since the attack on Atlassian came from the same source, it probably was also through JIRA.

I'm sure that JIRA's programmers feel embarrassed enough about all of this--I don't want to berate them, or insult them. Everybody makes mistakes; almost all software has some pretty bad security vulnerabilities at at times. Overall, the JIRA guys seem to do good work, and seem to be generally nice people. And on top of all of that, I understand how they feel! Whenever there's a reported security issue in Bugzilla, I freak out. Thankfully there hasn't been an attack on Bugzilla like this JIRA one in recent memory. But if there was an attack like this, I'd be absolutely mortified, and the last thing I'd need would be somebody trying to insult or attack me for simply having made a mistake.

Instead, I want to use this opportunity as a reminder to all web application developers for why web application security is so important, and talk about some of the things that we do in Bugzilla that would have prevented or mitigated an attack like this one, and that web applications should probably all do as standard practice:

And finally, on top of all those points, if you're a system administrator, upgrade your software regularly. Some of the security issues that let the Apache JIRA be compromised were supposedly fixed in newer versions of JIRA, before the attack ever happened. Almost every time I hear of an attack like this, it uses old, known problems to compromise the system.

Nobody likes getting attacked. Everybody feels bad about it, when it happens--system administrators, programmers, and most especially users. So let's just design secure applications to start with, and never have any of our system administrators or users have to bear the burden of compromised systems and stolen data.

-Max

April 13, 2010 11:14 AM

March 29, 2010

Bugzilla Tips

Alternative Data Formats

If you want data out of Bugzilla in some format other than an HTML web page, Bugzilla can support that. The “ctype” parameter takes a short name for a content type. Valid ctypes include:

So you can subscribe to a buglist using Atom, or import it into a spreadsheet using CSV. For security reasons, the JS template is limited to public bugs only.

You can also get all this data and more as XML or JSON from the built-in RPC API, and as JSON or unstable XML from the RESTful BzAPI.For these two formats, these APIs are the recommended way to get data.

New formats can be created simply by dropping a template into the relevant directory on a Bugzilla installation. So if there are formats you’d like, say so :-)

https://bugzilla.mozilla.org/buglist.cgi?resolution=—&query_format=advanced&component=Bugzilla-General&product=Bugzilla&ctype=csv

March 29, 2010 01:43 PM

March 24, 2010

Frédéric Buclin

Bugzilla installers now available on Windows

You want to install Bugzilla on your Windows operating system but don’t want to go through all the steps to install Perl, MySQL, Apache and Bugzilla? Just download and run the new Bugzilla installer for Windows! It’s a usual .exe file which all Windows users are used to.

Bugzilla installer for Windows

Bugzilla installer for Windows

It will ask you for information required to run Bugzilla and related services correctly, and once you click « Finish », Bugzilla will appear in your web browser magically. Our magician is named Byron Jones, one of the Bugzilla developers who did a wonderful job to build these installers. Thanks a lot Byron! :)

The installers are currently available for Bugzilla 3.4.6, our current stable release, and Bugzilla 3.6rc1, our first release candidate for 3.6. Note that these installers are not officially supported by Bugzilla, though they got some testing by some core developers. Also note that they will install everything in your C:\Program Files\Bugzilla\ folder, no matter what is already installed on your system. This means Bugzilla will run its own web and DB servers and run its own instance of Perl (which are easier to install/uninstall separately), at least for now. More information can be found on the wiki page of the installers.

Do not hesitate to give us some feedback and/or suggestions for future improvements. Enjoy!


March 24, 2010 04:30 PM

March 23, 2010

Bugzilla Tips

Neat BzAPI Tools

Atul Varma has built some very cool tools using the Bugzilla REST API:

You can hear and see him demoing them in the (open) video of the WeeklyUpdate meeting from yesterday, which is embedded at the top of the meeting’s wiki page. Starts 2 minutes in.

He said: “To alleviate some of my major pain points, I decided to look into Gerv’s RESTful API for Bugzilla. So I used that to make some tools”. That’s exactly what the BzAPI was created for. Go Atul! And everyone else, please do the same!


March 23, 2010 03:34 PM

March 17, 2010

Max Kanat-Alexander

Dear CSS,

I love you, man. I really do. You're like a brother to me. But you and me and these web developers here need to sit down and have a little intervention with you.

I know that you've go a lot on your mind right now, but there's some things that we need to talk about with you, dude.

First I just want to say that I love your styles. That's not what we're here to talk about, but it's something I really wanted to give you some kudos for. font, font-style, border, text-decoration, color, background, you are awesome. Those things are so good, I just wanna hug them, most of the time. text-decoration and I have had our differences, but I've learned to work around them, and I'm pretty good now.

And the cascade? The cascade is pretty sweet.

But CSS...your positioning sucks. I know it, these web developers here know it, and it's something that we really need to talk about. It's been happening for a long time, and all of us here really would like you to think pretty hard about bringing some changes into your life.

It's not a big overhaul or anything. It's just a few things that we'd really love to see. There's just a few things. Everybody here really loves you man. We mean it. There's just a few small, little things that would really help make all of us happier, and maybe they're things that could help you feel better about yourself, too:

Those are all the things that we'd need. I know that life is pretty difficult for you right now, what with CSS3, HTML5, quirks mode, standards mode, specs, working groups, modules, errata, and everything. So this isn't something I expect overnight. But it's time for us to say that there's millions of people that you're affecting, with your behavior, and we've given you so much love. Couldn't you just give us a little?

For Serious,

Max

March 17, 2010 12:46 PM

March 16, 2010

Bugzilla Tips

bugzilla.mozilla.org URL shorteners and shortcuts

Fed up of typing https://bugzilla.mozilla.org/show_bug.cgi?id=549867 ?

Firstly, it’s a great idea to set up a “bug” keyword in Firefox. So you can type (or, often more usefully, paste from an email) “bug 123456″ into your URL bar and have the Right Thing happen. The URL you need is:

https://bugzilla.mozilla.org/show_bug.cgi?id=%s

Right-click, select “Bookmark This Link” and type “bug” into the “keyword” box.

Secondly, the handily-named bugzil.la URL shortener permits e.g.:

http://bugzil.la/466419

http://bugzil.la/<some quicksearch string>

(Thanks to Reed for making that happen.) This is good if you are attempting to squeeze an important message into, say, 140 characters. In case anyone was wondering, “.la” is Laos.


March 16, 2010 11:08 AM

March 09, 2010

Guy Pyrzak

Bugzilla Extensions: Gravatar and Inline Images

There are 2 bugs which I have been paying some attention to recently.

The first one is Bug 222861 which requests that images are displayed when they are mentioned in comments. This bug was important to me because I often found myself and others referring to images and attachments in comments and then having to open them up in a new window. I really wanted developers to just see the mocks i made along with my comments about them. It was determined that this bug makes more sense as an extension. So I wrote one. I've posted it here: http://github.com/pyrzak/Bugzilla-Extension--Inline-Images. Hopefully you guys like it!

The second one is Bug 395802 which requests to be able to support gravatar images. This is something Aza Raskin specifically mentioned by saying make it easier to know "who is this guy". Step 1 is adding a human face to a comment via the gravatar, Step 2 might be about grabbing their stats.

There were 2 mocks that I made as suggestions for how this should look. The first is:

Here is the other mock:

My hope is that we're finally to the point where many of Aza's and other's ideas might be possible thanks to the new extension system and the jsonp bug 550727. Both of which wouldn't be possible if mkanat didn't work so hard to add this kind of mash-up and extensibility, so thanks!

Any feedback about either of these extensions or anything else I mentioned is very welcomed.

March 09, 2010 02:43 PM

March 08, 2010

Frédéric Buclin

Bugzilla 3.6 RC1 has been released today. Please test it!

We released Bugzilla 3.6rc1 today, our first release candidate for 3.6. This version should be stable enough for non-critical missions. There are currently no blockers left for Bugzilla 3.6, so depending on the feedback we get, we may as well release 3.6 final in a few weeks or release 3.6rc2 depending on the severity of bugs you may find. So now is a good time to test it and to report us bugs you may find. If you don’t want to install Bugzilla 3.6rc1 yourself, you can play with our test installation.


March 08, 2010 06:10 PM

Bugzilla Tips

Email Replies to Bugzilla Comments

sdwilsh has written a Thunderbird addon called Bugzilla Helper (not to be confused with the Bugzilla Helper which guides you through bug submission). It allows you to press Reply when viewing a bugmail, and instead of popping up an email addressed to a non-working address (not helpful), will instead give you a window to type your comment in, helpfully quoting the previous comment. When you hit Submit, it will add your comment via the BzAPI.

So you can now reply to bugmail :-)


March 08, 2010 05:42 PM

March 03, 2010

Bugzilla Tips

Linkify Like A Bugzilla Comment

Have you ever had a chunk of text and wished you could apply the Bugzilla comment autolinkifier to it?

Wish no longer.

This could be handy for e.g. some wiki text involving a load of bug numbers.


March 03, 2010 01:55 PM

February 28, 2010

Guy Pyrzak

New Advanced Search UI V2

Here is the second version trying to take into account the suggestions given.

This UI would remember whatever is expanded and collapsed based on the user's cookies.

Another option that isn't displayed here is the column layout would change from 3 to X based on how wide the screen is (aka elastic).

I tried to increase the information density as well.

For saved/editable searches we might try to use the text description from the search UI.

Looking forward to hearing your feedback about the changes and improvements.

February 28, 2010 12:49 AM

February 27, 2010

Guy Pyrzak

A new layout for the Attachments page

There were some comments today about the attachments page and how wonky it is. Bug 101770 has become the place where I've decided to post a response and possible solution to the problem but since I'm sure folks don't want to bother going to the bug here are the images that I posted. Let me know what you think. My hope is that we'll be able to implement this new UI quickly and make a big improvement without making anyone too upset about losing the current Attachments UI.



Things to note. The comments box and the attachment iframe would be elastic so they would grow with the width of the page. Clicking edit attachment as comment would cause the comment box to go away and the big area would turn into a comment.

My hope for this layout is to 1 give more realestate to the comment box that is equal to the area on the current bug page as well as make it easier for people editing the patches directly to have more room.

This UI also puts the focus where it belongs, on the attachment itself.

Things to note. I'm not at all happy with the placement of the patch and obsolete checkboxes. Any suggestions on where those should go is greatly appreciated.

February 27, 2010 06:59 PM

February 25, 2010

Guy Pyrzak

Bugzilla JSON-RPC Webservice with JQuery

I already posted how you can use YUI to use the Bugzilla web services available on the head. But lots of people don't like using YUI and prefer using JQuery. I haven't used JQuery much, but this experiment seems to have gotten the job done and should supply a basis for how to do more complex stuff with JQuery and the JSON-RPC interface.

Please note the JSON serialization capability isn't part of JQuery so I used a plug-in. The plugin doesn't seem to be as powerful as YUI's JSON serialization, but maybe it is and I haven't explored it enough. Anyway, here goes!

First you'll need JQuery and the JSON serialization parser. I added it under YUI but you should be able to add it before or after the YUI in the header.

    <script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.3.2/jquery.min.js"></script>
    <script type="text/javascript" src="http://jquery-json.googlecode.com/files/jquery.json-1.3.min.js"></script>

Next comes the actual code which is very similar to the previous post.

First you create the JSON-RPC object:

var myObject = { "method": "Bug.add_comment", 
                 "params": [ { "id": 1, 
                               "comment":"I am using bugzilla's webservices with jQuery! YAY" 
                           } ], 
                 "id": 1 };


Then we encode it into a string:
var enc = $.toJSON(myObject);


Lastly we send it on its way using the JQuery ajax method:

$.ajax({"contentType":"application/json",
        "data": enc, 
        "dataType": "json", 
        "url": "jsonrpc.cgi",
        "type": "post",
        success: function(d, ts){
                    console.log('w00t',d); 
                    console.dir(d);
                 }
       });


Just like in YUI we need to make sure we set the contentType to application/json and use a post (get is still disabled due to cross site scripting concerns). I set the dataType to JSON so Jquery would deserialize the response for me.

And now we've got a basic JSON-RPC message being sent. Now we'll still need to handle errors etc, but for now this is enough to get any eager JavaScript developer going.

Another example is getting bug info which might be equally helpful is available below. This method gets information about 2 bugs. I'm not going to explain it as much but it follows the same pattern.

var myObject = {
               "method": "Bug.get",
               "params": [{ "ids": [1,2]}],
               "id": 1
               }; 
var enc = $.toJSON(myObject); 
jQuery.ajax({"contentType":"application/json",
             "data":enc, 
             "dataType":"json", 
             "url":"jsonrpc.cgi", 
             "type":"post", 
             success:function(d, ts){
                     console.log('w00t', d); 
                     console.dir(d)
                     }
           });

The hope is eventually to release some JavaScript plugins for YUI (2 and 3) and JQuery that will make this sort of stuff much easier, like handle the serialization, and errors. But for now these examples will have to do.

For more info about what Bugzilla web services are available check out:
http://www.bugzilla.org/docs/3.4/en/html/api/index.html

Next experiment... Jetpack! Any ideas on a cool bugzilla jetpack app?

February 25, 2010 10:03 PM

February 21, 2010

Frédéric Buclin

Do you think more icons in the Bugzilla UI is useful and/or prettier?

I added a few icons to one of my local Bugzilla installations a few weeks ago to make it look prettier. Some people think this is useless and brings no value, but I think it makes some pages look better than pure text pages. Below can you see how it looks like with some icons stolen from the Oxygen theme used in KDE4. Don’t be surprised if some icons look unrelated (for instance the one I used for « Bug Status Workflow »); this is simply because I couldn’t find a good one and I picked a random one as a proof of concept. :)

Bugzilla with icons

From top-left to bottom-right: userprefs.cgi, admin.cgi, and report.cgi

I think such icons makes sense at least for some people for whom english is not their mother-language (like me). When you are unsure what a label means, the icon can help you here. I have to add some IDs to some HTML elements to be able to add icons as above, but my patch for bug 547496 is ready for checkin and so one can now build a skin with icons in it if he wants to (Bugzilla 3.7.1 or newer required, unless this patch is also accepted for 3.6rc1).

To be clear: these icons won’t be committed into the Bugzilla source code. So don’t worry, you are not going to see icons everywhere in the next release. I will probably create the skin and attach it somewhere else, so that you are free to download it if you like it (from what I understood on the legal page of the Oxygen icon theme website, their icons are freely available via the Creative Common license).

What do you think about this idea? Do you have better free icons in mind to use in Bugzilla? :)


February 21, 2010 01:15 PM

February 19, 2010

Bugzilla Tips

Getting bugzilla.mozilla.org Changed Quickly

Sometimes you need bugzilla.mozilla.org’s configuration changed – components, milestones or flags added, embarrassing attachments annulled, that sort of thing. Fortunately, we have a crack team of admins who deal with these requests, mostly within 24 hours. But for super-speed, it helps if you provide all the required information up front.

Fortunately, there is now a Bugzilla Administration wiki page which lists the info you need to provide for each sort of request. Consult that first and do what it says, and you are more likely to get hyperspeed service.


February 19, 2010 05:23 PM

February 18, 2010

Guy Pyrzak

Make it like code.google.com's bug tracker

For a while we've been having discussions about tags and Bugzilla on the dev mailing list. To boil down a lot of the suggestion it consists of "we could do away with most of our fields/flags and replace them with tags, it would make the UI way better".

We've also had other discussions about how the bug edit page should change. Many of the suggestions consist of moving the non-comment data about a bug to the left or right side of the page and letting the comments take up most of the page.

Today (for the first time) i went into the code.google.com (cgc) bug tracker to see what the status of tagging was in chrome. Turns out both of these UI suggestions are exactly how chrome is implemented. I event went to the advanced search page to see if the suggestions i received from the advanced search page were the same (they weren't).

Anyway, i've received the message loud and clear "we like how google did it".

I'm tempted to make a jetpack that makes the BMO UI act/look a lot more like cgc. What do you guys think? Is it worth it or is TidyBug more the direction people prefer?

If you haven't seen cgc here is the URL i looked at today: http://code.google.com/p/chromium/issues/detail?id=17536

February 18, 2010 10:22 PM

February 17, 2010

Guy Pyrzak

Tidy Bugzilla for Jetpack... kinda

So I saw the post for TidyBug and noticed someone commented that they switched back to Greasemonkey from Jetpack. I really like the idea of Jetpack, so i was bummed to see that someone had switch away from it because they wanted this feature so... I tried copying some of the features of tidyBug over to Jetpack.

Here is the URL for the jetpack in the gallery: http://jetpackgallery.mozillalabs.com/jetpacks/346

and an image to see what it does to the edit page...



For those of you who are not familiar with tidy bug here is the original post:
http://www.squarefree.com/2009/02/26/tidybug/

I'm still working on moving over all the features (like keyboard shortcuts). But the minimizing (what seems to be the best part) is part of this. Plus this version works with ANY version of Bugzilla running 3.4 onward, not just BMO.

For those using Chrome I might try to port this over as a chrome extension next weekend.

I'll also try using jetpack to prototype some other desired features, like prototyping the quicksearch helper mentioned in my previous post.

Feedback is always appreciated.

February 17, 2010 05:48 PM

February 16, 2010

Guy Pyrzak

Update to the Advanced Search UI

We've been working on fixes from our usability research and surveys. With the recent post of Bugzilla for Humanity, I was inspired to work on the Advanced Search UI because as Johnathan put it, "it is complete and terrible" and for "99% of searches you don't need it". However the other search, the simple search he doesn't bother to mention and of course he <3's quicksearch. I've filed bug 544404 to help quicksearch magic become more discoverable.

So the solution to make the advanced search page less complicated is a multi-parter as always in the Bugzilla world. Here are the steps which may or may not happen in the order they appear.

Step 1. Make the big summary box at the top of the page use quicksearch instead of a summary search.

Step 2. Make the other boxes on the advanced search page work as a helper to the quicksearch

Step 3. Make the advanced search page less complicated.

1 and 2 are more or less out of my area expertise so I'll leave those to mkanat and jjclark. But making the advanced search page less complicated, I can help with.

The approach I took was inspired by the redesign we did at work, basically apply a grid and hide the stuff that doesn't matter most of the time.

I've posted mocks up on bug 450301 but since I'm sure no one wants to read through the bug I'll post the images here:


and the expanded version


What do you all think?

February 16, 2010 04:08 AM

February 12, 2010

Bugzilla Tips

TidyBug: Simplified Bug Display

Jesse Ruderman’s TidyBug GreaseMonkey script (docs) turns this:

into this:

‘Nuff said.


February 12, 2010 05:46 PM

February 11, 2010

Frédéric Buclin

Who is fixing Bugzilla bugs these days? – part2

Two years and a half ago, I put a graph showing the contributions of main Bugzilla developers. Doing this exercice again on a broader time frame, the results are pretty dramatic (click the image for a larger view):

Top 5 Bugzilla contributors per major release

This table shows you the top 5 contributors per major Bugzilla release, and the third row shows you the percentage of bugs fixed by the top two contributors compared to all bugs fixed for a given release. As you can see, mkanat and I are the two main contributors since Bugzilla 2.20 (released in September 2005), and the ratio of bugs fixed by us two compared to all contributions keeps increasing, reaching 75% (!) for the coming Bugzilla 3.6 release. Knowing that we both have a real life and a day job, I hope you better understand why we cannot fix all bugs and implement all requests for enhancement in a timely manner, and why we have to prioritize what to do next, meaning that some of your requests won’t be addressed in the near future (/me waves some of the Mozilla folks who like to complain rather easily). As always in the open-source world, if you want something quickly, you are welcome to contribute! ;)


February 11, 2010 01:02 AM

February 05, 2010

Bugzilla Tips

Client-Side Bugmail Filtering

Everyone who uses Bugzilla seriously gets a lot of bugmail. Bugzilla provides controls so you can restrict the amount of it you get. But did you know it also adds headers to each email so you can do further filtering on the client side?

Here are a sample set of headers, with explanations:

X-Bugzilla-Reason: CC (the role you have on the bug which led to you getting the mail; other values are AssignedTo, QAcontact)
X-Bugzilla-Type: changed (other value is ‘new’)
X-Bugzilla-Watch-Reason: QAcontact places@firefox.bugs (the role of the person you are watching, and who it is, if you are getting bugmail for that reason)
X-Bugzilla-Who: gerv@mozilla.org (the person who made the change)
X-Bugzilla-Changed-Fields: AssignedTo Status (the names of the fields changed by the update)
X-Bugzilla-URL: https://bugzilla.mozilla.org/

The following headers give the values of particular bug fields after the change in question has been made.

X-Bugzilla-Classification: Client Software
X-Bugzilla-Product: Firefox
X-Bugzilla-Component: Places
X-Bugzilla-Keywords: crash, regression
X-Bugzilla-Severity: major
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: mconnor@mozilla.com
X-Bugzilla-Target-Milestone: Firefox 3.6

You can use any of these, or a combination, as a trigger to do something different with a bugmail – file it somewhere, tag it, mark it as read or delete it.

To set up filters in Thunderbird 3, go to Tools | Message Filters… . If you click “New” to add a new filter, and then scroll down to the bottom of the list of headers and other values you can filter on, you will find “Customize…” This allows you to enter custom header values, such as the X-Bugzilla headers above.


February 05, 2010 10:35 AM

February 01, 2010

Bugzilla Tips

Pronoun Substitution

It’s fairly easy to create a URL which does a search for “bugs reported by gerv@mozilla.org“. Whoever clicks it, you get the same thing – all bugs reported by that particular user. But you can also create a URL which does a search for something like “bugs reported by the user running this search”. This means you can share it with others, and have them find the bugs which apply to them.

This is done with “pronouns”. These only work with boolean charts (bug). The left hand side of the chart can be any field which expects an email address. The operator must be “is equal to” or “is not equal to”. The right hand side then can be of the following values: “%reporter%”, “%assignee%”, “%qacontact%”, or “%user%”. These do exactly what you might expect.

Examples:


February 01, 2010 03:18 PM

Bugzilla Update

Release of Bugzilla 3.0.11, 3.2.6, 3.4.5, and 3.5.3

Okay! So we’ve got four releases today! Bugzilla 3.4.5 is a bug-fix release, it’s got some good bug fixes and small improvements. Bugzilla 3.2.6 and 3.0.11 are only fixing a small security issue. Everything released today has security fixes, some of them could actually be important for your installation, depending on how you use Bugzilla. The Security Advisory has details.

We also have a development release, 3.5.3. We’re feature-frozen now, which means that there won’t be any major new features until 3.6 is released, but there still are a lot of bug fixes that need to be done, so it’s not stable yet. Here are some of the new features since 3.5.2:

The New Bugzilla::Extension System

One of the biggest new things in 3.5.3 is the new Bugzilla::Extension system, which is a complete overhaul of how extensions work. The new extensions system is consistent, fast, and fully documented. It makes it easy to create and distribute extensions. It’s even possible to distribute them via CPAN. And for people who were using the old system, the new system comes with a script to do some automatic conversion of older extensions.

If you want to know more about it, the Bugzilla::Extension documentation contains everything you need to know to write an extension. And you can get started quickly by using the extensions/create.pl script in Bugzilla itself.

Moving to Bzr

Very soon, Bugzilla development will be moving away from CVS and onto Bazaar (called “bzr” for short). CVS will still continue to work as a read-only repository though, so you’ll still be able to update your installations and check out via CVS if you want to. More details about bzr and how Bugzilla will use it will be available after we switch.

The Road to Bugzilla 3.6

The next steps on the road to Bugzilla 3.6 are for us to finish working on all the current blockers, then to write some QA scripts for 3.6, then to write the release notes, and then to do some release candidates, and then to release! The Bugzilla Calendar has more detail on the current estimated dates of release candidates and final release.

And that’s it for the Bugzilla Update for this time!

-Max


February 01, 2010 12:54 PM

January 26, 2010

Bugzilla Tips

Quicksearch

There are three ways of searching Bugzilla:

Quicksearch is a way of getting the simplicity of Find A Specific Bug with the specificity of Advanced Search. It does a case-insensitive, substring search of the keywords and free-text fields (except comments) on open bugs.

Some tips:

That should get you started; read the docs for more. The quicksearch box is in the Bugzilla header and footer. Try it out!


January 26, 2010 05:41 PM

Welcome to Bugzilla Tips

This blog will make you aware of tips and tricks to help you use Bugzilla more efficiently and more pleasantly. Most tips will work on any Bugzilla of version 3.4 (the latest stable version) or later, but a few may be specific to bugzilla.mozilla.org.


January 26, 2010 05:39 PM

December 30, 2009

Frédéric Buclin

Bugzilla 3.6 is now feature complete

I didn’t blog about new features in Bugzilla 3.5/3.6 for a long time (last time was more than 4 months ago) as most of my time devoted to Bugzilla these last few months was to review patches (I had 35 pending reviews in my queue at the beginning of the month, and I brought it down to only 7, none of which is critical for Bugzilla 3.6). But last week, we reached one important milestone in the development of Bugzilla 3.6 as we no longer accept new features for this branch. This means that the current 3.5.2+ code is feature complete and we will now focus on stability, polish and bug fixes only. Among others, this means fixing all blockers and writing new QA scripts. Bugzilla 3.5.3, which will be the first development snapshot to be feature complete, should be released pretty soon now, see bug 532515. Your feedback will be important as it will let us know what remains broken or badly implemented. When all blockers will be fixed, and when the QA team thinks the code is stable enough, we will release Bugzilla 3.6rc1 (somewhere in Q1 or Q2 2010). Note that the release of Bugzilla 3.6 means the end-of-life of Bugzilla 3.0, which should happen late in Q2 2010.

So, what’s new since my last post?

This is only a small list of all the hard work which has recently been done in this development cycle and doesn’t include all the bug fixes we worked on since Bugzilla 3.4. But major new features are listed here and Bugzilla 3.6 shouldn’t differ very much.


December 30, 2009 12:20 AM

November 11, 2009

David Miller

Upgrading bugzilla.mozilla.org to version 3.4.3

We’re finally at the point where I can say we’re ready to upgrade Bugzilla @ Mozilla this weekend.  We’re aiming for Sunday evening (probably 6pm PST).  I’ll post again when I know how long it’ll be down for (and that’ll be included in the eventual downtime notice on the IT blog as well).

There’s a staging copy set up at https://bugzilla-stage-tip.mozilla.org/ and I would appreciate people playing around with it and finding anything that might be broken before we get it to production.  Before filing bugs, make sure to check the detailed status linked from the red box at the top of every page to make sure it’s not already listed (and you can also see my progress on cosmetic issues and so forth, there).

It will be down for a while at some point tonight when I reload it with an up-to-date snapshot of the production server (and that’ll be my test to find out how long it’ll take to upgrade it, too).  I’m super excited because this has been a long time coming. :)

November 11, 2009 08:41 PM

November 05, 2009

Max Kanat-Alexander

The Bugzilla Update Has Moved!

Hey folks! The Bugzilla Update has moved to its own blog:

http://bugzillaupdate.wordpress.com/

If you'd like to subscribe in your news reader, the feed is here:

http://bugzillaupdate.wordpress.com/feed/atom/

There's a new post today that has a LOT of news from the Bugzilla Project, over there. :-)

-Max

November 05, 2009 04:25 PM

Bugzilla Update

Release of Bugzilla 3.4.3, 3.0.10, and 3.5.1

Here we are in our new home on wordpress.com! This should be generally easier to keep up with and is a better, more “official” place than my personal blog. As of now, the Bugzilla “Status Update” page is dead and this is the official location of Bugzilla status updates.

For the first post on the new blog, I’ve released Bugzilla 3.4.3, Bugzilla 3.0.10 and Bugzilla 3.5.1. The Release Announcement has all the details about the two stable releases. What we’re going to cover in this update is 3.5.1, our development release, which has a ton of new features and major improvements.

I’m only going to cover things that are new since our last Bugzilla Update, so if you want to know the whole history of Bugzilla 3.5 (what will become 3.6), read the prior updates about Bugzilla 3.5.

Bugzilla 3.5.1

I’d like to remind everybody that 3.5.1 is unstable. It had little to no testing at all, so shouldn’t be used in a production environment. You should test it out and report bugs or make suggestions, though! Now is the time to suggest changes in our major new features. By the time we get to the Release Candidate stage, it’s often too late to make major changes! So if you want any major changes to how things work in 3.5.1, let us know soon!

The Bugzilla Migration Framework

One of the biggest new features in 3.5.1 is migrate.pl, a script that allows easy migration from a different bug-tracking system to Bugzilla.

The exciting news is that this makes it very easy to write new migrators to migrate from any bug-tracking system to Bugzilla.

Also, this makes migration a first-class part of Bugzilla, not part of contrib/. This means that we will maintain the migration framework, and the migrators themselves, and if they break, that’s a regression.

The first migrator implemented is for GNATS. The code is in Bugzilla/Migrate/GNATS.pm, if you want to see what a migrator looks like.

The migration framework has the following features:

  1. It is non-destructive. You can migrate into an existing Bugzilla installation!
  2. It’s relatively easy to implement new migrators for systems. Basically all you have to do is provide arrays of hashes describing the products, users, and bugs in your bug-tracker, and Bugzilla::Migrate does the rest of the work. It even contains a facility to translate values from the old bug-tracker to Bugzilla, and allows the end user to specify how that translation should work.
  3. It is capable of doing a “dry-run” of your migration, so that you can see if everything is going to go well before actually committing anything to the database.

We would love to see new systems implemented to migrate from! The review requirements for new migrators are slightly relaxed–we will believe you when you say that they work, as long as they are coded well and follow the Bugzilla Developers’ Guide.

Also, if anybody wants to provide me (or the Bugzilla project in general) a dump of a large working installation of a bug-tracker, that will also help people who want to write a migrator.

Finally, this makes it much easier for consultants to write migrators, so if you were thinking of hiring a Bugzilla Consultant to help you migrate to Bugzilla, now is an ideal time!

Improvements in 3.5.1 for Administrators

Improvements in 3.5.1 for Users

Improvements in 3.5.1 for Customizers and Extension Authors

Upcoming Improvements For Bugzilla 3.6

There is a lot of exciting stuff on the horizon for Bugzilla 3.6, with patches written and awaiting review before they become an official part of Bugzilla:

Also, we expect Bugzilla 3.8 (but not Bugzilla 3.6) to support MS-SQL Server as a backend database.

Whew!

That was quite a Bugzilla Update! As you can see, the Bugzilla team is busier and more productive than ever, working to make you a better bug-tracker! One thing we always need, though, are more contributors! See our Contribute Page for more details on all the ways you can help out Bugzilla–you don’t just have to be a programmer!

Until next time, happy bug-tracking!

-Max


November 05, 2009 01:58 PM

October 26, 2009

Bugzilla Update

Release of Bugzilla 3.4! (Bugzilla Update: July 28, 2009)

I have just posted the tarballs and done the website updates for Bugzilla 3.4! This means that we’re out, released, ready to download, install, and go!

Bugzilla 3.4 is the best release of Bugzilla we’ve ever made. It has tons of great new features, the most exciting of which are listed in the release announcement, so I won’t repeat them here. But you should go download it!

The Story of Bugzilla 3.4

As you look through the New Features list of Bugzilla 3.4, you may notice that it fixes tons of major issues that Bugzilla has had since its beginning. For example, we fixed the biggest performance problem in Bugzilla–sending emails when a bug is updated–and we finally hide email addresses from logged out users, to prevent spam. And that’s just a tiny taste of what’s new. Really, check out the New Features list to see everything.

But you may be asking yourself, why the sudden fixing of all these issues, and why didn’t we do it before?

Well, that’s an interesting story! From about 2003 to 2008, we spent nearly all of our time fixing up the code of Bugzilla. It needed a lot of refactoring, and we really did it–five years of it! We added new features at the same time as we refactored (remember, Bugzilla 3.0 had the largest number of major new features of any release we’ve ever done, and we were still refactoring), but the refactoring was our main focus. But finally, finally, with the release of Bugzilla 3.2, we fixed up one of the last major code issues in Bugzilla–we changed process_bug.cgi into a nice, simple series of steps that use Bug objects to do all their work.

After all this was done, we could finally take the time to look around and say, “What next?”

Well, what happened next was what led to such a great Bugzilla 3.4 release. First, I declared a new method of prioritizing work on the Bugzilla Project that put major issues of our current users as higher priority than adding new features for our prospective users. This led to us looking at the major survey items from our 2008 Bugzilla Survey and doing something about all the major requests that we could address immediately. Then we went through and looked at the bugs with the most votes on them, and did something about a lot of them.

And that, pretty simply, led to us addressing the things that people most wanted, and that we could actually prove that they wanted (because we had great survey feedback, or a lot of votes from individuals on our bugs).

Now that we’ve addressed so many of the individual things that users wanted, look to Bugzilla 3.6 and later for some big user interface and usability improvements–we have the results of extensive usability research that was done on Bugzilla, thanks to students from Carnegie-Mellon University, and we are already addressing the list of issues that that research generated.

Warning for WebService Clients: Changes Since Bugzilla 3.4rc1

Anybody who has been writing WebService clients against the 3.3.x or 3.4rc1 releases should know that we changed a few things in the API between 3.4rc1 and 3.4:

Bug.comments now takes an “ids” parameter instead of a “bug_ids” parameter (we just renamed the parameter to be consistent with out other WebService functions). Also, it will now throw an error if you try to add a private comment and you don’t have the permissions to do so. (Previously it just added a public comment if you didn’t have the permissions to make a private comment.)

Bug.history now returns its result in a completely different format, one which is more consistent with the format that Bug.comments and Bug.get use.

Progress on Bugzilla 3.6

Since our last Bugzilla Update just a few weeks ago, we’ve fixed several usability issues, sped up quicksearch, and added the ability to disable field values in global drop-down fields (without deleting the value).

Coming up soon, expect to see a lot of new WebService methods–there’s been a lot of activity in adding WebService code, lately.

The End of Bugzilla 2.x

With this release, we EOL’ed Bugzilla 2.22, the last remaining supported 2.x release. That means that only 3.x releases are supported now. It’s kind of wild to think that Bugzilla 2.x is “dead”, after nearly ten years, and so much of my personal time spent on it. I started working on Bugzilla back in the 2.18 days, and I was pretty much the release manager for three major 2.x releases–2.18, 2.20, and 2.22. It’s amazing to think that those releases were so long ago that now the very last one has reached the end of its support life. It’s all Bugzilla 3.x (and hopefully 4.x soon) from here on out, my friends! :-)

Subscribe to the Bugzilla Update

There is an Atom feed that you can subscribe to and read in your RSS reader, for just the Bugzilla Update.


October 26, 2009 03:00 AM

Warning: Major Bugzilla Security Release Coming Soon

A major security issue has been discovered in versions of Bugzilla back to 3.0. We will be releasing a version of Bugzilla which fixes the issue within 48 hours (possibly within 24 hours), and all administrators should be ready to perform the upgrade (which does not require any database changes) shortly after the new version is released.

If you do not wish to do a full upgrade, patches for just the security issue will be available. The patches are relatively small and do not modify very much of Bugzilla.


October 26, 2009 01:05 AM

Bugzilla Update: Wednesday, July 8, 2009 (Release of Bugzilla 3.4rc1 and Bugzilla 3.2.4)

Well, it’s time for another Bugzilla update! And today I just did two releases, Bugzilla 3.4rc1 and Bugzilla 3.2.4.

Bugzilla 3.4rc1

Bugzilla 3.4rc1 is particularly exciting, because it’s our first Release Candidate for 3.4. We did a really good job on this Release Candidate, I think–there’s only one 3.4 blocker remaining (and it’s only still there because we’re waiting on an external party to do something). In other words, there are no known issues with the Release Candidate that are so bad that we couldn’t just call it 3.4 next week if all goes well, and we’ve never actually been in that state for a Release Candidate, at least not as long as I’ve been around the Bugzilla Project.

One of the particularly exciting thing about a Release Candidate is that it has release notes! That means that all the new features are listed. There’s a lot of really exciting stuff in 3.4, and you should take a look. There are some gems in the “Other Enhancements and Changes” section, too, so make sure you read that too. :-)

WebService Changes Since 3.3.4

Anybody who was writing WebService clients against 3.3.x development releases should know: we renamed the Bug.get_history method to Bug.history. You can still call it as Bug.get_history if you want, but that’s undocumented and not recommended.

Also, we don’t send <nil> for NULL items anymore–too many clients didn’t support it. Now we just remove items from the returned result if they are undefined. (This is documented in the Bugzilla::WebService documentation.)

Progress Toward Bugzilla 3.6

There’s been some activity on HEAD since our last update. We got a new WebService method to get attachment information, Bug.attachments. I’ve been working on making Quicksearch (the search box in the header and footer) even faster. Greg Hendricks (of Testopia fame) has been working on the ability for administrators to “disable” certain field values (so that they don’t show up as options anymore, but remain set on existing bugs). And Bradley Baetz has been adding new hooks and working on improving performance in some important areas.

There’s no ETA for Bugzilla 3.6, but if it works anything like how Bugzilla 3.4 works, we will have open development on it until two months after Bugzilla 3.4 is released, and then we will branch for 3.6 and the 3.6 branch will be “frozen” to only bug-fixes.

Bugzilla Meeting

We have a Bugzilla Meeting next week, on Tuesday, July 14. Just read the page if you want more information! Anybody is welcome to attend.


October 26, 2009 12:55 AM

Bugzilla Update: Wednesday, May 20, 2009

Hey hey. So, I was thinking that I’d do a regular (or semi-regular) post on the status of the Bugzilla Project, for anybody interested. This is the first one.

Bugzilla 3.4

We’re getting pretty close to releasing Bugzilla 3.4rc1, now. There are only a few blockers left. Mostly they’re just awaiting review. I’ll also need some help with the release process for Bugzilla 3.4rc1, if anybody wants to help out.

The only significant changes since 3.3.4 will be a lot of bug fixes, a change to the Bug.search WebServices API, and the ability to hide the “See Also” field. The bug fixes are pretty important, though, so if you’re using 3.3.4 you definitely want to update to the most recent BUGZILLA-3_4-BRANCH code regularly or update to 3.4rc1 when it comes out.

There are a lot of significant changes in 3.4 compared to Bugzilla 3.2, though. Those will all be listed in the release notes for 3.4rc1. The difference between 3.2 and 3.4 is not as great as the difference between 3.0 and 3.2 though. We’re working on having smaller releases more often (starting with 3.4), and it seems to be working pretty well so far.

HEAD (Bugzilla 3.6)

On trunk (which will be Bugzilla 3.6), we’ve done a fair bit. There’s a JSON-RPC interface, support for suexec environments in checksetup, and a lot of HCI improvements. We’ve decided that for Bugzilla 3.6, our focus isn’t going to be adding major new features, but fixing up the features we already have. I wrote a message to the Bugzilla Developers List about it, a week ago or so, and I got a lot of positive responses (mostly on IRC or by private email). If you’re interested in helping out, feel free to check out the list of bugs we’d like to fix for Bugzilla 3.6.

-Max


October 26, 2009 12:53 AM

Bugzilla Update: Thursday, June 4, 2009

Well, it’s time for another Bugzilla update!

Bugzilla 3.4

In the Bugzilla 3.4 area, we just made some more changes to how the login form in the header and footer work. Now it’s easy again for users to discover how to reset their password–when we moved the login forms into the header/footer, we at first didn’t have any way for people to discover how to reset their password, but now there’s a link and everything works really nicely. You can see how it all works on the Bugzilla 3.4 Test Installation.

We’re getting somewhat closer to Bugzilla 3.4rc1. We found a few more blockers, so those have to be resolved, and there’s also release notes that need to be written before we can have a Release Candidate.

One new feature of Bugzilla 3.4 that we haven’t talked much about is the “See Also” field. This is a field where you can put a URL to a bug in another Bugzilla installation or to a Launchpad bug. The “See Also” feature isn’t quite complete–in the future, we also want to make it update the other installation so that the other installation knows that you’re referring to it. We also want to fix up the display, and get summary/status/resolution information on the remote bug, etc. But for now it does check that you’ve entered a valid bug URL, and at least you can somehow record that bugs in different Bugzilla installations are related to each other, and there’s a WebService interface for updating the field.

For installations that don’t need the “See Also” field, you can turn it off by disabling the “use_see_also” Parameter.

Bugzilla 3.6 (HEAD)

We’re working on various interesting things for Bugzilla 3.6, though our focus recently has been on 3.4rc1, so there are a lot of patches awaiting review for HEAD that haven’t had the time to be reviewed. People are working on the ability to disable field values and some cool WebService enhancements, but of course our main focus is fixing up the HCI issues that the Carnegie-Mellon research team discovered in their 2008 study.

-Max


October 26, 2009 12:53 AM

October 18, 2009

Frédéric Buclin

Displaying custom fields and/or custom field values based on another field in Bugzilla

A long time ago, I promised to write an article on how to display custom fields under certain circumstances… and never wrote it. But as late is better than never, here we go!

One new feature in Bugzilla 3.4 is the ability to display a custom field only when some other field has some given value. For example, let’s say I want to display a custom field named « Impact » only when the priority of bugs is P1. The first thing to do is to create (or edit) the custom field (Administration > Custom Fields > Add a new custom field):

Displaying a custom field only when another field has some given value

Displaying a custom field only when another field has some given value

The important part is on the right of the screenshot. Available fields to depend on are drop-down and multi-select fields and custom fields. Typically, this means the priority, severity, OS, platform, bug status, resolution and the product fields. In our example, « Priority » is selected, and available values for the priority field are automatically listed, from which we can select « P1″, as desired. Now, when a bug has priority P1, the Impact custom field will be displayed, else it won’t:

The Impact custom field is only displayed when the priority is P1

The Impact custom field is only displayed when the priority is P1

The change is dynamic, thanks to JS, so you don’t need to reload the page to see the custom field appearing/disappearing. Once you select another priority, the Impact field will immediately disappear from the page, and it will reappear if you re-select P1. (In the screenshot above, I assume you know how to populate values for the Impact field: Administration > Field Values > Impact > Add)

Another cool feature is the ability to decide which values to display in drop-down and multi-select custom fields based on another field value. in our example above, let’s say I want to display values in the Impact field depending on what the severity of the bug is. The first thing is to add this dependency as follows:

Custom field whose values depend on another field

Custom field whose values depend on another field

Compared to the first screenshot, I added the dependency to the severity field. Available fields to depend on are the same as above, i.e. priority, severity, etc…. You then have to either click the « Edit legal values for this field » link on the left of the screenshot, or go to Administration > Field Values > Impact. Then you have to edit each field value which is affected by the severity of bugs:

Restricting when to display a custom field value

Restricting when to display a custom field value

As we added a dependency, a new item has been added when you edit field values. By default, the « Only appears when Severity is set to » field is left empty, meaning that the field value will always be available, independently of the bug severity. Let’s say we want to display the « Global: affects all other components » value of the Impact field only when the bug severity is « blocker ». In this case, we edit the value as shown in the screenshot. Let’s also say that we want to display the « Global: affects many other components » value only when the severity is « critical ». We edit the value in a similar way to what we did above. Now when you view a bug, you will see something like this:

Restrict the list of available field values

Restrict the list of available field values

The « Global: affects all other components » value is not listed, because the severity of the bug is not « blocker ». The « Global: affects many other components » value is listed because the bug severity is « critical ». The other two values are listed because I didn’t set any restriction on them, and so they are always available when the Impact field is displayed.

You will probably ask « How do we display the Impact field when the priority is either P1 or P2? ». The short answer is that you cannot yet, unfortunately. This is a limitation which we are working on, see bug 479400. Another question could be « How do we display a value when the bug severity is either blocker or critical or major? ». The answer is the same as for the previous question: you cannot do this yet, see bug 522971. I hope to see them fixed for Bugzilla 3.6, but the freezing date is pretty close and I fear these features won’t be available on time. Maybe in Bugzilla 3.8!


October 18, 2009 07:41 PM

September 10, 2009

Max Kanat-Alexander

Warning: Major Bugzilla Security Release Coming Soon

A major security issue has been discovered in versions of Bugzilla back to 3.0. We will be releasing a version of Bugzilla which fixes the issue within 48 hours (possibly within 24 hours), and all administrators should be ready to perform the upgrade (which does not require any database changes) shortly after the new version is released.

If you do not wish to do a full upgrade, patches for just the security issue will be available. The patches are relatively small and do not modify very much of Bugzilla.

September 10, 2009 12:53 AM

August 14, 2009

Frédéric Buclin

Latest news from Bugzilla 3.5 (unstable)

Now that Bugzilla 3.4.1 has been released earlier this month, we can focus on development again. I’m going to give you a brief overview of new features and major changes we did in our code recently:

More cool stuff should come in the coming weeks! :)

There is no planned date for Bugzilla 3.5.1 yet, and in all cases, keep in mind that it will be a development snapshot. It will not be suitable for production. Our next stable release will be Bugzilla 3.6.


August 14, 2009 12:16 AM

August 01, 2009

Frédéric Buclin

Bugzilla 3.4.1 released to fix a security bug

We released Bugzilla 3.4.1 a few minutes ago to fix a security bug reported two days ago. Your installation is only vulnerable if at least one of your products has the « Entry » bit turned on for at least one group. Note that users cannot do any harm: security checks are working fine and so no user can file or move a bug into a product if the user is not allowed to access this product. We marked this bug as a security one because a user could see the name of some products despite he should not be aware of their existence (when these products have Entry + Mandatory/Mandatory set).

Here is what happened since we released Bugzilla 3.4 on Tuesday:

Tuesday, July 28

11:00 GMT: Bugzilla 3.4 is available for download.

Thursday, July 30

15:02 GMT: Sergej Pupykin files bug 507389 about too much product names being visible in the « Product » drop-down field in show_bug.cgi to users with no access to them.

17:05 GMT: I confirm that the bug is a regression in 3.4.

18:40 GMT: A first fix is proposed.

Friday , July 31:

10:23 GMT: A second fix is proposed. This one gets r+

Saturday, August 1:

10:59 GMT: Bug 507800 is filed. We are going to release Bugzilla 3.4.1 today.

12:38 GMT: The security fix is checked in and the bug marked as FIXED.

12:48 GMT: Automated QA tests (running Selenium) report several errors.

13:04 GMT: I confirm that the security fix (which I wrote; oops) is bogus and is responsible for the bustage.

13:22 GMT: New fix proposed.

13:51 GMT: All QA tests now pass successfully. We are ready to go.

14:01 GMT: The fix is checked in.

15:00 GMT: mkanat is done with the website update.

15:41 GMT: Bug 507800 is marked as FIXED. Bugzilla 3.4.1 is officially available for download.

If you already upgraded to 3.4, you can safely upgrade to 3.4.1 as the changes between both versions are really non invasive. I hope we won’t need to release 3.4.2 next week! :)


August 01, 2009 04:38 PM

July 28, 2009

Frédéric Buclin

Bugzilla 3.4 released

We released Bugzilla 3.4 today, which also means Bugzilla 2.x is EOL (including Bugzilla 2.22). Here is a quick (and incomplete) list of new features/improvements compared to Bugzilla 3.2:

If you are still using Bugzilla 2.x, or a development snapshot (3.3.x), you are highly encouraged to upgrade to 3.4. Also, if you are already running Bugzilla 3.2.x, the upgrade to 3.4 should be straightforward as there is no charset conversion (remember when we moved to UTF8 in 3.2), and almost no DB changes (besides new foreign keys to ensure your DB integrity). Note that you should run sanitycheck.cgi and fix errors reported by this script before upgrading, to avoid problems later.


July 28, 2009 01:22 PM

Max Kanat-Alexander

Release of Bugzilla 3.4! (Bugzilla Update: July 28, 2009)

I have just posted the tarballs and done the website updates for Bugzilla 3.4! This means that we're out, released, ready to download, install, and go!

Bugzilla 3.4 is the best release of Bugzilla we've ever made. It has tons of great new features, the most exciting of which are listed in the release announcement, so I won't repeat them here. But you should go download it!

The Story of Bugzilla 3.4

As you look through the New Features list of Bugzilla 3.4, you may notice that it fixes tons of major issues that Bugzilla has had since its beginning. For example, we fixed the biggest performance problem in Bugzilla--sending emails when a bug is updated--and we finally hide email addresses from logged out users, to prevent spam. And that's just a tiny taste of what's new. Really, check out the New Features list to see everything.

But you may be asking yourself, why the sudden fixing of all these issues, and why didn't we do it before?

Well, that's an interesting story! From about 2003 to 2008, we spent nearly all of our time fixing up the code of Bugzilla. It needed a lot of refactoring, and we really did it--five years of it! We added new features at the same time as we refactored (remember, Bugzilla 3.0 had the largest number of major new features of any release we've ever done, and we were still refactoring), but the refactoring was our main focus. But finally, finally, with the release of Bugzilla 3.2, we fixed up one of the last major code issues in Bugzilla--we changed process_bug.cgi into a nice, simple series of steps that use Bug objects to do all their work.

After all this was done, we could finally take the time to look around and say, "What next?"

Well, what happened next was what led to such a great Bugzilla 3.4 release. First, I declared a new method of prioritizing work on the Bugzilla Project that put major issues of our current users as higher priority than adding new features for our prospective users. This led to us looking at the major survey items from our 2008 Bugzilla Survey and doing something about all the major requests that we could address immediately. Then we went through and looked at the bugs with the most votes on them, and did something about a lot of them.

And that, pretty simply, led to us addressing the things that people most wanted, and that we could actually prove that they wanted (because we had great survey feedback, or a lot of votes from individuals on our bugs).

Now that we've addressed so many of the individual things that users wanted, look to Bugzilla 3.6 and later for some big user interface and usability improvements--we have the results of extensive usability research that was done on Bugzilla, thanks to students from Carnegie-Mellon University, and we are already addressing the list of issues that that research generated.

Warning for WebService Clients: Changes Since Bugzilla 3.4rc1

Anybody who has been writing WebService clients against the 3.3.x or 3.4rc1 releases should know that we changed a few things in the API between 3.4rc1 and 3.4:

Bug.comments now takes an "ids" parameter instead of a "bug_ids" parameter (we just renamed the parameter to be consistent with out other WebService functions). Also, it will now throw an error if you try to add a private comment and you don't have the permissions to do so. (Previously it just added a public comment if you didn't have the permissions to make a private comment.)

Bug.history now returns its result in a completely different format, one which is more consistent with the format that Bug.comments and Bug.get use.

Progress on Bugzilla 3.6

Since our last Bugzilla Update just a few weeks ago, we've fixed several usability issues, sped up quicksearch, and added the ability to disable field values in global drop-down fields (without deleting the value).

Coming up soon, expect to see a lot of new WebService methods--there's been a lot of activity in adding WebService code, lately.

The End of Bugzilla 2.x

With this release, we EOL'ed Bugzilla 2.22, the last remaining supported 2.x release. That means that only 3.x releases are supported now. It's kind of wild to think that Bugzilla 2.x is "dead", after nearly ten years, and so much of my personal time spent on it. I started working on Bugzilla back in the 2.18 days, and I was pretty much the release manager for three major 2.x releases--2.18, 2.20, and 2.22. It's amazing to think that those releases were so long ago that now the very last one has reached the end of its support life. It's all Bugzilla 3.x (and hopefully 4.x soon) from here on out, my friends! :-)

Subscribe to the Bugzilla Update

There is an Atom feed that you can subscribe to and read in your RSS reader, for just the Bugzilla Update.

July 28, 2009 10:40 AM

July 21, 2009

Frédéric Buclin

Configuring Majordomo to not break Thunderbird’s “Reply To All” option


I just configured Majordomo to set headers correctly when sending emails to the qa@bugzilla.org mailing-list so that the “Reply To All” option in Thunderbird will work as expected. Blake Winton (working for Mozilla Messaging) thought this would be a good idea to blog about it.

Majordomo was configured to override the Reply-To header and replace it by qa@bugzilla.org. The goal is to help broken email clients which don’t understand list headers. The problem with this configuration is that “Reply To All” only replies to the mailing-list, which is a problem when the sender of the initial email is not in the mailing-list. And if you don’t pay attention to this, you will forget to CC him and the guy will never get any reply. I considered this as a bug and reported it on b.m.o as bug 505374.

To fix the problem, I had to add the following two lines to the ‘message_headers‘ parameter in Majordomo:

List-Id: QA Bugzilla <$LIST@$HOST>
List-Post: <mailto:$LIST@$HOST>

I also had to set the ‘override_reply_to‘ parameter to ‘no‘ and leave the ‘reply_to‘ parameter empty, instead of the existing $LIST@$HOST value. This way, the original Reply-To header, if present, is no longer overriden and the “Reply To All” option will send the original sender a reply, as expected. Thanks to the List-Id and List-Post headers, Thunderbird 3 will also offer you the “Reply To List” option, which lets you reply to the mailing-list only. And you can also choose the usual “Reply” option to reply to the sender only, ignoring the mailing-list.

July 21, 2009 03:23 AM

July 15, 2009

Frédéric Buclin

130,000 downloads of Bugzilla 3.2.3

We had a Bugzilla meeting yesterday, and one question was about the number of downloads of recent releases. Bugzilla 3.4rc1 and 3.2.4 were released last week, on July 8, i.e. 6 days before the meeting. There were 1204 downloads of Bugzilla 3.4rc1, and 4426 downloads of Bugzilla 3.2.4 so far. These numbers look low to us, but maybe that’s due to summer vacations. But the good news is about Bugzilla 3.2.3, which was released on March 30, i.e. 3.5 months ago: 131235 downloads! This number is consistent and slightly higher than for Bugzilla 3.0.4 (released on May 4, 2008), which has been downloaded 120500 times after the same time.

One year ago, I blogged about major Bugzilla installations and the version they were running. Many of them were running the latest Bugzilla version available. I think it’s interesting to see what these installations are running today. The number in brackets is the version which was used in August 2008.

We can see a few major upgrades (especially ClamAV, WebKit, and kernel.org), but many of them didn’t upgrade at all in the last 11 months. All those installations are unfortunately vulnerable to different security bugs. Keep in mind that Bugzilla 2.20.x is no longer supported, and that the support for 2.22.x will stop at the end of the month, when Bugzilla 3.4 will be released.


July 15, 2009 08:52 PM

July 08, 2009

Frédéric Buclin

Bugzilla 3.4rc1 and 3.2.4 released

We released Bugzilla 3.4rc1 and 3.2.4 a few minutes ago. If everything goes well, there won’t be a 2nd release candidate for 3.4, and so 3.4 could be released later this month or next month. New features in 3.4 compared to 3.2 are listed in the release notes. Both releases also contain one minor security fix. If you were running Bugzilla 3.3.x, you are highly encouraged to upgrade to 3.4rc1 asap.

If you are still running Bugzilla 2.22.x, keep in mind that we will stop supporting it when Bugzilla 3.4 is released. So you should upgrade to 3.2.4 (or 3.4rc1) very soon now.


July 08, 2009 03:46 PM

Max Kanat-Alexander

Bugzilla Update: Wednesday, July 8, 2009 (Release of Bugzilla 3.4rc1 and Bugzilla 3.2.4)

Well, it's time for another Bugzilla update! And today I just did two releases, Bugzilla 3.4rc1 and Bugzilla 3.2.4.

Bugzilla 3.4rc1

Bugzilla 3.4rc1 is particularly exciting, because it's our first Release Candidate for 3.4. We did a really good job on this Release Candidate, I think--there's only one 3.4 blocker remaining (and it's only still there because we're waiting on an external party to do something). In other words, there are no known issues with the Release Candidate that are so bad that we couldn't just call it 3.4 next week if all goes well, and we've never actually been in that state for a Release Candidate, at least not as long as I've been around the Bugzilla Project.

One of the particularly exciting thing about a Release Candidate is that it has release notes! That means that all the new features are listed. There's a lot of really exciting stuff in 3.4, and you should take a look. There are some gems in the "Other Enhancements and Changes" section, too, so make sure you read that too. :-)

WebService Changes Since 3.3.4

Anybody who was writing WebService clients against 3.3.x development releases should know: we renamed the Bug.get_history method to Bug.history. You can still call it as Bug.get_history if you want, but that's undocumented and not recommended.

Also, we don't send <nil> for NULL items anymore--too many clients didn't support it. Now we just remove items from the returned result if they are undefined. (This is documented in the Bugzilla::WebService documentation.)

Progress Toward Bugzilla 3.6

There's been some activity on HEAD since our last update. We got a new WebService method to get attachment information, Bug.attachments. I've been working on making Quicksearch (the search box in the header and footer) even faster. Greg Hendricks (of Testopia fame) has been working on the ability for administrators to "disable" certain field values (so that they don't show up as options anymore, but remain set on existing bugs). And Bradley Baetz has been adding new hooks and working on improving performance in some important areas.

There's no ETA for Bugzilla 3.6, but if it works anything like how Bugzilla 3.4 works, we will have open development on it until two months after Bugzilla 3.4 is released, and then we will branch for 3.6 and the 3.6 branch will be "frozen" to only bug-fixes.

Bugzilla Meeting

We have a Bugzilla Meeting next week, on Tuesday, July 14. Just read the page if you want more information! Anybody is welcome to attend.

July 08, 2009 02:57 PM

June 04, 2009

Max Kanat-Alexander

Bugzilla Update: Thursday, June 4, 2009

Well, it's time for another Bugzilla update!

Bugzilla 3.4

In the Bugzilla 3.4 area, we just made some more changes to how the login form in the header and footer work. Now it's easy again for users to discover how to reset their password--when we moved the login forms into the header/footer, we at first didn't have any way for people to discover how to reset their password, but now there's a link and everything works really nicely. You can see how it all works on the Bugzilla 3.4 Test Installation.

We're getting somewhat closer to Bugzilla 3.4rc1. We found a few more blockers, so those have to be resolved, and there's also release notes that need to be written before we can have a Release Candidate.

One new feature of Bugzilla 3.4 that we haven't talked much about is the "See Also" field. This is a field where you can put a URL to a bug in another Bugzilla installation or to a Launchpad bug. The "See Also" feature isn't quite complete--in the future, we also want to make it update the other installation so that the other installation knows that you're referring to it. We also want to fix up the display, and get summary/status/resolution information on the remote bug, etc. But for now it does check that you've entered a valid bug URL, and at least you can somehow record that bugs in different Bugzilla installations are related to each other, and there's a WebService interface for updating the field.

For installations that don't need the "See Also" field, you can turn it off by disabling the "use_see_also" Parameter.

Bugzilla 3.6 (HEAD)

We're working on various interesting things for Bugzilla 3.6, though our focus recently has been on 3.4rc1, so there are a lot of patches awaiting review for HEAD that haven't had the time to be reviewed. People are working on the ability to disable field values and some cool WebService enhancements, but of course our main focus is fixing up the HCI issues that the Carnegie-Mellon research team discovered in their 2008 study.

-Max

June 04, 2009 11:30 PM

May 24, 2009

Frédéric Buclin

Simpler form to file bugs in Bugzilla 3.4

In my previous post, I talked about the new front page which will be used in Bugzilla 3.4 (it will very likely change again in Bugzilla 3.6 to look something like this). Now I’m going to talk about the new form to file bugs. Technically, it’s the same page as before, but we now hide some fields by default which we don’t consider to be critical when reporting a new bug.

The form to file bugs in Bugzilla 3.2 and older looks like this:

Full bug filing form

Full bug filing form

There are many fields which advanced users probably love to see when reporting a new bug, but they may look too complicated for newbies. With the idea that newbies know mostly nothing about the internals of Bugzilla, and that they probably won’t know what to set, we know display important fields only, by default:

Simple bug filing form

Simple bug filing form

The information requested here seems small enough to not frighten new reporters. We could even imagine hidding the OS + hardware fields, as well as the component field, but I suppose the form would then look a bit too much like Hendrix. Anyway, it’s still a big improvement over what Bugzilla 3.2 displays to the user. And before you ask: yes, you can display all fields if you want to. Simply click the « Show Advanced Fields » link at the top of the page. Bugzilla will store your choice in a cookie so that you don’t have to worry about it in the future. Cool, isn’t it? :)

In my next post, I will show you how administrators can configure Bugzilla 3.4 to display some fields under certain circumstances only (for instance, on a per-product basis, or only for a given severity/priority, etc…) Another cool feature. ;)


May 24, 2009 07:03 PM

May 22, 2009

Max Kanat-Alexander

Bugbot's Code Gets a Home

I just created a Google Code page for the Supybot Bugzilla plugin (what bugbot is using to report changes):

http://code.google.com/p/supybot-bugzilla/

You can use that to get the code and to report issues about it.

I'd love to put the plugin's documentation on there, but the supybot-plugin-doc script throws a traceback when I try to generate documentation for the Bugzilla plugin, unfortunately.

There aren't currently any release tarballs on the page, but if anybody wants one, just ask me and I'll create one.

-Max

May 22, 2009 10:55 PM

May 20, 2009

Max Kanat-Alexander

Bugzilla Update: Wednesday, May 20, 2009

Hey hey. So, I was thinking that I'd do a regular (or semi-regular) post on the status of the Bugzilla Project, for anybody interested. This is the first one.

Bugzilla 3.4

We're getting pretty close to releasing Bugzilla 3.4rc1, now. There are only a few blockers left. Mostly they're just awaiting review. I'll also need some help with the release process for Bugzilla 3.4rc1, if anybody wants to help out.

The only significant changes since 3.3.4 will be a lot of bug fixes, a change to the Bug.search WebServices API, and the ability to hide the "See Also" field. The bug fixes are pretty important, though, so if you're using 3.3.4 you definitely want to update to the most recent BUGZILLA-3_4-BRANCH code regularly or update to 3.4rc1 when it comes out.

There are a lot of significant changes in 3.4 compared to Bugzilla 3.2, though. Those will all be listed in the release notes for 3.4rc1. The difference between 3.2 and 3.4 is not as great as the difference between 3.0 and 3.2 though. We're working on having smaller releases more often (starting with 3.4), and it seems to be working pretty well so far.

HEAD (Bugzilla 3.6)

On trunk (which will be Bugzilla 3.6), we've done a fair bit. There's a JSON-RPC interface, support for suexec environments in checksetup, and a lot of HCI improvements. We've decided that for Bugzilla 3.6, our focus isn't going to be adding major new features, but fixing up the features we already have. I wrote a message to the Bugzilla Developers List about it, a week ago or so, and I got a lot of positive responses (mostly on IRC or by private email). If you're interested in helping out, feel free to check out the list of bugs we'd like to fix for Bugzilla 3.6.

-Max

May 20, 2009 10:06 PM

April 30, 2009

Max Kanat-Alexander

Fixing HCI Bugs in Bugzilla

Guy Pyrzak led a bunch of Carnegie-Mellon students in conducting some HCI research on Bugzilla, and they came up with extensive and detailed results.

I have been working on filing bugs in response to their results. I haven't finished filing all the bugs yet, but if you want to follow along with the issues as they are filed and fixed, you can watch the tracking bug I filed to keep track of all the usability issues discovered during the research. Some of them are minor issues that now already have patches awaiting review. Some of them are larger issues that will require work over time to fix. But I am committed to seeing them all fixed as we move forward.

We've fixed Bugzilla's backend pretty well, now. It's time to focus some on the front end.

Anybody who wants to help, please do. Any of the bugs that block the tracking bug and are assigned to "Nobody", you are welcome to take and work on yourself.

-Max

April 30, 2009 08:53 AM

April 24, 2009

Guy Pyrzak

Lots of Design Feedback and Bugzilla Usability Data

There has been a lot of interest in the Bugzilla UI recently, which I'm super excited about. Attending usability conferences like CHI, I'd often hear about how hard it is to get any interest in usability or design in the open source community for various reasons (1, 2, 3, 4).

However, thanks to the post that LpSolit posted, many designers at Mozilla have stepped up with improvements to the Bugzilla UI, there is Boriss's suggestions for a new UI as well as Fligtar's new skin. Even a graphic designer from Spread Mozilla, graphicguru, stepped up to help improve my pathetic attempt at graphics(1,2,3). We've gotten some developers, like SS, to give some very useful feedback about how he'd prefer a more minimalist skin in general. And to top it off there has been feedback about new ways to think about the workflow from Jesse. Not to mention the meeting we had with the some of the Mozilla designers about future directions for Bugzilla, as documented by Aza. And today we had a small meeting with even more Mozilla folks about how they thought the tool could be improved. We're hoping to have more meetings in the future with Mozilla developers and get even more thanks to Jono.

It's been extremely exciting it is to see so many people interested in the Bugzilla UI. I'm hoping that with all these ideas you all can expect to see many design and usability improvements in future versions of Bugzilla.

But as my professor Bonnie John would say, one shouldn't design or develop without data. Turns out Mkanat, and many of the Mozilla folks feel the same way! And thanks to a very dedicated and smart group of HCII Carnegie Mellon students we've got usability data. This data was collected this past fall on Bugzilla 3.0, and I've attempted to post their research more or less unedited from their project to the Bugzilla wiki.

I haven't had a chance to look through and write an executive summery/conclusion to all their great data, but I thought to post it without one and perhaps let you all peruse the data and supply me with your important take aways from the data. This research was not based on how people use Mozilla's Bugzilla, but how people use bug trackers in general at software companies and other domains.

Let me know what you think of the data, what takeaways you find and what conclusions you draw from the data and maybe I can crowd source this task conclusion writing task.

Unfortunately Bugzilla 3.4 is going to be out the door pretty soon, and we won't be able to get many of these improvements into this version, but maybe we will see some of the improvements suggested this past week as well as ideas from the usability research appear in 3.6 or later versions of Bugzilla.

Again thanks to everyone who has become interested in redesigning Bugzilla, keep the designs and ideas coming! Feel free to email me when you've got ideas or designs and maybe we can work together to get the ideas into the source.

April 24, 2009 05:38 AM

April 17, 2009

Guy Pyrzak

A new Login Form for Bugzilla

So we've gotten lots of great feedback on the homepage, it's been really helpful and we're talking to folks about redoing the icons, making sure that the big icons are the right choice and much more. Wait for a post to find out more about the future of the homepage!

But we're also working on the log in process, attempting to make that easier as well!

Here is a view of the current log in form as it exists on the head.


One of the problems with this UI is that you can't reset your password very easily from this page, or any other page really. The nice part is, you can log in from any page, and not have to go through some intermediate page.

So here is the solution we've though of to make it easier to reset your password or log in from any page in Bugzilla.

How it appears if you've never come to the page


What happens when you click on log in, cursor focused on the log in. This is also what happens if the browser auto fills in your username and password.

This is what you'll see if you click on the forgot password link.


I omitted a close icon for now because it didn't seem necessary, but maybe you guys think it is. Let me know!

We're also adding a link to the reset password on the bad username/password error page.

One more thing to note about how this form will work. If the browser auto-fills your username and password, we'll make sure the javascript on the page detects your username and password and displays them to you, so you don't have to click the login hyperlink to login. We're hoping this will maintain the 1 click to login capability that so many people like.

This isn't something that will magically make Bugzilla super easier to use, but hopefully this will take us one step closer to a more usable Bugzilla.

As always feedback is really appreciated and unlike my previous post, I'll get emailed when you guys comments, so hopefully i can respond to your feedback in a more timely manner. Can't wait to hear your opinions.

April 17, 2009 04:14 AM

April 16, 2009

Frédéric Buclin

New front page for Bugzilla 3.4

This is the first post about new features/UI improvements available in what will become Bugzilla 3.4. I realized that many readers don’t waste their time following links in articles; if a screenshot is not included in the article itself, they ignore links pointing to them. So I decided to insert as many screenshots as possible so that you have them immediately in front of you. And also, you can no longer complain that you didn’t know about such or such (bad) improvements when your Bugzilla installation is upgraded. ;)

Today, I will talk about what will be the most noticeable UI change: the front page.

Front page displayed to logged out users

Front page displayed to logged out users

Above can you see the new front page displayed to logged out users. There are two major changes: the 3 big buttons in the center of the page, and the login form in the header and footer of the page (the login form is now in the header and footer of all pages). The first button (the green one) will let you file a new bug. Of course, it will display the login form first as you cannot file anonymous bug reports. The second button (the orange one) will display the search page (the specific or advanced search based on your cookie; the specific one being the default). And the third button (the blue one) will let you create a new user account. Below buttons can you see a search field, well known as a « quick search » (which is more powerful than the specific search form, which is mostly useless, but less powerful than the advanced search form. My vote to kill the specific search form completely, but that’s another story).

Some users already complained that there are now 6 ways to run searches from this single page: the « Search » link in the header, the « QuickSearch » form in the header (the one with the « Find » button) the big orange button in the middle, the « QuickSeach » form below big buttons, the « Search » link in the footer and the « QuickSearch » form in the footer (again, the one with the « Find » button). I agree this may look confusing to new users. Also, there are now 3 links to create a new user account: the « New Account » link in the header and in the footer as well as the big blue button. And finally, some complained that the « File a Bug » button is useless as you have to log in first anyway. Not ideal? Your feedback is welcome!

When you are logged in, the front page will look like this:

Front page for logged in users

Front page displayed to logged in users

The only major difference compared to the logged out page is that the blue button now points to your user preferences. Also, the login form disappeared and is replaced by your login name, as in previous Bugzilla versions. We all agree that this page is suboptimal for logged in users, as much more useful data could be displayed instead of these big buttons (advanced users already use links in the header/footer of the page anyway). But we plan to improve it for Bugzilla 3.6.

Do you like it? Do you hate it? You have no opinion? Please let us know! :)


April 16, 2009 11:50 AM

April 07, 2009

Marc Schumann

Translation for Bugzilla 3.2.3

A German translation for Bugzilla version 3.2.3 is now ready as Germzilla version 3.2.3-1. Find it in the download area.

April 07, 2009 08:58 PM

April 02, 2009

Max Kanat-Alexander

Switched to Thunderbird

I switched to Thunderbird today and I am really loving it. So far, it's the best email client I've ever used. :-) It has so many nice things about it--but then again, if you're reading this, you probably already know that. :-)

-Max

April 02, 2009 06:14 AM

April 01, 2009

Max Kanat-Alexander

New Default Bugzilla Workflow?

I have proposed that Bugzilla have a new default status workflow. I wrote my reasoning in a message on the mozilla.dev.planning newsgroup, originally as an argument for a workflow that Mozilla should move to, but I think that it covers the basic bug-fixing process sufficiently well as to apply to all organizations, and thus should be the default.

I'd welcome constructive feedback, even just statements of agreement. Note that I said "constructive" feedback, not insults or rudeness, which I will most likely just ignore. :-)

-Max

April 01, 2009 11:14 AM

March 31, 2009

Frédéric Buclin

Bugzilla 3.2.3 and 3.3.4 released

We finally released Bugzilla 3.2.3 and Bugzilla 3.3.4 last night, March 30. All existing Bugzilla 3.x installations will get automatic notifications within 24 hours (if administrators enabled this feature).

Bugzilla 3.2.3 fixes some important bugs:

All known regressions introduced in Bugzilla 3.2.1/3.2.2 have been fixed in Bugzilla 3.2.3. This means you really should upgrade your installation to 3.2.3.

Bugzilla 3.3.4 is our last development release before Bugzilla 3.4rc1. This means it’s feature complete and we will now only focus on bug fixes (enhancements are no longer allowed on this branch). Newly introduced features are listed in the Status Update. The most significant change is the new front page (screenshot). Feedback is much welcome! Please keep in mind that Bugzilla 3.3.4 got no QA at all, meaning that it’s potentially unstable. If you need a stable release, use Bugzilla 3.2.3.

To developers, note that we have reopened the trunk and new enhancements are again allowed. The current trunk version is Bugzilla 3.5 (which will become Bugzilla 3.6 when it’s stable). The 3.4 branch is tagged BUGZILLA-3_4-BRANCH.


March 31, 2009 03:59 PM

Feeds: Atom, RSS 2.0, RSS 1.0
Subscription list: FOAF, OPML

Last update: July 31, 2010 01:18 PM
All times are UTC.

Subscriptions