Planet Bugzilla

During the week-end, I received a pertinent email from a former Bugzilla developer who replied to an email I sent to all reviewers about the pretty low activity in the Bugzilla project during the current development cycle. He argued that one of the reasons which made him go away, and which probably took some other contributors away as well, is our high code quality standards we have in this project. The point is that we deny review if submitted patches do not follow our guidelines or are poorly written compared to what we expect in our codebase. He suggested that reviewers should accept and commit lower quality patches, and file follow-up bugs to clean up the new code. I then brought this discussion on IRC with other core developers, and we realized how hard it is to define the right level of code quality. The problems are:

• Some new features require some rewrite of some parts of the code to be easily extendable in the future and/or to reuse some existing code. These features could also be implemented without the code rewrite, which is easier to do for the contributor, but then would be harder to maintain, or would require to duplicate some existing code, which we try to avoid as much as possible. This is how Bugzilla 2.x was written, and it took us two full development cycles (Bugzilla 2.22 + 3.0) to clean up and rewrite the codebase to be able to implement new features in a reasonable way (the 2.x codebase became too ugly and complex to easily implement anything new on top of it). So the risk to accept such patches is that the codebase would become more messy again. But on the other hand, the risk is also to make contributors leave if we keep our high standards, because a rewrite is generally not something trivial nor exciting, and contributors generally do not understand why we reject a patch which does the job.
• Accepting patches which are of lower quality and filing follow-up bugs to fix the new code before the next release seems reasonable only if the community around the project is large enough to have the manpower to do the job in the expected timeframe. The current Bugzilla team is very small, maybe 4-5 core developers + some occasional contributors helping with some not too hard bugs. This isn’t large enough to expect these follow-up bugs to be fixed promptly. But we also cannot release a new version with poor code in it, some of the reasons being security implications, performance issues, or possible regressions in some use cases. As the community is small, fixing these bugs would delay the next major release a lot, which is not a desirable effect.
• Depending on how the submitted patch is written, it would take twice the time to review + rewrite the new code to match our standards compared to the time it would take for a core developer to write the patch himself. The lack of time being the main enemy, I personally wouldn’t want to spend more time on such or such feature because it’s not written as we would like it to be. The time spent to rewrite bad code means less time to work on other stuff.

So what’s the right threshold to not make new and occasional contributors go away without badly impacting our codebase? Which rules do other Mozilla and non-Mozilla projects use to solve this problem? Please share your experience with us.

May 15, 2012 05:56 PM

We released Bugzilla 4.3.1, 4.2.1, 4.0.6 and 3.6.9 a few hours ago, and they all contain 2 security fixes. All installations are highly encouraged to upgrade to these new releases. Bugzilla 3.6.9 and 4.0.6 only contain the two security fixes mentioned in the security advisory. Bugzilla 4.2.1 also contains a pretty large list of bug fixes, which makes it a good candidate to upgrade to the 4.2.x series if you didn’t upgrade to 4.2 yet. Note that Bugzilla 4.2.1 is also the first release to work with Testopia without needing to be patched first. A new release of Testopia should be available soon, which will take advantage of the improvements and new hooks available in 4.2.1.

We also released Bugzilla 4.3.1 which is the first development snapshot of the 4.4 series. I’m going to list some of the new features and improvements available:

• A new user preference lets you decide if you should be CC’ed when someone requests something from you via a flag. For instance, requesting someone for review would automatically CC the reviewer to the bug.
• Unset flags are now hidden by default, in bug reports.
• Duplicates are now listed at the top of the bug report, close to the dependency lists.
• URLs pointing to GitHub (github.com) are now accepted in the See Also field in bug reports.
• Personal tags can now be displayed in buglists. In Bugzilla 4.3.2, you will also be able to tag bugs from the bug reports themselves. This means the ugly box at the very bottom of every page will go away.
• You can now hide the description displayed at the top of buglists containing all the arguments passed to the query.
• You can now use pronouns (%reporter%, %user%, etc.) with the flag setter and requestee fields in boolean charts.
• A new email preference has been added to get emails when the product or the component of a bug changes.
• Bugzilla now keeps track of the last time a user used his account to access Bugzilla. This will let admins know which accounts are inactive.
• Bugzilla now supports SSL connections to SMTP servers.
• Target milestones can now be 64 characters long (instead of 20) to match the same limit as versions.
• Whine emails now correctly take the sort order of buglists into account.
• Several new WebServices methods: User.update, Product.update, Group.update, Bug.update_tags, Bugzilla.parameters (read-only), Bugzilla.last_audit_time.
• Several existing WebServices methods have been improved to return more data.
• The documentation is now generated using xmlto instead of jade.
• Several performance improvements have been made when viewing large bug reports.
• The Bugzilla source code now uses the MPL2.0 license, instead of the MPL1.1 one.

We are one month away from the freezing date for new features in Bugzilla 4.4. So if some of you really want something for 4.4, you have exactly one month left to submit patches, or find a kind developer to write the patch for you. Also note that Bugzilla 4.4 will be the last release to support Perl 5.8.x. The next major release, Bugzilla 4.6, will require Perl 5.10.1 or better.

April 19, 2012 01:10 AM

You probably noticed that there has been no activity related to the development of Testopia, a Bugzilla extension, for more than a year. The reason is that its maintainer, who was the single contributor to this project, had a new job and has no time to work on it anymore. Consequently, the latest version of this extension, Testopia 2.4, which was released in October 2010 (!), only works with Bugzilla 3.6, but not 4.x.

You will be happy to hear that with the help of some new contributors wanting to make Testopia work with Bugzilla 4.2, I committed several patches to the bzr repository which make it work pretty decently with Bugzilla 4.2.1 (probably also with Bugzilla 4.0.x, but I didn’t test). There is no official release yet (it should be named Testopia 2.5), but you can download updated files using bzr. Make sure to revert changes made to the core code of Bugzilla first before applying the new code.

To make things clear: I’m not the new maintainer of this extension, and I have no plan to take this role. I’m busy enough with my role as assistant project lead + reviewer + QA lead + bug triager + patch writer for the Bugzilla project. I simply decided to help the new contributors who jumped in these last few days and used my commit access to the Testopia repository to commit some patches. The Testopia maintainer is still alive, and emailed me this morning. So he is still the one who will take the decision to release 2.5 when it’s ready.

Update: Starting with Bugzilla 4.2.1, you no longer need to patch the source code of Bugzilla to make it work with Testopia 2.5! If you are upgrading from Testopia 2.4 or older, make sure to revert the changes made to the source code first.

April 09, 2012 05:58 PM

This is just a quick note to let you know that once we branch for Bugzilla 4.4 in May, I will commit a patch which will make Bugzilla 4.5 and newer to require Perl 5.10.1 as a minimum. This means Bugzilla won’t support Perl 5.8.x anymore. So Bugzilla 4.4 will be the last release to support the oldish Perl 5.8.x. This new requirement is tracked in bug 655477.

March 29, 2012 09:24 PM

There has been some complains these last few days on IRC and in the support mailing-list/newsgroup that admins couldn’t upgrade their Bugzilla installation to 4.2 due to the lack of a CVS mirror for this branch. As announced 3 years ago in the developers mailing-list and on b.m.o., and 1.5 years ago on the bugzilla.org website, the Bugzilla team switched from the old CVS to the more modern Bazaar (or bzr for short) VCS. If you use our tarballs to download Bugzilla, then you don’t really care about this change, and the process to upgrade won’t change for you. If you use CVS and you wonder how to upgrade using Bzr, here is how you can do it:

1. For now, there is no need to shut down Bugzilla. We will do this when we start the upgrade process itself. If you made changes to the Bugzilla code itself (instead of using its extension system), you will have to port these changes to the new version, else they will be lost. If you made no changes, or all changes are contained into extensions, you can jump to step 2 directly. To generate a patch with all the changes you made, go into your bugzilla/ directory and run this command:
   cvs diff -puN > patch.diff
   The file patch.diff will contain all the changes you made to your current installation.
2. Let’s download the new version of Bugzilla into a separate directory, to not mess with the current installation. Now you will need bzr. All Linux installations have it; have a look at your package manager. For instance, Fedora 16 has bzr-2.4.2-1.fc16.i686.rpm. On Windows, you can download it from canonical.com. The standalone application is recommended; for instance: bzr-2.4.2-1-setup.exe. Once bzr is installed, run this command to download Bugzilla 4.2:
   bzr co bzr://bzr.mozilla.org/bugzilla/4.2 bugzilla42
   Here, bzr co means “checkout”, i.e. it’s the first download of 4.2 with bzr. Then you have the URL to our Bugzilla 4.2 repository, and finally you have the name of the local directory into which to dowload the source code. If you don’t like the name bugzilla42, feel free to choose another one.
3. Now go into the new bugzilla42/ directory and run the following command:
   ./checksetup.pl –check-modules
   The –check-modules part is important for two reasons. First of all, we didn’t copy the configuration files from the old bugzilla/ directory into the new one. The advantage to do so is to prevent Bugzilla 4.2 from finding where your DB is located and start interacting with it. Remember that we did no backup of your DB yet! And the second reason is that we first want to make sure that we have all the required Perl modules installed. Between major releases of Bugzilla, the requirements may change, either by requiring new Perl modules, or by requiring a newer version of an existing Perl module. If you have missing or too old Perl modules, you will have to install or upgrade them, ideally using your package manager. On Windows, ActivePerl 5.12 and newer have all the required modules available, so that’s not a problem. On Linux, only old distros may have some missing or too old Perl modules. If this happens, you can use the install-module.pl script which is in the same directory as checksetup.pl to install them. The commands you need to execute are given by checksetup.pl –check-modules itself. So open your eyes. Note that you don’t need to install all the optional Perl modules. The reason is that they are…. optional! Only install those which are relevant to your installation.
4. If you made changes to your current Bugzilla installation, then you have to apply patch.diff you created at step 1 to your new installation. If you made no changes, you can jump to step 5 directly. If you are on Windows and you don’t have patch.exe, you can download it from sourceforge.net. Once downloaded, you must copy patch.exe into the Windows directory. At this point, it’s very likely that your changes will conflict with the new code, unless you are lucky or your changes are very minor. So we first check if there are conflicts or not. To do that, copy patch.diff into your new bugzilla42/ directory, and run this command from here:
   patch -p0 –dry-run < patch.diff
   –dry-run means that we made no changes to files; it was only a test. If all you get are messages such as “Hunk #1 succeeded at 79 (offset -26 lines)” or “Hunk #1 succeeded at 31 with fuzz 1 (offset 2 lines)”, then you are fine. But if you get messages such as “Hunk #1 FAILED at 27″ and “1 out of 2 hunks FAILED”, then you are in trouble. And don’t blame the Bugzilla team and Bzr, you would get the same errors with CVS! If the conflicts are minor, you can easily fix them manually, else you probably will have to rewrite your changes directly into the new code. If you have no conflicts, you can drop the –dry-run argument and apply your patch for real:
   patch -p0 < patch.diff
5. Now we are ready to start the upgrade process itself. The first thing to do is to shut down Bugzilla, because the DB must not be accessed by anyone but you during the upgrade process. To do that, go to Administration > Parameters > General > shutdownhtml, and add some explanation of what’s happening. For instance: “This installation is being upgraded to Bugzilla 4.2. The downtime should last approximatively 2 hours.”, and click the “Save Changes” button at the bottom of the page. I recommend that you don’t leave this page during the upgrade process, because all other pages will be deactivated besides this one. At this point, when someone tries to access Bugzilla during the downtime, this message will be displayed to them instead, so that you can upgrade your installation without having some users still interacting with it.
6. Then, and this rule applies all the time when upgrading to a newer major version: do a backup of your database! The reason is that once you start the upgrade process (i.e. when you run checksetup.pl), there is NO way to downgrade later. So if the upgrade process fails for some reason (most of the time because someone hacked the source code or the DB schema) and you made no backup, you are lost. To backup your DB with MySQL, run the following command, where you must replace $db_user and $db_name by their value set in your bugzilla/localconfig file (by default: $db_user = bugs; $db_name = bugs):
   mysqldump -u $db_user -p $db_name > db_backup.sql
