A year or so ago we redesigned our main website at https://www.bugzilla.org/ . The new site has a blog with an RSS feed available, so to avoid duplication of effort, news posts will be getting put there from now on.
So go check out the news page at https://www.bugzilla.org/blog !
Hint: We just released new versions of Bugzilla, and you can read about it there!
Today, August 26, marks the 25th anniversary of Bugzilla!
The first two paragraphs lifted from our Bugzilla history:
When mozilla.org first came online in 1998, one of the first products that was released was Bugzilla, a bug system implemented using freely available open source tools. Bugzilla was originally written in TCL by Terry Weissman for use at mozilla.org to replace the in-house system then in use at Netscape. The initial installation of Bugzilla was deployed to the public on a mozilla.org server on April 6, 1998.
After a few months of testing and fixing on a public deployment, Bugzilla was finally released as open source via anonymous CVS and available for others to use on August 26, 1998. At this point. Terry decided to port Bugzilla to Perl, with the hopes that more people would be able to contribute to it, since Perl seemed to be a more popular language. The completion of the port to Perl was announced on September 15, 1998, and committed to CVS later that night.
25 years is a long time in the software world, and it makes us happy that so many people still use Bugzilla to track bug reports and feature requests for their own products. We hope to continue to breath life into Bugzilla and continue to modernize it over the years to come!
Back in December I made an enthusiastic post about getting Bugzilla back in motion after it kind of stalled for a while. And then after a month I kind of stopped posting about it. So what happened?
Well, response to that post was actually pretty enthusiastic in itself. I heard from several people who wanted to donate money to the project to get it going again. Which then led to a new problem: we didn’t actually have a legal way to accept donations at the time. So after asking around a bit, and a few conference calls between myself, my own company’s lawyer, and a couple of Mozilla’s lawyers, it was decided that Bugzilla needed a legal entity to manage it, similar to how Thunderbird has been operating recently. And, that’s where the little bit of time that I’ve had to spend on Bugzilla has gone the last 6 months. And as you can understand, with the legal work going on in the background, there wasn’t much I could actually talk about until all of the pieces were actually in place.
Which now brings us to today, when I’m happy to announce the formation of Zarro Boogs Corporation, which will now be overseeing the Bugzilla Project. This is a taxable non-profit non-charitable corporation – we have filed with the IRS our intent to operate under US Tax Code §501(c)(4) (still pending approval from the IRS) meaning the IRS would require us to spend money raised on project expenses and not make a profit, but money donated to us will not earn you a tax deduction because we aren’t a charity (software development is not considered a charitable cause in the US). Unlike Thunderbird, which is a subsidiary of the Mozilla Foundation, we are an independent entity not owned by or associated with the Mozilla Foundation, although they have licensed the use of the Bugzilla trademark to us.
The name Zarro Boogs Corporation is a shout-out to the phrase returned by Bugzilla when you run a search which returns no results, “Zarro Boogs found.” The buggy spelling of “Zero Bugs” being intentional because it’s generally believed that there’s no such thing as a project with zero bugs in it, only bugs that haven’t yet been reported, thus, saying “Zero Bugs” is, in itself, buggy. There’s a nice write-up of this on Wikipedia.
If you would like to contribute to the project, we have a donation page set up on GitHub Sponsors. We hope to have additional ways to donate that don’t require a GitHub account in the future.
Those releases I talked about back in December are finally happening! Look for these (except for 5.9.1) this coming week! Right now we’re aiming for Wednesday, August 30th. We are aiming for September 15 for 5.9.1 (because it’s the 25th anniversary of the port from Tcl to Perl).
4.4.14 – The 4.4 branch has been on life support for a LONG time (it was initially released in 2013!!!). It supports outdated OSes that are hard to find or install, let alone test for these days, and we’ve been itching to drop it for a long time. But our support policy says that we have to support it for 4 months after the following two major releases. The next major release after 4.4 was 5.0, and there have been no major releases after that, which means that 4 month countdown hasn’t even started yet. I am intending this to be the final release of the 4.4 branch (barring any additional security issues being found in the next 4 months) as the 5.2 release below will start that 4 month countdown to End-of-Life this branch.
5.0.4.1 – Why 5.0.4.1 when there’s a 5.0.6 release? Well, if you paid attention to the change logs, 5.0.5 and 5.0.6 contained a massive schema change, as well as reformatting almost all of the Perl code in the source, both of which are a violation of our support policy for a stable branch (a new-to-the-process release manager pushed the release out not realizing that, and by the time we caught it, it was too late). A lot of people noticed this and never upgraded to 5.0.5 or 5.0.6, since they didn’t contain any security fixes. 5.0.4.1 will give those people additional fixes for 5.0.4 without forcing them to pick up those schema and code reformatting changes. Additional updates to the 5.0 branch from now on will continue from 5.0.4.2 and onward.
5.2 – This will be the next major release, and will start the 4 month countdown for discontinuing the 4.4 branch. 5.2 is forked from the 5.0 branch after 5.0.6, and will contain those schema and code formatting changes from 5.0.5 and 5.0.6 in it. So if you did upgrade to 5.0.6, 5.2 will be equivalent to a point upgrade for you. Those schema changes should have caused a major release to happen anyway, so this is just fixing the numbering problem with that release (i.e. 5.0.5 should have been called 5.2 to begin with). Note that if you are using the 5.1.x development releases, those did NOT feed into this, and 5.2 would actually be a downgrade for you.
5.1.3 – The 5.1 branch is basically dead, as we’ve put all of our resources into finishing off the Harmony release (see 5.9.1 below). We’re going to encourage people on 5.1.x to move to Harmony, but you’ll want to be mindful of the release blockers first before you make the jump. There are some features in 5.1.x that were implemented differently in Harmony, and the code to migrate the related data may or may not work yet (if the feature in question is listed on the release blockers and you use it, you’ll want to wait for now). Even though this branch is dead, we’re going to put out a release with the current batch of security fixes so you aren’t left high and dry before Harmony is ready for you.
5.9.1 – Coming September 15! This will be the first official release off the Harmony branch, and will be classified as a developer preview release, not for production use. This is what will eventually be Bugzilla 6. The code is mostly good enough to use right now, but there are still showstoppers to be able to fully release it as a production release. There are also a few gotchas when upgrading from older versions of Bugzilla. If you’re interested in helping make Bugzilla 6 happen, that list of showstoppers is here. We are hoping to have Bugzilla 6 in release candidate stage (or at least in beta) by the end of November. The security content for this branch that goes with the other branch releases will be committed to git at the same time the other releases get them, since anyone who has this already will only have it via git pull.
You can always find a list of ways to contribute to Bugzilla on our Contributing page. A few highlights with additional details:
We have a lot of excitement ahead of us with the first developer preview of Bugzilla 6 coming later this week (I was hoping to have that for you all today as well, but we didn’t quite make it), and the new opportunities in store for us with a real business entity to support the project now. Come find us in any of our chat rooms (links are in the footer of our website alongside the social media links) or drop in on our developers mailing list if you’d like to help.
I’m going to try to keep a monthly newsletter like this going so people can keep up to date on what’s going on with the Bugzilla project. Hopefully in the future I’ll get it out a little closer to the beginning of the month. With that said, here’s a review of what happened in December 2022:
We’re making slow and steady progress. I’m starting to think we won’t get the big releases that I mentioned in the blog post last month out as soon as hoped, but we’re definitely getting closer.
Most of the fixed bugs in December had to do with cleaning up the website (fixes for things broken by the site redesign).
Upcoming plans for January (and perhaps February) :
The rest of this post is a bunch of statistics, so if you’re not into that stuff you can stop reading now.
There were 11 new bugs filed in December, of which one of them is classified as a low-severity security bug. 2 of the bugs were for the website, and 1 for the IRC bot, the remainder for Bugzilla itself.
Overall there were 17 bugs touched during December, including the above 11.
7 bugs were resolved. 3 INVALID, 1 WORKSFORME, 1 DUPLICATE, and 2 FIXED.
0 pull requests were created in the bugzilla repo.
0 pull requests were touched in the bugzilla repo.
0 pull requests were closed in the bugzilla repo.
1 pull request was created in the harmony repo.
2 pull requests were touched in the harmony repo.
1 pull request was closed in the harmony repo
There were 22 total commits to GitHub across all of Bugzilla’s repositories.
The meaningful commits to harmony did the following:
And that’s it for December!
posted by Dave Miller – Bugzilla Project Lead
Surprise! Bugzilla’s not dead yet. 
So I posted a bunch of this a few months ago on the developers mailing list but it’s time to get it in front of a bigger audience.
I am trying to kick-start getting stuff moving again with Bugzilla since most of the core Bugzilla volunteers have had job changes over the last few years that have left them with less time to spend on the project, so things have been very slow going for a while. For those that don’t know, I’ve been more or less of a figurehead of a project leader for a number of years now, not having much time to spend on Bugzilla, but not having anyone in a position to be able to step in to replace me, and only stepping in myself to make decision calls when the other developers were at an impasse. I’ve attempted to hand off control of the project to someone else twice in the last 10 years or so, and both times, the person I was about to hand off to got a new job and didn’t have time for it anymore just before we were about to do the hand-off (on the plus side, that happened before they took over and not after). It takes a while for someone to build the trust needed to know I’m leaving it in good hands, so without a lot of active developers it’s hard to get someone in place to do that. But I’ve had some life changes of my own now, which actually give me more time to spend on Bugzilla finally, so I’m getting back in the saddle and taking direct control again. I’ve probably poked at it more in the last 5 or 6 months than I have in the last 5 or 6 years combined.
I have started a new consulting business, and I’ve been trying to structure it in a way that allows me to spend time on Bugzilla again. (If you want to hire me to help with your Bugzilla, or help funding work on upstream Bugzilla, feel free to contact me, even if I’m not publicly advertising yet)
Now back to the nitty gritty and my plans for this project.
There is a call for help in this post below the release information. If you can give us a hand it would be greatly appreciated. Not all of it is code-related, so there might be something you can do even if you’re not a coder!
Prior to a few weeks ago, our main website hadn’t been updated beyond quick bugfixes to content in a long time. LCP recently did a full overhaul of the website to modernize it and make information easier to find. We deployed this a few weeks ago, so go have a look! It looks awesome! Also, the new website has RSS feeds!
Also over the last couple months, I’ve been working on getting some of the project infrastructure back in place to help support active development. Among the list of things that have gotten done are:
I would like to put out a new multi-branch release of Bugzilla as soon as we can get all the pieces in place to do so. I was hoping to do this within a few weeks of the original post to the developers list, but that was back in August and it hasn’t happened yet. At this point I think we’ll be really lucky if it happens before the end of December; though mid-January is definitely a possibility. As a forewarning to everyone, there will be security content in it, and that’s part of the holdup. For obvious reasons I can’t ask for help with the security bugs outside of the existing core developer team, as that risks exposure to hackers that might take advantage of it before users have a chance to update. So we ask for your patience while we work through these issues and get them ready to land.
The 4.4 branch has been on life support for a LONG time (it was initially released in 2013!!!), supports outdated OSes that are hard to find or install, let alone test for these days, and we’ve been itching to drop it for a long time. But our support policy says that we have to support it for 4 months after the following two major releases. The next major release after 4.4 was 5.0, and there have been no major releases after that, which means that 4 month countdown hasn’t even started yet.
4.4.14 – I am intending this to be the final release of the 4.4 branch (barring any additional security issues being found in the next 4 months) as the 5.2 release below will start that 4 month countdown to End-of-Life this branch.
5.0.4.1 – Why 5.0.4.1 when there’s a 5.0.6 release? Well, if you paid attention to the change logs, 5.0.5 and 5.0.6 contained a massive schema change, as well as reformatting almost all of the Perl code in the source, both of which are a violation of our support policy for a stable branch (a new-to-the-process release manager pushed the release out not realizing that, and by the time we caught it, it was too late). A lot of people noticed this and never upgraded to 5.0.5 or 5.0.6, since they didn’t contain any security fixes. 5.0.4.1 will give those people additional fixes for 5.0.4 without forcing them to pick up those schema and code reformatting changes. Additional updates to the 5.0 branch from now on will continue from 5.0.4.2 and onward.
5.2 – This will be the next major release, and will start the 4 month countdown for discontinuing the 4.4 branch. 5.2 is forked from the 5.0 branch after 5.0.6, and will contain those schema and code formatting changes from 5.0.5 and 5.0.6 in it. So if you did upgrade to 5.0.6, 5.2 will be equivalent to a point upgrade for you. Those schema changes should have caused a major release to happen anyway, so this is just fixing the numbering problem with that release (i.e. 5.0.5 should have been called 5.2 to begin with). Note that if you are using the 5.1.x development releases, those did NOT feed into this, and 5.2 would actually be a downgrade for you.
5.1.3 – The 5.1 branch is basically dead, as we’ve put all of our resources into finishing off the Harmony release (see 5.9.1 below). We’re going to encourage people on 5.1.x to move to Harmony, but you’ll want to be mindful of the release blockers first before you make the jump. There are some features in 5.1.x that were implemented differently in Harmony, and the code to migrate the related data may or may not work yet (if the feature in question is listed on the release blockers and you use it, you’ll want to wait for now). Even though this branch is dead, we’re going to put out a release with the current batch of security fixes so you aren’t left high and dry before Harmony is ready for you.
5.9.1 – This will be the first official release off the Harmony branch, and will be classified as a developer preview release, not for production use. This is what will eventually be Bugzilla 6. The code is mostly good enough to use right now, but there are still showstoppers to be able to fully release it as a production release. There are also a few gotchas when upgrading from older versions of Bugzilla. If you’re interested in helping make Bugzilla 6 happen, that list of showstoppers is here.
There’s a few things (not all necessarily code related) that I would love to get help with prior to the above releases. This list is not entirely the same as the one that was in the original post to the developers list. Some of the items in that list actually got done! Yay! Thanks to those of you who pitched in!
There’s also a few things not specifically related to the above release that we’d love to get help with on an ongoing basis:
If you can help with any of these things, visit us on IRC or Matrix (links to both can be found in the left sidebar on https://bugzilla.org/ ), join the developer mailing list and post there, or add comments to the above-listed bugs.
—
Dave Miller
Bugzilla Project Lead
Our regular monthly project meeting video conference call for April will be Wednesday, April 3 at 8pm UTC / 4pm EDT / 1pm PDT. We’re getting close (relatively) with Bugzilla 6 – currently estimating end of summer or early fall, and we’ll be having some live demos of some of the recent new features and user experience improvements in Bugzilla at this month’s meeting, so you won’t want to miss it.
Our regular meeting schedule dictates that our meetings are held on the first Wednesday of every month at 21:00 London Time. Since the first Wednesday of January is the 2nd and a lot of people will still be on vacation then (and we’ll have issues getting resources for the meeting) we’ll be holding our January meeting on January 9th instead. You can still find all the details at https://wiki.mozilla.org/Bugzilla:Meetings
The Upcoming events in the sidebar here will update to reflect that whenever WordPress’s cache expires.
Yesterday, we had our monthly project meeting, and did it panel-discussion style from the Mozilla AllHands meeting in Orlando, FL. We ended up with quite an interesting discussion with lots of good info about Bugzilla 6, and some questions for users of Bugzilla (feel free to comment here with your answers!). The recorded video is here:
This month’s Bugzilla Project meeting coincides with the Mozilla Allhands in Orlando, and since most of our usual participants will be here in person we’ll be holding it panel-discussion style from the Europe 2 conference room on the Lobby level of the Dolphin at 4pm Eastern. Anyone who’s at the Allhands is welcome to come see us. Of course, it’ll still be streamed on Air Mozilla at 21:00 UTC as usual, and dial-in will be available for anyone remote who wants to talk or ask questions. All the details (Sched link, Video stream links, dial-in info) is at https://wiki.mozilla.org/Bugzilla:Meetings
The open source release of Bugzilla turns 20 years old today!
The first two paragraphs lifted from our Bugzilla history:
When mozilla.org first came online in 1998, one of the first products that was released was Bugzilla, a bug system implemented using freely available open source tools. Bugzilla was originally written in TCL by Terry Weissman for use at mozilla.org to replace the in-house system then in use at Netscape. The initial installation of Bugzilla was deployed to the public on a mozilla.org server on April 6, 1998.
After a few months of testing and fixing on a public deployment, Bugzilla was finally released as open source via anonymous CVS and available for others to use on August 26, 1998. At this point. Terry decided to port Bugzilla to Perl, with the hopes that more people would be able to contribute to it, since Perl seemed to be a more popular language. The completion of the port to Perl was announced on September 15, 1998, and committed to CVS later that night.
20 years later, Bugzilla is still alive and kicking, and about to get a major facelift that’s about 10 years overdue. I had really hoped to be announcing the release of Bugzilla 6 with this post, but we’re not quite there yet. Dylan has been making great progress with the recent merges from bugzilla.mozilla.org, though, and I’m hopeful that we’ll have something that people can at least try out in the really near future. Realistically we’re a few months away from having a full release though.
Over the last 20 years we’ve had about 300 contributors to the Bugzilla code. Here’s a few words from the very first one:
I am in complete shock and awe that Bugzilla has lasted this long. 20 years? Hardly any software lasts more than 5. I’m so very proud that it’s still going strong after these years.
20 years ago from tomorrow (on August 27th, 1998) I filed several bugs against Bugzilla, known problems that I thought would want to get fixed. I’m delighted to point out that one of these bugs <https://bugzilla.mozilla.org/show_bug.cgi?id=540> is STILL open. After all, you need long-living bugs if you’re going to have a long-living bug system!
— Terry Weissman
And that bug is finally about to get fixed.
Other exciting developments include running as a standalone daemon with Mojolicious and the multitude of user experience enhancements by BugzillaUX in the pipeline make the future look bright!
Here’s to the next 20 years!
For those that hadn’t already seen it, Air Mozilla is in the process of switching over to a new platform. They’ve already discontinued posting new content on the old platform, and the new platform doesn’t have anonymous access available yet (but it’s coming at the end of June). This means the old URL for watching our meetings live isn’t going to work this month. Fortunately, public meetings on the new platform are mirrored to Youtube, so you’ll be able to watch it at https://www.youtube.com/watch?v=A7OC8CXMGyo
Of course, if you want to participate instead of just watch, feel free to join us using one of the methods on the wiki.
Today’s meeting will probably be short – Dylan is traveling and won’t be able to attend. The only thing currently on the agenda is an update on our hosting situation. If you have anything else you’d like to discuss, attend the meeting and ask!
See you there!
Dylan is out sick today, and we don’t have any major updates to share at the moment anyway, so we’re cancelling today’s meeting. We’ll see you on June 6th.
Below are the minutes from today’s Bugzilla meeting along with a link to the video recording of the meeting.
There was a lot of good information in today’s project meeting. Below are the minutes from the meeting as well as a link to the video recording of the meeting. Be sure to check out and comment on the new project roadmaps!
video recording of this meeting
The next meeting will be on Wednesday, April 4, at 20:00 UTC (9pm BST / 4pm EDT / 1pm PDT)
Today we have several new releases.
All of today’s releases contain security fixes. We recommend that all Bugzilla administrators read the Security Advisory that was published along with these releases.
Bugzilla 5.0.4 is our latest stable release. It contains various useful bug fixes and security improvements:
Bugzilla 4.4.13 is a security update for the 4.4 branch:
Bugzilla 5.1.2 is an unstable development release. This release has not received QA testing from the Bugzilla Project, and should not be used in production environments. Development releases exist as previews of the features that the next major release of Bugzilla will contain. They also exist for testing purposes, to collect bug reports and feedback, so if you find a bug in this development release (or you don’t like how some feature works) please tell us.
Bugzilla comments are, by default, plain text – so typing <U> will produce less-than, U, greater-than rather than underlined text. However, Bugzilla will automatically make hyperlinks out of certain sorts of text in comments. For example, the text http://www.bugzilla.org will be turned into a link: http://www.bugzilla.org. Other strings which get linkified in the obvious manner are:
A corollary here is that if you type one or more bug numbers in a comment, you should put the word “bug” before each of them, so they gets autolinkified for the convenience of others.
But also, if you have some text you want linkified in this way, perhaps for use in a blog post, status report, wiki page or other place, you can use the handy linkifier, which will do exactly that for you.
Today we have several new releases for you!
All of today’s releases contain security fixes. We recommend that all Bugzilla administrators read the
Security Advisory that was published along with these releases.
Bugzilla 5.0.3 is our latest stable release. It contains various
useful bug fixes and security improvements:
Bugzilla 4.4.12 is a security update for the 4.4 branch:
Bugzilla 5.1.1 is an unstable development release.
This release has not received QA testing from the Bugzilla Project, and should not
be used in production environments. Development releases exist as previews of the
features that the next major release of Bugzilla will contain. They also exist for
testing purposes, to collect bug reports and feedback, so if you find a bug in this
development release (or you don’t like how some feature works) please
tell us.
Note:Make sure ImageMagick is up-to-date if the BmpConvert extension is enabled.
If no updated ImageMagick version is available for your OS, we recommend to disable the BmpConvert
extension for now (bug 1269793).
Today we have several new releases for you!
All of today’s releases contain two security fixes. We recommend that all Bugzilla administrators read the Security Advisory that was published along with these releases.
Bugzilla 5.0.2 is our latest stable release. It contains various useful bug fixes and security improvements:
Bugzilla 4.4.11 is a security update for the 4.4 branch:
Bugzilla 4.2.16 is a security update for the 4.2 branch:
Today we have several new releases for you!
All of today’s releases contain security fixes. We recommend that all Bugzilla administrators read the Security Advisory that was published along with these releases.
Bugzilla 5.0.1 is our latest stable release. It contains various useful bug fixes and security improvements:
Bugzilla 4.4.10 is a security and bug fix update for the 4.4 branch:
Bugzilla 4.2.15 is a security and bug fix update for the 4.2 branch:
The recent release of Bugzilla 5.0 was the first release sporting the new, improved Bugzilla documentation, which has been moved from DocBook XML to reStructuredText to make it easier to edit and so more likely to be up-to-date :-).
Readers of this blog may be particularly interested in the User Guide. Feedback on the new docs is welcome, particularly suggestions for where it is lacking – please use the bug filing link at the bottom of each docs page.
For the past few months, a new experimental modal bug view has been available on bugzilla.mozilla.org. This hides a lot of complexity both through being read-only initially, and also through having expandable and collapsible sections. It is also quicker and less resource-intensive to load. It requires you to click an “Edit” button, which reveals much more UI, when you want to do more than the common operations – add a comment, CC/NI people, or change the Status or Resolution. It is also more dynamic – for example, there are no more interstital pages when moving bugs between Products, because when you change the Product, the new lists of Components, Milestones etc. load into the widgets automatically.
A picture is worth a thousand words. Here’s the initial view:
And here’s the Edit view:
You can enable it in the Preferences – change “Use experimental user interface” to “On”.
Thanks to glob for doing the hard work on making this happen. This view has not yet made it upstream to Bugzilla itself.
As discussed on the Bugzilla developers mailing list/newsgroup and confirmed by project leads, Bugzilla’s new release policy is to end-of-life the oldest supported major version four months after a new major release. Since this is the first time we’re enacting this policy, we’ve extended the date to be 4 months from today rather than from Bugzilla 5.0’s exact release date (July 7th).
Thus Bugzilla 4.2 will be end-of-lifed on 30 November 2015. This means no fixes of any kind will be issued for Bugzilla 4.2 from that date onwards. As usual, all Bugzilla admins are encouraged to upgrade to the latest version of Bugzilla as soon as possible, especially those running 4.2 or earlier.
To expand a bit further on our new EOL process, after a new major release, we will support three major releases (including the new one) for four months. After four months, we will drop support for the oldest one. We will continue to support the remaining two until four months after the next release.
For example, currently we support 4.2, 4.4, and 5.0. In four months’ time we will drop support for 4.2 and support only 4.4 and 5.0. When the next major version comes out, perhaps 5.2*, we will support 4.4, 5.0, and 5.2. Four months later, we will drop support for 4.4 and support only 5.0 and 5.2.
Mark Côté
Assistant Project Lead, Bugzilla
* It may be 6.0 if there are major and/or breaking changes.
Today the Bugzilla Project is extremely proud to announce the release of Bugzilla 5.0!
It has been slightly over two years since we released Bugzilla 4.4 on May 2013. This new major release comes with many new features and improvements to WebServices and performance.
We hope that you enjoy and appreciate the results of the past two years of hard work by our entirely-volunteer community.
Please note that the release of Bugzilla 5.0 also marks End Of Life for the Bugzilla 4.0 series, meaning that there will be no further updates for the 4.0.x series, even if there are serious security
issues found in that series. We recommend that all installations running the 4.0 series upgrade as soon as possible to 5.0.
The Bugzilla team recently finished a big project to update, rewrite, improve and centralize Bugzilla’s documentation. You can find it at http://bugzilla.readthedocs.org/. In particular, there’s a User Guide which will be useful to, er, Bugzilla users.
If you have suggestions for further improvements to the documentation, please let the team know.
People often wonder how to make searches in Bugzilla faster on large installations. Two things will give you the most bang for the buck:
Do those two things, and your searches will be much faster.
Coincidentally enough, Bugzilla’s “Simple Search” (BMO version) allows you to specify precisely those two things.
Vanilla Bugzilla lets you decide which bugmail you receive based on what changed about a bug. But there are a couple of extensions which give you even more control, and both are installed on bugzilla.mozilla.org. So the new email filtering pipeline is as follows:
Firstly, ComponentWatching, as the name implies, lets you “watch” particular products or components, so you get put on the list to receive bugmail for all changes to any bugs in those products or components. This is very useful if you have an interest in a particular area of the project. You can also watch particular users – that function is built-in.
Secondly, the normal email filters run, which exclude or include you from emails based on the particular fields which have been changed in the bug update.
Lastly, the BugmailFilter extension allows you to define “include” or “exclude” rules based on any one of:
Using these three capabilities in tandem, it should be possible to carefully control how much bugmail you receive, even if you are using a system like Gmail which does not have good client-side filtering.
“Quicksearch” is a way of searching Bugzilla using simple yet powerful syntax. The search box at the top of every page supports it.
Jesse Ruderman has written a wonderful Quicksearch Reference – a must-read if you search Bugzilla a lot.
To speed up quicksearches, limit the search by product or component. Add “comp: <string>” to your query to limit it to components whose names contain that string. As an abbreviation, you can simply use “:” instead of “comp:”, although that also searches in products whose names which contain the string.
By analogy with the use of “:”, there are abbreviations for some other common fields as well.
(Thanks to Ben Hearsum and Ed Morley)
Another guest post from Stefan Arentz:
“If you do a lot of quick searches to find bugs by summary and you don’t care about also looking into the comments of those bugs, flip the “Include comments when performing quick searches (slower)” to NO in your preferences.
A search for ‘radio antenna’ just went down from 30+ seconds to just a few seconds.”
Guest tip from Stefan Arentz:
“Bugzilla actually does have HTML emails! [As of version 4.2, but it’s been backported to bugzilla.mozilla.org’s 4.0 installation – Ed.] I always though that it did not because I did not look further than the “Email Preferences” tab. But there actually is a “Preferred email format” under the “General Preferences” tab.
This makes Bugzilla emails 100x easier to read on a phone.”
Continue reading "Upgrading bugzilla.mozilla.org to version 3.4.3"