We released Bugzilla 4.4 and 4.2.6 today. Bugzilla 4.2.6 is a bugfix release, and contains no security fixes. It adds support for MySQL 5.6 and fixes a crash with Oracle.

Bugzilla 4.4 contains many new features:

• The searching system has been improved: it allows multiple search criteria to match one field; it has improved support for flags; it has better performance, especially with complex queries.
• The tagging system has been redesigned: the old tagging fields in the page footer are gone in favor of a Tags field in the bug itself. Tags remain private and are only visible by you. They can also be used in queries as any other field.
• Bugzilla can now correctly identify uploaded attachments which have a MIME type of application/octet-stream.
• You can now save tabular and graphical reports as you already do with saved searches. Previously, you had to bookmark them in your web browser.
• You can customize columns displayed in whinemails.
• As usual, the WebServices have been improved with several new methods.
• The security has been improved, such as using HMAC SHA-256 to generate tokens instead of MD5.
• etc ….

This release also means the End Of Life (EOL) of Bugzilla 3.6, which was the last series for Bugzilla 3.x. This branch is no longer supported, and any new security bug found on this branch will remain unfixed. Installations still running Bugzilla 2.x or 3.x are urged to upgrade to Bugzilla 4.4 or 4.2.6.

So, what’s next? Well, the main focus for Bugzilla 5.0 will be usability and user experience. Bugzilla sometimes (often?) looks old-fashioned because we wanted to support old browsers and browsers with JavaScript disabled. But we decided to move to a more interactive interface where JavaScript will help accomplish some tasks with less page reloads, such as submitting changes to a bug or adding an attachment. We also plan to add a new skin to Bugzilla which should look like this. Some pages will also be entirely redesigned, such as the Group Controls page to administrate access to bugs which was considered too complex for the average admin. More information will come with the release of development snapshots.

So, Bugzilla 4.4rc2 is finally here! It took us more time than expected, but the performance bugs are all fixed and we also fixed two security bugs which are described in the security advisory. Bugzilla 4.2.5, 4.0.10 and 3.6.13 also contain these two security fixes, so you should definitely upgrade.

Compared to 4.4rc1, the new release candidate contains the last feature which we wanted for 4.4: the ability to add several criteria in a query against the same field. In Bugzilla 4.2,

"Flags changed to approval+" AND "Flags changed by foo@bar.com"

were disconnected, which means that these criteria would match all bugs which had the approval+ flag set and which had a flag changed by foo@bar.com. In Bugzilla 4.4, you can now force these two criteria to match the same field, i.e. that you only want bugs where the approval+ flag has been set by foo@bar.com. Thanks to Byron Jones (glob) for this great feature. Of course, this feature is not limited to flags, but works with all fields. See the release notes for more details. Also, 4.4rc2 should in most cases be much faster than 4.2 to run some complex queries. In my testing, some queries which took several minutes to complete now run in a few (tens of) seconds only. This is especially noticable with many columns displayed in the buglist. Another good reason to test it!

The next release should be 4.4 final as I don’t think a 4.4rc3 is needed.

One instruction in the upgrade procedure for every release that often gets overlooked is to run the Sanity Check function from the Admin page on your Bugzilla site before upgrading.  It checks the integrity of the data in your database and will alert you to a number of possible problems with your data.  Sometimes bugs in Bugzilla or even people manually messing with the database will cause something to not be how Bugzilla expects it, and every so often one of these problems can cause issues for an upgrade.  Fixing any problems reported by Sanity Check before each upgrade can save you a lot of headaches.

In a recent example: newer versions of Bugzilla allow you to edit the available statuses and resolutions on bugs.  Older versions didn’t.  One of the steps performed by the upgrade script is to examine your database, take whatever current statuses you’ve been using (even if you hacked your Bugzilla to allow different ones before we actually let you customize them), and convert them to the way the new customizable ones are stored.  The new custom status system has a flag to distinguish between statuses that are allowed to have resolutions and those that aren’t.  When upgrading, it decides whether to set that flag on a status or not by looking in your database to see if there are any bugs with that status that have resolutions on them.  If it finds any, the status is set up to use them.

A long time ago there was Bug 107229 which caused duplicate bugs to get the wrong status if you midaired while marking it a duplicate.  This caused bugs to exist in an “ASSIGNED DUPLICATE” state that should have been “RESOLVED DUPLICATE”.  A side effect is if it was left that way, when you later upgraded to a version of Bugzilla that included the custom statuses, your ASSIGNED status became a “closed” type instead of an “open” one, and would require a resolution.  Sanity Check most likely would have caught this, as it checks for things like resolutions where there shouldn’t be any.