7. Copy the whole data/ directory and the localconfig file from your old bugzilla/ directory into the new bugzilla42/ one. data/ contains your parameters in the data/params file, your local attachments in data/attachments/ as well as data for Old Charts in data/mining/. And localconfig contains all the parameters to access the DB, including its password, the name of the web server group, and some other useful configuration information. If you wrote some extensions, now is a good time to also copy them into bugzilla42/extensions/. Only copy the ones you wrote, not the existing ones such as BmpConvert, Example, OldBugMove or Voting, which are maintained by the Bugzilla team.
8. It’s now time to upgrade your DB to work with Bugzilla 4.2. From the bugzilla42/ directory, run ./checksetup.pl with no arguments (so no –check-modules anymore) and let it run the upgrade process for you. As you copied the configuration and parameters files, it knows where the DB is, its password, and everything else it should know about. Depending on the size of your DB and from which version you are upgrading, this may take from a few minutes to several hours. But typically, it’s of the order of a few tens of minutes for a DB with several tens of thousands of bugs. If everything went well, the last message displayed by checksetup.pl must be “checksetup.pl complete” displayed in green. Else this means something went wrong at some point. If half of the messages are in red, then there is no doubt about this.
9. The upgrade is now complete, and it’s time to let your users admire this new version. Replace your old bugzilla/ directory by the new one, and re-enable Bugzilla. To do that, you must remove the text you wrote for the shutdownhtml parameter. As we replaced the old directory by the new one, the URL pointing to Bugzilla remains unchanged. You now have a fully-working bzr-based Bugzilla installation.

 

March 02, 2012 03:04 PM

Now that Bugzilla 4.2 is released, I could finally focus on enhancements instead of fixing blockers and doing QA. This week, I decided to spend some time to improve the performance of Bugzilla. My main focus was show_bug.cgi, i.e. bug reports. I plan to look at other CGI scripts soon, hopefully within 2 weeks.

You will be happy to hear that in the last 3 days, I managed to divide the time spent to load large bug reports such as bmo bug 38862 (235 comments, 32 attachments and 55 CC’ed users) or bmo bug 18574 (760 comments, 63 attachments and 170 CC’ed users!!) by a factor of 2 when using mod_cgi (-50%), and by 30% with mod_perl. The exact load time in seconds depends on the bugs being viewed and on your hardware, but these percentages seem pretty consistent with the different tests done this week. All my patches have been checked in upstream (see rev. 8133 – 8142), and Bugzilla 4.3.1 will be the first release to benefit from them all. Two of them have been backported to 4.2.1 as they are well contained and fix obvious problems, and the other ones are either too invasive for a stable branch or have unclear benefits (the perf win varies between a few 1/1oth of second to 2-3 seconds depending on the test installation).

Now talking about bmo specifically, I gave a look at the InlineHistory extension for the first time, and I proposed a patch which highly decreases the load time of bug reports. dkl did some testing for me with and without mod_perl, and he found these results:

for bug 38862: 5.18 s (unpatched) -> 3.01 s (patched)

for bug 18574 + mod_cgi: 8.01 s (unpatched) -> 4.57 s (patched)

for bug 18574 + mod_perl: 5.76 s (unpatched) -> 4.06 s (patched)

Now I hope the same gain will be visible once these patches are applied to bmo, but the hardware + software configurations of bmo are so different from our test environments that it’s hard to say for sure till the changes are committed and pushed to production. Fingers crossed!

March 02, 2012 12:49 AM

We released Bugzilla 4.2 today, exactly one year after our previous major release, 4.0! Bugzilla 4.2 now supports SQLite, lets you create attachments simply by pasting text into a text field, can send bug changes notifications in HTML format, supports more complex queries, lets you disable old target milestones, versions and components (so that you don’t need to delete them, but also don’t let users report new bugs to them), has accessibility improvements, and much more…

This release also means that Bugzilla 3.4.x is no longer supported. Installations still running 3.4.14 or older are highly encouraged to upgrade to 4.2, especially to benefit from the security improvements made in newer versions. This also means that Bugzilla 4.0.x will now only get security fixes, and other bug fixes won’t be accepted on this branch anymore, unless they fix critical flaws, such as upgrade issues or dataloss.

The Bugzilla team will now focus on the next major release, Bugzilla 4.4, which we expect to release before the end of the year. We expect to release the first development snapshot (4.3.1) in a few weeks. New features will be accepted for the next two months, till the end of April. Then we will focus on stabilization to prepare Bugzilla 4.4rc1.

If you are interested in helping with the development of Bugzilla, now is a good time to join the team and contribute with new features and/or bug fixes. Due to other activities and because life can sometimes make you very busy, some core developers had to stop their contributions to the Bugzilla project in the last few months and so we would be very happy to see new faces. Bugzilla needs to be faster, nicer, more user friendly, and all this is only possible with your help, your ideas and your feedback. So even if you aren’t a Perl expert, there is a lot of place for everyone (you  can do a lot with HTML + JS + CSS only, think about the User Interface!). If you are not sure about how to contribute or help, feel free to join us on IRC in the #bugzilla channel. There is always someone around to answer your questions.

February 22, 2012 11:50 PM

We released Bugzilla 4.2rc2, 4.0.4, 3.6.8 and 3.4.14 a few minutes ago. They all contain various security fixes which are described in the Security Advisory. 4.2rc2 should be our last release candidate before 4.2 final, which we expect to release in the 2nd half of February. On the other end, 3.4.14 is very likely our last release for the 3.4 branch. Once 4.2 final is released, we won’t support 3.4 any longer. This means that admins still running 3.4.x or older are highly encouraged to upgrade. Users should pester their admins to upgrade if they don’t do it themselves.

Now is a good time to explain (again) why upgrading is not only about getting new features and bug fixes, but also to keep your installation secure. Below are some security fixes and/or enhancements made to various releases:

X-XSS-Protection header

Since Bugzilla 4.4, the X-XSS-Protection header is used to block simple XSS attacks.

CSRF vulnerabilities in attachment.cgi and post_bug.cgi

Till recently, no token check was done before accepting new bug submissions or before uploading an attachment to an existing bug. The rationale behind this was that in older versions of Bugzilla there was no easy way to do it from the WebServices API, and we didn’t want to break existing 3rd-party tools which were legitimately interacting with Bugzilla. As the lack of token validation could be used by attackers to submit unwanted new bugs or attachments, it has been decided that a token was required in these cases too, and not only when updating a bug or an attachment. But to not break 3rd-party tools, these token checks have been implemented in Bugzilla 4.2 only, meaning that Bugzilla 4.0 and older are still vulnerable to these attacks. If you want your installation to be protected against this kind of vulnerabilities, upgrade to 4.2!

Configurable password complexity for user accounts

Bugzilla 4.2 has a new parameter which lets admins decide how complex a password must be to be accepted by Bugzilla. Up to 4.0, Bugzilla accepted all passwords which were long enough (min 6 characters by default). Now you can enforce the complexity: uppercase + lowercase characters, letters + numbers, etc… If you want this feature, upgrade to 4.2!

Clickjacking in attachments with the text/html MIME type

As Bugzilla accepts all attachments independently of their MIME type, it was possible to attach HTML files which could try to abuse users using a method known as clickjacking. To prevent this, the “Details” page of attachments now display the source code of these HTML files instead of rendering them. This security enhancement has been implemented in Bugzilla 4.0.4 and newer (including 4.2). If you want it, upgrade!

X-Frame-Options: sameorigin header

Since Bugzilla 4.0, the X-Frame-Options: SAMEORIGIN header is sent for all pages (besides attachments when delivered from their alternate host). This prevents to load a Bugzilla page from within a frame outside Bugzilla itself. This, combined with the clickjacking protection above, prevents an attacker to create an HTML page with malicious code in it to force a user to make undesired changes to Bugzilla. If you want this, upgrade!

Strict-Transport-Security (STS) header

Since Bugzilla 4.0, a new parameter lets admins enable the Strict-Transport-Security header to force the communication between Bugzilla and the user to be made over SSL only. This prevents data to be sent unencrypted.

X-Content-Type-Options: nosniff header

To prevent Internet Explorer 8 and newer from sniffing the content of attachments, Bugzilla 4.0 and newer now pass the X-Content-Type-Options: nosniff header to avoid some malicious attachments to be rendered as HTML files.

Lockout policy to prevent brute force

Since Bugzilla 3.6, if you try to guess someone else’s password and you fail 5 consecutive times, your IP is blocked for the next 30 minutes. If you still run Bugzilla 3.4 or older, Bugzilla will accept all your attempts to crack the victim’s password, severely increasing the risk that the attacker manages to do it.

And much more…

Those of you who are still running very old versions of Bugzilla (older than 3.2) don’t have their login cookies protected against JavaScript as they don’t have the HttpOnly attribute set. This means a malicious HTML page could steal your login cookies very easily and they could then be used to impersonate your user account. These same cookies also do not have the Secure attribute set which prevents them to be transmitted on unsecure connections. And last but not least, tokens used by Bugzilla 3.2.9 and older are not generated using a cryptographically secure pseudorandom number generator. This means that with some effort, your installation could be abused by an attacker who managed to guess how tokens are generated in your installation.

Now I think you know enough about security features implemented in Bugzilla to decide what you want to do. If security matters to you, you should upgrade to at least Bugzilla 4.0.4, and seriously plan to upgrade to 4.2 once it’s released later this month.

February 01, 2012 01:40 AM

Today we are announcing the second Release Candidate for Bugzilla 4.2, in addition to one new stable release and two security-only updates for the 3.4.x and 3.6.x series.

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!

February 01, 2012 12:08 AM

L’âge minimum pour posséder un compte sur Google+ a été abaissé par Google! Alors qu’il fallait auparavant être âgé d’au moins 18 ans, cette limite a été abaissée à 13 ans (sauf pour l’Espagne et la Corée du Sud: 14 ans, ainsi que les Pays-Bas: 16 ans). Cette limite d’âge est donc maintenant la même que pour Facebook et Twitter. Il y a fort à parier que cela va faire exploser le nombre de comptes Google+ dans les semaines à venir. Reste à savoir si cela sera suffisant pour concurrencer Facebook et ses 800 millions d’utilisateurs.

January 29, 2012 07:48 PM

After a very long delay due to some nasty blockers, we finally released Bugzilla 4.2rc1 last night! Just to name a few new features or improvements:

