December 29, 2011
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
November 29, 2011
November 14, 2011
October 11, 2011
August 11, 2011
August 05, 2011
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
June 08, 2011
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
May 17, 2011
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
May 09, 2011
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
May 04, 2011
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:
Click the image for a full-size (readable) version
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
April 28, 2011
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
April 01, 2011
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:
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
March 31, 2011
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
March 14, 2011
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
March 04, 2011
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
February 23, 2011
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
February 15, 2011
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
January 27, 2011
January 26, 2011
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
January 25, 2011
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
December 20, 2010
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
November 23, 2010
November 11, 2010
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
November 09, 2010
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
November 03, 2010
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
October 29, 2010
October 23, 2010
October 22, 2010
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
October 19, 2010
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
October 04, 2010
September 23, 2010
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
August 17, 2010
On Wednesday, August 4, we had the first Bugzilla Users & Administrators Group meeting, at the Wikimedia Foundation in San Francisco. In attendance were representatives from the Wikimedia Foundation, NASA, Yahoo!, the NTP Project, and the Bugzilla Project.
The event was catered with full meals and drinks (both beer and sodas) for anybody who wanted to take advantage of them.
Max Kanat-Alexander, one of the lead Bugzilla developers, went over some of the new features that are coming in Bugzilla 4.0, which spawned some discussion about WebServices between the attendees, and how best to use the new and existing features to implement various workflows.
This flowed nicely into a discussion of project management, and how best to implement project management around Bugzilla. The needs of the attendees around project management were all quite different, but we all generally agreed that the most important part of Project Management is ability to get an overview of the current status of a project at a glance. The Wikimedia Foundation had a a list of requirements for project management that more-or-less covered the advanced features that most organizations would expect from project management.
Yahoo! pointed out that many people have pre-existing project management systems that they are already comfortable with, so the most important thing is for Bugzilla to expose all of the interfaces that project management systems would need in order to interface with Bugzilla.
Once we had these requirements sorted out, the question was–how do we want to implement them?
Well, some things need to be implemented in Bugzilla itself, such as the ability for project management meetings to do simple mass-triage on a lot of bugs at once, using a single user interface. (For example, the ability to edit each field individually on each bug a list of bugs.)
However, most project management features belong in a separate product, perhaps an extension to Bugzilla, or maybe just a Mediawiki extension that allows for generating nice reports from Bugzilla. Most likely, we’ll end up with a combination of both–a Bugzilla Extension to add project management features to Bugzilla, and a Mediawiki extension to add more reporting and extended project management functionality.
It was universally agreed that the most important thing for us to do is to improve Bugzilla’s WebService interface until it can provide everything that an external Project Management tool would need, because even if we develop our own tool, there are still going to be a lot of people who want to use the tool that they’re already most familiar with, and offering integration points into Bugzilla will let people do that.
Our next meeting will be on Wednesday, December 8, 2010 at Yahoo! Inc. [alternate link: Faceook Event]. The focus of the meeting is going to be User Interface. We look forward to seeing you there!
-Max
August 17, 2010 03:17 AM
August 06, 2010
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
August 03, 2010
July 20, 2010
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
July 15, 2010
July 13, 2010
July 10, 2010
(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
Bugzilla 4.0 has frozen and soon it will be released. There are a bunch of exciting changes that you can expect which I will try to highlight over the next few posts. The big ones that I'm sure will get a lot of attention, for better or worse, are:
- the autocompletes for user fields and keywords
- redesigned advanced search page
- the redesigned attachments page.
- create page validation
We've also got a patch in the works that will redo the homepage and make it much prettier and professional looking thanks to Jon Pink. You can also look forward to that in 4.0!
As always we'd love to hear your feedback about this and the other changes that are coming in 4.0 (there are a lot of them,
jsonp, better extension support, new default workflow, more webservices... it's a long list).
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:
- UNCONFIRMED
- CONFIRMED
- IN_PROGRESS
- RESOLVED
- 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
June 26, 2010
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
June 25, 2010
June 19, 2010
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
June 03, 2010
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
June 02, 2010
May 15, 2010
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
May 05, 2010
April 23, 2010
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
April 14, 2010
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:
- On November 29, 2008, we released Bugzilla 3.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.
- 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
April 13, 2010
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
March 29, 2010
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 :-)
https://bugzilla.mozilla.org/buglist.cgi?resolution=—&query_format=advanced&component=Bugzilla-General&product=Bugzilla&ctype=csv
March 29, 2010 01:43 PM
March 24, 2010
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.
Bugzilla installer for Windows
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
March 23, 2010
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
March 17, 2010
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
March 16, 2010
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
There are 2 bugs which I have been paying some attention to recently.
The first one is
Bug 222861 which requests that images are displayed when they are mentioned in comments. This bug was important to me because I often found myself and others referring to images and attachments in comments and then having to open them up in a new window. I really wanted developers to just see the mocks i made along with my comments about them. It was determined that this bug makes more sense as an extension. So I wrote one. I've posted it here:
http://github.com/pyrzak/Bugzilla-Extension--Inline-Images. Hopefully you guys like it!
The second one is
Bug 395802 which requests to be able to support gravatar images. This is something Aza Raskin specifically mentioned by saying make it easier to know "who is this guy". Step 1 is adding a human face to a comment via the gravatar, Step 2 might be about grabbing their stats.
There were 2 mocks that I made as suggestions for how this should look. The first is:
My hope is that we're finally to the point where many of Aza's and other's ideas might be possible thanks to the new extension system and the jsonp bug
550727. Both of which wouldn't be possible if
mkanat didn't work so hard to add this kind of mash-up and extensibility, so thanks!
Any feedback about either of these extensions or anything else I mentioned is very welcomed.
March 09, 2010 02:43 PM
March 08, 2010
March 03, 2010
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
February 28, 2010
Here is the second version trying to take into account the suggestions given.
This UI would remember whatever is expanded and collapsed based on the user's cookies.
Another option that isn't displayed here is the column layout would change from 3 to X based on how wide the screen is (aka elastic).
I tried to increase the information density as well.
For saved/editable searches we might try to use the text description from the search UI.
Looking forward to hearing your feedback about the changes and improvements.
February 28, 2010 12:49 AM
February 27, 2010
There were some comments today about the attachments page and how wonky it is.
Bug 101770 has become the place where I've decided to post a response and possible solution to the problem but since I'm sure folks don't want to bother going to the bug here are the images that I posted. Let me know what you think. My hope is that we'll be able to implement this new UI quickly and make a big improvement without making anyone too upset about losing the current Attachments UI.
Things to note. The comments box and the attachment iframe would be elastic so they would grow with the width of the page. Clicking edit attachment as comment would cause the comment box to go away and the big area would turn into a comment.
My hope for this layout is to 1 give more realestate to the comment box that is equal to the area on the current bug page as well as make it easier for people editing the patches directly to have more room.
This UI also puts the focus where it belongs, on the attachment itself.
Things to note. I'm not at all happy with the placement of the patch and obsolete checkboxes. Any suggestions on where those should go is greatly appreciated.
February 27, 2010 06:59 PM
February 25, 2010
I already posted how you can use
YUI to use the Bugzilla web services available on the head. But lots of people don't like using YUI and prefer using JQuery. I haven't used JQuery much, but this experiment seems to have gotten the job done and should supply a basis for how to do more complex stuff with JQuery and the JSON-RPC interface.
Please note the JSON serialization capability isn't part of JQuery so I used a plug-in. The plugin doesn't seem to be as powerful as YUI's JSON serialization, but maybe it is and I haven't explored it enough. Anyway, here goes!
First you'll need JQuery and the JSON serialization parser. I added it under YUI but you should be able to add it before or after the YUI in the header.
<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.3.2/jquery.min.js"></script>
<script type="text/javascript" src="http://jquery-json.googlecode.com/files/jquery.json-1.3.min.js"></script>
Next comes the actual code which is very similar to the previous post.
First you create the JSON-RPC object:
var myObject = { "method": "Bug.add_comment",
"params": [ { "id": 1,
"comment":"I am using bugzilla's webservices with jQuery! YAY"
} ],
"id": 1 };
Then we encode it into a string:
var enc = $.toJSON(myObject);
Lastly we send it on its way using the JQuery ajax method:
$.ajax({"contentType":"application/json",
"data": enc,
"dataType": "json",
"url": "jsonrpc.cgi",
"type": "post",
success: function(d, ts){
console.log('w00t',d);
console.dir(d);
}
});
Just like in YUI we need to make sure we set the contentType to application/json and use a post (get is still disabled due to cross site scripting concerns). I set the dataType to JSON so Jquery would deserialize the response for me.
And now we've got a basic JSON-RPC message being sent. Now we'll still need to handle errors etc, but for now this is enough to get any eager JavaScript developer going.
Another example is getting bug info which might be equally helpful is available below. This method gets information about 2 bugs. I'm not going to explain it as much but it follows the same pattern.
var myObject = {
"method": "Bug.get",
"params": [{ "ids": [1,2]}],
"id": 1
};
var enc = $.toJSON(myObject);
jQuery.ajax({"contentType":"application/json",
"data":enc,
"dataType":"json",
"url":"jsonrpc.cgi",
"type":"post",
success:function(d, ts){
console.log('w00t', d);
console.dir(d)
}
});
The hope is eventually to release some JavaScript plugins for YUI (2 and 3) and JQuery that will make this sort of stuff much easier, like handle the serialization, and errors. But for now these examples will have to do.
For more info about what Bugzilla web services are available check out:
http://www.bugzilla.org/docs/3.4/en/html/api/index.htmlNext experiment... Jetpack! Any ideas on a cool bugzilla jetpack app?
February 25, 2010 10:03 PM
February 21, 2010
I added a few icons to one of my local Bugzilla installations a few weeks ago to make it look prettier. Some people think this is useless and brings no value, but I think it makes some pages look better than pure text pages. Below can you see how it looks like with some icons stolen from the Oxygen theme used in KDE4. Don’t be surprised if some icons look unrelated (for instance the one I used for « Bug Status Workflow »); this is simply because I couldn’t find a good one and I picked a random one as a proof of concept. 
From top-left to bottom-right: userprefs.cgi, admin.cgi, and report.cgi
I think such icons makes sense at least for some people for whom english is not their mother-language (like me). When you are unsure what a label means, the icon can help you here. I have to add some IDs to some HTML elements to be able to add icons as above, but my patch for bug 547496 is ready for checkin and so one can now build a skin with icons in it if he wants to (Bugzilla 3.7.1 or newer required, unless this patch is also accepted for 3.6rc1).
To be clear: these icons won’t be committed into the Bugzilla source code. So don’t worry, you are not going to see icons everywhere in the next release. I will probably create the skin and attach it somewhere else, so that you are free to download it if you like it (from what I understood on the legal page of the Oxygen icon theme website, their icons are freely available via the Creative Common license).
What do you think about this idea? Do you have better free icons in mind to use in Bugzilla?
February 21, 2010 01:15 PM
February 19, 2010
February 18, 2010
For a while we've been having discussions about tags and Bugzilla on the dev mailing list. To boil down a lot of the suggestion it consists of "we could do away with most of our fields/flags and replace them with tags, it would make the UI way better".
We've also had other discussions about how the bug edit page should change. Many of the suggestions consist of moving the non-comment data about a bug to the left or right side of the page and letting the comments take up most of the page.
Today (for the first time) i went into the code.google.com (cgc) bug tracker to see what the status of tagging was in chrome. Turns out both of these UI suggestions are exactly how chrome is implemented. I event went to the advanced search page to see if the suggestions i received from the advanced search page were the same (they weren't).
Anyway, i've received the message loud and clear "we like how google did it".
I'm tempted to make a jetpack that makes the BMO UI act/look a lot more like cgc. What do you guys think? Is it worth it or is TidyBug more the direction people prefer?
If you haven't seen cgc here is the URL i looked at today: http://code.google.com/p/chromium/issues/detail?id=17536
February 18, 2010 10:22 PM
February 17, 2010
So I saw the post for TidyBug and noticed someone commented that they switched back to Greasemonkey from Jetpack. I really like the idea of Jetpack, so i was bummed to see that someone had switch away from it because they wanted this feature so... I tried copying some of the features of tidyBug over to Jetpack.
Here is the URL for the jetpack in the gallery: http://jetpackgallery.mozillalabs.com/jetpacks/346
and an image to see what it does to the edit page...
For those of you who are not familiar with tidy bug here is the original post:
http://www.squarefree.com/2009/02/26/tidybug/
I'm still working on moving over all the features (like keyboard shortcuts). But the minimizing (what seems to be the best part) is part of this. Plus this version works with ANY version of Bugzilla running 3.4 onward, not just BMO.
For those using Chrome I might try to port this over as a chrome extension next weekend.
I'll also try using jetpack to prototype some other desired features, like prototyping the quicksearch helper mentioned in my previous post.
Feedback is always appreciated.
February 17, 2010 05:48 PM
February 16, 2010
We've been working on fixes from our usability research and surveys. With the recent post of
Bugzilla for Humanity, I was inspired to work on the Advanced Search UI because as Johnathan put it, "it is complete and terrible" and for "99% of searches you don't need it". However the other search, the simple search he doesn't bother to mention and of course he <3's quicksearch. I've filed bug
544404 to help quicksearch magic become more discoverable.
So the solution to make the advanced search page less complicated is a multi-parter as always in the Bugzilla world. Here are the steps which may or may not happen in the order they appear.
Step 1. Make the big summary box at the top of the page use quicksearch instead of a summary search.
Step 2. Make the other boxes on the advanced search page work as a helper to the quicksearch
Step 3. Make the advanced search page less complicated.
1 and 2 are more or less out of my area expertise so I'll leave those to mkanat and jjclark. But making the advanced search page less complicated, I can help with.
The approach I took was inspired by the redesign we did at work, basically apply a grid and hide the stuff that doesn't matter most of the time.
I've posted mocks up on bug
450301 but since I'm sure no one wants to read through the bug I'll post the images here:
and the expanded version
What do you all think?
February 16, 2010 04:08 AM
February 12, 2010
Jesse Ruderman’s TidyBug GreaseMonkey script (docs) turns this:
into this:
‘Nuff said.
February 12, 2010 05:46 PM
February 11, 2010
Two years and a half ago, I put a graph showing the contributions of main Bugzilla developers. Doing this exercice again on a broader time frame, the results are pretty dramatic (click the image for a larger view):
Top 5 Bugzilla contributors per major release
This table shows you the top 5 contributors per major Bugzilla release, and the third row shows you the percentage of bugs fixed by the top two contributors compared to all bugs fixed for a given release. As you can see, mkanat and I are the two main contributors since Bugzilla 2.20 (released in September 2005), and the ratio of bugs fixed by us two compared to all contributions keeps increasing, reaching 75% (!) for the coming Bugzilla 3.6 release. Knowing that we both have a real life and a day job, I hope you better understand why we cannot fix all bugs and implement all requests for enhancement in a timely manner, and why we have to prioritize what to do next, meaning that some of your requests won’t be addressed in the near future (/me waves some of the Mozilla folks who like to complain rather easily). As always in the open-source world, if you want something quickly, you are welcome to contribute!
February 11, 2010 01:02 AM
