Release of Bugzilla 3.2.10, 3.4.10, 3.6.4, and 4.0rc2

We just released Bugzilla 3.2.10, 3.4.10, 3.6.4, and 4.0rc2. Mostly, these contain a lot of very important security fixes. One of the fixes in particular took over 100 hours of work from the Bugzilla team as a whole and a host of external contributors, and we’ll be blogging about that in more detail in the coming days or weeks. Right now, what’s important to know is that these issues are pretty serious and you should update as soon as possible.

Older versions of Bugzilla are also affected, even though they haven’t been patched because they have reached End Of Life. If you are running a version of Bugzilla earlier than 3.2, it is now very important that you upgrade so that you can remain secure.

Most of the issues that were fixed today were discovered as a result of Mozilla expanding their security bug bounty program to include web applications. We’d like to thank Mozilla for funding this initiative and helping us significantly improve the security of Bugzilla in various areas.

Progress Toward Bugzilla 4.0

With the release of Bugzilla 4.0rc2, we’re that much closer to Bugzilla 4.0! This second Release Candidate has a fully-tested Bug.update WebService method, so we don’t expect its API to change any more (although it has changed quite a bit since 4.0rc1 thanks to testing and bug fixes). The other new WebService methods may still change before the final release of 4.0, as we haven’t tested all of them yet.

4.0rc2 also contains a lot of bug fixes over rc1, and should be relatively stable. Now is the time to start trying out deployments of it to see if everything is okay in your environment. Our current plan is to release Bugzilla 4.0 on Tuesday, February 15, 2011 if everything goes well with this release.

-Max

Deprecation of Windows 2000 Support for All Supported Branches of Bugzilla

In the upcoming weeks, the Bugzilla Project will be releasing new versions of Bugzilla on all branches–3.2.10, 3.4.10, 3.6.4, and 4.0rc2. Due to some important changes that are coming in those releases, you will no longer be able to install Bugzilla on Windows 2000 or Windows 2000 Server. You will, however, still be able to use a web browser on Windows 2000 or Windows 2000 Server as a client to access Bugzilla.

Note that Windows 2000 itself reached end-of-life from Microsoft in July of this year, so this is in line with that, as well.

All newer versions of Windows will still be supported. Only Windows 2000 and Windows 2000 Server support is being deprecated.

-Max

Bugzilla 4.0 Release Notes Ready

Just a quick update to let everybody know that we now have Draft Release Notes for Bugzilla 4.0, including a list of New Features in 4.0.

We’re expecting to have Release Candidate 1 out soon, for 4.0–possibly this coming week.

-Max

Make Bugzilla Pretty: A Contest

Hello out there, developers and designers! After many years of working on Bugzilla’s usability, we have finally come to the point where we think that it’s time…we want to make Bugzilla look nice. Gone are the days when it is OK for open-source software to be functional but unattractive–Bugzilla needs a UI that not only works well, but also looks great!

To this end, we are having a contest for designers, to see who can come up with the best new design for Bugzilla. It’s called Make Bugzilla Pretty!

You don’t have to know anything about HTML or Bugzilla to enter (though it helps), you just have to be able to redesign and submit an image to us.

With your entry, you could be giving the world a great-looking open-source bug-tracking system, impacting the lives of millions of developers, forwarding the cause of open-source in the new decade, and getting some sweet promotion for yourself in the process!

We look forward to seeing what you come up with!

The First Bugzilla Users & Administrators Group: August 4, 2010

On Wednesday, August 4, we had the first Bugzilla Users & Administrators Group meeting, at the Wikimedia Foundation in San Francisco. In attendance were representatives from the Wikimedia Foundation, NASA, Yahoo!, the NTP Project, and the Bugzilla Project.

The event was catered with full meals and drinks (both beer and sodas) for anybody who wanted to take advantage of them.

Max Kanat-Alexander, one of the lead Bugzilla developers, went over some of the new features that are coming in Bugzilla 4.0, which spawned some discussion about WebServices between the attendees, and how best to use the new and existing features to implement various workflows.

This flowed nicely into a discussion of project management, and how best to implement project management around Bugzilla. The needs of the attendees around project management were all quite different, but we all generally agreed that the most important part of Project Management is ability to get an overview of the current status of a project at a glance. The Wikimedia Foundation had a a list of requirements for project management that more-or-less covered the advanced features that most organizations would expect from project management.

