August 06, 2016
One recurring subject on the bugzilla
support mailing list is the installation of the Perl modules that Bugzilla
requires to function. When you are installing on a Linux distribution, the
recommended course of action is to use the packages supplied by the
distribution. But, on some distributions, these can be of a version lower than
what is required by Bugzilla.
One such distribution is RHEL. Version 7 came out in 2014 and its long support life
cycle make it popular for people to use it as a base for their bugzilla
instance. Using Bugzilla 4.4 is easy because all Bugzilla's mandatory Perl
packages are available by default but Bugzilla 5.0 came out after RHEL7 was
released and a number of Perl modules aren't available or are outdated. Users
then try to install the missing modules themselves, which is something easy to
get wrong. I decided to see if this could be made simpler.
My first step was to see if the modules could be supplied in EPEL, a third-party
software repository for RHEL and CentOS but some of the modules concerned are
in RHEL which makes them impossible to update via EPEL. Another solution is the
use of Fedora's COPR, an easy way for Fedora developers to maintain third party
repositories for Fedora and/or RHEL.
It took some amount of tweaking to find the package versions that allow you
to run Bugzilla 5.0.x without replacing RHEL7's entire Perl stack but the end
result is here. Activating a COPR repo is pretty straightforward:
- dnf install dnf-plugins-core
- dnf copr enable eseyman/bugzilla-5.0
At which point, you can install bugzilla just like any other
application:
The bugzilla package will be updated everytime a new version of Bugzilla is
released and its support will end when the Bugzilla developers end support for
the 5.0 branch.
August 06, 2016 03:17 PM
May 19, 2016
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).
May 19, 2016 07:04 PM
May 16, 2016
For historical reasons (or “hysterical raisins” as gps says) that
elude me, the BMO database has been in (ughhh) Pacific Time since it
was first created. This caused some weirdness on every daylight
savings time switch (particularly in the fall when 2:00-3:00 am
technically occurs twice), but not enough to justify the work in
fixing it (it’s been this way for close to two decades, so that means
lots of implicit assumptions in the code).
However, we’re planning to move BMO to AWS at some point, and their
standard db solution (RDS) only supports UTC. Thus we finally had the
excuse to do the work, and, after a bunch of planning, developing, and
reviewing, the migration happened yesterday without issues. I am
unreasonably excited by this and proud to have witnessed the
correction of this egregious violation of standard db principles 18
years after BMO was originally deployed.
Thanks to the BMO team and the DBAs!
May 16, 2016 12:52 AM
February 08, 2016
Much of this post is taken from a message I posted to the developers list a few days ago, so my apologies in advance to anyone reading it again. I’ve expanded on a few things and added the information about the upcoming meeting, so it’s probably worth re-reading.
For those unaware of the context, Frédéric Buclin last week announced that he was stepping down from his Assistant Project Manager position after 9 years.
To Frédéric: Thanks again (and again!) for all your hard work over the years! As stretched as I’ve been for time myself it has been a true godsend to have you picking up my slack the last few years. You will be missed!
To everyone else: For the time being, I’ll be handling approval requests, so if you have something up for approval and it’s not getting attention, I’m the one to pester.
This is sort of the end of an era for the Bugzilla project… Both Frédéric and Max (who left to work at Google a couple years ago and stepped down from his position earlier this year for lack of time) have been with the project for much longer than most people ever stick with a single employer in IT-related jobs (of which an open source project of this magnitude has a lot of similarities). For an open source project, that’s outright amazing, as people tend to come and go a lot in most projects. It’s kind of surprising that I’ve been around longer than them, but I’m kind of a “lifer” in some ways, and in reality I’ve had a good break from the project for the last few years because Max and Frédéric have been mostly taking care of everything while I’ve been busy with other things.
So it’s time to begin a new era. Since I’ve had a good break to clear the monotony I’m going to be trying to get more involved myself again (which I’ve been saying ever since Max left, but I have a lot more incentive now). I’d also like to kickstart a new team to lead the project, and kind of re-organize if you will. We have a number of positions within the project for various functions, which we’ve never really paid attention to as people moved on. So some questions we’ll be asking at our upcoming meeting are:
- What positions in our existing structure do we have open?
- Do we still need them all?
- Are there new positions we have a need for that we should create?
- Who should fill them?
- Do the existing holders of positions that we still need and haven’t been vacated want to keep doing them?
We also have some other “reinventing the project” type topics while we’re at it. There’s a number of things we’ve been talking about doing for a long time that we never really moved on, and some of the big elusive dreams (the big UI overhaul!) have actually been making progress as well, lately. When we’re in the middle of big changes like this, I think it’s a good time to review where we are, get everyone on the same page, and tackle some of these things we keep talking about.
We also have a lot of new useful technology at our disposal since the last time we had a project meeting. We’re going to experiment with using Google Hangouts for the meeting this time, and using their feature to stream the Hangout via YouTube for those who want to watch without participating. We’ll also keep our usual meeting IRC channel open so people who don’t have a Google+ account and don’t want to get one can still participate and ask questions via IRC.
The preliminary agenda and participation instructions have been posted at https://wiki.mozilla.org/Bugzilla:Meetings. The meeting will be held on Wednesday, July 17th, at 14:00 UTC. And before anyone complains about the time, this was the best time to avoid inconveniencing the largest number of people. The Bugzilla Project has a global pool of contributors, and we have active contributors in a wide variety of time zones. The time chosen puts the meeting in the middle of the night for the fewest number of people. Those on the west coast in the US will probably have to get up a little early, and those in eastern Australia will be up a little later.
A lot of the emails and comments I’ve gotten since Frédéric’s announcement have been really positive, so I’m encouraged by the number of people who are still committed to keeping Bugzilla vibrant! We’ll see you at the meeting on Wednesday!
February 08, 2016 12:30 AM
January 08, 2016
It’s been a whole year since my last BMO update, partly because I’ve
been busy with MozReview (and blogging a lot about it), and partly
because the BMO team got distracted from our goals by a few sudden
priority changes, which I’ll get to later in this post.
Plans from 2014
Even with some large interruptions, we fully achieved three of our
five goals for the year and made good progress on a fourth.
Alternative Bug Views
Have you tried out the new modal UI? Although not completely
finished (it lacks a few features that the standard UI has), it’s very
usable. I don’t remember the last time I had to switch back, and I’ve
been using it for at least 6 months. Bonus: gone is the intermediate
page when you change a bug’s product, a gripe from time immemorial!
Even though there are still a large number of controls, the new UI is
a lot more streamlined. glob gave a brief presentation at a
Mozilla Project Meeting in November if you’d like to learn more.
The part we haven’t yet undertaken is building on this new framework
to provide alternate views of bug data depending on what the user is
trying to accomplish. We want to experiment with stripping down the
presented data to only what is needed for a particular task,
e.g. developing, triaging, approving, etc. The new UI is a lot more
flexible than the old, so in 2016 we’ll build out at least one new
task-centric view.
GitHub Authentication
If you haven’t noticed, you can log into BMO via GitHub. If you’ve
never used BMO before, you’ll be prompted to set up an account after
authenticating. As with Persona, only users with no special
privileges (i.e. not admins nor people in security groups) can log in
via GitHub.
Auth Delegation
Originally designed to smooth the process of logging into Review
Board, auth delegation for API keys is actually a general-use
feature that greatly improves the user experience, not to mention
security, of third-party apps by allowing them to delegate
authentication to BMO. There’s now no reason for apps to directly ask
for your BMO credentials!
MozReview Details
There’s now a panel just above the attachments table that shows all
the MozReview commits associated with the displayed bug along with a
bit of other info:
We’re currently sorting out a single method to display other relevant
information, notably, status of reviews, and then we’ll add that to
this table.
Improved Searchability
This is the big item we haven’t made much progress on. We’ve got a
plan to mirror some data to an Elasticsearch cluster and wire it into
Quick Search. We’ve even started on the implementation, but it’s not
going to be ready until mid-2016. It will increase search speeds,
understandably one of the more common complaints about BMO.
Curve balls
We had two sets of surprises in 2015. One was work that ended up
consuming more time than we had expected, and the other was important
work that suddenly got a big priority boost.
BMO Backup in AWS
The first is that we moved the BMO failover out of a data center in
Phoenix and into the cloud. IT did most of the work, but we had to
make a series of changes to BMO to facilitate the move. We also had a
lot of testing to do to. The upside is that our new failover system
has had more testing than our old one had for quite some time!
Hardened Security
In August we found out that an attacker had compromised a privileged
BMO account, using a combination of a weak, reused password and an
exploit in another web site. In addition to a huge forensics effort
from the great security folks at Mozilla, the BMO team implemented a
number of security enhancements to BMO, most notably
two-factor authentication. This work naturally took high priority
and is the main reason for the slippage of our big 2015 goals. Here’s
to a more secure 2016!
Other Stuff
As usual, the BMO team rolled out a pile of smaller fixes, enhancements,
improvements, and new features. A few notable examples include
The guided bug-entry form got a nice refresh. This is the form
that users without the editbugs permission, i.e. new users, see
when entering bugs. You can always get to it via the “Switch to the
Bugzilla helper” link at the buttom of the advanced bug-entry form.
Note that if you’re an employee, you’ve been given editbugs by
default, so you’ve likely never seen the guided form. Check it
out—Bugzilla might be friendlier to new contributors than you expect.
The platform settings for new bugs now default to all
hardware and OSes, with a “Use my platform” button to easily set this to
the reporter’s system parameters. This should help clear up some
confusion between the reporter’s platform versus the platform the
bug applies to.
The ability to block requests for review, feedback, and needinfo.
The preferences page is now better organized.
HTML bugmail has microdata to make GMail display a “View bug”
button. Thanks to Ed Morley for the patch!
You can always find the exhaustive list of recent changes to BMO
on the wiki or on the mozilla.tools.bmo group/mailing list.
January 08, 2016 01:20 AM
December 22, 2015
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:
December 22, 2015 10:38 PM
September 30, 2015
the following changes have been pushed to bugzilla.mozilla.org:
- [1207926] change [email protected] to [email protected]
- [1204683] Add whoami endpoint
- [1208135] security not being mailed when bugs change core-security-release state
- [1199090] add printable recovery 2fa codes
- [1204623] timestamp on flags should reference the latest updated activity, not the first
- [1209745] Update get_permissions.html.tmpl to reflect new self-canconfirm process
discuss these changes on mozilla.tools.bmo.
Filed under:
bugzilla 
September 30, 2015 07:42 AM
September 10, 2015
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:
September 10, 2015 08:47 PM
September 08, 2015
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.
September 08, 2015 12:50 PM
August 13, 2015
the following changes have been pushed to bugzilla.mozilla.org:
- [1160929] add support for storing attachments in s3
- [1190693] Rewrite auth delegation to use a server-side POST instead of a client-side GET to delegate API Key
- [1184332] Add Restricted API calls for MozReview
- [1190029] Would like a way to see which groups are ‘secure’ groups in editusers.cgi when diagnosing password reset issues
- [1193590] Warning about obsolete patches on an unassigned bug
- [1036872] Bugmail filtering allows through bugmail that should be blocked when combined with the standard email prefs
- [1192854] change tabs on user preferences from horizontal to vertical layout
- [1193878] Make a few more fields optional on the intern request form
- [1192688] add ip to last used api key information
discuss these changes on mozilla.tools.bmo.
Filed under:
bugzilla 
August 13, 2015 06:27 AM
August 07, 2015
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.
August 07, 2015 02:35 PM
July 30, 2015
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.
July 30, 2015 06:13 AM
July 07, 2015
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.
EOL for 4.0.x
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.
July 07, 2015 09:20 PM
April 21, 2015
At the
Bugzilla project meeting on 2015-03-25 the project lead and assistant leads agreed on two major changes to Bugzilla’s source-code hosting:
- CVS support is officially dropped as of now. 4.0 is the last version that was released on CVS, and it will be EOLed when 5.0 comes out (very soon; rc3 was just released). In the event of a release on the 4.0 branch before it is EOLed, any Bugzilla installations that have not migrated to bzr or git will have to apply patches to upgrade, which will continue to be distributed as usual. Bugzilla site admins are strongly encouraged to migrate to pulling from git.mozilla.org as soon as possible.
- Bazaar hosting has been officially switched from bzr.mozilla.org to bzr.bugzilla.org. bzr.bugzilla.org is already active and syncing changes from git.mozilla.org. bzr.mozilla.org is no longer syncing changes and will soon be shut down. Any sites upgrading from bzr.mozilla.org must do one of the following to apply any future upgrades, in order of preference:
bzr.bugzilla.org will continue to mirror changes from git.mozilla.org for the 4.0, 4.2, and 4.4 branches as long as they are supported. Note that, at the moment, master/trunk is being mirrored as well, but no other branches, including and subsequent to 5.0, will be mirrored to bzr.bugzilla.org, and trunk mirroring may cease at any time.
Note that bzr.bugzilla.org is waiting on a proper certificate; please use plain http until this is resolved.
The Bugzilla team apologizes for any inconvenience. Please see our support options if you have trouble migrating.
Mark Côté
Assistant Project Lead, Bugzilla
April 21, 2015 09:13 PM
April 15, 2015
Today we have several new releases for you!
Bugzilla 5.0rc3 is our third Release Candidate for Bugzilla 5.0. This release has received QA testing, and should be considerably more stable than the development releases before it. It is still not considered fully stable, and so you should understand that if you use it, you use it at your own risk.
If feedback from this release candidate indicates that it is mostly stable, then Bugzilla 5.0 will be released in a few weeks. If feedback indicates that more extensive fixes are needed, there may be another release candidate after this one.
Bugzilla 4.4.9 is our latest stable release. It contains various useful bug fixes:
Bugzilla 4.2.14 is a bugfix update for the 4.2 branch:
Bugzilla 4.0.18 is a bugfix update for the 4.0 branch:
April 15, 2015 08:22 PM
April 14, 2015
bugzilla has a set of fields, “hardware” and “operating system”, that i’ll collectively call “platform” in this post. their default values are detected from the reporter’s user-agent string when a bug is created.
unfortunately on bmo, the platform fields have two distinctly different meanings: the reporter’s platform and the platform a bug applies to. for too long have these two conflicting meanings coexisted within the same field, leading to confusion and a field that on many bugs is wrong or useless.
thanks to bug 579089 we plan on making the following changes early next week:
- each product gains the ability to set their default platform
- the default platform for all products initially will be all / all
- a “use my platform” action will be added to enter-bug, allowing the bug reporter to quickly change from the product’s default
- a “from reporter” button will be visible when viewing untriaged bugs, which sets the platform to the reporter’s
Filed under:
bugzilla 
April 14, 2015 03:19 PM
February 18, 2015
Complaining about bugzilla.mozilla.org (BMO) is a Mozilla project activity as old as the hills. Back in 2009, it was realised by the Foundation that to make everyone happy was (and still is) an impossible task, and I was given a mandate to “help people solve their own problems”. So around September 2009, I released the first version of my Bugzilla API proxy software, BzAPI. This software presented a clean, well-documented RESTful interface on the front end, and did all sorts of things on the back end (XML, CSV, RPC, HTML scraping) that developers no longer had to worry about. We made a dev server VM for it so people could try it out – api-dev.bugzilla.mozilla.org.
It was popular. Extremely popular. People started building things, and then more things, all of which depended on this server for Bugzilla data. For various reasons, IT never got around to building a production instance, and so over the last five years, I’ve been maintaining this core piece of Mozilla project infrastructure, which was depended on by TBPL and many, many other tools which interfaced with Bugzilla. At its peak, it serviced 400,000 requests per day.
Over the intervening years, BMO itself acquired a REST API which slowly became more capable, and then a BzAPI-compatible API shim was implemented on top of it by the excellent dkl, so people could change their code to access BMO directly just by updating the endpoint URL. After a few false starts, requests to api-dev.bugzilla.mozilla.org are now served directly by BMO, via that shim code. Earlier today, the api-dev VM was finally powered down.
Here’s to you, api-dev. Good job.
February 18, 2015 04:04 PM
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.
February 18, 2015 02:36 PM
January 27, 2015
Sorry for the new release so soon, but we found a regression in the release last week and felt it would be best to get the fix out now rather than wait.
Bugzilla 5.0rc2 is our second Release Candidate for Bugzilla 5.0. This release has receive QA testing, and should be considerably more stable than the development releases before it. It is still not considered fully stable, and so you should understand that if you use it, you use it at your own risk.
If feedback from this release candidate indicates that it is mostly stable, then Bugzilla 5.0 will be released in a few weeks. If feedback indicates that more extensive fixes are needed, there may be another release candidate after this one.
Bugzilla 4.4.8 is our latest stable release. It contains an important bug fix:
Bugzilla 4.2.13 is a bug fix update for the 4.2 branch:
Bugzilla 4.0.17 is a bug fix update for the 4.0 branch:
January 27, 2015 08:23 PM
January 21, 2015
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.0rc1 is our first Release Candidate for Bugzilla 5.0. This release has received QA testing, and should be considerably more stable than the development releases before it. It is still not considered fully stable, and so you should understand that if you use it, you use it at your own risk.
If feedback from this release candidate indicates that it is mostly stable, then Bugzilla 5.0 will be released in a few weeks. If feedback indicates that more extensive fixes are needed, there may be another release candidate after this one.
Bugzilla 4.4.7 is our latest stable release. It contains various useful bug fixes and security improvements:
Bugzilla 4.2.12 is a security and bugfix update for the 4.2 branch:
Bugzilla 4.0.16 is a security and bugfix update for the 4.0 branch:
January 21, 2015 11:00 PM
January 19, 2015
Everyone loves statistics! Right? Right? Hello?
tap tap
feedback screech
Well anyway, here are some numbers from BMO in 2014:
BMO Usage:
33 243 new users registered
45 628 users logged in
23 063 users performed an action
160 586 new bugs filed
138 127 bugs resolved
100 194 patches attached
BMO Development:
1 325 bugs filed
1 214 bugs resolved
Conclusion: there are a lot of dedicated Mozillians out there!
January 19, 2015 01:09 AM
January 08, 2015
background
bugzilla.mozilla.org presents some interesting problems when it comes to UX; while it has a singular view of bug data, most teams use bugzilla in slightly different ways. some of these differences surface in fields used to track work (keywords, flags, whiteboard, summary), how bugs are prioritised (whiteboard, custom fields, priority fields), and even how inter-bug dependancies are tracked.
the net result is trying to design an user interface for viewing bugs optimised for how people use bugzilla is a near impossible task. in light of this, we’ve been working on a framework which allows us to deploy multiple experimental alternative view of bugs.
goals
the goals are to enable alternative bug views in a way which enables rapid development and doesn’t force incomplete or broken implementations upon users.
implemented as a bugzilla extension, alternativeUI provides a harness for alternative bug views, and implements the view selection – currently as a simple user preference. in the future we expect bugzilla to be able to automatically change view depending on the bug or your relationship to it. for example, we could present a slightly (or radically!) different view of a bug to the assignee vs. the reviewer vs. someone not involved in the bug.
generic show_bug alternative
of course a framework for alternative bug views would be useless without an actual alternative. i’ve been working on one which will likely be the basis of future experiments. show/edit modality is at the core of this design — a bug is loaded with most fields as static text and switching to “edit mode” is required to make changes.
ideas we’re throwing around:
hiding fields
if a field doesn’t have a value set there’s no need for that field to be displayed by default. removing those fields from the initial display greatly reduces the noise and complexity generally associated with bugzilla.
we can also use the user’s group membership or involvement in the bug as a cue to which data should be initially visible. an example would be hiding the QE flags from users who are not associated with the bug or members of a the QE team.
performance
when a bug is loaded right now in bugzilla, it has to load all the alternatives for many fields (products, components, versions, milestones, flags, …). in most cases bugzilla’s fine-grained security model results in a measurable cost to generating these alternatives — you can see the difference yourself by logging out of bugzilla or opening a bug in a private tab and comparing the page load times against a logged-in request.
by loading a bug as read-only initially, we can defer loading the alternatives until after the user clicks on ‘edit’.
selected “editable by default”
requiring a mode switch to perform any change to a bug isn’t an ideal situation either – operations that are frequently performed should be easy to do with minimal extraneous steps.
the current implementation allows you to comment, CC, or vote for a bug without switching to edit mode. this can be extended to, for example, allow the bug’s assignee to change a bug’s status/resolution without needing to switch to edit mode.
screenshots
Filed under:
bmo,
bugzilla,
mozilla 
January 08, 2015 02:46 AM
January 07, 2015
The second half of 2014 was spent finishing up some performance work
and shifting into usability improvements, which will continue into
2015.
More performance!
By the end of 2014, we’d managed to pick most of the low-to-medium-hanging
fruit in the world of Bugzilla server-side performance. The result is
approximately doubling the performance of authenticated bug views.
Here are graphs from January 2014 and October 2014:
The server now also minifies and concatenates JavaScript and CSS
files. This affects cold loads mostly, since these files are cached,
but even on reload it saves a few round trips.
As mentioned above, we’re shifting focus away from performance work
and towards usability/work-flow improvements, but there will still be
perf benefits, both by reducing and delaying loading of content and by
making it easier for users to accomplish common tasks.
New, better documentation
We’ve converted the upstream Bugzilla documentation to
reStructuredText, massively updated and reorganized it, and, perhaps
of most interest to anyone reading this, completely rewrote the
API docs, which were very hard to grok.
For BMO specifically, we’ve fixed up the wiki page. We’ve also
started a user guide, but it’s just a skeleton at the moment.
There are lots of users out there who know the ins and outs of BMO, so
feel free to contribute a section!
GMail support
To support Mozilla’s transition to GMail, we added two features.
First, we now limit the number of emails sent to a user per minute
and per hour, since GMail will temporarily disable accounts that
receive too much mail, and some BMO users receive a lot of bugmail.
Second, since GMail’s ability to filter mail by headers is limited
compared to other email servers, users can now include the
X-Bugzilla-* headers in the body via General Preferences.
Other things
When entering a new bug, after selecting the product, any
relevant custom bug-entry forms are now displayed at the top of the
form. We also added a full list of all the custom forms in BMO
(linked at the bottom of the bug-entry landing page).
There’s now a UI for your Review History (as reviewer).
BMO now uses the Fira Sans typeface to improve consistency with
other Mozilla web properties, although we reverted to the old
monospace style after a lot of negative feedback about Fira’s
monospace. If you don’t like Fira, you can always switch to OpenSans
by changing your skin in the General Preferences.
My Dashboard now has an “Interesting Bugs” query. You can see a
full description of the bug criteria in the bug’s user story,
but in effect it should be close to what you would receive in
bugmail. This is useful on its own if you don’t want to rely on
bugmail, but we have plans to make it even more useful by adding
weighted scoring to order bugs according to how relevant the
changes are to you in particular.
There’s now an easy way to generate a shortened link for
search URLs, which tend to be long.
And just landed yesterday, which is technically 2015 but the result
of work done in 2014, is a new look for the guided bug-entry form,
aka the Bugzilla Helper, which new BMO users get by default
when filing new bugs. It’s the first step of a series of improvements
intended to make it easier for new users to file good bugs.
2015!
As I’ve said a few times now, in 2015 we’re going to do a lot of work
on improving general BMO-user productivity: usability, UX, work flows,
whatever you want to call it. I’ll write more about this later, but
here are a few things we’re looking into:
Experimenting with alternative bug views. There’s a lot of stuff
on the standard bug view. Can we give different windows into the
data depending on what the user is trying to accomplish? Can we load
this data more intelligently, and organize it more intuitively?
A proper field for MozReview links that dynamically loads and
displays state information on the review request.
Authentication via GitHub. A lot of Mozilla projects are on
GitHub, but many use Bugzilla for issue tracking. To make it easier
for contributors coming to us via GitHub, we’ll let them log into
Bugzilla using their GitHub account.
As I wrote about in an earlier post, improved searchability.
As usual, if you have questions or comments, you can leave them here,
but an even better place is the mozilla.tools.bmo mailing list,
also available as a Google Group and via NNTP.
January 07, 2015 07:31 PM
December 17, 2014
BMO currently supports five—count ‘em, five—ways to search for
bugs. Whenever you have five different ways to perform a similar
function, you can be pretty sure the core problem is not well
understood. Search has been rated, for good reason, one of the least
compelling features of Bugzilla, so the BMO team want to dig in there
and make some serious improvements.
At our Portland get-together a couple weeks ago, we talked about
putting together a vision for BMO. It’s a tough problem, since BMO is
used for so many different things. We did, however, manage to get some
clarity around search. Gerv, who has been involved in the Bugzilla
project for quite some time, neatly summarized the use cases. People
search Bugzilla for only two reasons:
- to find a set of bugs, or
- to find a specific bug.
That’s it. The fact that BMO has five different searches, though,
means either we didn’t know that, or we just couldn’t find a good way
to do one, or the other, or both.
We’ve got the functionality of the first use case down pretty well,
via Advanced Search: it helps you assemble a set of criteria of almost
limitless specificity that will result in a list of bugs. It can be
used to determine what bugs are blocking a particular release, what
bugs a particular person has assigned to them, or what bugs in a
particular Product have been fixed recently. Its interface is,
admittedly, not great. Quick Search was developed as a different,
text-based approach to Advanced Search; it can be quicker to use but
definitely isn’t any more intuitive. Regardless, Advanced Search
fulfills its role fairly well.
The second use of Search is how you’d answer the question, “what was
that bug I was looking at a couple weeks ago?” You have some hazy
recollection of a bug. You have a good idea of a few words in the
summary, although you might be slightly off, and you might know the
Product or the Assignee, but probably not much else. Advanced Search
will give you a huge, useless result set, but you really just want one
specific bug.
This kind of search isn’t easy; it needs some intelligence, like
natural-language processing, in order to give useful
results. Bugzilla’s solutions are the Instant and Simple searches,
which eschew the standard Bugzilla::Search module that powers Advanced
and Quick searches. Instead, they do full-text searches on the Summary
field (and optionally in Comments as well, which is super slow). The
results still aren’t very good, so BMO developers tried outsourcing
the feature by adding a Google Search option. But despite Google being
a great search engine for the web, it doesn’t know enough about BMO
data to be much more useful, and it doesn’t know about new nor
confidential bugs at all.
Since Bugzilla’s search engines were originally written, however,
there have been many advances in the field, especially in FLOSS. This
is another place where we need to bring Bugzilla into the modern
world; MySQL full-text searches are just not good enough. In the
upcoming year, we’re going to look into new approaches to search, such
as running different databases in tandem to exploit their particular
abilities. We plan to start with experiments using Elasticsearch,
which, as the name implies, is very good at searching. By standing up
an instance beside the main MySQL db and mirroring bug data over, we
can refer specific-bug searches to it; even though we’ll then have to
filter based on standard bug-visibility rules, we should have a net
win in search times, especially when searching comments.
In sum, Mozilla developers, we understand your tribulations with
Bugzilla search, and we’re on it. After all, we all have a reputation
to maintain as the Godzilla of Search Engines!
December 17, 2014 03:37 PM
December 06, 2014
People often wonder how to make searches in Bugzilla faster on large installations. Two things will give you the most bang for the buck:
- Specify you only want open bugs (if that’s true)
- Specify a product (and, if you know it, a component) to search
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.
December 06, 2014 10:14 PM
December 01, 2014
The Bugzilla team is aware that there are currently 5 different methods of searching Bugzilla (as explained in yesterday’s presentation) – Instant Search, Simple Search, Advanced Search, Google Search and QuickSearch. It has been argued that this is too many, and that we should simplify the options available – perhaps building a search which is all three of Instant, Simple and Quick, instead of just one of them. Some Bugzilla developers have sympathy with that view.
I, however, having caught the mood of the times, feel that Mozilla is all about choice, and there is still not enough choice in Bugzilla search. Therefore, I have decided to add a sixth option for those who want it. As of today, December 1st, by installing this GreaseMonkey script, you can now search Bugzilla with Yahoo! Search. (To do this, obviously, you will need a copy of GreaseMonkey.) It looks like this:
In the future, I may create a Bugzilla extension which allows users to fill the fourth tab on the search page with the search engine of their choice, perhaps leveraging the OpenSearch standard. Then, you will be able to search Bugzilla using the search engine which provides the best experience in your locale.
Viva choice!
December 01, 2014 12:01 AM
November 28, 2014
In 2010, johnath did a very popular video introducing people to Bugzilla, called “Bugzilla for Humans“. While age has been kind to johnath, it has been less kind to his video, which now contains several screenshots and bits of dialogue which are out of date. And, being a video featuring a single presenter, it is somewhat difficult to “patch” it.
Enter Popcorn Maker, the Mozilla Foundation’s multimedia presentation creation tool. I have written a script for a replacement presentation, voiced it up, and used Popcorn Maker to put it together. It’s branded as being in the “Understanding Mozilla” series, as a sequel to “Understanding Mozilla: Communications” which I made last year.
So, I present “Understanding Mozilla: Bugzilla“, an 8.5 minute introduction to Bugzilla as we use it here in the Mozilla project:
Because it’s a Popcorn presentation, it can be remixed. So if the instructions ever change, or Bugzilla looks different, new screenshots can be patched in or erroneous sections removed. It’s not trivial to seamlessly patch my voiceover unless you get me to do it, but it’s still much more possible than patching a video. (In fact, the current version contains a voice patch.) It can also be localized – the script is available, and someone could translate it into another language, voice it up, and then remix the presentation and adjust the transitions accordingly.
Props go to the Popcorn team for making such a great tool, and the Developer Tools team for Responsive Design View and the Screenshot button, which makes it trivial to reel off a series of screenshots of a website in a particular custom size/shape format without any need for editing.
November 28, 2014 11:52 AM
November 25, 2014
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:
- the field changed
- the current product
- the current component
- your relationship to the bug
- who made the change (useful to exclude changes made by bots).
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.
November 25, 2014 05:40 PM
November 19, 2014
The load time for viewing bugs on bugzilla.mozilla.org has got 2x faster since January. See this tweet for graphical evidence.
If you are looking for a direction in which to send your bouquets, glob is your man.
November 19, 2014 10:42 AM
November 13, 2014
on monday 17th november the database on bugzilla-dev.allizom.org will be refreshed with a recent database dump from bugzilla.mozilla.org.
if you have an account on bugzilla-dev its password will be deleted, and you will have to contact the BMO team to get a password reset.
you can contact us on irc in #bmo: glob, dkl, or dylan.
Filed under:
bugzilla 
November 13, 2014 02:41 PM
October 06, 2014
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 4.4.6 is our latest stable release. It contains various useful bug fixes and security improvements:
Bugzilla 4.2.11 is a security update for the 4.2 branch:
Bugzilla 4.0.15 is a security update for the 4.0 branch:
Bugzilla 4.5.6 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.
October 06, 2014 07:33 PM
We did a Bugzilla security release today, to fix some holes responsibly disclosed to us by Check Point Vulnerability Research, to whom we are very grateful. The most serious of them would allow someone to create and control an account for an arbitrary email address they don’t own. If your Bugzilla gives group permissions based on someone’s email domain, as some do, this could be a privilege escalation.
(Update 2014-10-07 05:42 BST: to be clear, this pattern is most commonly used to add “all people in a particular company” to a group, using an email address regexp like .*@mozilla.com$. It is used this way on bugzilla.mozilla.org to allow Mozilla Corporation employees access to e.g. Human Resources bugs. Membership of the Mozilla security group, which has access to unfixed vulnerabilities, is done on an individual basis and could not be obtained using this bug. The same is true of BMO admin privileges.)
These bugs are actually quite interesting, because they seem to represent a new Perl-specific security problem. (At least, as far as I’m aware it’s new, but perhaps we are about to find that everyone knows about it but us. Update 2014-10-08 09:20 BST: everything old is new again; but the level of response, including changes to CGI.pm, suggest that this had mostly faded from collective memory.) This is how it works. I’m using the most serious bug as my example. The somewhat less serious bugs caused by this pattern were XSS holes. (Check Point are going to be presenting on this vulnerability at the 31st Chaos Communications Congress in December in Hamburg, so check their analysis out too.)
Here’s the vulnerable code:
my $otheruser = Bugzilla::User->create({
login_name => $login_name,
realname => $cgi->param('realname'),
cryptpassword => $password});
This code creates a new Bugzilla user in the database when someone signs up. $cgi is an object representing the HTTP request made to the page.
The issue is a combination of two things. Firstly, the $cgi->param() call is context-sensitive – it can return a scalar or an array, depending on the context in which you call it – i.e. the type of the variable you assign the return value to. The ability for functions to do this is a Perl “do what I mean” feature.
Let’s say you called a page as follows, with 3 instances of the same parameter:
index.cgi?foo=bar&foo=baz&foo=quux
If you call param() in an array context (the @ sigil represents a variable which is an array), you get an array of values:
@values = $cgi->param('foo');
-->
['bar', 'baz', 'quux']
If you call it in a scalar context (the $ sigil represents a variable which is a scalar), you get a single value, probably the first one:
$value = $cgi->param('foo');
-->
'bar'
So what context is it being called in, in the code under suspicion? Well, that’s exactly the problem. It turns out that functions called during hash value assignment are evaluated in a list context. However, when the result comes back, that value or those values are assigned to be part of uthe hash as if they were a set of individual, comma-separated scalars. I suspect this behaviour exists because of the close relationship of lists and hashes; it allows you to do stuff like:
my @array = ("foo", 3, "bar", 6);
my %hash = @array;
-->
{ "foo" => 3, "bar" => 6 }
Therefore, when assigning the result of a function call as a hash value, if the return value is a single scalar, all goes as you would expect, but if it’s an array, the second and subsequent values end up being added as key/value pairs in the hash as well. This allows an attacker to override values already in the hash (specified earlier), which may have already been validated, with values controlled by them. In our case, real_name can be any string, so doesn’t need validation, but login_name most definitely does, and it already has been by the time this code is called.
So, in the case of the problematic code above, something like:
index.cgi?realname=JRandomUser&realname=login_name&[email protected]
would end up overriding the already-validated login_name variable, giving the attacker control of the value used in the call to Bugzilla::User->create(). Oops.
We found 15 instances of this pattern in our code, four of which were exploitable to some degree. If you maintain a Perl web application, you may want to audit it for this pattern. Clearly, CGI.pm param() calls are the first thing to look for, but it’s possible that this pattern could occur with other modules which use the same context-sensitive return feature. The generic fix is to require the function call to be evaluated in scalar context:
my $otheruser = Bugzilla::User->create({
login_name => $login_name,
realname => scalar $cgi->param('realname'),
cryptpassword => $password});
I’d say it might be wise to not ever allow hash values to be assigned directly from functions without a call to scalar.
October 06, 2014 07:13 PM
August 28, 2014
UPDATE: We have reset all passwords on all Landfill test Bugzilla systems. All users will be required to set a new password the next time they access the test Bugzilla systems.
One of our developers discovered that, starting on about May 4th, 2014, for a period of around 3 months, during the migration of our testing server for test builds of the Bugzilla software, database dump files containing email addresses and encrypted passwords of roughly 97,000 users of the test build were posted on a publicly accessible server. As soon as we became aware, the database dump files were removed from the server immediately, and we’ve modified the testing process to not require database dumps.
Generally, developers who use our test builds have told us they understand that these builds are insecure and may break, so they do not use passwords they would reuse elsewhere. However, because it is possible that some users could have reused their passwords on other websites or authentication systems, we’ve sent notices to the users who were affected by this disclosure and recommended that they change any similar passwords they may be using. It’s important to note that, unless users reused the password they used on landfill.bugzilla.org, this does not affect bugzilla.mozilla.org email addresses or passwords.
We are deeply sorry for any inconvenience or concern this incident may cause you.
Thanks,
Mark Côté
Assistant Project Lead, Bugzilla
August 28, 2014 08:11 PM
July 24, 2014
Today we have several new releases for you!
All of today’s releases contain a security fix. We recommend that all Bugzilla administrators read the Security Advisory that was published along with these releases.
Bugzilla 4.4.5 is our latest stable release and contains a security fix.
Bugzilla 4.2.10 is a security update for the 4.2 branch:
Bugzilla 4.0.14 is a security update for the 4.0 branch:
Bugzilla 4.5.5 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.
July 24, 2014 09:40 PM
July 04, 2014
bugzilla is a large legacy perl application initially developed at the birth of the world wide web. it has been refactored significantly in the 15 years since its release; however, some design decisions made at the start of the project carry significant technical debt in today’s modern web.
while there have been a large number of micro-optimisations over the course of bugzilla’s life (generally as a result of performance profiling), there are limits to the benefits these sorts of optimisations can provide.
this year has seen a lot of focus on improving bugzilla’s performance within mozilla, centred around the time it takes to display a bug to authenticated users.
tl;dr bugzilla is faster
memcached
the design of a modern large web application is generally centred around caches, between the business logic layer and the data sources, as well as between the users and the user interface. while bugzilla has been refactored to use objects, database abstraction, templates, etc, it had zero caching capabilities. this coupled with completely stateless processing of each request meant that every byte of html returned to the user was regenerated from scratch, starting with a new connection to the database.
towards the end of 2013 i worked on implementing a memcached framework into bugzilla [bug 237498].
retrofitting a caching mechanism into a large extendible framework proved to be a significant challenge. bugzilla provides the ability for developers to extend bugzilla’s functionality via extensions, including but not limited to adding new fields, user interface, or process. the extensions system conflicts with caching as it’s possible for an extension to conditionally alter an object in ways that would render it impossible to cache (eg. add a new field to an object only if the current user is a member of a particular group).
some compromises had to be made. instead of caching fully constructed objects, the cache sits between the object’s constructor and the database. we avoid a trip to the database, but still have to construct objects from that data (which allows extensions to modify the object during construction).
code which updated the database directly instead of using bugzilla’s objects had to be found and rewritten to use the objects or updated to manually clear the cache entries. extra care had to be taken as returning stale data could silently result in data loss. to placate concerns that these errors would be impossible to detect, the caller of an object’s constructor must pass in a parameter to “opt-in” to caching.
in 2014 i built upon the memcached framework to support most of bugzilla’s objects [bug 956233], with the “bugs” object being the only notable exception. memcached also caches bugzilla’s configuration parameters (classifications, products, components, groups, flags, …) [bug 987032]. although caching the “bugs” object would be beneficial given its central role in all things bugzilla, it is highly likely that enabling this by default would break bugzilla extensions and customisations as a high proportion of them update the database directly instead of using bugzilla’s object layer. this would manifest as data which is silently stale, making undetectable dataloss a high probability.
memcached support will be released with bugzilla 5.0, but has been live on bugzilla.mozilla.org (bmo) since february 2014.
instrumentation
while profilling tools such as nytprof have often been pointed at bugzilla, bmo’s high number of concurrent requests and usage patterns time and time again resulted in performance optimisations performing worse than expected once deployed to production.
we took the decision to deploy instrumentation code into bugzilla itself, reporting on each http request, database query, and template execution. as bugzilla is written in perl, support was absent for off-the-shelf instrumentation tools such as new relic, so we had to roll our own data collection and reporting system [bug 956230].
the collector wraps specific Bugzilla::DB, Bugzilla::Memcached and Bugzilla::Template calls via subclassing, then reports data to an elasticsearch cluster. currently all reporting solutions are ad-hoc and involve running of scripts which identify the most costly database queries and templates.
this data identified areas of bugzilla which require optimisation or caching. examples include the optimisation of a single query which shaved 200ms (~15%) off page load times for most users [bug 993894], caching of all queries which read an entire table [part of bug 987032], and caching of user groups [bugs 993939] and settings [bug 993926].
we continue to revisit the instrumentation reports in order to guide further improvements.
stylesheet concatenation and minification
improving the performance of a web applications isn’t limited to focusing on server-side execution speed.
due to bugzilla’s extensions we ended up in a situation where bugzilla was serving multiple small css files – on bmo we loaded 17 stylesheets as part of show_bug in comparison with 5 for an installation of bugzilla without any extensions installed.
similar to the issue encountered with memcached, extensions have complete control with regards to optionally loading stylesheets, which means any css concatenation and minification solution needed to be implemented at run-time.
[bug 977969] does exactly that – the template passes an array of stylesheets to load to bugzilla’s global header, where a hash of the array is used to find a unified stylesheet. simple minification is performed which dropped the stylesheet size from 54kb to 43kb on show_bug on bmo.
stylesheet concatenation and minification support will be released with bugzilla 5.0, and has been live on bugzilla.mozilla.org since may 2014.
database
in order to address performance issues caused by bugzilla’s use of the myisam table type, in march our DBAs upgraded our database cluster to mysql version 5.6. this was the result of analysis by the DBAs into replication and stability issues around our myisam table.
as mysql 5.6 adds support for fulltext indexing to its innodb table type, bugzilla was able to switch away from myisam. this immediately fixed the database replication issues, and provided a noticeable performance boost to searches involving comments.
looking forward
the next large project is to update bugzilla so the bug object can use memcached on an unmodified installation without any non-default extensions enabled. for reasons previously covered it’s unlikely we’ll ship a version of bugzilla with this enabled by default, however this will allow sites to audit their own code (if any) and enable caching of the bug object if required.
we will build on the css concatenation and minification work to provide the same benefits to javascript files.
we periodically enable instrumentation and use it to identify the next set of targets for optimisation. this will continue for the foreseeable future.
Filed under:
bmo,
bugzilla 
July 04, 2014 07:50 AM
May 08, 2014
a high-level goal across multiple teams this year is to improve bugzilla.mozilla.org’s performance, specifically focusing on the time it takes to load a bug (show_bug.cgi).
towards this end, in q1 2014 i focused primarily on two things: implementing a framework for bugzilla to use memcached, and deep instrumentation of bmo in our production environment to help identify areas which require optimisation and could leverage memcached.
i’ll talk more about memcached in a later blog post. today i’ll talk about a single little query.
the data gathered quickly identified a single query used to determine a user’s group membership was by far the slowest query, averaging more than 200 ms to complete, and was executed on every page:
Filed under:
bmo,
bugzilla 
May 08, 2014 05:06 PM
May 03, 2014
Milestone bugzilla.mozilla.org bug 1,000,000 was filed on 2014-04-23 at 01:10 ZST by Archaeopteryx (although rumour has it he used a script, as he also filed the 12 previous bugs in quick succession). The title of the bug was initially “Long word suggestions can move/shift keyboard partially off screen so it overflows” (a Firefox OS Gaia::Keyboard bug, now bug 1000025), but has since been changed to “Celebrate 1000000 bugs, bring your own drinks.”
The winner of the sweepstake to guess the date and time is Gijs Kruitbosch, who guessed 2014-04-25 05:43:21 – which is 2 days, 4 hours, 33 minutes and 5 seconds out. This is a rather wider error, measured in seconds, than the previous sweepstake, but this one had a much longer time horizon – it was instituted 9 months ago. So that’s an error of about 0.95%. The 800,000 bug winner had an error of about 1.55% using the same calculation, so in those terms Gijs’ effort is actually better.
Gijs writes:
I’m Dutch, recently moved to Britain, and I’ll be celebrating my 10th “mozversary” sometime later this year (for those who are counting, bugs had 6 digits and started with “2” when I got going). Back in 2004, I got started by working on ChatZilla, later the Venkman JS debugger and a bit of Firefox, and last year I started working on Firefox as my day job. Outside of Mozilla, I play the piano every now and then, and try to adjust to living in a nation that puts phone booths in its cycle paths.
The two runners-up are Håvard Mork (2d 14h 50m 52s out) and Mark Banner (8d 8h 24m 36s out). Håvard writes:
My name is Håvard Mork. I’m a Java software developer, working with Firefox and web localization to Norwegian. I’ve been involved with localization since 2003. I think localization is rewarding, because it is a process of understanding the mindset of the users, and their perception of IT.
I’m surprised that my estimate came that close. I spent almost an hour trying to figure out how much bug numbers grow, and estimate the exponential components. Unfortunately I lost the equation, so need to start over for the 2,000,000 sweepstakes…
Mark writes:
I’m Mark Banner, also known as Standard8 on irc, I work from home in the UK. I came to Mozilla through volunteering on Thunderbird, and then working at Mozilla Messaging. I still manage Thunderbird releases. Alongside those, I am working on the Loop project (formally Talkilla), which is aiming to provide a real time communications service for Mozilla products, built on top of WebRTC.
Gijs will get a Most Splendid Package, and also a knitted thing from Sheeri as a special bonus prize! The other winners will receive something a little less splendid, but I’m sure it’ll be worth having nevertheless.
May 03, 2014 07:57 PM
April 28, 2014
Thanks to glob, we’ve got some interesting stats from BMO as it crosses the 1M bug mark.
Statuses
UNCONFIRMED 23745
NEW 103655
ASSIGNED 8826
REOPENED 3598
RESOLVED 640326
VERIFIED 220235
CLOSED 1628
Resolutions
RESOLVED
DUPLICATE 119242
EXPIRED 10677
FIXED 303099
INCOMPLETE 30569
INVALID 58096
MOVED 27
WONTFIX 36179
WORKSFORME 82437
VERIFIED
DUPLICATE 64702
EXPIRED 27
FIXED 108935
INCOMPLETE 1746
INVALID 17099
MOVED 150
WONTFIX 6105
WORKSFORME 21471
- Total bugs fixed (RESOLVED/FIXED + VERFIED/FIXED): 412034
- Total duplicates: 183944
Bugs Filed Per Day (April)
2014-04-01 519
2014-04-02 531
2014-04-03 620
2014-04-04 373
2014-04-05 133
2014-04-06 132
2014-04-07 544
2014-04-08 622
2014-04-09 597
2014-04-10 571
2014-04-11 467
2014-04-12 156
2014-04-13 170
2014-04-14 573
2014-04-15 580
2014-04-16 574
2014-04-17 619
2014-04-18 356
2014-04-19 168
2014-04-20 118
2014-04-21 445
2014-04-22 635
2014-04-23 787
2014-04-24 562
2014-04-25 498
2014-04-26 173
Busiest Days Ever
2013-12-30 1360 (bulk import from another tracker)
2013-12-29 1081 (bulk import from another tracker)
2008-07-22 1037 (automated security scanner filing bugs)
2012-10-01 1013 (Gaia bugs import)
2014-02-11 805
2014-04-23 787
2014-02-04 678
2013-01-09 675
2013-11-19 647
2014-04-22 635
User Activity
(You can find these stats about yourself by going to your own user profile. If you are logged in, you can search for other users and see their stats.)
Top 10: Assignees
[email protected] 349671
[email protected] 16385
[email protected] 15056
[email protected] 13350
[email protected] 11974
[email protected] 10995
[email protected] 4768
[email protected] 4697
[email protected] 4672
[email protected] 4273
Top 10: Reporters
[email protected] 8037
[email protected] 6129
[email protected] 5032
[email protected] 4789
[email protected] 4351
[email protected] 4348
[email protected] 4038
[email protected] 3680
[email protected] 3651
[email protected] 3528
Top 10: Commenters
[email protected] 347695
[email protected] 148481
[email protected] 65552
[email protected] 58588
[email protected] 50560
[email protected] 48840
[email protected] 48704
[email protected] 47453
[email protected] 43596
[email protected] 42885
Top 11: Patches Attached
[email protected] 8080
[email protected] 4879
[email protected] 4502
[email protected] 4397
[email protected] 4079
[email protected] 3930
[email protected] 3890
[email protected] 3739
[email protected] 3659
[email protected] 3530
[email protected] 3411
Top 11: Reviews
[email protected] 15581
[email protected] 14869
[email protected] 9424
[email protected] 8352
[email protected] 8103
[email protected] 7272
[email protected] 6198
[email protected] 5983
[email protected] 5499
[email protected] 5346
[email protected] 5126
April 28, 2014 12:38 PM
April 19, 2014
There are four new releases today. All of today’s releases contain an important bug fix discovered since the last release.
Bugzilla 4.4.4 is our latest stable release. It is a bug fix update for the 4.4 branch:
Bugzilla 4.2.9 is a bug fix update for the 4.2 branch:
Bugzilla 4.0.13 is a bug fix update for the 4.0 branch:
Bugzilla 4.5.4 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.
April 19, 2014 02:08 PM
April 18, 2014
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 4.4.3 is our latest stable release. It contains various useful bug fixes and security improvements:
Bugzilla 4.2.8 is a security update for the 4.2 branch as well as contains several bug fixes:
Bugzilla 4.0.12 is a security update for the 4.0 branch:
Bugzilla 4.5.3 is an unstable development release. This release has not received QA testing from the Bugzilla Project, and should not be used in production environments. Development releases exist as previews of the features that the next major release of Bugzilla will contain. They also exist for testing purposes, to collect bug reports and feedback, so if you find a bug in this development release (or you don’t like how some feature works) please tell us.
April 18, 2014 02:34 AM
April 04, 2014
A large number of external applications have grown up around Bugzilla
serving a variety of purposes. One thing many of these apps have in
common is a need to get updates from Bugzilla. Unfortunately, the
only way to get notifications of changes was, until recently, to poll
Bugzilla. Everyone knows that polling is bad, particularly because it
doesn’t scale well, but until recently there was no alternative.
Thus I would like to introduce to the world Bugzfeed, a
WebSocket app that allows you to subscribe to one or more bugs and
get pushed notifications when they change. It’s rather a small app,
based on Tornado, and has a very simple interface, so it should
scale quite nicely. It relies on a few moving parts to work, but I’ll
start with the basics and explain the whole system later.
The production version is at ws://bugzfeed.mozilla.org. I also made a
very simple (and ugly) example app for you to use and examine. A
development version of Bugzfeed is available at
ws://bugzfeed-dev.allizom.org; it’s tied to the
development Bugzilla server, so it’s a good place to experiment if
you’re a Mozilla contributor; you can make whatever changes you need
to bugzilla-dev without worrying about messing with production data.
You’ll need to get someone in #bmo on irc.mozilla.org to reset your
password, since we periodically refresh and sanitize the database on
bugzilla-dev, and email is disabled so you can’t reset it yourself.
(This makes me think that there should probably be a Bugzfeed instance
tied to Landfill; maybe I’ll look into that, in particular if we
implement middleware other than Pulse (see below).)
Client commands, responses, and notifications are all in JSON format.
The project wiki page has the full list of commands. Here’s a
little example of what you need to send to subscribe to bugs 1234 and
5678:
{"command": "subscribe", "bugs": [1234, 5678]}
The server will send a simple response, including a list of all the
bugs you are (now) subscribed to:
{"command": "subscribe", "result": "ok", "bugs": [1234, 5678]}
Now you can just wait for notifications to be pushed from the server
to your app:
{"command": "update", "bug": 1234, "when": "2014-04-03T21:13:45"}
Wait, you are probably asking, that’s it? That’s all I get?
The short answer is yup, that’s it. You can now use the regular
REST API to get further details about what changed.
The longer answer is yup, that’s it, because security. Bugzilla has
evolved a very fine-grained security system. We have bugs,
attachments, and even comments that can only be seen by a privileged
few, due to security, legal, and other considerations. Furthermore,
many of the variables involved in determining whether a particular
user can see a particular bug/attachment/comment can change at any
time: not only can elements of a bug shift between public and
confidential, but so can a user’s groups, and the groups themselves.
Monitoring for all those possible changes would make this app
significantly more complex and brittle, so we opted for the most
secure notification, which is also the simplest: just a bug ID and a
timestamp. All the other work is handled by the standard Bugzilla
APIs.
(You might also be asking “why is ‘update’ considered a command?” and,
to be honest, I’m not sure, so maybe that’ll change.)
There are other commands, and some limited caching of changes in case
your client disconnects; see the project wiki page for more.
So how does it work? Here’s a system diagram created by contributor
musingmario:
The four main pieces (with links to source) are
On the Bugzilla side, the BMO team created an extension which writes
the bug ID and timestamp to a table when any bug changes. A simple
Python app polls this table and sends all the updates to Pulse,
cleaning up the table as it does so.
Pulse is a Mozilla RabbitMQ server with a specific configuration and
message format implementing the publish/subscribe pattern. The
usage is somewhat Mozilla specific, but it would be pretty easy to set
up a similar system or even modify Bugzfeed and the Bugzilla shim to
use RabbitMQ directly, or a different AMQP system like ØMQ.
Notifications from all bugs flow through Pulse; it is Bugzfeed, the
WebSocket server, that does the filtering for its clients to notify
only on subscribed bugs. Subscribing to individual notifications from
Pulse is possible via topics, but this requires one channel per
bug, so I doubt it would be any more efficient if hundreds of clients
are connected to Bugzfeed.
While you could have the Bugzfeed server read directly from the
Bugzilla database, eliminating the shim and the queuing system, having
an intermediary allows us to easily stand up more Bugzfeed servers if
load gets too high, as each Bugzfeed instance would see the stream of
changes via its own subscriber queue. We can also easily interface
new applications to the notification stream, such as the
BMO Elastic Search cluster.
Enough technicalities; go out and play with it! And if you want to
adapt it for your own Bugzilla installation, I’d be more than willing
to help out.
April 04, 2014 04:13 AM
A large number of external applications have grown up around Bugzilla
serving a variety of purposes. One thing many of these apps have in
common is a need to get updates from Bugzilla. Unfortunately, the
only way to get notifications of changes was, until recently, to poll
Bugzilla. Everyone knows that polling is bad, particularly because it
doesn’t scale well, but until recently there was no alternative.
Thus I would like to introduce to the world Bugzfeed, a
WebSocket app that allows you to subscribe to one or more bugs and
get pushed notifications when they change. It’s rather a small app,
based on Tornado, and has a very simple interface, so it should
scale quite nicely. It relies on a few moving parts to work, but I’ll
start with the basics and explain the whole system later.
The production version is at ws://bugzfeed.mozilla.org. I also made a
very simple (and ugly) example app for you to use and examine. A
development version of Bugzfeed is available at
ws://bugzfeed-dev.allizom.org; it’s tied to the
development Bugzilla server, so it’s a good place to experiment if
you’re a Mozilla contributor; you can make whatever changes you need
to bugzilla-dev without worrying about messing with production data.
You’ll need to get someone in #bmo on irc.mozilla.org to reset your
password, since we periodically refresh and sanitize the database on
bugzilla-dev, and email is disabled so you can’t reset it yourself.
(This makes me think that there should probably be a Bugzfeed instance
tied to Landfill; maybe I’ll look into that, in particular if we
implement middleware other than Pulse (see below).)
Client commands, responses, and notifications are all in JSON format.
The project wiki page has the full list of commands. Here’s a
little example of what you need to send to subscribe to bugs 1234 and
5678:
{"command": "subscribe", "bugs": [1234, 5678]}
The server will send a simple response, including a list of all the
bugs you are (now) subscribed to:
{"command": "subscribe", "result": "ok", "bugs": [1234, 5678]}
Now you can just wait for notifications to be pushed from the server
to your app:
{"command": "update", "bug": 1234, "when": "2014-04-03T21:13:45"}
Wait, you are probably asking, that’s it? That’s all I get?
The short answer is yup, that’s it. You can now use the regular
REST API to get further details about what changed.
The longer answer is yup, that’s it, because security. Bugzilla has
evolved a very fine-grained security system. We have bugs,
attachments, and even comments that can only be seen by a privileged
few, due to security, legal, and other considerations. Furthermore,
many of the variables involved in determining whether a particular
user can see a particular bug/attachment/comment can change at any
time: not only can elements of a bug shift between public and
confidential, but so can a user’s groups, and the groups themselves.
Monitoring for all those possible changes would make this app
significantly more complex and brittle, so we opted for the most
secure notification, which is also the simplest: just a bug ID and a
timestamp. All the other work is handled by the standard Bugzilla
APIs.
(You might also be asking “why is ‘update’ considered a command?” and,
to be honest, I’m not sure, so maybe that’ll change.)
There are other commands, and some limited caching of changes in case
your client disconnects; see the project wiki page for more.
So how does it work? Here’s a system diagram created by contributor
musingmario:
The four main pieces (with links to source) are
On the Bugzilla side, the BMO team created an extension which writes
the bug ID and timestamp to a table when any bug changes. A simple
Python app polls this table and sends all the updates to Pulse,
cleaning up the table as it does so.
Pulse is a Mozilla RabbitMQ server with a specific configuration and
message format implementing the publish/subscribe pattern. The
usage is somewhat Mozilla specific, but it would be pretty easy to set
up a similar system or even modify Bugzfeed and the Bugzilla shim to
use RabbitMQ directly, or a different AMQP system like ØMQ.
Notifications from all bugs flow through Pulse; it is Bugzfeed, the
WebSocket server, that does the filtering for its clients to notify
only on subscribed bugs. Subscribing to individual notifications from
Pulse is possible via topics, but this requires one channel per
bug, so I doubt it would be any more efficient if hundreds of clients
are connected to Bugzfeed.
While you could have the Bugzfeed server read directly from the
Bugzilla database, eliminating the shim and the queuing system, having
an intermediary allows us to easily stand up more Bugzfeed servers if
load gets too high, as each Bugzfeed instance would see the stream of
changes via its own subscriber queue. We can also easily interface
new applications to the notification stream, such as the
BMO Elastic Search cluster.
Enough technicalities; go out and play with it! And if you want to
adapt it for your own Bugzilla installation, I’d be more than willing
to help out.
April 04, 2014 04:13 AM
April 01, 2014
This discussion took place three years ago, and we have been working very hard to make it happen. But we are now done: Bugzilla 5.0, the next major release of Bugzilla which will be released later this month on April 31, will be based on Python 3.4, meaning that Bugzilla 4.4 was the last major release to be based on Perl. We hope this migration to Python will trigger more contributors and will increase the development rate of Bugzilla.
Bugzilla 5.0 comes with many major changes. Just to name a few:
- Support for Internet Explorer (including IE 11) and less known browsers has been removed. You must now run Firefox, Google Chrome or Safari, which fully support HTML5, else an error message will be displayed asking you to use one of these browsers.
- You must have Java 8 installed and enabled in your browser in order to upload new attachments. This way, sanity checks can be done client-side before the attachment is uploaded to Bugzilla. If you don’t have Java installed or enabled, you can still view existing attachments, though, but you won’t be able to upload new ones.
- The version 5.0 of Bugzilla can be downloaded for free, but security fixes (5.0.1, 5.0.2, …) require that you register to our server to be able to download them. The fee isn’t expensive: $20 per security release for installations with less than 10 users. $200 between 10 and 50 users. $1000 above 50 users. As we do security releases only once every 4 months or so, this means that you can keep your installation safe for only $60 per year (or $3000 for larger installations).
- For other changes, please read the Bugzilla 5.0 release notes.
Enjoy!
Note: For the ones who didn’t notice when I wrote this post (April 1): yes, it was an April fool!
April 01, 2014 10:23 AM
March 27, 2014
I’ve invited Mark Côté to step up to fill the Assistant Project Lead position vacated by Simon Green two months ago. He’ll also be taking on a role as a “Community Coordinator” to try to step up efforts to make new community members feel welcome and encourage more involvement.
You probably all know him most recently for his leadership in the project to move our source control from bzr to git. He’s a long-time developer outside of Bugzilla, and has been heavily involved with Bugzilla the last year or so via his participation in maintaining bugzilla.mozilla.org. He’s mainly been in the role of a project manager for BMO, and that’s really what Bugzilla needs right now. We haven’t had a really good project manager or community coordinator in a long time, and the state of the project kinda shows it. In another first (in recent history), “approval” rights aren’t initially coming with the job. Any patches that need commit approval can continue to be directed towards Byron (glob) or myself (justdave).
I’ve had a long-standing policy of trying to avoid having the entire senior leadership team being employed by Mozilla, in order to try to keep it a real community project and not feel like it was being controlled by Mozilla, but the reality is that nobody else from outside of Mozilla has been involved enough to step into this kind of role in the recent past, and it’s better to have it filled and get things done than to leave it vacant and let the project stagnate even further. If he’s an effective community builder, that problem will probably solve itself eventually.
We’re going to try to set up another real-time project meeting soon either on IRC or Air Mozilla or in Google Hangouts again (that wasn’t too bad when we did it) so we can regroup on where we are and where we plan to go. Expect to be hearing from Mark on that soon.
For more information about Mark, see his Mozillians profile at https://mozillians.org/en-US/u/mcote/ or his LinkedIn profile at https://www.linkedin.com/profile/view?id=27908882 or find him in the #bugzilla channel on IRC as mcote.
March 27, 2014 03:12 AM
March 25, 2014
Or, how to migrate to git using only three programming languages
Another aspect of Bugzilla has been dragged, kicking & screaming, into
the future! On March 11, 2014, the Bugzilla source
moved to git.mozilla.org. We’re still mirroring to
bzr.mozilla.org (more on that later), but the repository of record
is now git, meaning it is the only place we accept new code.
Getting over there was no small feat, so I want to record the
adventure in the hopes that it can benefit someone else, and so I can
look back some day and wonder why I put myself through these things.
Background
The rationale isn’t the focus of this post, but suffice it to say that
Bazaar isn’t very widely used, and many projects are abandoning
it. Eric S. Raymond wrote a good post on the Emacs dev list about
why they need to move from Bazaar to git. The same rationale applies
to Bugzilla: “Sticking to a moribund version-control system will
compound and exacerbate the project’s difficulty in attracting new
talent.”
So, moving on, I started off scouring the Internet to find the best
way to perform this migration. One major complication is the fact that
we want to keep mirroring (one-way) to Bazaar for at least a while, since
the main suggested way to upgrade Bugzilla is from
bzr.mozilla.org. It was deemed unreasonable to require existing
installations to switch to git to obtain a small security fix, so
we’ll continue to mirror changes to Bazaar for some time.
Initial migration
I found a few posts here and there about people who had done
migrations like this, but the most useful was a post by David Roth
from last year that detailed how to preserve Bazaar’s commit metadata,
specifically bug-tracker metadata, which Bugzilla has used on
virtually every commit since switching from CVS. It involves using
the --no-plain option with bzr fast-export and then translating
the output to something git understands.
Interestingly, Roth’s translation script was written in C#, not my
personal first choice for such a task (or any, really, since I don’t
generally develop for Windows). However it compiled fine under
Mono, so I could run it on a Linux box. Something I learned,
though, is to not try this kind of thing on OS X, where, by default,
the filesystem is case-insensitive.
As much as I’d prefer to deal with a
language with which I am more comfortable, I dislike duplicated
effort even more. I used Roth’s
C# script as a basis, modifying it a bit for our needs. The metadata
is in the form <bug URL> <resolution>. Rather than editing existing
commit messages, I just took that string and pasted it to the bottom
of the commit message, but only if the bug number was not already in
the commit message. This actually revealed a few typos in the “Bug
123456” strings that generally start commit messages.
There turned out to a few other subtle bugs, like the fact that a file
which is both renamed and modified in the same commit shows up, in the
output from bzr fast-export, as being modified under the original
name. Thus if the delete is processed first, it looks like bzr has
modified an nonexistent file. Those were easy to see by comparing the
contents of every file before and after migration (admittedly just for
the last revision).
Since there are a lot of branches on bzr.mozilla.org, I created a bash
script to record them all and make sure none were missed. It output
the pre-/postmigration diff of md5 sums as well as doing a
git repack for each repo, after all branches were migrated.
One thing I forgot was pushing tags via the --tags option to git push;
I had to do that manually after the migration. That’s also when I
discovered that the same tag existed in several related bzr branches
which were all combined into one git repo. This is, of course, not
allowed in git. It made me think more about how Bugzilla uses certain
tags, like current-stable, which are moved after each release. In
git this requires the --force option to git push and is a big
no-no if the remote repo is shared. I learned that, in fact, this is
also the case in bzr, though perhaps it’s regarded as less of a sin
than it is in git. Anyway, I’ve since realized that those should be
branches, named appropriately (per branch). Despite them not being
branches in the standard sense—they’ll always point to somewhere at or behind a
version branch and never fork—it’s perfectly acceptable to move them,
as opposed to tags, and since they’ll always be fast-forwarded, they
won’t take any more space than a lightweight tag.
Mirroring
This was a harder problem. Originally, I tried to use the
bzr-git extension, and it failed when I tried to pull in changes from
git. I exchanged some emails with bzr-git’s author, Jelmer Vernooij,
and he said that to keep an existing bzr branch in sync with a newly
formed git repo is impossible at the moment: “This is essentially the
‘roundtripping’ support that we’ve been trying to achieve with bzr-git
for a while. It’s a nontrivial problem (since it requires all
semantics from bzr to be preserved when pushing to git).” Considering
bzr-git hasn’t had a new release in two years, I won’t be holding my
breath.
Luckily (and perhaps somewhat unfortunately) Bugzilla has jumped VCSes
before, as I hinted above. With the old bzr-to-cvs script as a
starting point, I created a git-to-bzr script—in, of course, Perl, as
the original.
This script is essentially an automated way of applying individual
commits from a git branch to a bzr branch. For each commit, the entire
file tree is copied from a local git clone to a local bzr checkout,
bzr add and remove are executed where needed, and the changes
committed with the original author, contributor, and date
preserved. The script also parses out the standard “Bug X:”
commit-message format and passes it to bzr’s --fixes commit
option. A file called .gitrev in the bzr repo tracks the associated
git commit ID for each bzr commit.
To avoid excessive disk activity, since the script polls git and bzr
for changes, the script uses bzr cat to check the contents of the
.gitrev file and git ls-remote to get the ID of the last git
commit. If they are equal, no further actions are performed.
Summing up
And that, folks, is how you can migrate from bzr to git! The initial
migration is pretty straightforward, more so if you don’t care about
any bzr commit metadata. It was unfortunate that there was no
off-the-shelf way to sync the repos afterwards, but the basic idea
isn’t too complicated.
For more, there’s the project page on our wiki, and all the
scripts used are in a GitHub repo for your perusal. I’m no VCS
expert—I’ve never heavily used bzr, and I’m constantly learning
new things about git—but feel free to ask me questions if you
want our process further clarified.
March 25, 2014 12:39 AM
February 17, 2014
A migration of Bugzilla and related code from bzr.mozilla.org to git.mozilla.org will be perfomed on Tuesday, 11 March 2014, starting at 17:00 UTC. At this time, all Bazaar branches on bzr.mozilla.org will be made read-only (aside from a few admin accounts), and the migration to git repos on git.mozilla.org will commence. It should take around 1.5 hours to migrate everything, after which point write access will be enabled on the git repos for all users previously authorized on bzr.mozilla.org. A script will periodically mirror changes from git to bzr for all currently supported Bugzilla branches (4.0, 4.2, and 4.4). Changes will not be mirrored for any other branches of Bugzilla nor any other related branches (extensions, misc, etc.).
We will start mirroring changes to read-only repos on GitHub at some point (to be determined) after the migration to git.mozilla.org. git.mozilla.org will remain the repository of record, meaning the only place to which changes should be committed by developers. All mirroring, e.g. to GitHub and bzr.mozilla.org, will be unidirectional.
We’ve already done one test migration; see http://git.mozilla.org. It was successful aside from some missed file deletions, resulting in extra files on a handful of git repos after the migration. I manually deleted the superfluous files after migration, and I also fixed the migration script to account for this oddity in Bazaar’s fast-export output, so it won’t happen during the real migration.
I would like to open up testing to all developers, starting with another complete, fresh migration, on Tuesday, 18 February 2014, around 17:00 UTC. To test the git-to-bzr mirroring script, we’ll create a new branch, “migration-test”, off of Bugzilla trunk and run the mirroring script on it after the migration. We’ll leave it running until the real migration, and I invite anyone with commit access to bzr.mozilla.org to commit changes to the test-migration branch on git and ensure that they are mirrored properly to bzr.
The full migration and testing plan, along with other details, is at https://wiki.mozilla.org/Bugzilla:Migrating_to_git.
Post reprinted from Mark Côté’s post on mozilla.dev.apps.bugzilla.
February 17, 2014 08:23 AM
January 28, 2014
Today we are releasing 4.4.2 and the unstable development snapshot 4.5.2.
Bugzilla 4.4.2 is our latest stable release. It contains various useful bug fixes for the 4.4 branch.
Note that 4.5.2 is an unstable development release and should not be used in production environments. We are not yet feature-frozen at this time so the features you see in 4.5.2 might not accurately represent the behavior that 5.0 will have.
Note that when Bugzilla 5.0 is released, the Bugzilla 4.0.x series will reach end of life. If you are using that series, we encourage you to upgrade to 4.4.2 now.
Download
Bugzilla is available at:
http://www.bugzilla.org/download/
MD5SUMS
982ef341c55795e02388bb15bdc07ccf bugzilla-4.5.2.tar.gz
4aae9730d8187d13a133874f3dd5cc2b bugzilla-4.4.2.tar.gz
Release Notes & Changes
Before installing or upgrading, you should read the Release Notes for the new version of Bugzilla:
4.4.2: http://www.bugzilla.org/releases/4.4.2/release-notes.html
It is VERY IMPORTANT to read the Release Notes if you are upgrading from one major version to another (like 3.6.x to 4.4.x).
To see a list of all changes between your version of Bugzilla and the current version of Bugzilla, you can use the chart at: http://www.bugzilla.org/status/changes.html
The Bugzilla Update
You can see the latest updates from the Bugzilla Project and the status of Bugzilla development on The Bugzilla Update:
https://bugzillaupdate.wordpress.com/
Also, you can follow the Bugzilla Project on Twitter for frequent updates on new features being developed in Bugzilla, our current release plans, and much more:
http://twitter.com/#!/bugzilla
Report Bugs
If you find a bug in Bugzilla, please report it! Instructions are at this URL: http://www.bugzilla.org/developers/reporting_bugs.html
Support
You can ask questions for free on the mailing lists (or in IRC) about Bugzilla, or you can hire a paid consultant to help you out:
Free Support: http://www.bugzilla.org/support/
Paid Support: http://www.bugzilla.org/support/consulting.html
About Bugzilla
Bugzilla is a “Defect Tracking System” or “Bug-Tracking System.” Defect Tracking Systems allow individuals or groups of developers to keep track of outstanding bugs in their product effectively. Most commercial defect-tracking software vendors charge enormous licensing fees. Despite being “free”, Bugzilla has many features its expensive counterparts lack. Consequently, Bugzilla has quickly become a favorite of thousands of organizations across the globe, and is widely regarded as one of the top defect-tracking systems available.
See http://www.bugzilla.org/about/ for more details.
January 28, 2014 04:53 AM
January 22, 2014
Have you written an app or system of some sort which uses the Bugzilla REST API (BzAPI)? If so, please do as the docs have long recommended and make sure you are a member of the mozilla.tools discussion forum. There are several upcoming announcements in the next few weeks and months which you will need to be aware of, and that is where they are going to be posted.
January 22, 2014 02:24 PM
January 08, 2014
A quick note to let you know that starting with Bugzilla 4.5.2, which should be released soon (a few weeks at most), it now uses the HTML5 doctype instead of the HTML 4.01 Transitional one. This means that cool new features from HTML5 can now be implemented in the coming Bugzilla 5.0. A lot of cleanup has been required to remove all obsolete HTML elements and attributes, and to move all hardcoded styles into CSS files, and to replace many <table> by <div> where appropriate. There are still many places to fix to be fully HTML5 compliant as HTML 4.01 was more lenient with some code, but we did a great jump toward the HTML5 world.
January 08, 2014 11:19 PM
November 26, 2013
The Bugzilla Project is currently considering moving our source code repository from Bazaar (bzr) to git. Part of the impetus for this is that Mozilla is trying to get out of the business of hosting every version control system known to man (which they currently do, or close to it anyway) and bzr is one of the low-hanging fruit (Bugzilla is the only Mozilla project using it). There’s also a lot of feeling out there that mirroring to github may make contributions easier for new contributors. The general consensus on the thread so far is that we should do it; the main point of contention is how long to keep it mirrored in bzr after it moves.
What’s your take on it? We’d appreciate anyone who currently works on Bugzilla or is contemplating it to join in on the discussion.
The main discussion thread is in a thread on our developers list, and the metabug to track it is bug 929685.
November 26, 2013 03:18 AM
November 20, 2013
October 17, 2013
Today we are releasing 4.4.1, 4.2.7, 4.0.11, and the unstable development snapshot 4.5.1.
Initially, we released new tarballs and diffs for these releases to the download site but found a new bug shortly after. New tarballs and diffs have been uploaded to the site which we recommend everyone update to if you downloaded the first version. To make sure you have the fixed version, md5sum values are provided further down in the announcement.
All of today’s releases contain security fixes. We recommend all Bugzilla administrators to read the Security Advisory linked below.
Bugzilla 4.4.1 is our latest stable release. It contains various useful bug fixes, performance improvements and security fixes for the 4.4 branch.
Bugzilla 4.2.7 and 4.0.11 are security updates for the 4.2 branch and the 4.0 branch, respectively.
Note that 4.5.1 is an unstable development release and should not be used in production environments. We are not yet feature-frozen at this time so the features you see in 4.5.1 might not accurately represent the behavior that 5.0 will have.
Note that when Bugzilla 5.0 is released, the Bugzilla 4.0.x series will reach end of life. If you are using that series, we encourage you to upgrade to 4.4.1 now.
Download
Bugzilla is available at:
http://www.bugzilla.org/download/
MD5SUMS
53d0bffc3055f7d5af1c754f177de4ad bugzilla-4.5.1.tar.gz
fd9d6dcc85bb359536be52e34ad20dfd bugzilla-4.4.1.tar.gz
ebf0a75d1037f09994660d3958fc66fb bugzilla-4.2.7.tar.gz
48402a4a105de3f00962dca244cd7569 bugzilla-4.0.11.tar.gz
Security Advisory
There is a security advisory describing the security issues fixed in these releases, at:
http://www.bugzilla.org/security/4.0.10/
Release Notes & Changes
Before installing or upgrading, you should read the Release Notes for
the new version of Bugzilla:
4.4.1: http://www.bugzilla.org/releases/4.4.1/release-notes.html
4.2.7: http://www.bugzilla.org/releases/4.2.7/release-notes.html
4.0.11: http://www.bugzilla.org/releases/4.0.11/release-notes.html
It is VERY IMPORTANT to read the Release Notes if you are upgrading from one major version to another (like 3.6.x to 4.4.x).
To see a list of all changes between your version of Bugzilla and the current version of Bugzilla, you can use the chart at:
http://www.bugzilla.org/status/changes.html
October 17, 2013 03:36 PM
September 16, 2013
This week, Bugzilla turns 15! On September 18, 1998, Terry Weissman released Bugzilla 2.0, the first version written in Perl. A few days before, on August 25, 1998, the Bugzilla source code was committed to CVS for the first time, and was written in Tcl (Terry decided to rewrite it in Perl to attract more contributors). Since this first public release, Bugzilla changed a lot, though some of its original features are still clearly recognizable. You may wonder how Bugzilla looked like 15 years ago? Well, I’m going to tell you all.
Installing Bugzilla 2.0 wasn’t as easy as it is today. You had to manually run six(!) scripts to create DB tables and to populate them (checksetup.pl only replaced them in Bugzilla 2.8). The tarball was very small, only 52 KB (compared to 2.4 MB for Bugzilla 4.4), and you needed MySQL 3, Perl 5.4 and a web server. The home page was pretty…. simple:
So what do we see? A link to the search page, another link to file a new bug, and a text box to enter the ID of an existing bug. Oh, and a huge picture of an ant. You can see that there is no link to create a new account. That’s because there is no UI for that! To create an account, you had to click on "Enter a new bug", and Bugzilla would ask your credentials. As you have none, you had to click the "Forgot password" button, and Bugzilla would send you an email with your password in it. This had the side-effect to automatically create an account for you with the email address you just gave and the password included in the email you just received. This page has evolved a lot, and it now looks like this in Bugzilla 4.4:
Big icons help users to more easily find what they are looking for, and the page header and footer also make navigation through pages much easier.
Once you pass this first page, the next step is the search page:
Yes, the page says "Bugzilla 1.2", but it’s really 2.0 minus one minor string change in the parameters page (1.2 is only 70 minutes older than 2.0). As you can see, the search page is not very different from what we have today:
The product, component, bug status, resolution, severity and priority fields are still here. The main difference is that we greatly improved search capabilities of Bugzilla, and all the sections above are expandable to offer more search criteria:
And many new bug fields appeared, such as the target milestone, keywords, the status whiteboard, attachments and flags.
The buglist didn’t change a lot either:
Note that I had to fix the code to correctly display <table> in the bug summary. Bug summaries weren’t HTML-escaped, and so it was trivial to inject arbitrary code in the buglist. But this shouldn’t be a surprise to anyone as we had to wait 8 years for Bugzilla 2.18 to see correct HTML-escaping. :)
To file a bug, you had to first select the product…
… and then enter details of the bug report:
If these pages look familiar to you, that’s because they didn’t change a lot in the last 15 years:
The main difference is that the product description has been added to help users select the right product.
This is the simple form to report new bugs. If you click the "Show advanced fields" link, more fields are displayed. You now also have the possibility to attach a file and to set flags when reporting a new bug. Attachments and flags didn’t exist in Bugzilla 2.0. Attachments have been implemented in 1999 in Bugzilla 2.4, and flags in 2002 in Bugzilla 2.18. And you had to wait for 2006 and Bugzilla 3.0 to be able to attach files and set flags on bug creation.
Bug reports in Bugzilla 2.0 had very few fields and, of course, were not customizable:
You probably recognize knobs which have been removed in 2008 in Bugzilla 3.2 in favor of a better UI. Also, you will note that comments were all concatenated into a single comment, making it impossible to track who commented in the bug, and when.
On the backend, things have changed a lot. First of all, the number of DB tables exploded. In Bugzilla 2.0, there were only 7 tables:
In Bugzilla 4.4, there are more than 70 tables (the output is truncated):
The exact number of tables will depend on the number of custom fields. The reason for so many tables is because Bugzilla now has many new features which didn’t exist in previous releases, and admins now have the ability to edit mostly everything to customize Bugzilla as desired. In Bugzilla 2.0, everything was static:
You couldn’t customize bug statuses, resolutions, bug severities, priorities, etc… Now admins have a nice UI to edit them:
Same goes about the list of products, components and assignees:
The list was hardcoded, and you had to manually edit the DB to add/edit/remove entries. Now this can be done from the UI:
The list of parameters also increased a lot, and the ugly old UI…
… became a well organized list of tabs:
Maybe you wonder how other pages looked like in Bugzilla 2.0? Well, there are no other pages. They are all listed above. :) No preferences page, no tabular and graphical reports, and… no groups! Which means no admins, no editbugs nor canconfirm privileges, no way to restrict the visibility of bugs and comments. Frightening, isn’t it? :)
Happy birthday, Bugzilla!
September 16, 2013 02:02 AM
August 01, 2013
[Note: The closing date for entries was midday ZST on Thursday 5th September 2013, i.e. a long time ago :-).]
Some of you may have noticed that, after a long history of contests, there was no competition to predict the time of arrival of the 900,000th bug on bugzilla.mozilla.org. This was because we were preparing for the big 1M.
Now we are over 9000,00 (can that really be right?), I can reveal that the prize for the Millionth Bug Sweepstake will be the top-of-the-range Most Splendid Package from the Mozilla Gear Store, which includes a black hoodie, a drawstring tote bag, a Moleskine notebook, and a Rickshaw laptop bag, all Firefox or Mozilla-branded.
The aim of the contest is simple – you need your guess to be the closest to the actual filing date of the one millionth bug in our Bugzilla installation.
To enter, email me a plain text email at [email protected], ideally using this link, filling in the date and time you think the one millionth bug will be filed, along with your Bugzilla ID or email address. As the link suggests, your entry should be on the first line of your email, and formatted as follows:
2010-09-08 06:54:32 [email protected]
All times are in ZST (‘Zilla Standard Time, a.k.a. Pacific Time, as displayed in Bugzilla timestamps unless you’ve changed a pref). If you prefer to be contacted on a different address, add that as well, in brackets on the end of the same line. We have ample graphs and charts (requires editbugs) to help you with your assessment. But if you can’t be bothered to do any research and analysis, just guess optimistically and hope!
This is a Mozilla community event. To keep it that way, entrants must have either a Bugzilla account on bugzilla.mozilla.org created before the end of July 2013, and which has done something useful in the past six months, or a Mozillians account vouched for before the same date. Anyone who meets those criteria can (and is encouraged to) enter, including Mozilla employees. Once the bug is filed, I’ll check those entries who are closest, and keep discarding them until I find one which meets these criteria. Therefore, there’s no point posting this to Slashdot or any other non-Mozilla-focussed news source. But please do post it in Mozilla news sources!
Badly-formatted entries may be discarded. The judge’s decision is final, and any funny business regarding the filing of bugs on or around the one million mark will be frowned upon. The closing date for entries is midday ZST on Thursday 5th September 2013.
August 01, 2013 11:26 AM
July 08, 2013
"Everything that has a beginning has an end". I joined the Bugzilla project in August 2004 (already 9 years ago) and fixed more than 1600 bugs (including a few bugs in Bonsai, Doctor and Testopia). I became an official reviewer in December 2004, only 4 months after my first contribution, and reviewed patches in more than 2000 bugs. I also got approval privileges in January 2007, meaning that I had the responsibility to grant/deny approval for the last 6.5 years, and approved no less than 1500 patches to be committed into the source code. I’m also the QA manager for the Bugzilla project since July 2005 and so I am responsible to make sure Bugzilla quality is good enough before each new release. That’s a lot of work, and takes a lot of my free time and energy.
In the last few months, my free time was pretty limited and so my contributions to the project were mostly to triage new bugs, set blockers for the next releases, approve (or reject) reviewed patches, and help fixing blockers and security bugs. But now that my free time increased a bit again, I realized that my motivation to write new patches, either bug fixes or new features, and my motivation to review patches in my too long review queue are gone. And to lead a project correctly (I’m actually an assistant project lead, the project lead being justdave), you need to put time and energy into it to not be the bottleneck in the development of the application. And so without enough motivation and energy anymore it’s time for me to resign my role as assistant project lead. This means that decisions about the direction Bugzilla should take no longer belong to me. So please stop marking bugs as WONTFIX because LpSolit (me) said he didn’t agree with such or such new feature; my opinion is no longer relevant. :)
Those who know me shouldn’t be too surprised by my decision. Two years ago, I was very close from taking the same decision. The only reason I didn’t was because mkanat left the Bugzilla project to go work for Google, and it wasn’t the right time to also leave the project. So I stayed involved two additional years to help with the release of Bugzilla 4.2 and 4.4, but now it’s really time for me to say goodbye. This also means you shouldn’t ask me to review your patches anymore. Those should be addressed to another reviewer (glob, dkl, justdave). I will keep my reviewer and QA manager hats for now, but really stop asking me for review (unless it’s a security or critical bug which requires my skills).
It was a really great and fantastic experience to work with other Bugzilla developers and contributors, and I wish all the best for the future of Bugzilla. :)
July 08, 2013 07:47 PM
May 24, 2013
(cross-posted from LpSolit’s Blog)
We released Bugzilla 4.4 and 4.2.6 today. Bugzilla 4.2.6 is a bugfix release, and contains no security fixes. It adds support for MySQL 5.6 and fixes a crash with Oracle.
Bugzilla 4.4 contains many new features:
- The searching system has been improved: it allows multiple search criteria to match one field; it has improved support for flags; it has better performance, especially with complex queries.
- The tagging system has been redesigned: the old tagging fields in the page footer are gone in favor of a Tags field in the bug itself. Tags remain private and are only visible by you. They can also be used in queries as any other field.
- Bugzilla can now correctly identify uploaded attachments which have a MIME type of application/octet-stream.
- You can now save tabular and graphical reports as you already do with saved searches. Previously, you had to bookmark them in your web browser.
- You can customize columns displayed in whinemails.
- As usual, the WebServices have been improved with several new methods.
- The security has been improved, such as using HMAC SHA-256 to generate tokens instead of MD5.
- etc ….
This release also means the End Of Life (EOL) of Bugzilla 3.6, which was the last series for Bugzilla 3.x. This branch is no longer supported, and any new security bug found on this branch will remain unfixed. Installations still running Bugzilla 2.x or 3.x are urged to upgrade to Bugzilla 4.4 or 4.2.6.
So, what’s next? Well, the main focus for Bugzilla 5.0 will be usability and user experience. Bugzilla sometimes (often?) looks old-fashioned because we wanted to support old browsers and browsers with JavaScript disabled. But we decided to move to a more interactive interface where JavaScript will help accomplish some tasks with less page reloads, such as submitting changes to a bug or adding an attachment. We also plan to add a new skin to Bugzilla which should look like this. Some pages will also be entirely redesigned, such as the Group Controls page to administrate access to bugs which was considered too complex for the average admin. More information will come with the release of development snapshots.
May 24, 2013 04:14 PM
May 23, 2013
(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
May 23, 2013 12:26 AM
We just released Bugzilla 3.2.10, 3.4.10, 3.6.4, and 4.0rc2. Mostly, these contain a lot of very important security fixes. One of the fixes in particular took over 100 hours of work from the Bugzilla team as a whole and a host of external contributors, and we’ll be blogging about that in more detail in the coming days or weeks. Right now, what’s important to know is that these issues are pretty serious and you should update as soon as possible.
Older versions of Bugzilla are also affected, even though they haven’t been patched because they have reached End Of Life. If you are running a version of Bugzilla earlier than 3.2, it is now very important that you upgrade so that you can remain secure.
Most of the issues that were fixed today were discovered as a result of Mozilla expanding their security bug bounty program to include web applications. We’d like to thank Mozilla for funding this initiative and helping us significantly improve the security of Bugzilla in various areas.
Progress Toward Bugzilla 4.0
With the release of Bugzilla 4.0rc2, we’re that much closer to Bugzilla 4.0! This second Release Candidate has a fully-tested Bug.update WebService method, so we don’t expect its API to change any more (although it has changed quite a bit since 4.0rc1 thanks to testing and bug fixes). The other new WebService methods may still change before the final release of 4.0, as we haven’t tested all of them yet.
4.0rc2 also contains a lot of bug fixes over rc1, and should be relatively stable. Now is the time to start trying out deployments of it to see if everything is okay in your environment. Our current plan is to release Bugzilla 4.0 on Tuesday, February 15, 2011 if everything goes well with this release.
-Max
May 23, 2013 12:26 AM
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
May 23, 2013 12:26 AM
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
May 23, 2013 12:26 AM
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
May 23, 2013 12:26 AM
Today we are announcing the second Release Candidate for Bugzilla 4.2, in addition to one new stable release and two security-only updates for the 3.4.x and 3.6.x series.
Bugzilla 4.2rc2 is our second Release Candidate for Bugzilla 4.2. This release has received QA testing, and should be considerably more stable than the development releases before it. It is still not considered fully stable, and so you should understand that if you use it, you use it at your own risk. This will most likely be the last release candidate before 4.2 final.
Bugzilla 4.0.4 is our latest stable release. It contains various useful bug fixes and security improvements for the 4.0 branch.
Bugzilla 3.6.8 and 3.4.14 are security updates for the 3.6 branch and the 3.4 branch, respectively.
All the gory details and download links and the security advisory are available on our website.
Get Involved
As always, we love new contributors in every area. There are a lot of ways to contribute to Bugzilla–you don’t just have to be a programmer. In particular, we’d really love to have somebody to be in charge of our documentation. If you know anybody who’s a great documenter (including yourself!) who wants to help out an open-source project, please send them our way!
May 23, 2013 12:26 AM
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 4.2.2 is our latest stable release. It contains various useful bug fixes and security improvements:
Bugzilla 4.0.7 is a security update for the 4.0 branch:
Bugzilla 3.6.10 is a security update for the 3.6 branch:
Bugzilla 4.3.2 is an unstable development release. This release has not received QA testing from the Bugzilla Project, and should not be used in production
environments. Development releases exist as previews of the features that the next major release of Bugzilla will contain. They also exist for testing purposes, to collect bug reports and feedback, so if you find
a bug in this development release (or you don’t like how some feature works) please tell us.
May 23, 2013 12:26 AM
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 4.2.3 is our latest stable release. It contains various useful bug fixes and security improvements:
Bugzilla 4.0.8 is a security update for the 4.0 branch:
Bugzilla 3.6.11 is a security update for the 3.6 branch:
Bugzilla 4.3.3 is an unstable development release. This release has not received QA testing from the Bugzilla Project, and should not be used in production environments. Development releases exist as previews of the features that the next major release of Bugzilla will contain. They also exist for testing purposes, to collect bug reports and feedback, so if you find a bug in this development release (or you don’t like how some feature works) please tell us.
May 23, 2013 12:26 AM
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 4.4rc1 is our first Release Candidate for Bugzilla 4.4. This release has received QA testing, and should be considerably more stable than the development releases before it. It is still not considered fully stable, and so you should understand that if you use it, you use it at your own risk.
If feedback from this release candidate indicates that it is mostly stable, then Bugzilla 4.4 will be released in a few weeks. If feedback indicates that more extensive fixes are needed, there may be another release candidate after this one.
Bugzilla 4.2.4 is our latest stable release. It contains various useful bug fixes and security improvements:
Bugzilla 4.0.9 is a security update for the 4.0 branch:
Bugzilla 3.6.12 is a security update for the 3.6 branch:
May 23, 2013 12:26 AM
May 22, 2013
We released Bugzilla 4.4 and 4.2.6 a few minutes ago. Bugzilla 4.2.6 is a bugfix release, and contains no security fixes. It adds support for MySQL 5.6 and fixes a crash with Oracle.
Bugzilla 4.4 contains many new features:
- The searching system has been improved: it allows multiple search criteria to match one field; it has improved support for flags; it has better performance, especially with complex queries.
- The tagging system has been redesigned: the old tagging fields in the page footer are gone in favor of a Tags field in the bug itself. Tags remain private and are only visible by you. They can also be used in queries as any other field.
- Bugzilla can now correctly identify uploaded attachments which have a MIME type of application/octet-stream.
- You can now save tabular and graphical reports as you already do with saved searches. Previously, you had to bookmark them in your web browser.
- You can customize columns displayed in whinemails.
- As usual, the WebServices have been improved with several new methods.
- The security has been improved, such as using HMAC SHA-256 to generate tokens instead of MD5.
- etc ….
This release also means the End Of Life (EOL) of Bugzilla 3.6, which was the last series for Bugzilla 3.x. This branch is no longer supported, and any new security bug found on this branch will remain unfixed. Installations still running Bugzilla 2.x or 3.x are urged to upgrade to Bugzilla 4.4 or 4.2.6.
So, what’s next? Well, the main focus for Bugzilla 5.0 will be usability and user experience. Bugzilla sometimes (often?) looks old-fashioned because we wanted to support old browsers and browsers with JavaScript disabled. But we decided to move to a more interactive interface where JavaScript will help accomplish some tasks with less page reloads, such as submitting changes to a bug or adding an attachment. We also plan to add a new skin to Bugzilla which should look like this. Some pages will also be entirely redesigned, such as the Group Controls page to administrate access to bugs which was considered too complex for the average admin. More information will come with the release of development snapshots.
May 22, 2013 09:56 PM
March 08, 2013
I am proud to announce the release of version 1.3 of the Bugzilla REST API. This maintenance release has a bug fix or two, and fully supports the version of Bugzilla 4.2 which has just been deployed on bugzilla.mozilla.org. For smooth interaction with BMO, you should be using this version.
The installation of BzAPI 1.1 on api-dev.bugzilla.mozilla.org will go away in 4 weeks, on 4th April. There is a limit to the number of old versions we can support on the server, particularly as the older ones can put a larger load on Bugzilla and may not work correctly. Please use either the /1.3 or the /latest endpoints. Now that BzAPI has been stable for some time, tools which earlier rejected using the /latest endpoint may want to reconsider.
File bugs | Feedback and discussion
March 08, 2013 11:47 AM
February 20, 2013
(mirrored from LpSolit’s Blog)
So, Bugzilla 4.4rc2 is finally here! It took us more time than expected, but the performance bugs are all fixed and we also fixed two security bugs which are described in the security advisory. Bugzilla 4.2.5, 4.0.10 and 3.6.13 also contain these two security fixes, so you should definitely upgrade.
Compared to 4.4rc1, the new release candidate contains the last feature which we wanted for 4.4: the ability to add several criteria in a query against the same field. In Bugzilla 4.2,
"Flags changed to approval+" AND "Flags changed by [email protected]"
were disconnected, which means that these criteria would match all bugs which had the approval+ flag set and which had a flag changed by [email protected]. In Bugzilla 4.4, you can now force these two criteria to match the same field, i.e. that you only want bugs where the approval+ flag has been set by [email protected]. Thanks to Byron Jones (glob) for this great feature. 
Of course, this feature is not limited to flags, but works with all fields. See the release notes for more details. Also, 4.4rc2 should in most cases be much faster than 4.2 to run some complex queries. In my testing, some queries which took several minutes to complete now run in a few (tens of) seconds only. This is especially noticable with many columns displayed in the buglist. Another good reason to test it! 
The next release should be 4.4 final as I don’t think a 4.4rc3 is needed.
February 20, 2013 03:47 AM
So, Bugzilla 4.4rc2 is finally here! It took us more time than expected, but the performance bugs are all fixed and we also fixed two security bugs which are described in the security advisory. Bugzilla 4.2.5, 4.0.10 and 3.6.13 also contain these two security fixes, so you should definitely upgrade.
Compared to 4.4rc1, the new release candidate contains the last feature which we wanted for 4.4: the ability to add several criteria in a query against the same field. In Bugzilla 4.2,
"Flags changed to approval+" AND "Flags changed by [email protected]"
were disconnected, which means that these criteria would match all bugs which had the approval+ flag set and which had a flag changed by [email protected]. In Bugzilla 4.4, you can now force these two criteria to match the same field, i.e. that you only want bugs where the approval+ flag has been set by [email protected]. Thanks to Byron Jones (glob) for this great feature. :) Of course, this feature is not limited to flags, but works with all fields. See the release notes for more details. Also, 4.4rc2 should in most cases be much faster than 4.2 to run some complex queries. In my testing, some queries which took several minutes to complete now run in a few (tens of) seconds only. This is especially noticable with many columns displayed in the buglist. Another good reason to test it! ;)
The next release should be 4.4 final as I don’t think a 4.4rc3 is needed.
February 20, 2013 02:10 AM
January 23, 2013
[Update 2013-01-23 18:35 GMT – turns out there are a couple of Persona features we still need to be absolutely certain that this is a good thing. The change has been reverted until we’ve got those. Sorry for any confusion.]
In April last year, we enabled Persona logins on bugzilla.mozilla.org using a Bugzilla extension I wrote. However, we restricted this login method to low-privilege accounts only while Persona and the extension both matured.
I’m pleased to say that, as of now, unless you are a member of the administrative Bugzilla groups “admin”, “editusers” or “editgroups”, or the “legal” group, then you can now use Persona to log in to bugzilla.mozilla.org :-) In particular, this means all Mozilla employees and security group members can now log in this way.
Make sure you use the correct email address; if you pick a different one to your usual one, Bugzilla will auto-create a Bugzilla account for it.
If for some reason you want b.m.o. not to accept Persona logins for your account, you can do so; file a bug to have your account manually added back to the “no-browser-id” group.
January 23, 2013 04:24 PM
January 18, 2013
BMO is a core tool in the Mozilla project. There is now a shared, curated space for people’s tips, ideas, best practices, FAQs and so on relating specifically to BMO: https://wiki.mozilla.org/BMO/Support.
This includes Things Every BMO User Really Should Do, and a BMO FAQ (currently in its infancy).
Suggestions for additional content would be very welcome.
January 18, 2013 01:27 PM
December 26, 2012
You may wonder what’s going on since we released Bugzilla 4.4rc1 on November 13. Well, very few bugs have been reported which seems to indicate that 4.4rc1 is pretty stable. But we also found that running some queries were very slow since Bugzilla 4.2. Bugzilla 4.2 got a major rewrite of its search code (Bugzilla::Search), where the focus was readability, maintainability and the removal of some hacks, but this new code had some severe performance impact for some queries, especially those involving subselects in MySQL. That’s why several bugs related to performance have been filed since we released 4.4rc1 and we decided that they were critical enough to fix them in the 4.4 branch rather than waiting another year to include them in Bugzilla 5.0 only. As it’s unclear if these recent changes can have negative impact on some queries, or break some other ones, we decided that a 2nd release candidate was necessary to give admins and developers some time to test the new code and give us feedback before 4.4 final. There is no ETA for 4.4rc2 yet, but it will probably be somewhere in January 2013.
If you have some queries which you consider as being very slow, I would be interested in hearing you about them: which criteria did you use, which columns are displayed in buglists, which Bugzilla installation did you use for your testing, are you logged in or logged out, etc…? Please don’t run your queries on Bugzilla 3.x or older. I’m really not interested in such old installations (and the code changed too much anyway with what we have in 4.4). In my own testing, I found that some queries which were previously timing out now run in a few seconds only. Of course, the time taken to execute these queries highly depends on the data you have in your DB and so only relative timing matters.
December 26, 2012 03:30 PM
December 21, 2012
“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.
December 21, 2012 11:25 AM
December 07, 2012
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)
December 07, 2012 06:20 PM
December 06, 2012
When planning on upgrading your Bugzilla to a newer version, it’s always a good idea to read the release notes in case of special instructions that need to be done to handle certain situations in upgrades. Our checksetup.pl script has gotten pretty good at handling a lot of situations automatically for you these days, but nothing is ever perfect.
One instruction in the upgrade procedure for every release that often gets overlooked is to run the Sanity Check function from the Admin page on your Bugzilla site before upgrading. It checks the integrity of the data in your database and will alert you to a number of possible problems with your data. Sometimes bugs in Bugzilla or even people manually messing with the database will cause something to not be how Bugzilla expects it, and every so often one of these problems can cause issues for an upgrade. Fixing any problems reported by Sanity Check before each upgrade can save you a lot of headaches.
In a recent example: newer versions of Bugzilla allow you to edit the available statuses and resolutions on bugs. Older versions didn’t. One of the steps performed by the upgrade script is to examine your database, take whatever current statuses you’ve been using (even if you hacked your Bugzilla to allow different ones before we actually let you customize them), and convert them to the way the new customizable ones are stored. The new custom status system has a flag to distinguish between statuses that are allowed to have resolutions and those that aren’t. When upgrading, it decides whether to set that flag on a status or not by looking in your database to see if there are any bugs with that status that have resolutions on them. If it finds any, the status is set up to use them.
A long time ago there was Bug 107229 which caused duplicate bugs to get the wrong status if you midaired while marking it a duplicate. This caused bugs to exist in an “ASSIGNED DUPLICATE” state that should have been “RESOLVED DUPLICATE”. A side effect is if it was left that way, when you later upgraded to a version of Bugzilla that included the custom statuses, your ASSIGNED status became a “closed” type instead of an “open” one, and would require a resolution. Sanity Check most likely would have caught this, as it checks for things like resolutions where there shouldn’t be any. :)
December 06, 2012 10:58 PM
