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:

• If your Bugzilla is behind a proxy, you can tell it to accept X-Forwarded-For as the end user’s IP address, when the request comes from the proxy.
• The “Required” parameters section now only lists actually required parameters. Other parameters have been moved to the “General” or “Advanced” section.
• When installing Bugzilla, the “maintainer” parameter will automatically be set to the admin user you create during checksetup.pl.
• “votestoconfirm” is now unrelated to the existence of the UNCONFIRMED status in a product. There is instead a checkbox to enable UNCONFIRMED.
• QuickSearch has had a syntax overhaul to make it much simpler and also able to search more fields. Unfortunately, the documentation for this change didn’t make it into 3.5.3, but it will be in 3.6 at the latest.
• New WebService function: Bug.fields.
• The show_bug UI has had a few small changes.
• The “milestoneurl” feature of a product has been removed.
• The strings at the top of comments that say that you created or commented on an attachment are now localizable.
• User accounts are now locked out on a particular IP for 30 minutes if they fail to log in 5 times from that IP.
• There’s a new “Browse” interface–it’s actually just an updated interface to describecomponents.cgi, but it’s linked from the toolbar as “Browse” now.
• You can now add attachments to a bug when using email_in.pl.
• enter_bug.cgi now indicates in the UI which fields are mandatory.
• mod_perl should be working on Windows now, though it hasn’t received a lot of testing from us.
• There’s a whole awesome new Extensions system for Bugzilla (see below for more about that).

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

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

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

-Max

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.

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.

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.

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

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