All of today’s releases contain security fixes. We recommend that all Bugzilla administrators read the Security Advisory that was published along with these releases.

Bugzilla 4.4rc1 is our first Release Candidate for Bugzilla 4.4. This release has received QA testing, and should be considerably more stable than the development releases before it. It is still not considered fully stable, and so you should understand that if you use it, you use it at your own risk.

If feedback from this release candidate indicates that it is mostly stable, then Bugzilla 4.4 will be released in a few weeks. If feedback indicates that more extensive fixes are needed, there may be another release candidate after this one.

• Download 4.4rc1
• Release Notes for 4.4rc1

Bugzilla 4.2.4 is our latest stable release. It contains various useful bug fixes and security improvements:

• Download 4.2.4
• Release Notes for 4.2.4

Bugzilla 4.0.9 is a security update for the 4.0 branch:

• Download 4.0.9
• Release Notes for 4.0.9

Bugzilla 3.6.12 is a security update for the 3.6 branch:

• Download 3.6.12
• Release Notes for 3.6.12

All of today’s releases contain security fixes. We recommend that all Bugzilla administrators read the Security Advisory that was published along with these releases.

Bugzilla 4.2.3 is our latest stable release. It contains various useful bug fixes and security improvements:

• Download 4.2.3
• Release Notes for 4.2.3

Bugzilla 4.0.8 is a security update for the 4.0 branch:

• Download 4.0.8
• Release Notes for 4.0.8

Bugzilla 3.6.11 is a security update for the 3.6 branch:

• Download 3.6.11
• Release Notes for 3.6.11

Bugzilla 4.3.3 is an unstable development release. This release has not received QA testing from the Bugzilla Project, and should not be used in production environments. Development releases exist as previews of the features that the next major release of Bugzilla will contain. They also exist for testing purposes, to collect bug reports and feedback, so if you find a bug in this development release (or you don’t like how some feature works) please tell us.

• Download 4.3.3

All of today’s releases contain security fixes. We recommend that all Bugzilla administrators read the Security Advisory that was published along with these releases.

Bugzilla 4.2.2 is our latest stable release. It contains various useful bug fixes and security improvements:

• Download 4.2.2
• Release Notes for 4.2.2

Bugzilla 4.0.7 is a security update for the 4.0 branch:

• Download 4.0.7
• Release Notes for 4.0.7

Bugzilla 3.6.10 is a security update for the 3.6 branch:

• Download 3.6.10
• Release Notes for 3.6.10

Bugzilla 4.3.2 is an unstable development release. This release has not received QA testing from the Bugzilla Project, and should not be used in production
environments. Development releases exist as previews of the features that the next major release of Bugzilla will contain. They also exist for testing purposes, to collect bug reports and feedback, so if you find
a bug in this development release (or you don’t like how some feature works) please tell us.

• Download 4.3.2

Bugzilla 4.2rc2 is our second Release Candidate for Bugzilla 4.2. This release has received QA testing, and should be considerably more stable than the development releases before it. It is still not considered fully stable, and so you should understand that if you use it, you use it at your own risk. This will most likely be the last release candidate before 4.2 final.

Bugzilla 4.0.4 is our latest stable release. It contains various useful bug fixes and security improvements for the 4.0 branch.

Bugzilla 3.6.8 and 3.4.14 are security updates for the 3.6 branch and the 3.4 branch, respectively.

All the gory details and download links and the security advisory are available on our website.

Get Involved

As always, we love new contributors in every area. There are a lot of ways to contribute to Bugzilla–you don’t just have to be a programmer. In particular, we’d really love to have somebody to be in charge of our documentation. If you know anybody who’s a great documenter (including yourself!) who wants to help out an open-source project, please send them our way!

Now, in 4.0.1 and 3.6.5, install-module.pl won’t install the module if installing it would break your system. Basically, following the standard installation instructions should work fine, now. Bugzilla 3.4.11 took this a step further and no longer uses Math::Random::Secure at all for this older branch (although don’t worry, Bugzilla 3.4.x is still secure).

For 4.1.2, we made this protection even more extreme–install-module.pl now completely refuses to operate if you don’t have a compiler installed somewhere on your system (because so many CPAN modules require a compiler, and CPAN throws very confusing error messages when there is no compiler available on your system).

New Features in 4.1.2

