05. November 2009

Release of Bugzilla 3.4.3, 3.0.10, and 3.5.1

by Max Kanat-Alexander (mkanat)

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

  • The default priority values are now human-readable words instead of P1, P2, etc.
  • I spent a lot of time making checksetup.pl faster at updating Bugzillas, particularly older Bugzillas. If you wanted to upgrade in the past, but you were worried that running checksetup.pl would cause too much downtime, I’d suggest trying an upgrade to 3.5.1 and see how it goes.
  • checksetup.pl now displays important messages in red.
  • The code that optionally converted BMPs to PNGs has been made into an extension, and is disabled by default. If you want to enable it, delete extensions/bmp_convert/disabled and run checksetup.pl. In the future, this extension will be removed from Bugzilla and shipped separately.
  • checksetup.pl now displays warnings when it fails to fix permissions on files, and dies with an error if it fails to create a directory.
  • checksetup.pl no longer dies when it cannot delete the data/template directory–instead it moves the directory out of the way.
  • duplicates.cgi now gets all of its information directly from the database, meaning that it no longer stores huge numbers of files in the data/ directory, and no longer requires that collectstats.pl be run nightly in order for it to work.
  • ssl options are simpler–there is now a parameter called ssl\_redirect which, if on, will always redirect users to the SSL version of your Bugzilla.
  • The loginnetmask parameter has been removed. Users are always allowed to use their cookie from any IP address, unless they choose to restrict it to their IP address when they log in.
  • email\_in.pl now runs in taint mode for increased security.

Improvements in 3.5.1 for Users

  • There are now arrows on the bug list which indicate what direction each column is currently sorting in.
  • There is no longer a maximum length for passwords.
  • request.cgi now groups the Product drop-down by Classification, if you are using Classifications.
  • Users are now automatically logged in after changing their password.
  • You can now load a saved search as the search for a New Charts series.
  • You can now see flags on a bug as part of search results.
  • Dependency Graph arrows now go the other direction, which seems to make more sense.
  • When creating an attachment, you will now be warned via a popup if you attempt to submit it without a description (instead of only being warned with an error after submitting the attachment).
  • You can now make comments on attachments even if you can’t edit their properties.
  • Links are now more visible, in the Dusk skin.
  • If you are logged out or don’t have permissions to edit the properties of attachments, you will now get a read-only page when viewing an attachment’s details.
  • If a user in the “insider group” adds a private comment and also makes public changes, an email about those public changes will now be sent to users who can see them. (In the past, adding a private comment entirely prevented email to users who were not in the “insider group”.)

Improvements in 3.5.1 for Customizers and Extension Authors

  • There is now a $bug-\>set\_flags and $attachment-\>set\_flags, which are used to create and update flags on bugs and attachments.
  • Bugzilla::Template::quoteUrls now has a hook that should be pretty easy to use, if you want to adjust how Bugzilla highlights comments. (The hook is bug-format\_comment.)
  • There is now a hook for page.cgi, which allows extensions to add their own new pages to Bugzilla.
  • You can now use Bugzilla-\>feature to detect if the modules for a certain feature are installed, instead of having to attempt to load those modules yourself.
  • The bug/show.html.tmpl template now requires far fewer variables in order to display it.
  • There is now a hook that allows you to modify an attachment’s data before it goes into the database.
  • Hooks can now call exit safely under mod_perl.
  • There is now a template-before\_process hook which allows you to modify variables before $template->process is called. It will be improved before Bugzilla 3.6 is released to allow for modifying variables before any template is ever loaded..
  • There are many other new hooks.
  • There is now a basic infrastructure in place that will allow localizers to translate field values for every field on display.

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:

  • Adding attachments to a bug by email (via email\_in.pl).
  • Tons of new hooks. Extensions are becoming very powerful.
  • QuickSearch is becoming simplified and improved, and getting new documentation. It will be merged into the Simple Search page, as well.
  • WebService clients will be able to authenticate by passing the arguments Bugzilla\_login and Bugzilla\_password to any method.
  • The default statuses and status workflow are going to change, based on 10 years of Bugzilla experience.
  • Some UI improvements for the bug editing page are on the way.
  • The WebService will respect taint mode, for improved security.
  • You will be able to specify groups for a bug when creating it via email\_in.pl or the Bug.create WebService function.
  • There is going to be a Bugzilla::Comment object in the code to assist with loading and creating comments.
  • Users who fail to guess a password too many times will be locked out of their account for a certain amount of time.

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!