Posts Tagged '3.6'

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.


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).
  • 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/ 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 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!


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/

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


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:


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.


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


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.


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 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.