All right, with all that out of the way, let’s talk about new features in 4.1.2! Here’s a quick list of important new things:

• Extensions can call a web_dir method to get the on-disk path to where web-accessible files should go for the extensions.
• Work to improve Bugzilla’s accessibility (per the WAI WCAG) is ongoing.
• There’s a new hook in Bugzilla::Install::Filesystem to allow extensions to create their own files, directories, etc.
• Searching by relative dates (like 1d, 1w, etc.) now don’t round you off to the beginning of the time period (that is, the beginning of the day, the start of the week) unless you put the letter “s” after them (exception: searching for “0d” or “0w” still gives you the start of that the current day, week, etc.).
• New WebService function: Product.create
• New WebService function: Group.create
• If you change the requestee of a flag that is set to “?”, the “requester” will not change.
• install-module.pl now requires a compiler to be installed on the system.
• Update to YUI 2.9.0.
• contrib/bugzilla_ldapsync.rb has been removed (it was non-functional).
• If you are using some authentication method that uses the extern_id field (like LDAP), you can now edit a user’s extern_id from the Users control panel.

The Plan For Pretty

So, as you may have read, the “Make Bugzilla Pretty” contest is over, and Jonathan Wilde has won. The current plan is for his UI to be the new official UI for Bugzilla 5.0, which will come some time after 4.2.

Basically, the way that it will work is this: After we branch for 4.2, we will create a new “pretty” branch. The Bugzilla team will work on implementing the new UI in this branch, while simultaneously doing new feature development on the normal Bugzilla trunk. Once the “pretty” branch is ready, it will be merged back into the trunk. We can do this all fairly efficiently thanks to bzr.

Now, there is a chance that the “pretty” branch won’t be ready by the time we want to do the release that follows 4.2. In this case, that release will be called 4.4 and the release after that will have the new UI. However, we very much want to release the new UI as soon as possible, so our goal is for 5.0 to be the release after 4.2.

Get Involved

As always, we love new contributors in every area. There are a lot of ways to contribute to Bugzilla–you don’t just have to be a programmer. In particular, we’d really love to have somebody to be in charge of our documentation. If you know anybody who’s a great documenter (including yourself!) who wants to help out an open-source project, please send them our way!

-Max

First off, let me say that every single entry was amazing. Every single person who entered had innovative ideas, and nearly every entry was prettier than our current UI.

There were four candidates who were mentioned in some positive way by almost every voter:

• Long Duong
• Jonathan Wilde
• Alex Faaborg
• Zeeshan Syed

Any of these designers would be a worthwhile addition to any UX team anywhere. Simply the ability to take Bugzilla’s existing UI and turn it into something that nearly everybody finds attractive is an accomplishment that few designers could achieve. In the 13 years of Bugzilla’s history, I’ve never seen it done before these entries. I would be personally happy to write a recommendation for any of the above designers, and they may contact me for that if they wish.

Let’s just say a few words about each of these designs:

Alex Faaborg

There were a ton of positive comments on the usability aspects and organization of Alex Faaborg’s [Bracket] theme, particularly some of the new fields suggested and the brilliant use of color to improve the scanability of the page. It was impressive that everything on the page is basically text or lines, and yet it creates a very readable, clean, simple layout.

We expect future versions of Bugzilla to draw a lot on the usability concepts present in Faaborg’s design, even though it is not the first-place winner.

Zeeshan Syed

There were a lot of positive comments on the use of space in Zeeshan Syed’s design. The color contrast really makes things readable, the tab navigation is very clear, and the section titles really stand out.

Long Duong

Voters were almost overwhelmingly positive about Long Duong’s design. Many people mentioned that they liked the clean lines and very “Bugzilla” feel of the bug page, and that the collapsible sections were a great touch while still being visually appealing. There was also a lot of positive feedback about the header design–people really loved its organization and style. Finally, the home page design was just really cool.

Based on the number of votes and the general amount of positive feedback, Duong is our first runner-up for the Make Bugzilla Pretty contest, and it is very likely that we will end up incorporating some of his UI concepts into our final design.

Jonathan Wilde

This was a stiff competition, and all of the above designs would have worked great as our new UI. However, the winner of the “Make Bugzilla Pretty” contest, and indeed the recipient of the majority of votes, is Jonathan Wilde:

Jonathan’s ability to convert our UI into something beautiful and simple that even new users will find approachable is beyond anything that we had ever imagined could be done with Bugzilla. We are thrilled that Jonathan has won, and excited to implement his design as the official UI of Bugzilla 5.0.

