What do you do when you have two very different projects that both want to
maintain their independence but developers need to land coordinated changes
across them?
a quick introduction
I'm currently working on a project that's outside of my normal realm;
"bi-directional" synchronisation between a Mercurial repository and one hosted
on GitHub.
But before I dive too deep there's some terms and processes that I should
define.
mozilla-central
A large mercurial host repository that stores the majority of the Firefox
source.
mozilla-integration branches
Called "branches" internally, these are actually separate Mercurial
repositories. Reviewed code is landed onto an integration branch (historically
mozilla-inbound) which then triggers Firefox's test suite.
sheriffs
They look after the "tree" (the repository). One task they perform is
monitoring the test results on the integration branches, and either merge into
mozilla-central if it passes, or backout the commit if it causes failures.
servo, gecko, stylo, and quantum
Servo is a browser written in rust under Mozilla's research umbrella. It
was designed from the ground up to take advantage of modern CPU and GPU
architectures. Gecko is the core engine that drives Firefox, from parsing
HTML to rendering the page. Stylo is a project to bring Servo's modern
CSS/layout engine into Firefox. Quantum is a large collection of work that
plans on delivering significant changes to Firefox's core engine (aka "the
Firefox platform" or just "the platform").
autolanders
These take code that has passed review and land them on the target repository.
Servo's autolander "homu" gates landed on a successful run of Servo's tests
(continuous integration, or CI), while Gecko's autolander "autoland" just
transplants code from the review to the integration repository.
Servo is developed on GitHub, while Gecko's lives in a Mercurial repository.
For a multitude of good reasons it was decided that neither moving Servo to
Mercurial or Gecko to GitHub would be viable. What we needed was a way for
changes made on GitHub be synchronised to Mercurial and vice-versa.
the problem
The core problem at hand is it's fairly common for Stylo patches to touch both
Servo and Gecko at the same time. These changes need to land simultaneously on
the integration branch in order for the Firefox tests to pass. In the current
environment this is not possible. Changes first need to land on Servo via a
GitHub pull request, wait for Servo's tests to run and for homu to land the
code (~45 minutes), watch the integration branch for the Servo changes to be
overlaid, ignore the build/test failures, and finally push the Gecko changes to
fix the code and (hopefully) return tests to a passing state.
Needless to say this is a sub-optimal experience for both developers and
sheriffs.
in the beginning - unification
Long before I was involved the plan called for unification of the Servo and
Firefox autolanders.
Large parts of homu would be rewritten into Gecko's autoland, and changes to
both GitHub and Mercurial would funnel through this central autolander. It
would kick off tests for both Servo and Gecko, and would land to both
repositories only if tests on both repositories passed.
This plan was ambitious and relied Gecko's test suite returning a boolean
pass/fail result.
autolander development
As it happens both of the project's autolanders were developed rapidly and grew
organically as demands grew. As a result working on them can present issues,
especially when implementing non-trivial changes. homu doesn't have any real
tests, which adds risk to any large scale changes. Meanwhile autoland's
development environment can be a nightmare at times; look at it the wrong way
and you might lose the next two hours of your day getting your environment up
and running again.
It became clear that somebody from outside of the autoland team was not going
to be able to extend it to merge the two landers without heroic efforts.
gps and glob join the party
At the end of last year, gps and I were called in to provide whatever help we
could to this project. gps is an expert in all things source control related,
and I was familiar with gecko's autoland. While gps dove straight into
developing servo-vcs-sync (see below), I acted in a supporting role for the
existing engineer, however I wasn't called upon much in that capacity.
My involvement really ramped up when gps took one and a half months of
leave at the start of this year, and I was called in to cover for him as best
as I could.
servo-vcs-sync is born
gps realised that implementing uni-direction synchronisation from GitHub to
Mercurial would be an important first step, and would ease a lot of the issues
the Stylo team were having with their manual vendoring in of the servo code.
He worked diligently on this and servo-vcs-sync was deployed on the Friday
before his long leave.
This system and works well, but it wasn't without some teething
problems; in fact it failed on its first weekend, generating ~10k error emails
before the server was shutdown (pans out the failure retry interval was
accidentally set to 100ms instead of 5 minutes - ouch).
In the time that gps was away I was able to resolve issues and add some missing
functionality and it's been stable for some time.
a change of ownership
At the same time it was realised that the existing engineer was unable to work
on the project and ownership was transferred to me. Development had not
progressed beyond the planning stage, which gave me the opportunity to really
look at the plan with a fresh set of eyes.
It also became evident that a critical part of this project - the ability for
the Firefox's test suite to return a boolean pass or fail - was much harder
than expected, and would not be ready within a reasonable time-frame.
What was needed was a new plan.
a new plan, or two
Being brought into the project late meant was good and bad. I had a lot to
learn, but I also didn't have any preconceived notions of how this should be
done; I was able to focus on the end goal.
I set up meetings and spoke with anyone who would listen to gather advice. I
drew diagrams, we discussed, I discarded and drew more diagrams. At every
increment complexity was shaved off.
For example early designs called for a new service to co-ordinate the two
autolanders - the idea was for changes to register patches with the
coordinator, which gathered results and ensured patches landed in the correct
order across both repositories.
and here were are
After much discussion, especially around how best to manage backouts, we've
settled on the following plan.
When a change is requested to be landed through autoland the following will
happen:
The list of files modified is checked to determine if files in the servo/
directory are touched
If this is the case, the request is not landed by autoland, instead it notes
the gecko changes then sends a message to the servo-vcs-sync service
servo-vcs-sync creates a pull request on the servo/servo GitHub repository
Homu tests and lands the pull request as per the existing process
servo-vcs-sync is triggered by the changes to the GitHub repository
Any gecko changes are mixed into the commit before it is pushed to the
integration/autoland repository
Backouts:
A sheriff performs a normal backout on the integration/autoland repository
The mercurial server notifies servo-vcs-sync via pulse
servo-vcs-sync creates a pull request on the servo/servo GitHub repository
with the highest priority
Homu lands the PR before any other, including those in-flight
The change flows through to gecko via the normal GitHub → Mercurial flow
The following diagrams illustrate the flow of data across the systems.
Landing:
Backout:
I'm currently working on implementing this, which thus far mostly involves
shaving yaks.
Bugzilla comments are, by default, plain text – so typing <U> will produce less-than, U, greater-than rather than underlined text. However, Bugzilla will automatically make hyperlinks out of certain sorts of text in comments. For example, the text http://www.bugzilla.org will be turned into a link: http://www.bugzilla.org. Other strings which get linkified in the obvious manner are:
bug 12345
comment 7
bug 23456, comment 53
attachment 4321
mailto:george@example.com
george@example.com
ftp://ftp.mozilla.org
A corollary here is that if you type one or more bug numbers in a comment, you should put the word “bug” before each of them, so they gets autolinkified for the convenience of others.
But also, if you have some text you want linkified in this way, perhaps for use in a blog post, status report, wiki page or other place, you can use the handy linkifier, which will do exactly that for you.
Here’s a sampling of improvements to BMO that were launched in 2016.
Improvements to bug-modal
We’ve continued to refine the modal bug view, aka the “experimental UI”.
The BMO team fixed 39 bugs relating to the new interface in 2016.
We’ve got a couple more blockers before we make the modal view
the default, which should happen in the middle of January. We
know there are a still a few outstanding bugs and some missing
functionality, so we will leave the standard view available for a
little while, at least until all the blockers of bug 1273046 are
resolved. All future improvements to the bug view will happen only on
the modal UI, which is not just more usable but also more hackable.
HTML email
There was actually no real work involved here, as HTML email was added
to BMO years ago. At that time, since it was a new feature, we didn’t
enable it by default… and then 4 years went by. Just a couple weeks
ago a new BMO user suggested that we implement HTML emails, having no
idea that the option was already there (buried in many other
preferences). That was the prompting we needed to finally enable it
by default.
Readable bug statuses
Emma Humphries added readable statuses prominently displayed at
the top of the status panel (in the modal UI only). They quickly
summarize the status of a bug in a visible place, mainly for triaging
and tracking purposes.
One big change we made this year was hopefully completely invisible to
everyone: BMO’s database moved to UTC. When BMO was originally
deployed in 1998, the database, being based in California, was set to
Pacific Time. 6 years later someone suggested that UTC would be a
better choice. When I took over management of the BMO team about 4.5
years ago, I was pretty horrified that a major application would be
running in any time zone other than UTC, not in the least because of
the confusion caused by an hour being repeated every year when PDT
switched back to PST, since the presence or absence of DST is not
noted in the database. However, we were never able to justify
the required effort to move over to UTC, that is, until last year, as
we were setting up a failover system in AWS. RDS, the natural choice
for a MySQL-based application, supported only UTC, thus giving us a
hard requirement to migrate. A heroic effort by dkl got us smoothly
switched over in May 2016.
Memory-usage & perf improvements
We’ve known for some time that Bugzilla has a persistent memory leak.
It was never a huge issue because the webheads would automatically
restart Apache processes when their memory usage got too high, but it
is understandably something that lurks in the back of the minds of the
developers working on Bugzilla. Dylan finally got frustrated enough
to fix a big leak, which resulted in the webheads restarting much
less frequently, which in turn led to a performance increase. He’s
been investigating and fixing other such leaks when he finds the time.
Stuff we’re wrapping up in 2017
Some of the bigger projects bled over into 2017.
Content Security Policy
We’ve been working on implementing CSP in BMO, starting with the
new modal bug view. It was pretty hairy due to generated HTML, inline
JavaScript, and other old web-dev techniques that make security
harder. After some back and forth, we’re just about there; see
bug 1286290 for progress.
Note that CSP can break browser extensions. Since the modal UI is
relatively new, there are probably not too many extensions designed
for it; however, we’ll be spreading CSP over time. And of course,
we’ll be removing the old bug view at some point, which will
definitely break some things.
Elastic Quicksearch
In the spring, Dylan hacked up a prototype of a quicksearch
alternative powered by an Elasticsearch index. It’s lightning fast,
so we explored setting it up in production. Of course a prototype is
always easier than the real thing, and we had to do some structural
work to BMO to make it possible, although that in turn has had side
benefits. The indexing code is just about ready to roll out, and
while we’re verifying that it works correctly, we’ll be finishing up
the search code. You can also follow the main tracker bug for
the whole deployment.
New stuff in 2017
We’re expecting to wrap up the above features in Q1, and we’ve already
developed a road map for the first half of 2017 with some fun and
long-awaited features. Emma will be going over this in another post,
wearing her hat as BMO product manager, a job she has recently, and
graciously, taken on herself!
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:
dnf install bugzilla
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.
One of the first projects I worked on when I moved to the MozReview team was "review delegation". The goal was to add the ability for a reviewer to redirect a review request to someone else. It turned out to be a change that was much more complicated than expected.
MozReview is a Mozilla developed extension to the open source Review Board product; with the primary focus on working with changes as a series of commits instead of as a single unified diff. This requires more than just a Review Board extension, it also encompasses a review repository (where reviews are pushed to), as well as Mercurial and Git modules that drive the review publishing process. Autoland is also part of our ecosystem, with work started on adding static analysis (eg. linters) and other automation to improve the code review workflow.
I inherited the bug with a patch that had undergone a single review. The patch worked by exposing the reviewers edit field to all users, and modifying the review request once the update was OK'd. This is mostly the correct approach, however it had two major issues:
According to Review Board and Bugzilla, the change was always made by the review's submitter, not the person who actually made the change
Unlike other changes made in Review Board, the review request was updated immediately instead of using a draft which could then be published or discarded
Permissions
Review Board has a simple permissions model - the review request's submitter (aka patch author) can make any change, while the reviewers can pretty much only comment, raise issues, and mark a review as "ready to ship" / "fix it". As you would expect, there are checks within the object layer to ensure that these permission boundaries are not overstepped. Review Board's extension system allows for custom authorisation and permissions check, however the granularity of these are course: you can only control if a user can edit a review request as a whole, not on a per-field level.
In order to allow the reviewer list to be changed, we need to tell Review Board that the submitter was making the change.
Performing the actions as the submitter instead of the authenticated user is easy enough, however when the changes were pushed to Bugzilla they were attributed to the wrong user. After a few false starts, I settled on storing the authenticated user in the request's meta data, performing the changes as the submitter, and updating the routines that touch Bugzilla to first check for a stored user and make changes as that user instead of the submitter. Essentially "su".
This worked well except for on the page where the meta data changes are displayed - here the change was incorrectly attributed to the review submitter. Remember that under Review Board's permissions model only the review submitter can make these changes, so the name and gravatar were hard-coded in the django template to use the submitter. Given the constraints a Review Board extension has to operate in, this was a problem, and developing a full audit trail for Review Board would be too time consuming and invasive. The solution I went with was simple: hide the name and gravatar using CSS.
Drafts and Publishing
How Review Board works is, when you make a change, a draft is (almost) always created which you can then publish or discard. Under the hood this involves duplicating the review request into a draft object, against which modifications are made. A review request can only have one draft, which isn't a problem because only the submitter can change the review.
Of course for reviewer delegation to work we needed a draft for each user. Tricky.
The fix ended up needing to take a different approach depending on if the submitter was making the change or not.
When the review submitter updates the reviewers, the normal review board draft is used, with a few tweaks that show the draft banner when viewing any revision in the series instead of just the one that was changed. This allows us to correctly cope with situations where the submitter makes changes that are broader than just the reviewers, such as pushing a revised patch, or attaching a screenshot.
When anyone else updates the reviewers, a "draft" is created in local storage in their browser, and a fake draft banner is displayed. Publishing from this fake draft banner calls the API endpoint that performs the permissions shenanigans mentioned earlier.
Overall it has been an interesting journey into how Review Board works, and highlighted some of the complications MozReview hits when we need to work against Review Board's design. We've been working with the Review Board team to ease some of these issues, as well as deviating where required to deliver a Mozilla-focused user experience.
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 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).
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.
when a comment is left on a review in review board/mozreview it is currently displayed as a small square in the left column.
our top reviewers have strongly indicated that this is suboptimal and would prefer to match what most other code review systems do in displaying comments as an inline block on the diff. i agree — review comments are important and deserve more attention in the user interface; they should be impossible to miss.
while the upstream review board team have long said that the current display is in need of fixing, there is minimal love for the inline comments approach.
recently we worked on a plan of attack to appease both our reviewers and upstream's requirements. :smacleod, :mconley and i talked through a wide assortment of design goals and potential issues. we have a design document and i've started mocking up the approach in html:
we also kicked off discussions with the upstream review board development team, and are hopeful that this is a feature that will be accepted upstream.
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.
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!
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.
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:
for the next couple of quarters (at least) i'll be shifting my attention full time from bugzilla to mozreview. this switch involves a change of language, frameworks, and of course teams. i'm looking forward to new challenges.
one of the first things i've done is sketch out a high level architectural diagram of mozreview and its prime dependencies:
mozreview exists as an extension to reviewboard, using bugzilla for user authentication, ldap to check commit levels, with autoland pushing commits automatically to try (and to mozilla-central soon). there's mecurial extensions on both the client and server to make pushing things easer, and there are plans to perform static analysis with bots.
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:
The recent release of Bugzilla 5.0 was the first release sporting the new, improved Bugzilla documentation, which has been moved from DocBook XML to reStructuredText to make it easier to edit and so more likely to be up-to-date :-).
Readers of this blog may be particularly interested in the User Guide. Feedback on the new docs is welcome, particularly suggestions for where it is lacking – please use the bug filing link at the bottom of each docs page.
For the past few months, a new experimental modal bug view has been available on bugzilla.mozilla.org. This hides a lot of complexity both through being read-only initially, and also through having expandable and collapsible sections. It is also quicker and less resource-intensive to load. It requires you to click an “Edit” button, which reveals much more UI, when you want to do more than the common operations – add a comment, CC/NI people, or change the Status or Resolution. It is also more dynamic – for example, there are no more interstital pages when moving bugs between Products, because when you change the Product, the new lists of Components, Milestones etc. load into the widgets automatically.
A picture is worth a thousand words. Here’s the initial view:
And here’s the Edit view:
You can enable it in the Preferences – change “Use experimental user interface” to “On”.
Thanks to glob for doing the hard work on making this happen. This view has not yet made it upstream to Bugzilla itself.
As discussed on the Bugzilla developers mailing list/newsgroup and confirmed by project leads, Bugzilla’s new release policy is to end-of-life the oldest supported major version four months after a new major release. Since this is the first time we’re enacting this policy, we’ve extended the date to be 4 months from today rather than from Bugzilla 5.0’s exact release date (July 7th).
Thus Bugzilla 4.2 will be end-of-lifed on 30 November 2015. This means no fixes of any kind will be issued for Bugzilla 4.2 from that date onwards. As usual, all Bugzilla admins are encouraged to upgrade to the latest version of Bugzilla as soon as possible, especially those running 4.2 or earlier.
To expand a bit further on our new EOL process, after a new major release, we will support three major releases (including the new one) for four months. After four months, we will drop support for the oldest one. We will continue to support the remaining two until four months after the next release.
For example, currently we support 4.2, 4.4, and 5.0. In four months’ time we will drop support for 4.2 and support only 4.4 and 5.0. When the next major version comes out, perhaps 5.2*, we will support 4.4, 5.0, and 5.2. Four months later, we will drop support for 4.4 and support only 5.0 and 5.2.
Mark Côté
Assistant Project Lead, Bugzilla
* It may be 6.0 if there are major and/or breaking changes.
Today the Bugzilla Project is extremely proud to announce the release of Bugzilla 5.0!
It has been slightly over two years since we released Bugzilla 4.4 on May 2013. This new major release comes with many new features and improvements to WebServices and performance.
We hope that you enjoy and appreciate the results of the past two years of hard work by our entirely-volunteer community.
Please note that the release of Bugzilla 5.0 also marks End Of Life for the Bugzilla 4.0 series, meaning that there will be no further updates for the 4.0.x series, even if there are serious security
issues found in that series. We recommend that all installations running the 4.0 series upgrade as soon as possible to 5.0.
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.
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.
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.
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.
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.
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.
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).
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.
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 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.
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!
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.
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.
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.
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.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.
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.)
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:
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:
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:
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.
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.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.
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.
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.
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.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.
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.
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.
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.
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:
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.
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.
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.
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.
[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 gerv@mozilla.org, 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 bugzilla-id@example.com
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.
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.
[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.
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.
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.
“If you do a lot of quick searches to find bugs by summary and you don’t care about also looking into the comments of those bugs, flip the “Include comments when performing quick searches (slower)” to NO in your preferences.
A search for ‘radio antenna’ just went down from 30+ seconds to just a few seconds.”
“Bugzilla actually does have HTML emails! [As of version 4.2, but it’s been backported to bugzilla.mozilla.org’s 4.0 installation – Ed.] I always though that it did not because I did not look further than the “Email Preferences” tab. But there actually is a “Preferred email format” under the “General Preferences” tab.
This makes Bugzilla emails 100x easier to read on a phone.”
I am proud to announce the release of version 1.2 of the Bugzilla REST API. This maintenance release has a bug fix or two, and some features useful to the admins of Bugzillas which BzAPI is pointed at.
The installation of BzAPI 1.0 on api-dev.bugzilla.mozilla.org will go away in 4 weeks, on 19th December. 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. Please use either the /1.2 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.
You can do this – unless, that is, you are a member of certain particularly sensitive groups. While Mozilla has great confidence in the BrowserID technology, it does not have perfect confidence in my coding ;-) Therefore, we are restricting who can log in until we get a little more experience with my extension. Eventually, it’s possible that we might go the other way and require BrowserID for certain sensitive groups, once BrowserID primaries appear with 2-factor authentication. But that’s a little way off yet.
If you visit your permissions page, you can see if you should be able to log in using BrowserID. If you are listed as a member of the “no-browser-id” group, you shouldn’t. Otherwise, you should. The no-browser-id group is currently made up of members of the following groups: admin, bz_sudoers, autoland, generic-assignees, hr, infrasec, legal, and anything with “security” in its name.
I know of some software, and it has documentation. I want to be able to maintain this documentation, for the general good of its userbase. At the moment, its documentation is XML files in a VCS, with their own special build procedure with prerequisites. That makes them hard to modify, and as a consequence they are often out of date and certainly not as good as they could be.
Requirement A): I’d like the documentation to be web-editable, because that makes it really easy for anyone to edit quickly, which makes it much more likely the documentation will actually be up-to-date. I want the URL for the “latest version” to always be the same URL.
Requirement B): My software has multiple versions. Once I release a version, I’d like to keep a copy of the documentation in the state that it applies to that version. It may not change much again, but needs to be able to accept bug fixes. However, trunk documentation development must continue. In other words, I need to be able to branch the documentation, check in independently to each branch, and give people URLs to either a branch or the trunk. Each version should have a URL containing the software version number.
Is there any software out there, ideally already in use by the Mozilla project, which can meet both A) and B)? A) is met by all wiki software. B) is met by all version control software. But I haven’t found wiki software with the concept of branches, and I haven’t found a VCS which can display documents prettily and has a web-based interface for editing.
RPMFusion's Bugzilla has gathered a number of bugs over the years and, for
lack of maintainance, bugs filed against EOL-ed versions of Fedora have never
been closed. The result is a number of open bugs:
I've added a new resolution, EXPIRED, in
bugzilla.rpmfusion.org and I'll be using it over the next few weeks to close
bugs filed against Fedora 8 through 14. Once a week, I'll be taking one
version's bugs and closing them with the EXPIRED resolution
and adding a comment on the next version's bugs warning that they will be
closed a week later. Once we're done with those, it will probably be time to do
the same thing to the Fedora 15 bugs. At that point, we'll probably join the
Fedora bug triage cycle, doing this every 6 months.
(If you have tips to share on using Bugzilla, please email them to gerv@mozilla.org.)
Mozilla’s Bugzilla now has a left-click menu whenever you see a user displayed. You can email the user (which was the previous left-click action, or see what they’ve been up to in Bugzilla recently on the Activity screen. Administrators can also jump straight to editing that user’s account.
I recently did up a diagram of how our Bugzilla site was set up, mostly for the benefit of other sysadmins trying to find the various pieces of it. Several folks expressed interest in sharing it with the community just to show an example of how we were set up. So I cleaned it up a little, and here it is:
Click the image for a full-size (readable) version
At first glance it looks somewhat excessive just for a Bugzilla, but since the Mozilla Project lives and dies by the content of this site, all work pretty much stops if it doesn’t work, so it’s one of our highest-priority sites to keep operating at all times for developer support. The actual hardware required to run the site at full capacity for the amount of users we get hitting it is a little less than half of what’s shown in the diagram.
We have the entire site set up in two different datacenters (SJC1 is our San Jose datacenter, PHX1 is our Phoenix datacenter). Thanks to the load balancers taking care of the cross-datacenter connections for the master databases, it’s actually possible to run it from both sites concurrently to split the load. But because of the amount of traffic Bugzilla does to the master databases, and the latency in connection setup over that distance, it’s a little bit slow from whichever datacenter isn’t currently hosting the master, so we’ve been trying to keep DNS pointed at just one of them to keep it speedy.
This still works great as a hot failover, though, which got tested in action this last Sunday when we had a system board failure on the master database server in Phoenix. Failing the entire site over to San Jose took only minutes, and the tech from HP showed up to swap the system board 4 hours later. The fun part was that I had only finished setting up this hot failover setup about a week prior, so the timing couldn’t have been any better for that system board failure. If it had happened any sooner we might have been down for a long time waiting for the server to get fixed.
When everything is operational, we’re trying to keep it primarily hosted in Phoenix. As you can see in the diagram, the database servers in Phoenix are using solid-state disks for the database storage. The speed improvement when running large queries that is gained by using these instead of traditional spinning disks is just amazing. I haven’t done any actual timing to get hard facts on that, but the difference is large enough that you can easily notice it just from using the site.
Bugzilla 4.0 has frozen and soon it will be released. There are a bunch of exciting changes that you can expect which I will try to highlight over the next few posts. The big ones that I'm sure will get a lot of attention, for better or worse, are:
the autocompletes for user fields and keywords
redesigned advanced search page
the redesigned attachments page.
create page validation
We've also got a patch in the works that will redo the homepage and make it much prettier and professional looking thanks to Jon Pink. You can also look forward to that in 4.0!
I've attached images of the 3 new pages which will hopefully encourage you all to play around with landfill!
As always we'd love to hear your feedback about this and the other changes that are coming in 4.0 (there are a lot of them, jsonp, better extension support, new default workflow, more webservices... it's a long list).
There are 2 bugs which I have been paying some attention to recently.
The first one is Bug 222861 which requests that images are displayed when they are mentioned in comments. This bug was important to me because I often found myself and others referring to images and attachments in comments and then having to open them up in a new window. I really wanted developers to just see the mocks i made along with my comments about them. It was determined that this bug makes more sense as an extension. So I wrote one. I've posted it here: http://github.com/pyrzak/Bugzilla-Extension--Inline-Images. Hopefully you guys like it!
The second one is Bug 395802 which requests to be able to support gravatar images. This is something Aza Raskin specifically mentioned by saying make it easier to know "who is this guy". Step 1 is adding a human face to a comment via the gravatar, Step 2 might be about grabbing their stats.
There were 2 mocks that I made as suggestions for how this should look. The first is:
Here is the other mock:
My hope is that we're finally to the point where many of Aza's and other's ideas might be possible thanks to the new extension system and the jsonp bug 550727. Both of which wouldn't be possible if mkanat didn't work so hard to add this kind of mash-up and extensibility, so thanks!
Any feedback about either of these extensions or anything else I mentioned is very welcomed.
There were some comments today about the attachments page and how wonky it is. Bug 101770has become the place where I've decided to post a response and possible solution to the problem but since I'm sure folks don't want to bother going to the bug here are the images that I posted. Let me know what you think. My hope is that we'll be able to implement this new UI quickly and make a big improvement without making anyone too upset about losing the current Attachments UI.
Things to note. The comments box and the attachment iframe would be elastic so they would grow with the width of the page. Clicking edit attachment as comment would cause the comment box to go away and the big area would turn into a comment.
My hope for this layout is to 1 give more realestate to the comment box that is equal to the area on the current bug page as well as make it easier for people editing the patches directly to have more room.
This UI also puts the focus where it belongs, on the attachment itself.
Things to note. I'm not at all happy with the placement of the patch and obsolete checkboxes. Any suggestions on where those should go is greatly appreciated.
I already posted how you can use YUI to use the Bugzilla web services available on the head. But lots of people don't like using YUI and prefer using JQuery. I haven't used JQuery much, but this experiment seems to have gotten the job done and should supply a basis for how to do more complex stuff with JQuery and the JSON-RPC interface.
Please note the JSON serialization capability isn't part of JQuery so I used a plug-in. The plugin doesn't seem to be as powerful as YUI's JSON serialization, but maybe it is and I haven't explored it enough. Anyway, here goes!
First you'll need JQuery and the JSON serialization parser. I added it under YUI but you should be able to add it before or after the YUI in the header.
Just like in YUI we need to make sure we set the contentType to application/json and use a post (get is still disabled due to cross site scripting concerns). I set the dataType to JSON so Jquery would deserialize the response for me.
And now we've got a basic JSON-RPC message being sent. Now we'll still need to handle errors etc, but for now this is enough to get any eager JavaScript developer going.
Another example is getting bug info which might be equally helpful is available below. This method gets information about 2 bugs. I'm not going to explain it as much but it follows the same pattern.
The hope is eventually to release some JavaScript plugins for YUI (2 and 3) and JQuery that will make this sort of stuff much easier, like handle the serialization, and errors. But for now these examples will have to do.
For a while we've been having discussions about tags and Bugzilla on the dev mailing list. To boil down a lot of the suggestion it consists of "we could do away with most of our fields/flags and replace them with tags, it would make the UI way better".
We've also had other discussions about how the bug edit page should change. Many of the suggestions consist of moving the non-comment data about a bug to the left or right side of the page and letting the comments take up most of the page.
Today (for the first time) i went into the code.google.com (cgc) bug tracker to see what the status of tagging was in chrome. Turns out both of these UI suggestions are exactly how chrome is implemented. I event went to the advanced search page to see if the suggestions i received from the advanced search page were the same (they weren't).
Anyway, i've received the message loud and clear "we like how google did it".
I'm tempted to make a jetpack that makes the BMO UI act/look a lot more like cgc. What do you guys think? Is it worth it or is TidyBug more the direction people prefer?
If you haven't seen cgc here is the URL i looked at today: http://code.google.com/p/chromium/issues/detail?id=17536
So I saw the post for TidyBug and noticed someone commented that they switched back to Greasemonkey from Jetpack. I really like the idea of Jetpack, so i was bummed to see that someone had switch away from it because they wanted this feature so... I tried copying some of the features of tidyBug over to Jetpack.
Here is the URL for the jetpack in the gallery: http://jetpackgallery.mozillalabs.com/jetpacks/346
and an image to see what it does to the edit page...
For those of you who are not familiar with tidy bug here is the original post: http://www.squarefree.com/2009/02/26/tidybug/
I'm still working on moving over all the features (like keyboard shortcuts). But the minimizing (what seems to be the best part) is part of this. Plus this version works with ANY version of Bugzilla running 3.4 onward, not just BMO.
For those using Chrome I might try to port this over as a chrome extension next weekend.
I'll also try using jetpack to prototype some other desired features, like prototyping the quicksearch helper mentioned in my previous post.
We've been working on fixes from our usability research and surveys. With the recent post of Bugzilla for Humanity, I was inspired to work on the Advanced Search UI because as Johnathan put it, "it is complete and terrible" and for "99% of searches you don't need it". However the other search, the simple search he doesn't bother to mention and of course he <3's quicksearch. I've filed bug 544404 to help quicksearch magic become more discoverable.
So the solution to make the advanced search page less complicated is a multi-parter as always in the Bugzilla world. Here are the steps which may or may not happen in the order they appear.
Step 1. Make the big summary box at the top of the page use quicksearch instead of a summary search.
Step 2. Make the other boxes on the advanced search page work as a helper to the quicksearch
Step 3. Make the advanced search page less complicated.
1 and 2 are more or less out of my area expertise so I'll leave those to mkanat and jjclark. But making the advanced search page less complicated, I can help with.
The approach I took was inspired by the redesign we did at work, basically apply a grid and hide the stuff that doesn't matter most of the time.
I've posted mocks up on bug 450301 but since I'm sure no one wants to read through the bug I'll post the images here:
We’re finally at the point where I can say we’re ready to upgrade Bugzilla @ Mozilla this weekend. We’re aiming for Sunday evening (probably 6pm PST). I’ll post again when I know how long it’ll be down for (and that’ll be included in the eventual downtime notice on the IT blog as well).
There’s a staging copy set up at https://bugzilla-stage-tip.mozilla.org/ and I would appreciate people playing around with it and finding anything that might be broken before we get it to production. Before filing bugs, make sure to check the detailed status linked from the red box at the top of every page to make sure it’s not already listed (and you can also see my progress on cosmetic issues and so forth, there).
It will be down for a while at some point tonight when I reload it with an up-to-date snapshot of the production server (and that’ll be my test to find out how long it’ll take to upgrade it, too). I’m super excited because this has been a long time coming.