• SQLite is now supported and becomes the 4th supported database besides MySQL, PostgreSQL and Oracle. Its support must still be considered as experimental, though.
• It is now possible to create an attachment by pasting text into a text field, without having to save your text as a file on your machine. Of course, you can still upload files as you always did.
• By default, bugmails are now sent in HTML format instead of the plain text format used till now. There is a user preference to select the format you want (text only, or text+html).
• The searching system has been improved, especially the Custom Search section in the Advanced Search page. It’s now easier to build more complex queries.
• Old components, versions and milestones can be disabled if you no longer want users to  use them. Bugs which already use them are not affected, but users won’t be able to report new bugs into them (e.g. against an old version, or against a deprecated component).
• A custom field can now be displayed based on multiple values of another field. For instance, this lets you display a custom field in several products. Till now, you had to choose between a single product and all products.
• Most administrative changes made in Bugzilla are now logged and stored in the audit_log table. There is no UI to access this table yet, but developers can already start build their own tools for auditing.
• There have been several accessibility improvements to become more compliant with the W3C Web Accessibility Initiative. The project just started, and a lot of work is still needed.
• Users without editbugs privileges can no longer remove other users from the CC list of bugs.
• The encoding of text files can be automatically detected when uploading them as attachments.
• Tabular reports are now sortable based on any column.
• Buglists have a new default column list: product | component | assignee | bug status | resolution | bug summary | last change date
• Math::Random::Secure is no longer used to generate cryptographically secure pseudorandom numbers. We use Math::Random::ISAAC instead.
• X-Frame-Options = SAMEORIGIN is now passed to all page headers to protect users from framing and subsequent possible clickjacking problems.
• Two new WebServices methods have been added: Product.create and Group.create.
• Bugmails are now fully localizable and customizable (no hardcoded strings anymore).

Read the complete Release Notes to discover other new features or improvements. As it’s still a release candidate, do not forget to report any regression or broken feature to us, so that we can investigate and fix them before 4.2 final.

IMPORTANT NOTE FOR ORACLE USERS: There is still a bug when upgrading to 4.2rc1 using Oracle. Make sure to apply the patch from bug 715870 before upgrading! This patch will be in 4.2 final (or 4.2rc2, if there is one).

We also released Bugzilla 4.0.3, which is our current stable release, and Bugzilla 3.6.7 and 3.4.13. All these releases contain two security fixes. Bugzilla 4.2rc1 also has some security improvements which have not been backported to stable branches to not break 3rd-party applications.

With the coming release of Bugzilla 4.2, the 3.4.x series will reach End Of Life, meaning that no more security fixes will be released for this series. If you have Bugzilla 3.4.x or older, you are highly encouraged to upgrade to Bugzilla 4.2rc1 or 4.0.3.

December 29, 2011 10:30 AM

(If you have tips to share on using Bugzilla, please email them to gerv@mozilla.org.)