Thanks to Everybody

We would like to thank everybody who entered. Your entries made this contest a fascinating and transformative experience for the Bugzilla Project. We were consistently amazed at the creativity, intelligence, and design sense that so many of you displayed, and wish you great fortune in the future of your careers.

-Max

• Bugzilla now sends bugmail in both text and HTML.
• You can disable component, milestone, and version values.
• You can now create an attachment by pasting it into a text field.
• If you are using a modern web browser, then after you update a bug, the URL in your web browser will be the URL to view the bug. (So, pressing refresh will simply let you see the bug, and not try to update it again. Also, if you have “session restore” in your browser, it will load the bug instead of an error page.)
• Comments are no longer automatically word-wrapped by the server, but are instead word-wrapped in the browser. This means that they are no longer exactly 80 characters wide–they are now wider.
• Tabular reports now look nicer and can be sorted.
• There is a new link, (take) that appears next to the Assignee field and allows you to assign a bug to yourself.
• Bugzilla can now run on SQLite as its database system. This is experimental and should not yet be used for production systems.
• You can now say that a custom field should only appear when any of a set of values are set on another field. (So, for example, you could say that a single field appears in multiple products.)
• You can now choose to optionally (as a user preference) not have Quicksearch search bug comments.
• The default list of columns for search results is now more sensible.
• Bugzilla now audits most changes to most things in the system, and stores this auditing information in a table in the database. There is not yet a UI into this table.
• The system for deciding how and when to store attachments on the disk (instead of in the database) has been simplified.
• long_list.cgi, xml.cgi, and showattachment.cgi are gone. (They were not in use since a very old version of Bugzilla.) We also removed sidebar.cgi (the sidebar) because it wasn’t in use and future versions of Firefox will not support it.
• You can search for bugs based on the number of comments that they have.
• Also, you can add “number of comments” as a column in your search results.
• Boolean charts now work sensibly for almost all fields. For example, searching for “CC is not equal to” now finds bugs where that user is not CC’ed, instead of all bugs that have at least one CC who isn’t that user. However, some of the old “magical” boolean chart functionality (such as searching for only attachment flags if you specify both a flag criterion and an attachment criterion) is temporarily missing while we redesign the search system.
• By default, searches now only return 500 results. (You can click a link to see more.) Searches may also now never return more than 10,000 results.
• The “See Also” field now accepts many more types of URLs. It also accepts simple bug numbers to refer to a bug in your current Bugzilla. Adding a local bug number to the “see also” field will also cause that bug’s “See Also” to point to this bug.
• If you only have the “editcomponents” privilege for one or more products, you can now manage Flags for those products.
• You can now specify “limit” and “offset” as URL parameters for all searches. These work much like their similar SQL equivalents.
• You can now require a certain level of password complexity for your users.
• When you run checksetup.pl to create a new Bugzilla database, it will print out far less information than it used to.
• Almost all of the important information that checksetup.pl prints out can now be localized.
• There is now a specific directory in bz_locations (in Bugzilla::Constants) for where the pre-compiled templates are stored, that can be customized.
• This release contains an initial implementation of a new tags system. The new UI for this tags system has not yet been implemented.
• There is now a special group for moderating quips, so you don’t have to be an admin.
• Bugzilla can now automatically detect the correct encoding for text attachments that aren’t in UTF-8.

Those are most of the major new changes that are in 4.1.1 over 4.0. We also have many other features planned for 4.2.

We hope that you enjoy testing Bugzilla 4.1.1 and we would love to hear your feedback, both on how the new features work and any bugs that you may find!

-Max

In addition to all of these huge features, though, there were a lot of smaller improvements that were pretty awesome in and of themselves. The major, major features are so huge that it’s easy to miss how great some of the other changes were, so I wanted to take some time in this blog to talk about some of those “smaller” improvements that can be pretty significant for some users.

UI Improvements

In addition to the redesigned search page, one of the biggest UI improvements is the new “attachment details” page (log in to see the full functionality). If you do a lot of code review in your Bugzilla, or if you open up attachments frequently to comment on them, you’ll appreciate the new full-size comment box and the enormous textarea space available for commenting inline on text attachments.

Also, another really nice change is that when you forget to set a required field on bug entry, you’re notified before you leave the page, instead of having to submit the form and then go back to add any missing data. Bugzilla highlights the fields you missed and puts a clear message in bold red letters on the page so that you can see what you need to fill out. It even puts the page focus on the first box you need to fix, now.