Yahoo! pointed out that many people have pre-existing project management systems that they are already comfortable with, so the most important thing is for Bugzilla to expose all of the interfaces that project management systems would need in order to interface with Bugzilla.

Once we had these requirements sorted out, the question was–how do we want to implement them?

Well, some things need to be implemented in Bugzilla itself, such as the ability for project management meetings to do simple mass-triage on a lot of bugs at once, using a single user interface. (For example, the ability to edit each field individually on each bug a list of bugs.)

However, most project management features belong in a separate product, perhaps an extension to Bugzilla, or maybe just a Mediawiki extension that allows for generating nice reports from Bugzilla. Most likely, we’ll end up with a combination of both–a Bugzilla Extension to add project management features to Bugzilla, and a Mediawiki extension to add more reporting and extended project management functionality.

It was universally agreed that the most important thing for us to do is to improve Bugzilla’s WebService interface until it can provide everything that an external Project Management tool would need, because even if we develop our own tool, there are still going to be a lot of people who want to use the tool that they’re already most familiar with, and offering integration points into Bugzilla will let people do that.

Our next meeting will be on Wednesday, December 8, 2010 at Yahoo! Inc. [alternate link: Faceook Event]. The focus of the meeting is going to be User Interface. We look forward to seeing you there!

-Max

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:

• Bug.update, which allows you to update all of a bug’s fields via the WebService.
• Bug.add_attachment, which lets you add an attachment to a bug via the WebService.

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

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

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:

• There is AJAX auto-completion of usernames in the CC, Assignee, and QA Contact boxes.
• The First/Last/Next/Prev and the “Show my last search results” links at the top of a bug now work with multiple searches, so doing a new search won’t “clobber” your old list.
• Bug ID custom fields can now represent relationships, much like “Blocks/Depends On” do now.
• You can now add Hours Worked to a bug without having to comment.
• There are now calendar widgets on every date field in the UI.
• The Voting system and the Bug Moving system have been moved into being extensions, and at some point will be maintained separately from the main Bugzilla codebase (though they still ship with Bugzilla, for now).
• email_in.pl now takes command-line arguments that allow you to specify defaults for field values, or override the field values specified in the incoming email.
• Multi-select custom fields can now be columns on bug lists.
• There is a new user preference for whether the “Additional Comment” box should show up before or after the existing comments.
• In the code, there is a new function $bug->set_all, which takes a bunch of arguments and updates a bug doing all the updates in the proper order, making it extremely easy for custom code to update bugs.
• The Bugzilla/Search.pm file (which implements the searching logic in Bugzilla) has been majorly refactored to be much simpler to understand and customize.
• When you do a quicksearch, the quicksearch boxes in the header and footer will contain your last search.
• You can now restrict the values and visibility of custom fields by the value of the Component field.
• Custom fields can now be marked as mandatory (that is, they must have a value).
• The “fields.html” page now contains help for every single bug field in Bugzilla, and the fields display the help when you hover over their names, on enter_bug.cgi.
• There are a lot of great new code hooks, including ones for adding new columns and validators to objects, and another for modifying bug field permissions (so you can make certain fields read-only for certain users, using a hook).
• Bugzilla can now be installed using Strawberry Perl, on Windows.
• Comments are no longer manually word-wrapped at 80 columns before being sent to the browser–they are just word-wrapped in the browser.
• Any time checksetup.pl throws an error, it will make it red to make it clearer.
• YUI has been updated to 2.8.1, and Bugzilla now contains almost all of YUI, so all YUI features are available to customizers.

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

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

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:

• Work is underway on a single-package Windows installer for Apache, MySQL, Perl, and Bugzilla.
• The voting system has become an extension, which also involved adding a few useful new hooks.
• You can specify “groups” as an argument when creating a bug via the WebService or email.
• The Assignee, QA Contact, and CC fields have autocomplete in the browser, via AJAX!
• You can restrict the visibility and values of custom fields by components.
• The Deadline field now has a Calendar widget attached to it.
• Bugzilla now sends email when a comment becomes private or un-private.
• You can undo “Forget Search” on the buglist if you forgot the search by accident.
• “Bug ID” fields can now represent relationships between bugs, like “Blocks”/”Depends On”.

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

• JSONP support for the JSON-RPC WebServices interface, so you can do secure cross-domain WebService calls on web pages.
• There’s some work towards making Bugzilla use HTML 5.
• The ability to restrict the visibility and values of custom fields by classification.
• More JavaScript validation of enter_bug.cgi when filing bugs

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