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:

• Password lockout: If a user tries to guess their password and fails five times within 30 minutes, they will be locked out of their account for 30 minutes. Also, the administrators of Bugzilla (as specified in the maintainer parameter) will get an email notifying them of the lockout. This is all very important to protect against “brute-force password attacks”, where attackers just try passwords over and over until they find the right one. With this new feature, not only are brute-force attacks nearly impossible (it would take far too long to try enough passwords), but your Bugzilla administrators will also be able to stop any significant brute-force attacks after being notified by Bugzilla that they are occurring.
• Longer minimum password length, no maximum password length: The minimum password length is now six characters. Granted, that’s not very long, but it’s far better than the default in earlier versions. If you want to increase the minimum, just edit the USER_PASSWORD_MIN_LENGTH constant in Bugzilla/Constants.pm.

  Also, older versions of Bugzilla had a maximum password length. Bugzilla 3.6 has no maximum–your passwords can be, basically, infinitely long.

• Improved SSL Support: For many years, Bugzilla has had the capability to force connections to redirect to SSL, for improved security of login data. Now, the SSL redirect code has been simplified and made even more secure, so that if you enable it, you’re guaranteed that every connection will have SSL enabled, and never interfere with the operation of other parts of Bugzilla.

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:

• Consistent Language: If we’re talking about searching, we use the word “search” everywhere now. We don’t use a mixture of “query”, “find”, etc. Just “search”. Some other language was made more consistent like this, too.
• Visual Indication of Mandatory Fields: When you go to file a bug, Bugzilla now visually shows you which fields are mandatory.
• Javascript validation of attachment form: When creating a new attachment, we make sure that the attachment form values are valid with JavaScript, before the attachment gets submitted.
• Visually Indicate Search Results’ Sort Order: When you do a search, you can now see the sort order, thanks to triangles next to the column headers.
• Helpful Links after “Zaroo Boogs”: When there are no search results, some helpful links are displayed, offering actions you might want to take, including possibly filing a bug.
• Improved and Simplified Quicksearch: The Search box at the top and bottom of each page is called the “quicksearch” box. In Bugzilla 3.6, this box now has full, clear documentation of its very powerful syntax, which has been extended and simplified, in preparation for its becoming the primary search system in Bugzilla for future releases.
• Better Default Priority Names: Instead of the confusing P1-P5 (what’s highest, 1 or 5?), by default on a new Bugzilla installation, priorities are named “Highest”, “High”, “Normal”, “Low”, and “Lowest”.
• Many Other Improvements: If you want the whole list of the changes we’ve made, see the Other Enhancements and Changes section of the Bugzilla 3.6 Release Notes. There are so many improvements to make Bugzilla “just work” that I can’t even list them all here.

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:

• 3.0: Released 1 year, 1 month after 2.22 was released.
• 3.2: Released 1 year, 6 months after 3.0 was released.
• 3.4: Released 8 months after 3.2 was released.
• 3.6: Released 8.5 months after 3.4 was released.

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:

• The “Browse” interface is great for small-to-medium-sized projects, where you just want to see a list of every open bug in a component.
• The new JSON-RPC WebServices interface is pretty exciting, but even more exciting is that in future versions of Bugzilla, it will allow secure cross-domain access to Bugzilla’s data, allowing “web mash-ups” of Bugzilla data!
• The new system for migrating from other bug-trackers is a big deal, because it means that once somebody implements an importer for a particular system, that importer will keep working for all the future versions of Bugzilla. So, slowly, over time, we’re going to build up an awesome collection of importers for other bug-tracking systems.
• You can see Flags in search results! If you use Flags, this is pretty big.
• If you have multiple languages installed in your Bugzilla, users can simply click to pick the language they want to view Bugzilla in–you don’t have to switch your browser settings to switch languages, anymore.
• Field values for global fields (not per-product fields yet, unfortunately) can be “disabled” so that they don’t show up as selectable on bugs anymore! This allows for cleaning up old values in the Platform field, the OS field, the Resolution field, etc.
• checksetup.pl prints out its errors in a special color so that administrators will actually notice that there’s a problem.

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

• Uncategorized