On the Search page and the bug entry page, you can hover over the label of any field to get a description of what that field does. Your mouse cursor will even change to indicate the availability of help. This should be particularly useful to people who are new to Bugzilla.

When you do a “quicksearch” using the box in the header or footer, your search will still be there when you see the search results, now. This makes editing the search you just did a lot easier.

There is a “Calendar” widget for every single date/time field in Bugzilla now.

You can choose to have the “Add a new comment” box above or below the existing comments, when viewing a bug, now. (See your Preferences.)

Every command-line script of Bugzilla now prints any error in red (if this is possible in your terminal), to make it really clear that running the script did not succeed.

And of course, this is pretty obvious, but there are great new icons for the Home page, now.

Custom Fields

People have long asked for the ability to make certain custom fields “mandatory”–that is, when filing a bug, you have to fill those fields out, and after the bug is filed, those fields can never be empty. Bugzilla 4.0 now supports this–all you have to do is check a single checkbox in the Administration UI, and your custom field becomes mandatory!

You can see “Multi-Select” custom fields as a column in your search results (the bug list) now!

Almost every custom field in your system will now be available as an axis for Graphical Reports and Tabular Reports. (Actually, a whole lot of other built-in fields are now available, too!)

You can now represent relationships between bugs when using the “Bug ID” field.

You can now display custom fields only in a certain Component or only in a certain Classification.

Search

Some people make really heavy use of the “Show my last search results” link, or the “First/Previous/Next/Last” links at the top of the bug page. In past versions of Bugzilla, doing a new search would entirely replace your “last search results”, meaning that “Show my last search results” and the “First/Previous/Next/Last” links would suddenly be working with a whole new set of bugs. Now Bugzilla “remembers” the last five search results for all logged-in users and does its best to give you the right list whenever you’re trying to navigate using those links on the bug page.

You can now search for attachments with specific flags on them, when using the Boolean Charts (which are now called “Custom Search”). Just specify a criteron for an attachment and a criterion for a flag in the same Chart.

Since almost the very first version of Bugzilla, you haven’t been able to search for a Product, Component, Target Milestone, etc. if its name contained a comma. Now you can!

WebServices

You can get data from the Bugzilla JSON-RPC WebService using HTTP GET, now, which is a lot easier in many situations. Also, you can even call the JSON-RPC WebServices from another domain using JSONP, meaning that you can use data from an external Bugzilla on your webpage, straight from JavaScript!

Also, there are a ton of new WebService functions and parameters available. See the full list of WebService improvements for details. Probably the biggest one is the new Bug.update function that allows you to update existing bugs.

Miscellaneous

Loading pages in Bugzilla should now be much faster, particularly if it’s your first time visiting Bugzilla, since we have eliminated the need for the browser to download a large number of unnecessary CSS files.

If you’re using time-tracking, you don’t have to enter a comment just to enter Hours Worked anymore!

If you’re setting up the Inbound Email interface, you can set defaults for certain fields using command-line switches.

If you are using a localized version of Bugzilla and your terminal does not understand Unicode, all of Bugzilla’s command-line scripts will now attempt to output their messages in your terminal’s character set.

If you are running Bugzilla under suexec (usually meaning that you’re on shared hosting), checksetup.pl now properly sets permissions on everything, meaning that all functionality of Bugzilla should now be working (including graphs and dependency trees).

Bugzilla now optionally supports sending the Strict-Transport-Security HTTP header for improved security on HTTPS installations.

If you are writing extensions, there are a ton of new hooks. The Extensions system is now capable of implementing the vast majority of possible extensions, particularly if you know a few tricks.

Future Plans

Now that 4.0 is released, we’re working on 4.2! Actually, we’ve been working on 4.2 for quite some time, and it already has some great new features, such as HTML bugmail and a new “tags” system that we’re implementing. We also expect to have a fully-redesigned Search backend that behaves consistently and intelligently for all searches while also performing considerably better than the current system does. There are already 100 enhancements marked as FIXED for 4.2, in fact! Check out that full list for details.

Currently our plan is to freeze for 4.2 on April 20, which would put our likely release date at some point in Q4 of 2011. Of course, depending on how many contributors we get, we could possibly release even earlier than that! Finding and fixing bugs in the trunk code is the fastest way to speed up our release process, so if you want to do that, see our development process for information on how to get our code and submit patches!

-Max

-Max

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

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

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

-Max

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

• 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

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

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