Mozilla’s Bugzilla now has a left-click menu whenever you see a user displayed. You can email the user (which was the previous left-click action, or see what they’ve been up to in Bugzilla recently on the Activity screen. Administrators can also jump straight to editing that user’s account.

November 29, 2011 11:59 AM

I just created an “official” Bugzilla page on Google+: https://plus.google.com/104215203522965843895. Feel free to look at it from time to time to get the latest news about the Bugzilla development.

November 14, 2011 05:02 PM

A few weeks ago, kernel.org was compromised. Today, it’s the turn of WineHQ.org with all its credentials stolen (email addresses and encrypted passwords). Who is next?

Note: I won’t give any price to the winner.

October 11, 2011 08:52 PM

If you are like me and want to compile DBD::Oracle to use with Bugzilla and your installation of Oracle 10g XE, simply type the following command from the bugzilla/ root directory:
ORACLE_SID=XE
ORACLE_HOME=/usr/lib/oracle/xe/app/oracle/product/10.2.0/server
LD_LIBRARY_PATH=$ORACLE_HOME/lib
./install-module.pl DBD::Oracle

Of course, you must have installed oracle-xe-univ-10.2.0.1-1.0.i386.rpm already. This should save you a few headaches to make it work.

August 11, 2011 12:37 AM

More than 3 months after our last releases, we finally released Bugzilla 4.1.3, 4.0.2, 3.6.6 and 3.4.12 last night. Bugzilla 3.6.6 and 3.4.12 are security releases for our old supported branches. Bugzilla 4.0.2 contains security fixes and several useful bug fixes, including:

• The Bug.create() WebService method now throws an error if you pass a group name which doesn’t exist. In Bugzilla 4.0 and 4.0.1, this group name was silently ignored, leaving your bug unsecure if no other group applied.
• Moving several bugs at once into another product works again. In Bugzilla 4.0 and 4.0.1, it displayed the same confirmation page again and again, and changes were never committed.
• Marking a bug as a duplicate now works in Internet Explorer 9.
• The XML-RPC interface now works with SOAP::Lite 0.711 and 0.712 under mod_perl.
• and much more!

I strongly recommend to upgrade to 4.0.2, which is much more stable and usable than 4.0 or 4.0.1!

And for those who love to live dangerously, we also released Bugzilla 4.1.3, our lastest development snapshot. It contains all the security and bug fixes mentioned above. As we don’t accept any new features for Bugzilla 4.2 since we released 4.1.2, we focused on fixing regressions and other nasty bugs. Bugzilla 4.1.3 should be much more usable than 4.1.2, even if it’s not production-quality yet. Depending on how things go and the feedback we get, this could be the last development snapshot before 4.2rc1. Note that once Bugzilla 4.2 is released (probably near the end of this year), Bugzilla 3.4 will reach End Of Life and we won’t support this branch anymore.

August 05, 2011 11:12 AM

We had another Bugzilla meeting on IRC yesterday (channel log), and the three topics were about Bugzilla 4.0.2, 4.2rc1 and about Bugzilla 5.0. So I’m going to give you a brief summary of what has been discussed.

Bugzilla 4.0.2

We still have a few blockers for 4.0.2. Due to security bugs being under investigation, we are probably going to release Bugzilla 4.0.2, 4.1.3, 3.6.6 and 3.4.12 before we branch for 4.2rc1. ETA: asap (I cannot be more precise as it all depends on our free time, as we are all volunteers; but this should be done in the coming few days or weeks)!

Bugzilla 4.2rc1

The list of blockers for 4.2rc1 is pretty large. Fortunately, they all have a developer assigned to them, and so we can expect some activity there, at least once the security releases mentioned above are out. ETA: several weeks, maybe July?

Bugzilla 5.0

What will come after Bugzilla 4.2 depends on the progress made to redo the UI of Bugzilla, especially about show_bug.cgi, see bug 662605. Once the new UI is complete, we will call Bugzilla 5.0. Meanwhile, we will release Bugzilla 4.4, 4.6, … till the new UI (which is developed in its own branch) is merged with the main tree. Besides the new UI, we defined some main goals for the next release (independently of its version being 4.4 or 5.0), and we will try to fix as many of them during the next development cycle. As major Bugzilla releases are time-based, instead of feature-based, probably not all these enhancements will be implemented on time for the next release. If there is one you really cannot live without, feel free to join us and help implement them. New contributors are always welcome!

June 08, 2011 08:30 PM

Before programming, programmers usually go to school at least till the age of 16 (and then there is also high school and university for some of them). During the secondary school, pupils all learn the order of operations in mathematics. In particular, they all learn that -4^2 = -16, because exponents always take precedence over +, -, * and /. There is no exception to this rule, except in the world of spreadsheets, including Excel, OpenOffice and LibreOffice. Here, there are some developers (I hope not all of them) who either never went to school, or preferred to sleep during maths classes. Why? Because in their world, -4^2 = 16. Arghh! In the world of spreadsheets, only Gnumeric developers seem to have gone to school and remember what their maths teachers told them, and Gnumeric works just fine. Oh, and guess what? Scientific tools like Gnuplot and Mathematica also return -16, as well as Perl and Python and probably mostly everything else which exists in the world.

But when you report this bug to the OpenOffice (see also here) and LibreOffice Bugzilla installations, you are considered as being completely dumb:

OpenOffice bug 24271 comment 1:

"you're wrong. The function works according to the
 mathematical rules.

 -4^2 is -4*-4 or 16"

OpenOffice bug 24271 comment 27:

"Result of input '=-2^4' can't be anything else than (-2)^4!
 Here the '-' can't be anything else than an algebraic sign,
 interpretation as a subtraction operator for  '-(2^4) is
 completely useless like a mathematical expression '/3'"

LibreOffice bug 37271 comment 1:

"Imho LibO "intuitively" correctly recognizes the difference
 between a "Sign of a number" ant the subtraction operator. 

 I disagree with reporter's interpretation. [...]
 Please provide information concerning public available
 mathematical sources supporting your thesis."

These last two comments are from the same developer (one who definitely never went to school). The OpenOffice bug has been marked as INVALID, and the LibreOffice bug has been marked as NOTABUG (a synonym but more polite bug resolution to say INVALID). It’s just unacceptable that developers intentionally ignore mathematicals rules which are universally accepted across the whole world, and decide to reimplement their own rules, and then treat users who are totally right as if they said that 1+1=3. A more respectful (but still unsatisfying) bug resolution would have been WONTFIX with the comment that the reporters of the bugs are right, but due to the way Excel works, and for compatibility reasons with Excel, they are forced to do this incorrect statement that -X^2 = (-X)^2. Also, the helper assistant should pop up and warn the user about this misbehavior.

I hope the developers who wrote these comments above are not the ones who write the core code of OpenOffice/LibreOffice! Else I wouldn’t be surprised to discover that 1+1=3 is finally correct too.

May 17, 2011 07:09 PM

Just changed email address?

Unlike many sites, it is possible in Bugzilla to change your login name/username/email address. I can be done in the Preferences, on the Email Preferences tab, with the box marked “New Email Address”.

This is much preferred to creating a new account and then trying to migrate all of your CCs and watchlists, or realising you did the wrong thing and asking an admin to ‘merge’ the accounts. If you have created a new account for your new address but not really used it yet, and want to “undo” your mistake, change the address for the new account to something throwaway, and then change the address for the old account to your new real email address. If you have used both accounts significantly, you’ll have to ask the admins to do a merge. Not all Bugzilla admins may be able to do this, as it’s not a supported feature of the software with a UI.

May 09, 2011 07:48 PM

I recently did up a diagram of how our Bugzilla site was set up, mostly for the benefit of other sysadmins trying to find the various pieces of it.  Several folks expressed interest in sharing it with the community just to show an example of how we were set up.  So I cleaned it up a little, and here it is:

At first glance it looks somewhat excessive just for a Bugzilla, but since the Mozilla Project lives and dies by the content of this site, all work pretty much stops if it doesn’t work, so it’s one of our highest-priority sites to keep operating at all times for developer support.  The actual hardware required to run the site at full capacity for the amount of users we get hitting it is a little less than half of what’s shown in the diagram.

We have the entire site set up in two different datacenters (SJC1 is our San Jose datacenter, PHX1 is our Phoenix datacenter).  Thanks to the load balancers taking care of the cross-datacenter connections for the master databases, it’s actually possible to run it from both sites concurrently to split the load.  But because of the amount of traffic Bugzilla does to the master databases, and the latency in connection setup over that distance, it’s a little bit slow from whichever datacenter isn’t currently hosting the master, so we’ve been trying to keep DNS pointed at just one of them to keep it speedy.

This still works great as a hot failover, though, which got tested in action this last Sunday when we had a system board failure on the master database server in Phoenix.  Failing the entire site over to San Jose took only minutes, and the tech from HP showed up to swap the system board 4 hours later.  The fun part was that I had only finished setting up this hot failover setup about a week prior, so the timing couldn’t have been any better for that system board failure.  If it had happened any sooner we might have been down for a long time waiting for the server to get fixed.

When everything is operational, we’re trying to keep it primarily hosted in Phoenix.  As you can see in the diagram, the database servers in Phoenix are using solid-state disks for the database storage. The speed improvement when running large queries that is gained by using these instead of traditional spinning disks is just amazing.  I haven’t done any actual timing to get hard facts on that, but the difference is large enough that you can easily notice it just from using the site.

May 04, 2011 06:40 PM

For Bugzillas with the Sitemap extension, which now includes bugzilla.mozilla.org, you can search Bugzilla using Google, with site:bugzilla.mozilla.org.

May 04, 2011 04:39 PM

Hey Bugzilla users! We just released four new versions of Bugzilla. There were a lot of cool bug fixes in 3.6.5 and 4.0.1, but most importantly, if you had trouble installing Bugzilla 4.0, you should try again now with Bugzilla 4.0.1. There was a problem with the way that our install-module.pl script installed the Math::Random::Secure module–basically, it would install the module even though the module’s prerequisites failed to install. Then when you tried to run checksetup.pl, Math::Random::Secure would throw a cryptic error about “Math::Random::Secure::irand.”

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

April 28, 2011 03:40 AM

All the votes are in for the “Make Bugzilla Pretty” contest, and we have a winner!

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

April 01, 2011 01:18 AM

Since the release of Bugzilla 4.0 in mid-February, you may have noticed that I strongly reduced my involvement in the Bugzilla project. There are several reasons for this decision:

• I spent so much time at the end of last year and at the beginning of this one in writing and reviewing patches to fix the remaining nasty blockers for 4.0 that I needed some rest. As the QA lead, I also spent a fair amount of time checking all the regressions reported in the last few months and testing Bugzilla 4.0 as much as possible to make sure it was ready for release. Among others, this meant also updating all our automatic QA test scripts (which use Selenium) to correctly run with 4.0.
• I was also involved in several discussions taking place among core developers and managers about the way Bugzilla should go and the way the Bugzilla project is managed, and there are some hot topics where we are far from a consensus. All these discussions take a lot of time and energy too. This is not the right place to give details, though. Those who are concerned by these discussions already know the details.
• The main reason why I joined the Bugzilla team in August 2004 was because there were obvious broken or missing features in the version of Bugzilla available at that time, i.e. Bugzilla 2.18rc2. As the code didn’t look too terrible, I decided to give it a try and fix some bugs myself, and that’s how I started contributing. But as time passed, obvious broken features were fixed, and obvious missing features were implemented. So I then focused on more difficult, but less annoying, bugs and missing features. And with the releases of Bugzilla 4.0 and 4.1.1, I came to a point where all I think was important to have was there. You guess what this means. My motivation to implement new features obviously decreased, mostly because they aren’t trivial to implement and the benefit for users is smaller.

I think now is a good time to see how much I contributed to the project in these last 7 years, and what I achieved during this time. As I was checking this myself today, I thought you may be curious to know what were my main contributions, and so I decided to share the list below. Note that I fixed 1224 bugs in the Bugzilla product, so I’m not going to list them all. Only the outstanding bug fixes and new features are listed below, ordered by release versions:

Bugzilla 2.16 – 4.0

34 security bugs, across all versions.

Bugzilla 2.18

Bug 206037: There were many places where user data was incorrectly filtered before being displayed in the web browser, which could potentially lead to XSS or break pages entirely. This was a pain to fix all these places, and I had no fun in doing this, but it was necessary to really protect our users.

Other contributions for this release were all bug fixes as Bugzilla 2.18 was already feature frozen when I joined the project.

Bugzilla 2.20

Bug 180879: Till now, everybody could edit flags in bugs. I implemented permissions for flags so that admins could decide who would be allowed to request a flag, and who would be allowed to grant and deny them. Mozilla uses this feature heavily e.g. for their blocking and approval flags.

Bug 319055: If a bug comment had a “.” on its own line, the remaining part of the comment was skipped in bugmails.

In this release, I also helped with the cleanup process to remove all these old %FORM, SendSQL() and other oddities which were in Bugzilla 2.x.

Bugzilla 2.22

Bug 46296: Till now, all parameters were listed in a single page, making the page ridiculously long and parameters hard to find. I refactored this into separate panels, grouped by topic. I also did it in a way that parameter descriptions could be localized.

Bug 301508: CGI.pl was a kind of black hole with tons of subroutines in it, to achieve many unrelated goals. With the help of other developers, we moved these subroutines into modules, grouped logically. This was a required cleanup to be able to develop new features without adding additional mess to the code.

Bug 313020: I implemented the ability to tag bugs individually. These tags then appeared as normal saved searches in the footer of pages, so that you could easily list all bugs with the same tag.

I also helped with removing stuff from globals.pl, another black hole used in previous releases.

Bugzilla 3.0

Bug 38862: In order to protect users from malicious attachments, I implemented the ability to specify an alternate host for attachments. You can even set it to have one different host per bug, to avoid attachments from one bug to interact with attachments from another bug. That’s the configuration used e.g. by Mozilla.

Bug 44595: I implemented the ability for admins to delete attachments, e.g. malicious ones, or because they contain confidential data which wasn’t supposed to be attached to the bug.

Bug 87795: When creating a new user account, you now get a token by email to confirm that your email address is valid, rather than assuming that it’s the case and sending the password by email directly. This also lets you choose your password yourself rather than generating a random one automatically.

Bug 92515: When the resolution on a bug is wrong, you can now change it without having to first reopen the bug. In some other bugs, I also fixed several such annoying two-steps processes which were not needed and irritating.

Bug 94534: I implemented the ability for admins to customize the list of bug resolutions. Admins can add/edit/remove resolutions from the web UI directly instead of having to hack the source code to make it work.

Bug 174039: When filing a new bug, you can set flags at the same time, instead of having to file the bug first and then edit it.

Bug 189627: I implemented the ability to give canconfirm, editbugs and editcomponents privs on a per-product basis so that installations with many distinct products can better separate user privileges (and only give privileges for products they are working on).

Bug 274802: Previously, when you were moving a bug from one product which has some given flag types to another product which has a different set of flag types, all existing flags set to the bug were deleted. Now, if the target product has a flag type with the same name as the original product, Bugzilla migrate the old flag to the new one.

Bug 282121: globals.pl is now gone. All subroutines have been moved into their respective modules. At this point, we can say that the old and ugly code has been removed from the source code. Bugzilla 3.0 is born!

Bug 287326: I implemented the ability to add custom single-select fields to bugs. This was the second custom field type being implemented, after free text fields.

Bug 317409: I implemented the ability to hide obsolete attachments in bug reports.

Bug 330487: In Bugzilla 2.x, an admin had to manually check if there were new releases of Bugzilla, or at least watch some mailing-list to get this information. Now, Bugzilla can automatically notify admins when a new release is available.

Bug 340426: It was a pain to be forced to scroll to the bottom of the page to access links such as “New”, “Search”, “Log in”, etc… I duplicated these links to the top of the page to avoid this problem.

Bug 344875: I implemented the ability to create and control custom fields from the web UI. Before that, you had to run a script from the shell.

Bug 354661: I created a search plugin for Firefox 2+ and IE 7+.

Bugzilla 3.2

Bug 101179: Till now, bug statuses were hardcoded in the source code. Admins can now add/edit/remove them from the web UI. I also implemented the ability to control which transitions were allowed.

Bug 218618: When viewing a patch, line numbers are now displayed, greatly helping to locate code and changes in files.

Bug 304005: Bugzilla is now able to authenticate against a SMTP server to send bugmails.

Bugzilla 3.4:

Bug 182238: Till now, the timezone used to display the timestamp of comments was controlled by the admin. Now, each user can select the timezone of his choice.

Bugzilla 3.6

Bug 108243: You can now display bug flags in buglists.

Bug 302542: You can now delete series in new charts, either one by one, or when deleting a product.

Bugzilla 4.0

Nothing exciting from me in this release. I spent most of my time fixing regressions and doing QA. I only implemented minor new stuff.

Bugzilla 4.2

Bug 119703: You can now create an attachment simply by pasting text into a text field, instead of being forced to attach a file.

Bug 142394: You can now sort columns in tabular reports.

Bug 466968: I did a major cleanup of the mail-generation code. It’s now much easier to extend and customize it, and bugmails are now fully localizable.

Bug 529974: Users with local editcomponents privs, i.e having such privs for some products only, can now also edit flag types for these products. Before that, you had to ask someone with global editcomponents privs to do changes for you.

As you can see, I hacked many different parts of the Bugzilla code, implementing various major features. Now, I came to the point where I think I implemented most things I considered important, from my point of view. I still have one last new feature which is in progress, which is the ability to identify the sender of an email sent to email_in.pl, see bug 419203. I hope to have this feature ready for 4.2. After that, it’s unclear what my contributions to the project will be, if any. There are two additional features which would be great to see being implemented:

• Bug 123130: Let several Bugzilla installations talk to each other, e.g. for dependencies or to get the bug status and resolution of an external bug.
• Bug 55970: Add the ability to better track progress of a bug relative to several branches.

I think those two features together would be great candidates to define what would be called Bugzilla 5.0. But maybe I won’t be around anymore when this happens, as Bugzilla 5.0 isn’t expected before 2012 at the earliest (Bugzilla 4.2 will be released at the end of 2011, and I suppose there will be a 4.4 before 5.0).

March 31, 2011 11:23 PM

Less than a month after our release of 4.0, we have our first development snapshot, Bugzilla 4.1.1 available for you! This is our first release towards what will eventually be 4.2, and it’s got a bunch of new features. Here’s a really quick overview of what’s new in 4.2:

• 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

March 14, 2011 07:06 AM

On http://www.debian.org/security/, I can read:

“Debian takes security very seriously. We handle all security problems brought to our attention and ensure that they are corrected within a reasonable timeframe.”

By default, there is no reason to not believe them. But while talking with the administrator of Samba Bugzilla in bug 7121, I realized this was far from being true! What follows is specific to the Bugzilla case, but I guess there are plenty of other similar examples for other Debian packages.

This security report set the urgency to “High”, and despite the corresponding bug report has been reported to Debian more than a month ago asking the maintainer of the Bugzilla package to release new versions, nothing has been done so far. Even Secunia marked this security issue as “moderately critical”, which is the third level out of five. And I myself emailed the Bugzilla package maintainer at Debian a few days ago, but got no response so far.

So my question is this: how can Debian honestly argue that they take security very seriously? It looks like it takes ages to get something done, which is usually not a big deal when talking about new features, but is definitely a problem when talking about security.

I wanted to know if there were other older unpatched security bugs relative to Bugzilla packages, and I’m a bit irritated to see that there are many! Some of them are two years old! Yes, very seriously!

Bugzilla developers at Mozilla are in no way in charge to maintain these packages, neither for Debian, nor Fedora, nor Mandriva nor any other Linux distro, so we have no control at all on that. And people often come on IRC asking us for help, because their Bugzilla package provided with their Linux distro is broken or behaves in a weird way (typically a broken configuration or customization). And guess what? Most of the time, they use the Debian package. Yes, very seriously! For comparison, Fedora updated their Bugzilla packages the day after we released 3.6.4, and Mandriva the week after! It looks like they take security a bit more seriously.

March 04, 2011 03:30 PM

So, last week we released Bugzilla 4.0, which was pretty exciting. It had some awesome major new features, like the redesigned search page, automatic duplicate detection, autocomplete for user and keyword fields, and an enormously-enhanced WebServices interface.

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

February 23, 2011 04:52 PM

We released Bugzilla 4.0 a few minutes ago! It has many new features and improvements compared to Bugzilla 3.x, and comes almost 4 years after Bugzilla 3.0 (which was released in May 2007). With this major release, Bugzilla 3.2 reached End Of Life (EOL) and is now unsupported. Everybody running a version older than 3.4.10 should upgrade to 4.0 to get future security and stability fixes.

Bugzilla 4.0 got full testing from the QA team, and should be considered stable:

All tests successful.
Files=55, Tests=11621, 2473 wallclock secs ( 1.86 usr  0.23 sys + 21.95 cusr  1.66 csys = 25.70 CPU)
Result: PASS

Enjoy!

 

Update: If you get the error “ExpiresActive not allowed” from Apache when upgrading to Bugzilla 4.0, edit your Apache config file httpd.conf as explained in the Bugzilla documentation. Till now, you probably had:

<Directory /var/www/html/bugzilla>
  ...
  AllowOverride Limit
</Directory>

Now the AllowOverride command must be:

  AllowOverride Limit FileInfo Indexes

in order to force the web browser to update its cache with newer CSS and JS files when they change (e.g. when upgrading to a newer release in some months). If Bugzilla 4.0 is working fine without this change, then this means that you either don’t use mod_cgi, or this feature is not enabled in your Apache server.

Update 2: Contrary to what Samuel Gibbs said in his post, we are not dropping support for all versions of Bugzilla 3. As I said above, only support for Bugzilla 3.2 and older is dropped. This means that Bugzilla 3.4 and 3.6 are still supported, at least till the end of the year.

Update 3: Bugzilla 4.2 should be released at the end of this year, if everything goes well.

February 15, 2011 07:21 PM

Hey there, user experience designers! Our deadline for the Make Bugzilla Pretty contest is coming up pretty soon, on February 28. If you were thinking about submitting an entry, now would definitely be the time to start working on it. You have a pretty good chance of winning, becoming famous, and changing the world for all the developers who use Bugzilla!

-Max

January 27, 2011 01:39 PM

Yesterday (23 hours ago, to be exact), we released new versions of Bugzilla which all include fixes for critical security vulnerabilities. The most critical one is described in CVE-2010-4568 and you can get the patches from bug 621591 for all versions of Bugzilla 3.2 and newer. This means that we provided no patch for Bugzilla 3.0.11 and older, and so if you are running such an old version, then you are in trouble, and you would have to backport the patches to your installation yourself. If you didn’t yet, now would be a good time to decide to upgrade to Bugzilla 3.6.4, or 4.0rc2 which should now be stable enough. You have been warned!

About Bugzilla 4.0rc2, note that this is probably our last release candidate before 4.0 final, which we expect to release mid-February. When 4.0 final will  be released next month, we will also stop supporting Bugzilla 3.2.x. So if you run something older than Bugzilla 3.4.10, then you should really upgrade. Just for your information, Mozilla, GCC and Xfce already upgraded to 3.6.4 today. So this is doable even for large installations.

January 26, 2011 12:15 AM

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

January 25, 2011 01:26 AM

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

December 20, 2010 10:51 PM

Bugzilla supports ‘tags’ or taglike things in a number of ways:

• Keywords
• Freeform, in the status whiteboard
• Its own tagging implementation

You may not have heard of the last of these because it’s disabled by default. Head over to your Preferences, the General Preferences tab, and turn “Enable tags for bugs” to On. This adds new UI to your footer: “add the tag [        ] to bugs [        ]“. You can type a tag name and some bug numbers here, and those bugs will be tagged. Once you have one or more tags defined, you’ll also get the option of adding existing tags to a list of bug numbers.

The tagging system is built on top of saved searches, so:

• by default only you can see the tag and get the list of bugs tagged
• links appear in the footer for each tag (but can be removed)
• you can share the “search” with a Bugzilla group

November 23, 2010 04:27 PM

Recently, there were two security issues discovered in Bugzilla that would fall under the category of HTTP Response Splitting attacks. Although this is a common issue in web applications, many developers are unaware of it, its consequences, or how to protect their applications from it.

In short, here's what you need to know:

Never allow unsanitized user data into HTTP headers.

Most of the time, if you're using some HTTP framework, it should be handling this for you. So mostly you just need to make sure that you have a good HTTP library that security-checks its header output properly. But if you're printing headers directly to the user, as plain text (as I've seen many PHP apps do), you do need to be concerned about this.

In particular, it's most important that you never allow any character that might be considered a "newline" into your HTTP headers. To understand why, and what could be dangerous about this, you need to know a little bit about HTTP. Let's say that we're sending a response to the user that looks like this:

200 OK
X-My-Header: some_user_data
Content-Type: text/html; charset=UTF-8

<html><head><title<Hello World!</title><body></body></html>

Okay, pretty simple. This is a page that has "Hello World!" as the title, and no content. Harmless. However, what's that X-My-Header: some_user_data there? Let's imagine that some_user_data can be anything that the user input, and he inputs a string that looks like:

some data;
Content-Type: text/html; charset=UTF-8

<script type="text/javascript">all_your_base();</script>

Now, your response looks like:

200 OK
X-My-Header: some data;
Content-Type: text/html; charset=UTF-8

<script type="text/javascript">all_your_base();</script>

Content-Type: text/html; charset=UTF-8

<html><head><title<Hello World!</title><body></body></html>

And I could have inserted anything! It's not just like a normal Cross-Site Scripting vulnerability, where I can only insert a small dangerous piece of HTML into an already-existing page. I could insert any HTML, any script, or any content at all. That content could be an ActiveX control for Internet Explorer, it could be some other content that your system is already configured to open automatically--anything. I'm not limited just to HTML or JavaScript. There's also a good chance that any Set-Cookie headers will become a part of the body instead of being part of the headers, too, so I can steal cookies even if they're marked "httponly".

For the most part, this vulnerability is prevented if you never allow people to insert a CR or LF character into headers. There's no good reason to allow inserting those characters directly into a single header, so you should be pretty safe to just completely deny those characters in HTTP headers generated by your application.

-Max

November 11, 2010 04:19 AM

If you are curious to know the version running on some well known Bugzilla installations worldwide, I collected this information in a single place: http://lpsolit.wordpress.com/bugzilla-usage-worldwide/. I think this way of doing it is better than writing a new article each summer, as I did for the last three years. This page also lists the approximate number of bugs contained in the DB, to give you an idea how big an installation is.

It’s pretty cool to know that so many large companies and projects use Bugzilla to track their bugs. For instance: kernel.org, RedHat, Novell, Mandriva, Mozilla, WebKit, KDE, GNOME, Logitech, Facebook, GCC, Apache and especially Yahoo! with more than 4 million bugs! I hope even more companies and projects will use Bugzilla in the future.

November 09, 2010 11:02 PM

Last night, we released Bugzilla 4.0rc1 and Bugzilla 3.6.3, as well as security-fixes only  3.4.9 and 3.2.9.

Bugzilla 4.0rc1 comes 3 months after our latest development snapshot 3.7.3, and is considered stable enough for use in non-critical environments. If nothing serious is found in this release candidate, we will release Bugzilla 4.0 final in a few weeks (probably in December). Else we may release another release candidate if major problems are found. Bugzilla 4.0rc1 comes with many improvements over Bugzilla 3.6, for instance: automatic detection of duplicates when reporting a new bug, improved search and attachment details pages, autocompletion for all user fields (requires JSON-RPC to work on your installation), a new default status workflow, the ability for Bugzilla to remember more than one search at once, several new WebService methods among which the highly desired Bug.update() method, the ability to display multi-select custom fields as a column in bug lists (including bug flags!), and many new code and template hooks to help you write extensions without having to hack the core code.

Bugzilla 3.6.3 is our latest stable release, which includes several bug fixes as well as three security fixes, as described in the security advisory. It contains no new features.

Note that once Bugzilla 4.0 is released, we won’t support the 3.2.x series anymore. Installations running such old versions should upgrade to either 3.6.3 or 4.0 final when it comes out.

November 03, 2010 02:12 PM

The Bugzilla tweaks addon for Firefox has the following features:

• Interleaving the bug’s change history with the comments on the same page
• Showing the last time that a bug or attachment flag was changed
• Proving user name autocompletion support
• “Assign To Me” button

The history interleaving (for which there have been several jetpacks etc.) is particularly valuable. If you use bugzilla.mozilla.org, go get it :-)

October 29, 2010 11:29 AM

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

October 23, 2010 02:00 AM

It’s usually easier to make Bugzilla work with Apache, but IIS7 made things a lot easier than in previous versions, and it’s now pretty trivial to make it work with IIS too. The screenshots below are in french, but I guess you can understand what needs to be done.

Only two actions are needed, as shown above. Two new panels will be displayed:

 

 

That’s it! Bugzilla should work fine now.

October 22, 2010 12:37 PM

Hey folks! I just wanted to let everybody know that there's now an official Twitter account for the Bugzilla Project. This will be a really good way to stay up to date on the very latest news about Bugzilla--we plan to keep it updated frequently about all our new feature development, releases, and things going on in the Bugzilla community.

-Max

October 19, 2010 09:45 PM

Our latest stable release, Bugzilla 3.6.2, is now available in 10 languages: bg, cs, de, en, es-es, fr, ja, pl, pt-br, and zh-tw. No idea what happened to the russian team, which disappeared soon after 3.5.2. No idea either for the belarusian team, which stopped releasing new templates after 3.2.3. If you don’t want to install the l10n templates yourself, but you want to see how Bugzilla looks like in other languages, you can play with this test installation, which has all the available l10n templates installed.

October 19, 2010 11:24 AM

For those who use GCC Bugzilla and Sources Bugzilla (sourceware.org), please note that they have both been upgraded to 3.6.2+ (Sources Bugzilla was running 2.17.5 two hours ago, haha).

October 04, 2010 08:35 PM

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!

September 23, 2010 09:07 PM

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

August 17, 2010 03:17 AM

We released Bugzilla 3.6.2, 3.4.8, 3.2.8, and 3.7.3 last night! They all contain fixes for 4 security bugs, and Bugzilla 3.6.2 and 3.7.3 also include numerous bug fixes. Bugzilla 3.6.2 is our most stable release, and is the recommended version to use in production. Bugzilla 3.7.3 is a development snapshot to let you test what will become Bugzilla 4.0. Bugzilla 3.7.3 is now feature complete, and I hope our next release on the 4.0 branch will be 4.0rc1, assuming we manage to fix all remaining blockers (18 blockers as of today). There is no ETA for 4.0rc1 yet, but probably around September or October, if everything goes well. Note that many bugs and regressions are being found in 3.7.x, so you shouldn’t use Bugzilla 3.7.3 in production (but we would be happy that you install it in a test environment and help us catch remaining bugs and regressions before we reach the release candidate phase).

Bugzilla 3.7.3 being feature complete, and no major changes in templates being expected, now is also a good time for localizers to start their work on the 4.0 branch. Once you are ready, feel free to ping me on IRC (nick: LpSolit), or leave a comment to this post with a URL to your website, and I will add it to our list of available localized tarballs (of course, if you have checkin privs, you can update the list yourself). For new localizers, please don’t waste your time translating Bugzilla 3.2.8 or 3.4.8. Bugzilla 3.2 will reach End Of Life at the end of the year or early next year, when Bugzilla 4.0 is released, and Bugzilla 3.4 should reach EOL at the end of next year. Focusing on Bugzilla 3.6 and 4.0 only is a better way to spare some time.

August 06, 2010 04:05 PM

While reviewing and testing a patch for Bugzilla, I spent tens of minutes looking at and playing with IE8 parameters to configure it to display text files inline, i.e. from the web browser directly. I couldn’t figure out why it was unable to display a simple text file. As Google was unhelpful, I had to figure it myself. The reason is crazy: the file I attached to Bugzilla was named “attachment.txt”, and due to the word “attachment”, IE8 automatically wants to download the file! If I rename the file to e.g. “file.txt” or “bazooka.txt”, it works fine again and displays the text file inline, as desired. If you don’t believe me, try yourself and open the two attachments I put here on landfill.

August 03, 2010 04:31 PM

I didn’t blog for a long time about new features in the coming Bugzilla 4.0, nor Bugzilla 4.2 whose development just started. So here are some highlights:

Bugzilla 4.0:

• Bug 521416 – Older versions of IIS were causing Bugzilla to crash under some circumstances, due to problems with undefined values being passed back to Bugzilla when they shouldn’t (neither IIS 7.5 nor Apache are affected. IIS 5.1 definitely is. Not sure about IIS 6 and 7). This problem is now fixed, and all versions of IIS should work correctly now. This fix has also been backported to Bugzilla 3.6.2.
• Bug 490923 – Enable autocompletion for the assignee, QA contact, and CC fields. No need to remember the full email address of another user, Bugzilla will now show you a list of users matching the string you entered.
• Bug 412074 – Bug.add_attachment is a new WebService method which lets you add attachments to a bug.
• Bug 415813 – Bug.update is a new WebService method which lets you edit all aspects of an existing bug. Combined with Bug.add_attachment mentioned above, you can do everything you want with bugs. For the record, Bug.create already exists for a long time, to create new bugs.
• Bug 486292 – The default workflow has been changed. New installations will now have UNCONFIRMED, CONFIRMED, IN_PROGRESS, RESOLVED and VERIFIED as bug statuses instead of the old UNCONFIRMED, NEW, ASSIGNED, REOPENED, RESOLVED, VERIFIED and CLOSED bug statuses. You are of course free to edit them from the administrative pages if you don’t like the new default workflow.
• Bug 22353 – Automatic duplicate bug detection has been implemented when filing a new bug, to give you a chance to see existing bugs matching your data before reporting your own bug. We hope this will decrease the number of duplicates.
• Bug 556422 – The existing bug-moving functionality has been converted into an extension which is disabled by default. So this functionality is still present in Bugzilla 4.0, but you now have to enable it by deleting the “extensions/Voting/disabled” file instead of enabling it from the “Parameters” page. Once the extension is enabled, you have to re-run checksetup.pl again.
• Bug 24896 – Bugzilla now supports multiple (by default: 10) buglists at once, meaning that if you edit a bug and click the “Show last search results” link, it will show you the list the bug came from, even if you did another search meanwhile. Note that Bugzilla does its best to guess which buglist a bug comes from. And if a bug appears in several buglists, there is a risk that it redisplays the “wrong” buglist.

Bugzilla 4.2:

• Bug 119703 – You can now create an attachment by pasting text directly into a text field. This means you don’t need to save your text in a file first, which you then have to upload. This is very useful e.g. if you want to copy and paste something very quickly.
• Bug 142394 – Tabular reports are now sortable (requires JS to be enabled). You can choose the column you want to sort data.

As many new, and sometimes invasive, features have landed, we need as much feedback and testing as possible. So do not hesitate to download development snapshots and report bugs if you find something wrong. Remember that these development snapshots are for testing purposes only, and should in no case be used in production (we have a huge list of blockers for 4.0!).

July 20, 2010 01:40 PM

With the release of Bugzilla 3.6, the already-awesome Quicksearch got a facelift. That linked page is now a tutorial on all its excellent capabilities. bugzilla.mozilla.org recently upgraded to 3.6, so they can all now be used on that site.

July 15, 2010 10:59 PM

For the third consecutive summer, I wanted to know which version major Bugzilla installations were running. In parentheses is the Bugzilla version they were running one year ago. As you can see, only the half of these installations have been upgraded in the last 12 months, and one third runs a version which is no longer supported and which has unpatched security holes. I know Yahoo! plans to upgrade to 3.6 later this year, but I have no idea about the other ones. Remember that Bugzilla 3.0.9 and older are no longer supported, and that we will stop supporting 3.2.x once Bugzilla 4.0 is released (end of this year/beginning of next year).

• Mozilla: 3.6.1+ (3.2.4)
• OpenSSH: 3.6.1 (3.2.3)
• RedHat: 3.4.7+ (3.2.3+)
• Gnome: 3.4.6+ (2.20.5)
• FreeDesktop: 3.4.6 (3.0.8)
• Apache: 3.4.6 (3.2.3)
• Wikimedia: 3.4.5 (3.0.8)
• ClamAV: 3.4.5 (3.4rc1)
• Eclipse: 3.4.4 (3.0.4)
• Novell: 3.4.3 (3.2.2)
• W3C: 3.2.6 (3.0.4)
• KDE: 3.2.5+ (3.2.3+)
• WebKit: 3.2.3 (unchanged)
• Wine: 3.2.3 (unchanged)
• Mandriva: 3.2.3 (unchanged)
• kernel.org: 3.2.2 (unchanged)
• Songbird: 3.0.9 (3.0.5)
• Facebook: 3.0.4 (unchanged)
• ActiveState: 3.0.3 (unchanged)
• Itos (NASA): 3.0.2 (unchanged)
• Gentoo: 2.22.7 (2.22)
• Samba: 2.22.1 (unchanged)
• Maemo: 2.22.1 (unchanged)
• Yahoo!: 2.22.1 (unchanged)
• GCC: 2.20+ (unchanged)

July 15, 2010 09:38 AM

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

July 13, 2010 10:53 PM

… and thank you! Today, Windows 2000 reached End Of Life (EOL). This was a great OS, and I used it till a few months ago when I decided to upgrade to Windows 7, skipping both Windows XP and Vista.

July 13, 2010 08:59 AM

(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

July 10, 2010 08:56 AM

July 09, 2010 06:40 PM

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

July 09, 2010 05:31 PM

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

July 09, 2010 05:31 PM

This is a very serious question, and it seems a number (at least 0) of people agree:

Why is Mozilla legitimizing your mom?

Mozilla clearly relies on your mom for services like doing the occasional laundry and making dinner when you go over to her house, and yet clearly your mom stands for everything that Mozilla doesn't. I mean, let's look at the points:

• Your mom is clearly closed-source.
• Your mom only has proprietary, biological interfaces.
• The traditional, uniform, standards-based lifeform is the monocell. Your mom is practically the opposite of a monocell.
• Mozilla provides most of its services over the Internet, but your mom's services are not available over the Internet. In fact, your mom's services aren't even publicly available.

I wonder what the Mozilla Foundation could do with the funds that your mom has received?

So, the question is: why is Mozilla legitimizing your mom?

-Max

P.S. This is a joke that, for the most part, only people subscribed to mozilla.governance will fully get.

June 26, 2010 08:05 PM

It is possible to search for who added comments to Bugzilla and when they did it. In boolean charts,

"Commenter" "is equal to" "<person>"

will find bugs to which that person has added a comment.

"A Comment" "changed before" / "changed after" "<date>"

finds bugs where a comment was added before or after a certain date. You can combine the two (must be in the same boolean chart in order to apply to the same comment) to look for bugs where a particular person added a comment before or after a certain date.

Example: all bugs you have commented on since June 18th 2010 (also uses pronoun substitution)

June 25, 2010 09:41 AM

I just uploaded the first stable release of a new library to CPAN, called RPC::Any. It's a simple server framework that presents an object-oriented, unified interface for both XML-RPC and JSON-RPC. It has the following features:

• You can use both JSON-RPC and XML-RPC with the same backend code. (That is, you only have to write your functions once--you never have to do anything special for each individual protocol in your code.)
• It fully supports Unicode, proven with extensive Unicode tests in the test suite.
• If it gets tainted input, it will send your functions tainted parameters.
• It can take input from STDIN, from a string, or from an HTTP::Request.
• Everything is written as a series of methods whose names and parameters will stay stable, so it's very easy to subclass for your own application, and make it behave completely differently.
• It gives your functions the ability to call a type() method to explicitly type return values correctly for the protocol in use. (So you can do $class->type('int', $some_value) within your WebService methods and have that value properly returned as an int instead of a string.)
• It doesn't try to start its own server process or send its own output, so you can control exactly how it is used and how the output is sent.
• It supports operation in a CGI environment (in addition to almost any other environment you can come up with).
• The test suite of RPC::Any has nearly 100% (about 98%) code coverage over the entire library.

More or less, it's everything that I ever wanted in an RPC library, and had hacked into Bugzilla using some very complex code (more on that below). It's also extremely simple to use, for most cases:

use RPC::Any::Server::JSONRPC::HTTP;
my $server = RPC::Any::Server::JSONRPC::HTTP->new(
  dispatch => { 'Foo' => 'My::Methods' });
print $server->handle_input();

package My::Methods;
use strict;

sub hello {
  my ($class) = @_;
  return $class->type('string', 'Hello World!');
}

The server above will read from STDIN, parse HTTP headers and JSON-RPC input, and return proper HTTP headers and JSON-RPC output (for any version of JSON-RPC, no less! 1.0, 1.1, or 2.0). Sending JSON-RPC input with Foo.hello as the method name would call My::Methods->hello() and return the string "Hello World!", explicitly typed as a string. You'll notice that My::Methods calls $class->type even though it never defines a "type" method--that's a magic method that RPC::Any gives the class immediately before it calls the method (and removes after the method is done being called).

To get XML-RPC support instead of JSON-RPC support, just replace every instance of the string "XMLRPC" with "JSONRPC" in the above code (so, in two places) and you have an XML-RPC server instead! No changes whatsoever required to My::Methods or any other code.

A Little Background

So, you might be wondering--why did I write a whole new WebServices module when there are so many options available on CPAN? Well, in fact, I'm actually using two of them as the backends for RPC::Any--RPC::XML and JSON::RPC::Common. So I'm not re-inventing the wheel for RPC--I'm just giving it all a clean, consistent interface.

Here's the whole story behind what motivated me to start writing RPC::Any:

Many years ago, for Bugzilla 3.0, we added a WebServices interface to Bugzilla. When we started off, it was pretty simple. We were using SOAP::Lite for XML-RPC, and everything seemed to be working okay.

Then, we realized that Unicode support was broken in SOAP::Lite (at the time), and so we had to write a workaround for that. Then we wanted to change how we dealt with null values, and we had to write a complex workaround for that. Then we changed how we dealt with input values--more complex, hackish workaround code. Oh, and then we realized that we wanted to preserve taint on incoming values, for security in Perl's taint mode (because otherwise we might accidentally send unchecked input to the database).

All of this was really tough, because SOAP::Lite was basically a SOAP module, with XML-RPC support tacked on. So all our workarounds involved modifying very convoluted SOAP code, when all we really wanted to do was modify how our XML-RPC support worked. Our XML-RPC Server module became quite a monster. (You might ask--okay, so why not switch to a pure XML-RPC module from CPAN? Ah, I tried--but more on that later.)

And then, we added JSON-RPC support, and we wanted to do it with the same backend code--that is, I didn't want to maintain one whole Bug.get function for JSON-RPC and another, separate Bug.get function for JSON-RPC. I just wanted to have one Bug.get function, with two separate frontends.

Well, this was far, far harder than I anticipated. The biggest problem was that SOAP::Lite called methods like Bugzilla::WebService::Bug->get(@params), but JSON::RPC called methods like $server->Bugzilla::WebService::Bug::get(@params);. (So under XML-RPC, the first argument to our methods was the name of our class, like "Bugzilla::WebService::Bug", but under JSON-RPC the first argument was an instance of JSON::RPC::Server.) So in order to be able to explicitly type return values using $self->type within our WebService code, I had to have one "type" implementation in Bugzilla::WebService::Server (which was the base class for both our XML-RPC and JSON-RPC servers) and another "type" implementation in Bugzilla::WebService (which is the base class for our WebService itself--that is, the base of things like Bugzilla::WebService::Bug and so on).

Then, there were numerous bugs in JSON::RPC--so many that I practically ended up writing my own JSON-RPC implementation on top of JSON::RPC, just to get it working properly for Bugzilla. Oh, and also, remember, I had to do all the same things I did for XML-RPC above, like get taint mode working right and testing/fixing Unicode. Oh, and then we added HTTP GET support to our JSON-RPC interface (which JSON::RPC didn't really support natively) and then we added JSONP support to it. It was crazy--just look at the old Bugzilla::WebSevice::Server::JSONRPC.

So along then comes the day when I have a bit of free time, and I'm looking for a project. I think, "Oh, I know, I've always wanted to move away from SOAP::Lite for our XML-RPC service. Let's see what else I can find on CPAN!" So I looked around at all of the available options, and I found RPC::XML, which, though not exactly what I needed, it was well-maintained, XML-RPC specific, and the maintainer had been really helpful with my requests.

So, I started to write a patch to move Bugzilla from SOAP::Lite to RPC::XML...and started to write a whole other series of workarounds--this time not for bugs (because the RPC::XML maintainer was very responsive about fixing those) but just because RPC::XML worked in a different way than we needed it to work, for Bugzilla.

Finally, at this point, I decided it was time to take the engineer attitude and solve the problem the right way--that is, not just fix the problem with our XML-RPC server, but fix all architectural problems of our WebServices by refactoring.

I looked around CPAN to see if there were any good, unified RPC frameworks that supported both the XML-RPC and JSON-RPC protocols, and didn't find anything. So, I rolled up my virtual sleeves and put the time in to do it really right--to write a module that would be the best, simplest, and most powerful RPC framework available for XML-RPC and JSON-RPC. One that fit the (very complex) needs of the Bugzilla Project, but could be used by anybody. A few weeks later, and I had RPC::Any.

It's really been a surprising amount of work, particularly in the test suite. But I think it was worth it--the new Bugzilla WebServices code is way cleaner, simpler, and actually much more powerful than it was before the RPC::Any.

-Max

June 19, 2010 06:14 PM

Mike Beltzner has made an excellent video on how to use Bugzilla Quicksearch. If you use Bugzilla for more than about ten minutes every day, then this is definitely worth 5 minutes 33 seconds of your time.

Sadly, free WordPress doesn’t seem to allow the <video> tag, so you’ll have to go to all the effort of clicking this link (Theora video).

My favourite part is right at the beginning, where Beltzner says breezily “OK! So, now I’m going to change your life!”, and in the background you can just hear Madhava’s entirely unimpressed “I see.”

[Historical correction: as Jesse has pointed out, although he was a great supporter and inspirer, Andreas Franke made Quicksearch, not him.]

June 03, 2010 08:34 AM

This is only sort-of a Bugzilla tip (it’s more a Firefox tip), but it makes searching Bugzilla a lot quicker and easier.

In Firefox, head over to bugzilla.mozilla.org, right click on the Search box and hit “Add a Keyword for this Search…”. Give it the keyword “bug”.

Now, you can search Bugzilla directly from your URL bar using QuickSearch syntax, by typing “bug <terms>”.

June 02, 2010 04:32 PM

I wanted to test Bugzilla on Windows 7 using Perl 5.12.0. I first installed ActivePerl 5.12.0. Unfortunately, DBD::mysql is missing from the PPM repository. So I installed Microsoft Visual C++ 2010 express to use nmake.exe and compile DBD::mysql myself, but it keeps throwing errors:

C:\Users\buclin\Downloads\dbd-mysql> »\Program Files\Microsoft Visual Studio 10.0\VC\bin\nmake.exe »

Microsoft (R) Program Maintenance Utility Version 10.00.30319.01
Copyright (C) Microsoft Corporation. Tous droits réservés.

syntax error at -e line 1, near « ’755′) »
Missing right curly or square bracket at -e line 1, at end of line
Execution of -e aborted due to compilation errors.
NMAKE : fatal error U1077: ‘C:\Perl\bin\perl.exe’ : code retour ’0xff’
Stop.

I then installed Strawberry Perl 5.12.0, which already has DBD::mysql, but now I get the following error when accessing Bugzilla from the web browser:

Software error:

install_driver(mysql) failed: Can’t load ‘C:/strawberry/perl/vendor/lib/auto/DBD/mysql/mysql.dll’ for module DBD::mysql: load_file: Le module spécifié est introuvable at C:/strawberry/perl/lib/DynaLoader.pm line 200.
at (eval 938) line 3
Compilation failed in require at (eval 938) line 3.
Perhaps a required shared library or dll isn’t installed where expected
at Bugzilla/DB.pm line 1095

I wasted several hours playing with ActivePerl, Strawberry Perl and Visual C++, with no success. Someone, please compile DBD::mysql successfully and put it in the ActivePerl PPM repository! Thanks!

May 15, 2010 10:53 PM

Just a quick one this week: when linking to bugs, you can highlight particular comments (giving them a green background) by specifying the comment numbers like this:

https://bugzilla.mozilla.org/show_bug.cgi?id=540&mark=63,100

You can combine that with a fragment identifier to jump straight to one of the comments you’ve highlighted:

https://bugzilla.mozilla.org/show_bug.cgi?id=540&mark=63,100#c63

May 05, 2010 02:20 PM

Bugzilla’s comment autolinkifier will linkify the following things:

• bug 12345
• bug #12345
• comment 6
• comment #6
• bug 12345, comment 6 (and other variations with a #)
• attachment 67890
• URLs for the following schemes: ‘afs’, ‘cid’, ‘ftp’, ‘gopher’, ‘http’, ‘https’, ‘irc’, ‘mailto’, ‘mid’, ‘news’, ‘nntp’, ‘prospero’, ‘telnet’, ‘view-source’, ‘wais’
• Duplicate markers

These will only linkify if the bug exists – “bug 10000000″ will not autolinkify until you have that many bugs.

Note that it doesn’t linkify bare numbers, so if you are talking about other bugs, please put the word “bug” before each of them. (Note also that the word “bug” is customizable system-wide – everywhere else as well as autolinkification).

Bugzilla also provides the ability to hook into this mechanism using the bug_format_comment hook, so an admin can extend it to autolinkify any text you like. If you have ideas for text you’d like autolinkified on bugzilla.mozilla.org, file a bug about it.

April 23, 2010 01:42 PM

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

April 14, 2010 11:04 PM

We released a new major version of Bugzilla today! Bugzilla 3.6 is coming out less than 9 months after Bugzilla 3.4. This release also means that we no longer support Bugzilla 3.0.x, which reached End Of Life. So if you still use Bugzilla 3.0 or older (Bugzilla 2.x, argh), you should really upgrade, not only to use great new features, but also to protect yourself and your users from possible security attacks!

If you are running Windows and you want to try/test/evaluate Bugzilla 3.6, this is now as simple as dowloading Bugzilla-Setup-3.6.exe and execute the installer. It will install Perl, Apache, MySQL and Bugzilla for you (in a separate C:\Program Files\Bugzilla\ directory, so that they do not interfere with your existing copies of Perl & co), and asking you the minimum required information to have it work immediately. And if you want to uninstall it later, just select Bugzilla in the usual « Add/Remove Applications » panel, and installed applications will go away, with no interaction with existing copies (so if you already have e.g. MySQL installed, the Bugzilla uninstaller will leave it alone, and will only remove the copy of MySQL it installed under C:\Program Files\Bugzilla\). Note that the Windows installer is not officially supported by the Bugzilla team, and is only provided by one of the Bugzilla developers to help people install Bugzilla on Windows.

So now that Bugzilla 3.6 is released, what is coming next? Well, we are already working on the next major release, Bugzilla 3.8, which should bring some highly wanted features, such as a WebService API to edit existing bugs (we will call this method Bug.update), so that you can alter them after having used the already implemented Bug.create method. We are also working on a better support for branches, which will better let you know the status of a bug on a per-branch basis. And we also plan to implement the ability to collect information about remote bugs living in other bug trackers (either Bugzilla or Launchpad.net or Google Code, for instance) and display this information in your Bugzilla itself (I’m talking about improving the « See Also » field in show_bug.cgi, for those who know what it is). If we manage to implement all three features on time, i.e. this summer at the latest, we will skip « Bugzilla 3.8 » in the versioning and rename it « Bugzilla 4.0 », as it would be a super-major release. Basically, Bugzilla 4.0 would be able to « talk » to each others and interact together.

April 13, 2010 07:00 PM

Today it was revealed that servers at Apache.org and Atlassian were successfully attacked, leading to thousands of stolen passwords. The attack on apache.org's servers was via JIRA, and since the attack on Atlassian came from the same source, it probably was also through JIRA.

I'm sure that JIRA's programmers feel embarrassed enough about all of this--I don't want to berate them, or insult them. Everybody makes mistakes; almost all software has some pretty bad security vulnerabilities at at times. Overall, the JIRA guys seem to do good work, and seem to be generally nice people. And on top of all of that, I understand how they feel! Whenever there's a reported security issue in Bugzilla, I freak out. Thankfully there hasn't been an attack on Bugzilla like this JIRA one in recent memory. But if there was an attack like this, I'd be absolutely mortified, and the last thing I'd need would be somebody trying to insult or attack me for simply having made a mistake.

Instead, I want to use this opportunity as a reminder to all web application developers for why web application security is so important, and talk about some of the things that we do in Bugzilla that would have prevented or mitigated an attack like this one, and that web applications should probably all do as standard practice:

• Lock down the on-disk permissions of files and directories. When you install Bugzilla, the actual installation script makes sure that the permissions on Bugzilla's files and directories are as secure as possible. That way, even if there is a security compromise in Bugzilla, the attackers can't upload programs and run them, modify existing scripts, or generally do anything nasty to the machine. It's particularly important that web applications never allow anything to be uploaded into a location where the web server could execute it.

  This is actually something that I rarely see web applications stress, in any of their documentation. Some web applications recommend that system administrators fix permissions themselves, but the chance is that the vast majority of people installing your software are going to skip the optional security recommendations, and just go for whatever's easiest. The only way to guarantee that security happens right on every installation is to have the actual installer do the setting of the permissions.

  The attackers configured the Apache JIRA to allow uploads into a location where the webserver would execute files, which is what let them compromise Apache's servers and steal the passwords of every JIRA user who logged in to the system. If, like Bugzilla, it was impossible to configure JIRA in that way, that part of the attack would have been impossible.

• Httponly: Never allow Javascript to read the login cookie. This is one of the simplest and most effective protections you can make in a web application. Seriously--for Bugzilla, it was just a few lines of code, and eliminated a whole set of possible attacks. All you have to do is to set an extra attribute on cookies when you send them, and you gain a lot of security. If Javascript must read some of your cookie data, that's fine, just don't let it read the login cookie.

  If Httponly had been set on the Apache JIRA session cookie, then the cross-site scripting attack that the attackers used could not have stolen administrators' login privileges.

• Open-source your software. Okay, look, I know that that's not practical or possible for everybody. But I will tell you, a lot of the security bugs that are found in Bugzilla are found by people we've never met who just happened to be reading the code. These users find all our security issues before they're ever exploited, and so we can release fixes before systems are harmed. In particular, I don't think there has ever been a successful Cross-site scripting attack performed on a Bugzilla--at least not any publicly discussed in the six years I've been working on Bugzilla.

  The "many eyes make all bugs shallow" maxim may not always be true, but for security issues, in my experience, it has absolutely held up.

  If the cross-site scripting vulnerability in JIRA had been found by an outside user before it was exploited, the Apache JIRA administrators would have been safe from it.

• Have automated tests scan your code for potential security issues. There are lots of ways to do this. In Bugzilla, we have an automated test that makes sure that we properly "filter" any data that we got from the user or the database before displaying it on a web page, so that people can't inject malicious HTML or JavaScript into our system. The automated tests don't always catch our security issues, but the number of times that I've fixed a security issue in my code thanks to the tests is uncountable--probably in the thousands, at this point. And those are fixes that happen before the code even gets checked in, so that's a security vulnerability that gets fixed before it even becomes a part of the product.

  There are lots of other ways to do automated security testing of code, these days. Static code analysis, Fuzz testing, and automated security scanners seem to be the most popular, from what I've seen.

  If the cross-site scripting vulnerability in JIRA had been found by automated tests before it was exploited, the Apache JIRA administrators would have been safe from it.

• Lock out users who fail to guess their password too many times. There are lots of approaches to account security, but this is one of the simplest and most failsafe. If an attacker can only guess five passwords every 30 minutes, and then they get locked out, the statistical probability that they will ever guess anybody's password is pretty slim. Starting with Bugzilla 3.6, we implement exactly that policy, and we even notify the Bugzilla administrators whenever somebody gets locked out, so that if there's a large brute-force password attack, the admins will know immediately.

  Some people say that the answer to password security is to have people change their passwords every three months. This is probably sensible on some systems, but on a web application, it's mostly pretty ridiculous. If you only change your password every three months, then that gives an attacker three months to guess your password. I can promise you that almost any normal user password could be guessed in that time, particularly if the system doesn't prevent brute force attacks. Then once the user has your password, they can usually do everything damaging that they want to do within a few minutes. So, almost any forced-rotation period is pretty silly, in a pure web application. (In other systems it can make sense--it all depends on the context.)

  Other people suggest that passwords need to be a certain level of complexity or a certain length, and up to a point, that's true. If your password is one of the 100 most-common passwords, then even with a sensible lockout policy, the attacker will eventually guess it, if they keep up over a few days. (Of course, in Bugzilla, the system administrators would see all of these lockout notices and probably stop the attack pretty quickly. Still, it's better to be safe than sorry.) So your application should probably enforce a level of password complexity that's sufficient to make it impossible to guess passwords when combined with your lockout policy.

  If the Apache JIRA had had brute-force password-guessing protection like Bugzilla's lockout method, the attackers would not have been able to discover administrators' passwords using that method. (My understanding is that newer versions of JIRA do have this protection.)

• Store passwords securely. If you're going to store a password in the database or anywhere, store it using some standard, secure method. Don't just hash the password--you have to at least salt them. Preferably, don't even invent your own password-storage scheme--just use some library that already exists.

  Never store passwords as plain text. You might be saying to yourself, "Oh, nobody will ever break into the system and steal them." That sounds pretty good until somebody does break in and steal them, and then you'll really be wishing that you stored them properly.

  If the Apache JIRA had been storing passwords properly, then Apache.org's users would be at far less risk of the attackers now knowing all the passwords in JIRA.

And finally, on top of all those points, if you're a system administrator, upgrade your software regularly. Some of the security issues that let the Apache JIRA be compromised were supposedly fixed in newer versions of JIRA, before the attack ever happened. Almost every time I hear of an attack like this, it uses old, known problems to compromise the system.

Nobody likes getting attacked. Everybody feels bad about it, when it happens--system administrators, programmers, and most especially users. So let's just design secure applications to start with, and never have any of our system administrators or users have to bear the burden of compromised systems and stolen data.

-Max

April 13, 2010 11:14 AM

If you want data out of Bugzilla in some format other than an HTML web page, Bugzilla can support that. The “ctype” parameter takes a short name for a content type. Valid ctypes include:

• Bugs: xml (using a custom Bugzilla schema)
• Bug lists: js, ics, atom, rdf (which is XML), csv
• Reports: csv

So you can subscribe to a buglist using Atom, or import it into a spreadsheet using CSV. For security reasons, the JS template is limited to public bugs only.

You can also get all this data and more as XML or JSON from the built-in RPC API, and as JSON or unstable XML from the RESTful BzAPI.For these two formats, these APIs are the recommended way to get data.

New formats can be created simply by dropping a template into the relevant directory on a Bugzilla installation. So if there are formats you’d like, say so :-)

March 29, 2010 01:43 PM

You want to install Bugzilla on your Windows operating system but don’t want to go through all the steps to install Perl, MySQL, Apache and Bugzilla? Just download and run the new Bugzilla installer for Windows! It’s a usual .exe file which all Windows users are used to.

It will ask you for information required to run Bugzilla and related services correctly, and once you click « Finish », Bugzilla will appear in your web browser magically. Our magician is named Byron Jones, one of the Bugzilla developers who did a wonderful job to build these installers. Thanks a lot Byron!

The installers are currently available for Bugzilla 3.4.6, our current stable release, and Bugzilla 3.6rc1, our first release candidate for 3.6. Note that these installers are not officially supported by Bugzilla, though they got some testing by some core developers. Also note that they will install everything in your C:\Program Files\Bugzilla\ folder, no matter what is already installed on your system. This means Bugzilla will run its own web and DB servers and run its own instance of Perl (which are easier to install/uninstall separately), at least for now. More information can be found on the wiki page of the installers.

Do not hesitate to give us some feedback and/or suggestions for future improvements. Enjoy!

March 24, 2010 04:30 PM

Atul Varma has built some very cool tools using the Bugzilla REST API:

• User Dashboard – shows things you need to review, bugs assigned to you, ones you reported recently and other useful lists.
• User Finder – put your Bugzilla username and password in the first two fields, and the person you are searching for in the third one. Handy for knowing what someone’s email address is to CC them. You can also use this to make your own Dashboard by searching for yourself then hitting the button.
• Bug Filer – automatically finds products and components matching a string, and takes you to an Enter Bug page for that component. This one is a bit slow, but we checked in two fixes this week to Bugzilla core to speed up config.cgi which (indirectly) supplies the data, so hopefully they’ll make it to b.m.o. before too long.
• For Hg users, he’s also working on a qexportbz command to match qimportbz, but it’s not quite ready yet.

You can hear and see him demoing them in the (open) video of the WeeklyUpdate meeting from yesterday, which is embedded at the top of the meeting’s wiki page. Starts 2 minutes in.

He said: “To alleviate some of my major pain points, I decided to look into Gerv’s RESTful API for Bugzilla. So I used that to make some tools”. That’s exactly what the BzAPI was created for. Go Atul! And everyone else, please do the same!

March 23, 2010 03:34 PM

I love you, man. I really do. You're like a brother to me. But you and me and these web developers here need to sit down and have a little intervention with you.

I know that you've go a lot on your mind right now, but there's some things that we need to talk about with you, dude.

First I just want to say that I love your styles. That's not what we're here to talk about, but it's something I really wanted to give you some kudos for. font, font-style, border, text-decoration, color, background, you are awesome. Those things are so good, I just wanna hug them, most of the time. text-decoration and I have had our differences, but I've learned to work around them, and I'm pretty good now.

And the cascade? The cascade is pretty sweet.

But CSS...your positioning sucks. I know it, these web developers here know it, and it's something that we really need to talk about. It's been happening for a long time, and all of us here really would like you to think pretty hard about bringing some changes into your life.

It's not a big overhaul or anything. It's just a few things that we'd really love to see. There's just a few things. Everybody here really loves you man. We mean it. There's just a few small, little things that would really help make all of us happier, and maybe they're things that could help you feel better about yourself, too:

• All I want for Christmas is the ability to position a box relative to another box that is not the container. Like, say, something like: position: relative-to #other_box top-right; top: 0; left: 0;, and then the top-left of my box would be aligned to the top-right of #other_box. Then I would never have to wrangle with float ever again, except when I wanted to have some text spill around a box.
• Then while we're at it, I'd really love to be able to specify the size of a box (either horizontal or vertical) as being identical to another box. Maybe something like: width: #other_box and height: #other_box. Tables do this. They did it in 1996. Now it's 2010, and I think that this is something we all would love, but without the tables. So it's something for you to think about; it would really help us out.
• Since we're talking about height, it would also be awesome to have a way to say "this should be the height of its container but no larger". You'd think height: 100% would do that, but no, that seems to make the box the height of its content, at least the last time I tried it (yesterday). That's OK, though, we love you even though you're eccentric, CSS. I think we just need a little something different, here.
• I can't say how much I'd love to be able to vertically center something in a box. Some of the less-informed members of this little sit-down here might think that vertical-align has something to do with vertically aligning things in boxes. But no, no, it doesn't. It was a bit of a trick that CSS pulled on us, and we understand that there were some reasons, so we're annoyed, but understanding.
• While we're at it, wouldn't it be nice to have a single, simple way to center anything horizontally in its containing box? margin: 0 auto usually works. I mean, if you wrap the contents in a table so that they auto-size. (That's a whole other issue, though, possibly solved by display: table?) Sometimes you have to use text-align: center, though. That's fun, but not really what we meant. Then sometimes there's no way at all, which isn't so fun.
• If you felt really nice, letting me specify z-index on non-positioned elements and having it actually work would be really awesome. That's just if you feel like it, though. I know that there's a lot of other stuff to think about, here, and and I want you to take your own time to do it, and think about it for yourself.

Those are all the things that we'd need. I know that life is pretty difficult for you right now, what with CSS3, HTML5, quirks mode, standards mode, specs, working groups, modules, errata, and everything. So this isn't something I expect overnight. But it's time for us to say that there's millions of people that you're affecting, with your behavior, and we've given you so much love. Couldn't you just give us a little?

For Serious,

Max

March 17, 2010 12:46 PM

Fed up of typing https://bugzilla.mozilla.org/show_bug.cgi?id=549867 ?

Firstly, it’s a great idea to set up a “bug” keyword in Firefox. So you can type (or, often more usefully, paste from an email) “bug 123456″ into your URL bar and have the Right Thing happen. The URL you need is:

https://bugzilla.mozilla.org/show_bug.cgi?id=%s

Right-click, select “Bookmark This Link” and type “bug” into the “keyword” box.

Secondly, the handily-named bugzil.la URL shortener permits e.g.:

http://bugzil.la/466419

http://bugzil.la/<some quicksearch string>

(Thanks to Reed for making that happen.) This is good if you are attempting to squeeze an important message into, say, 140 characters. In case anyone was wondering, “.la” is Laos.

March 16, 2010 11:08 AM

March 09, 2010 02:43 PM

We released Bugzilla 3.6rc1 today, our first release candidate for 3.6. This version should be stable enough for non-critical missions. There are currently no blockers left for Bugzilla 3.6, so depending on the feedback we get, we may as well release 3.6 final in a few weeks or release 3.6rc2 depending on the severity of bugs you may find. So now is a good time to test it and to report us bugs you may find. If you don’t want to install Bugzilla 3.6rc1 yourself, you can play with our test installation.

March 08, 2010 06:10 PM

sdwilsh has written a Thunderbird addon called Bugzilla Helper (not to be confused with the Bugzilla Helper which guides you through bug submission). It allows you to press Reply when viewing a bugmail, and instead of popping up an email addressed to a non-working address (not helpful), will instead give you a window to type your comment in, helpfully quoting the previous comment. When you hit Submit, it will add your comment via the BzAPI.

So you can now reply to bugmail :-)

March 08, 2010 05:42 PM

Have you ever had a chunk of text and wished you could apply the Bugzilla comment autolinkifier to it?

• Autolinkified URLs, bug numbers and attachment numbers (with “details” link)
• Bug numbers have the bug title as the tooltip
• Strikeout style for closed bugs

Wish no longer.

This could be handy for e.g. some wiki text involving a load of bug numbers.

March 03, 2010 01:55 PM