Tag: mozilla

Captain's log, stardate 2016-10-26

Posted on by Liz

Once again I resolve to write about my work at Mozilla as a Firefox release manager. It’s hard to do, because even the smallest thing could fill LONG paragraphs with many links! Since I keep daily notes on what I work on, let me try translating that in brief. When moved, maybe I’ll go into depth.

This week we are coming into the home stretch of a 7 week release cycle. “My” release for right now is Firefox 49, which was released on I’m still juggling problems and responses and triaging for that every day. In a week and a half, we were scheduled to release Firefox 50. Today after some discussion we pushed back that schedule by a week.

Meanwhile, I am also helping a new release manager (Gerry) to go through tracked bugs, new regressions, top crash reports, and uplift requests for Aurora/Developer Edition (Firefox 51). I’m going through uplift requests for Firefox 45.5.0esr, the extended support release. There’s still more – I paid some attention to our “update orphaning” project to bring users stuck on older versions of Firefox forward to the current, better and safer versions.

As usual, this means talking to developers and managers across pretty much all the teams at Mozilla, so it is never boring. Our goal is to get fixes and improvements as fast as possible while making sure, as best we can, that those fixes aren’t causing worse problems. We also have the interesting challenges of working across many time zones around the world.

Firefox stuffed animal installed

Today I had a brief 1:1 meeting with my manager and went to the Firefox Product cross-functional meeting. I always find useful as it brings together many teams. There was a long Firefox team all hands discussion and then I skipped going to another hour long triage meeting with the platform/firefox engineering managers. Whew! We had a lively discussion over the last couple of days about a performance regression (Bug 1304434). The issues are complicated to sort out. Everyone involved is super smart and the discussions have a collegiate quality. No one is “yelling at each other”, while we regularly challenge each other’s assumptions and are free to disagree – usually in public view on a mailing list or in our bug tracker. This is part of why I really love Mozilla. While we can get a bit heated and stressed, overall, the culture is good. YMMV of course.

By that time (11am) I had been working since 7:30am, setting many queries in bugs, and on IRC, and in emails into motion and made a lot of small but oddly difficult decisions. Often this meant exercising my wontfix powers on bugs — deferring uplift (aka “backport” ) to 50, 51, or leaving a fix in 52 to ride the trains to release some time next year. As I’m feeling pretty good I headed out to have lunch and work from a cafe downtown (Mazarine – the turkey salad sandwich was very good!)

This afternoon I’m focusing on ESR 45, and Aurora 51, doing a bit more bug triage. There are a couple of ESR uplifts stressing me out — seriously, I was having kittens over these patches — but now that we have an extra week until we release, it feels like a better position for asking for a 2nd code review, a bit more time for QA, and so on.

Heading out soon for drinks with friends across the street from this cafe, and then to the Internet Archive’s 20th anniversary party. Yay, Internet Archive!

A useful Bugzilla trick

Posted on by Liz

At the beginning of February I changed teams within Mozilla and am now working as a release manager. It follows naturally from a lot of the work I’ve already been doing at Mozilla and I’m excited to join the team working with Lukas, Lawrence, and Sylvestre!

I just learned a cool trick for dealing with several bugzilla.mozilla.org bugs at once, on MacOS X.

1) Install Bugzilla Services.

2) Add a keyboard shortcut as Alex Keybl describes in the blog post above. (I am using Control-Command-B)

3) Install the Tree Style Tab addon.

Now, from any text, whether in email, a desktop text file, or anywhere in the browser, I can highlight a bunch of text and bug number will be parsed out of the text. For example, from an email this morning:

Bug 1137050 - Startup up Crash - patch should land soon, potentially risky
David Major seems to think it is risky for the release.

Besides that, we are going to take:
Bug 1137469 - Loop exception - patch waiting for review
Bug 1136855 - print preferences - patch approved
Bug 1137141 - Fx account + hello - patch waiting for review
Bug 1136300 - Hello + share buttons - Mike  De Boer will work on a patch today

And maybe a fix for the ANY query (bug 1093983) if we have one...

I highlighted the entire email and hit the “open in bugzilla” keystroke. This resulted in a Bugzilla list view for the 6 bugs mentioned in the email.

Bugzilla list view example

With BugzillaJS installed, I have an extra option at the bottom of the page, “Open All in Tabs”, so if I wanted to triage these bugs, I can open them all at once. The tabs show up in my sidebar, indented from their parent tab. This is handy if I want to collapse this group of tabs, or close the parent tab and all its children at once (The original list view of these 6 bugs, and each of its individual tabs.) Tree Style Tab is my new favorite thing!

Tree style tabs bugzilla

In this case, after I had read each bug from this morning and closed the tabs, my coworker Sylvestre asked me to make sure I cc-ed myself into all of them to keep an eye on them later today and over the weekend so that when fixes are checked in, I can approve them for release.

Here I did not want to open up every bug in its own tab but instead went for “Change Several Bugs at Once” which is also at the bottom of the page.

Bugzilla batch edit

This batch edit view of bugs is a bit scarily powerful since it will result in bugmail to many people for each bug’s changes. When you need it, it’s a great feature. I added myself to the cc: field all in one swoop instead of having to click each tab open, click around several times in each bug to add myself and save and close the tab again.

It was a busy day yesterday at work but I had a nice time working from the office rather than at home. Here is the view from the SF Mozilla office 7th floor deck where I was working and eating cake in the sun. Cannot complain about life, really.
Mozilla bridge view

Running mochitests for Firefox

Posted on by Liz

I’m experimenting with automated testing for Firefox and figured it may be useful to record what I learned. I had a look at the Mochitest page on MDN as well as the main page on Automated testing at Mozilla. It is hard to know how to even begin to explain this. Mochitests are a huge ball of tests for Firefox. They run every time a change is pushed to mozilla-central, which is the sort of tip of the current state of our code and is used every day to build the Nightly version of Firefox. They’re run automatically for changes on other code repositories too. And, you can run them locally on your own version of Firefox.

This is going to have ridiculous levels of detail and jargon. Warning!

The first thing to do is to download the current code from mozilla-central and build it on my laptop. Here are the Firefox build instructions!

As usual I need to do several other things before I can do those things. This means hours of twiddling around on the command line, installing things, trying different configurations, fixing directory permissions and so on. Here are a few of the sometimes non-trivial things I ended up doing:

* updated Xcode and command line tools
* ran brew doctor and brew update, fixed all errors with much help from Stack Overflow, ended up doing a hard reset of brew
* Also, if you need to install a specific version of a utility, for example, autoconf: brew tap homebrew/versions; brew install autoconf213
* re-installed mercurial and git since they were screwed up somehow from a move from one Mac to another
* tried two different sample .mozconfig files, read through other Mac build config files, several layers deep (very confusing)
* updating my Firefox mozilla-central directory (hg pull -u)
* filed a bug for a build error and fixed some minor points on MDN

The build takes around an hour the first time. After that, pulling the changes from mozilla-central and reticulating the splines takes much less time.

Firefox build

Now I’m to the point where I can have a little routine every morning:
* brew doctor
* brew upgrade
* cd mozilla-central, hg pull -u
* ./mach build

Then I’m set up to run tests. Running all the mochitest-plain tests takes a long time. Running a single test may fail because it has dependencies on other tests it expects to have run first. You can also run all the tests in a particular directory, which may work out better than single tests.

Here is an example of running a single test.

./mach mochitest-browser browser/base/content/test/general/browser_aboutHome.js

Your Nightly or Nightly-debug browser will open and run through some tests. There will be a ton of output. Nifty.

Here is that same test, run with e10s enabled.

./mach mochitest-browser —e10s browser/base/content/test/general/browser_aboutHome.js

BTW if you add “2>&1 | tee -a test.log” to those commands they will pipe the output into a log file.

Back to testing. I poked around to see if I could find a super easy to understand test. The first few, I read through the test code, the associated bugs, and some other stuff. A bit overwhelming. My coworker Juan and I then talked to Joel Maher who walked us through some of the details of how mochitests work and are organized. The tests are scattered throughout the “tree” of directories in the code repository. It is useful generally to use DXR to search but I also ended up just bouncing around and getting familiar with some of the structure of where things are. For example, scarily, I now know my way to testing/mochitest/tests/SimpleTest/. Just by trying different things and looking around you start to get familiar.

Meanwhile, my goal was still to find something easy enough to grasp in an afternoon and run through as much of the process to fix a simple bug as I could manage. I looked around for tests that are known not to work under e10s, and are marked in manifest files that they should be skipped if you’re testing with e10s on. I tried turning some of these tests on and off and reading through their bugs.

Also meanwhile I asked for commit access level 1 (for the try server) so when I start changing and fixing things I can at least throw them at a remote test server as well as my own local environment’s tests.

Then, hurray, Joel lobbed me a very easy test bug.

From reading his description and looking at the html file it links to, I got that I could try this test, but it might not fail. The failure was caused by god knows what other test. Here is how to try it on its own:

./mach mochitest-chrome browser/devtools/webide/test/test_zoom.html

I could see the test open up Nightly-debug and then try to zoom in and out. Joel had also described how the test opens a window, zooms, closes the window, then opens another window, zooms, but doesn’t close. I have not really looked at any JavaScript for several years and it was never my bag. But I can fake it. Hurray, this really is the simplest possible example. Not like the 600-line things I was ending up in at random. Danny looked at the test with me and walked through the JavaScript a bit. If you look at the test file, it is first loading up the SimpleTest harness and some other stuff. I did not really read through the other stuff. *handwave* Then in the main script, it says that when the window is loaded, first off wait till we really know SimpleTest is done because the script tells us so (Maybe in opposition to something like timing out.) Then a function opens the WebIDE interface, and (this is the main bit Danny explained) the viewer= winQuerInterface etc. bit is an object that shows you the state of the viewer. *more handwaving, I do not need to know* More handwaving about “yield” but I get the idea it is giving control over partly to the test window and partly keeping it. Then it zooms in a few times, then this bit is actually the meat of the test:

 is(roundZoom, 0.6, "Reach min zoom");

Which is calling the “is” function in SimpleTest.js, Which I had already been reading, and so going back to it to think about what “is” was doing was useful. Way back several paragraphs ago I mentioned looking in testing/mochitest/tests/SimpleTest/. That is where this function lives. I also felt I did not entirely need to know the details of what the min and max zoom should be. Then, we close the window. Then open a new one. Now we see the other point of this test. We are checking to see that when you open a WebIDE window, then zoom to some zoomy state, then close the window, then re-open it, it should stay zoomed in or out to the state you left it in.

OK, now at this point I need to generate a patch with my tiny one line change. I went back to MDN to check how to do this in whatever way is Mozilla style. Ended up at How to Submit a Patch, then at How can I generate a patch for somebody else to check in for me?, and then messing about with mq which is I guess like Quilt. (Quilt is a nice name, but, welcome to hell.) I ended up feeling somewhat unnerved by mq and unsure of what it was doing. mq, or qnew, did not offer me a way to put a commit message onto my patch. After a lot of googling… not sure where I even found the answer to this, but after popping and then re-pushing and flailing some more, and my boyfriend watching over my shoulder and screeching “You’re going to RUIN IT ALL” (and desperately quoting Kent Beck at me) as I threatened to hand-edit the patch file, here is how I added a commit message:

hg qrefresh -m "Bug 1116802: closes the WebIDE a second time"

Should I keep using mq? Why add another layer into mercurial? Worth it?

To make sure my patch didn’t cause something shocking to happen (It was just one line and very simple, but, famous last words….) I ran the chrome tests that were in the same directory as my buggy test. (Piping the output into a log file and then looked for anything that mentioned test_zoom. ) The test output is a study in itself but not my focus right now as long as nothing says FAIL.

./mach mochitest-chrome browser/devtools/webide/test/

Then I exported the patch still using mq commands which I cannot feel entirely sure of.

 hg export qtip > ~/bug-1116802-fix.patch

That looked fine and, yay, had my commit message. I attached it to the bug and asked Joel to have a look.

I still don’t have a way to make the test fail but it seems logical you would want to close the window.

That is a lot of setup to get to the point where I could make a useful one line change in a file! I feel very satisfied that I got to that point.

Only 30,000 more tests to go, many of which are probably out of date. As I contemplate the giant mass of tests I wonder how many of them are useful and what the maintenance cost is and how to ever keep up or straighten them out. It’s very interesting!

You can have a look at the complicated nature of the automated tests that run constantly to test Firefox at treeherder. For any batch of commits merged into mozilla-central, huge numbers of tests run on many different platforms. If you look at treeherder you can see a little (hopefully green) “dt” among the tests. I think that the zooming in WebIDE test that I just described is in the dt batch of tests (but I am not sure yet).

I hope describing the process of learning about this small part of Firefox’s test framework is useful to someone! I have always felt that I missed out by not having a college level background in CS or deep expertise in any particular language. And yet I have still been a developer on and off for the last 20 years and can jump back into the pool and figure stuff out. No genius badge necessary. I hope you can see that actually writing code is only one part of working in this kind of huge, collaborative environment. The main skill you need (like I keep saying) is the ability not to freak out about what you don’t know, and keep on playing around, while reading and learning and talking with people.

How to test new features in Firefox 34 Aurora

Posted on by Liz

If you’re a fan of free and open source software and would like to contribute to Firefox, join me for some Firefox feature testing!

There are some nifty features under development right now for Firefox 34 including translation in the browser, making voice or video calls (a feature called “Hello” or “Loop”), debugging information for web developers in the Dev Tools Inspector, and recent improvements to HTML5 gaming.

I’ve written step by step instructions on these
ways to test Firefox 34. If you would like to see what it’s like to improve a popular open source project, trying out these tasks is a good introduction.

Aurora

First, Install the Aurora version of Firefox. It is best to set it up to use multiple profiles. That ensures you don’t use your everyday version of Firefox for testing, so you won’t risk losing your usual profile information. It also makes it easy to restart Firefox with a new, clean profile with all the default settings, very useful for testing. Sometimes I realize I’m running 5 different versions of Firefox at once!

To test “Hello”, try making some voice or video calls from Firefox Aurora. You will need a friend to test with. Or, use two computers that you control. This is a good task to try while joining our chat channels, #qa or #testday on irc.mozilla.org; ask if anyone there wants to test Hello with you. The goal here is mostly to find and report new bugs.

If you test the translation infobar in Aurora you may find some new bugs. This is a fun feature to test. I like trying it on Wikipedia in many different languages, and also looking at newspapers!

If you’re a web developer, you may use Developer Tools in Firefox. I’m asking Aurora users to go through some unconfirmed bug reports, to help improve the Developer Tools Inspector.

If you like games you can test HTML5 web-based games in Firefox Aurora. This helps us improve Firefox and also helps the independent game developers. We have a list of demo games so you can play them, report glitches, and feel like a virtuous open source citizen all at once. Along the way you have opportunities to learn some interesting stuff about how graphics on the web can work (or not work).

Monster madness

These testing tasks are all set up in One and Done, Mozilla QA’s site to start people along the path to joining our open source community. This site was developed with a lot of community contribution including the design and concept by long-time community member Parul and a lot of code by two interns this summer, Pankaj and Maja.

Testing gives a great view into the development process for people who may not (yet) be programmers. I especially love how transparent Mozilla’s process can be. Anyone can report a bug, visible to the entire world in bugzilla.mozilla.org. There are many people watching that incoming stream of bug reports, confirming them and routing them to developer teams, sometimes tagging them as good first bugs for new contributors. Developers who may or may not be Mozilla employees show up in the bugs, like magic . . . if you think of bugmail notifications as magic . . .

It is amazing to see this very public and somewhat anarchic collaboration process at work. Of course, it can also be extremely satisfying to see a bug you discovered and reported, your pet bug, finally get fixed.

Mozilla's bug reporting, QA, and release processes

Posted on by Liz

AdaCamp Portland was an amazing conference for feminist women in open source tech and culture. Not all, but many of the conference attendees are developers, system administrators, or do other technical work in open source software. I gave an informal talk meant to be an overview of some things I currently do at Mozilla. Lots of people came to the session! We all introduced ourselves going around the room.

To start off with, I showed a sample bug to talk about the process of reporting a bug, using Bugzilla, and practicing the skill of reading and understanding a bug report.

We looked first at Bug 926292.

Bugzilla couple

Let’s look at the life of this bug!

This bug was reported in October 2013 for Firefox 24 by someone new to bugzilla.mozilla.org. New users have basic permissions to file and comment on bugs. For around their first 25 bugs filed or commented on, they are marked “New to Bugzilla” to anyone with more permissions on the system. This helps more experienced users to know when they’re in conversation with people who are relatively new to the system. And, bugs reported by new users are automatically entered into Bugzilla with a status of “UNCONFIRMED”.

Our bug reporter was answered the same day by a community bug triager who used the “needinfo” checkbox to ask the bug reporter more questions. A bit later, in Comment 2, I was able to confirm the bug; I marked it NEW. Community members often jump in to do this from Bug Triage bug days, from our One and Done community taskboard, or because they watch the “Firefox::Untriaged” component. (Yes . . . you too can sign up to get email from Bugzilla every time a new bug is filed!)

Francesca Ciceri is currently working on bug triage and verification with our team as part of the GNOME-OPW internship program, doing similiar work to Tiziana Selitto who was an OPW intern last year! Both their blogs have good insights into what it’s like to approach QA in a huge and somewhat chaotic system like Mozilla’s.

In our example bug, I took a guess as to which product and component to add to the bug. This is like putting the bug into the right place where developers who work in a particular area will be likely to see it, and pay attention to it. I moved it from “Firefox” to “Core” and thought it may be something to do with the CSS Object Model. Picking the right product and component is tricky. Sometimes I look for similar bugs, to see what component they’re in. Sometimes I use Bugzilla’s Browse pages to skim or search through the descriptions of components for Firefox, Core, and Toolkit. Even after doing this for a year and a half, I get it wrong. Here, a developer moved the bug to what he thought was a better component for it, Core::Layout. (Developers also sometimes guess wrong, and keep passing a bug around to each others’ components like a hot potato.)

At this point a few developers explored the bug, and went back and forth with each other and the bug reporter about whether it had been fixed or not, exactly what the bug was, whether it is a Mac issue or a Firefox issue, and how to fix it. It was resolved as a duplicate of another bug in October, but the bug reporter came back to reopen it in February 2014. The bug reporter was polite but persistent in explaining their view, giving more details of the browser behavior, trying to find the bug in the very latest developer build (Nightly), giving a test case and comparing the behavior in different browsers. A developer submitted a patch, asked for code review. Related bugs were mentioned and linked. At least two new bugs were filed.

One important thing to note is that people working on QA and development tend to move very fluidly between using various Firefox versions. One of the best things you can do to get involved with helping out is to set up all four “channels” of Firefox with the capability to run them all at once with different profiles, and to start with new, clean profiles. In fact, we need better and more up to date documentation of how to do that on different operating systems, with screenshots! Here are some links that may help you set that up:
* http://www.callum-macdonald.com/about/faq/multiple-firefox-instances/
* https://developer.mozilla.org/en-US/docs/Mozilla/Multiple_Firefox_Profiles
* https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles

OK, back to bug 926292!

Since I had worked on the bug and added myself to the cc field, I got bugmail about all these changes, and more or less followed a long. I often think that the collaboration that happens in bug fixing is very beautiful, and even fairly efficient!

In comment 29 you can see that code got committed to a mercurial repository, to “inbound”. From there, it goes through automated tests and is merged by one of the “sheriffs” into another hg repository, mozilla-central, where it will go into the next build of Nightly, which at that point in April, was Firefox 31.

Comment 30 suggests uplifting the patch to versions that will soon be released, to Aurora and Beta. Release managers started to get involved, commenting and asking the developers to formally nominate the bug for uplift.

At this point in my talk I explained a little bit about the “trains”.

Trains

The versions of Firefox under development advance on a 6 week cycle, from Nightly to Aurora to Beta to the main release of Firefox. In this rapid release schedule, Firefox 31 was Nightly, so Aurora was 30, 29 was Beta, and the release version most folks use was 28. The uplift request was refused so the patch “rode the train”. That means, if you were using Firefox 31 any time after the patch was merged into mozilla-central, you will see its effect. (It would also be fixed for Firefox 32 and 33 which are currently in use as Aurora and Nightly, since 31 is currently Beta.)

Our bug was marked “FIXED” when the patch was merged into mozilla-central. You can see near the end of its comments that I tagged the bug “verifyme” to put it into the queue of bugs that need verifying for Firefox 31. Many people see that list and work on verifying bugs including community members in our Bug Verification test days. I hope the story of this particular bug is over. I don’t have the number immediately to hand but I believe that over 1000 bugs are fixed for each version of Firefox over its release cycle. We can’t verify them all, but it’s amazing what we do get done as a team!

Other tools we looked at in my talk and the ensuing discussion:

Datazilla, which tests and measures Firefox performace: https://datazilla.mozilla.org/

Mozmill, a UI automation framework for Mozilla apps including Firefox and Thunderbird: https://github.com/mozilla/mozmill

Socorro, or crash-stats, where QA and other teams keep track of crashes in Firefox and other Mozilla products: https://crash-stats.mozilla.com

The ftp directories where Firefox builds and build candidates are stored: ftp://ftp.mozilla.org/pub/mozilla.org/firefox/candidates/

The mercurial repositories or “the tree”: http://hg.mozilla.org/

DXR, a nifty tool to search Mozilla’s code: http://dxr.mozilla.org/mozilla-central/source/

TBPL which shows the test results for every commit that’s merged into different branches https://tbpl.mozilla.org/

And a quick view into Mozilla’s Jenkins continuous integration dashboard which you can only see from our VPN, just to give an idea of the work we do when Firefox is in Beta. As a particular version of Firefox advances through rapid release, QA pays more attention to particular areas and uses different tools. We have to know a little bit about everything, be able to reproduce a user’s bug on many different possible platforms, figure out which developers may be able to fix a bug (or whose commit may have caused a regression or crash).

It was a lot to cover in an hour long talk! I wanted to pilot this informally as a test for doing a more formal talk with slides.

It represented fairly well that QA covers quite a lot of territory; it’s complicated and interesting work.

Steady contribution to Firefox support forums

Posted on by Liz

Every once in a while I go over to the Mozilla support forums to this query for questions asked in the last 24 hours that haven’t been answered. I like how it’s phrased. Right now it’s “6 questions in the last 24 hours have no reply. Help solve them!”. That’s out of 86 questions asked in the last day.

Looking up the answers is interesting. To answer the question, I poke around on the support forums, do a general google search, and usually find something relevant or can at least link to advice. Hopefully, the person asking the question feels happy to get a reply even if the answer isn’t easy! And, sometimes, other people who are support forum regulars come in afterwards and give a better answer or correct my answer. So I am not afraid to answer wrong; other people are on it, and if their answers are more useful they will get voted up higher on the answers page. Either way, there is plenty to learn by trying to answer well, giving a link or a source for the information, and just plain being nice to people.

Then I take a look at my SUMO user profile to see my stats build up. I only answer a question now and then, and have edited and translated a few articles. Actually I’m a sucker for anything that shows a steady buildup of activity and any kind of stats. While my mere 38 questions answered isn’t a lot compared to some of the incredibly dedicated contributors on the support leaderboard. It is like a little dragon hoard of evidence that I did something and that is satisfying even when it’s a very small hoard!

Sumo user profile 913

I only realized recently there are canned responses for replying in the support forums. There is an icon like a top hat, or a magician’s hat, which I didn’t notice for months. Perhaps from being a person who is way more into text than images.

Sumo magichat

It never occurred to me to click on that hat. Then someone mentioned it on IRC. Wow! I may file a bug to suggest adding a label next to it, that appears even when you don’t mouse over the hat. (Or is it a can… or a bucket?)

The selection of common responses is extremely useful. Basically there is a lot of infrastructure built to support, not just the people coming to look for answers, but the community contributors answering the questions.

Sumo canned

Bugzilla now has user profiles which I’ll be working to improve and make useful. You can see a person’s last activity in bugzilla.mozilla.org, the number of bugs they’ve filed, commented on, and various other stats that may be relevant to bug reporters, bug triagers, and developers. I’ll post more about this soon!

By the way, my avatar on SUMO, though it kind of looks like me with its purple hair, is from a game called Glitch that closed in late 2012. Glitch was a descendent of Game Neverending. GNE had an image management and social network build into it that became Flickr. I still miss Glitch – it was a great game and a beautiful community!

Bugs and sheriffs in London

Posted on by Liz

Travelling Bugmaster update! I am in London with a bunch of the automation tools team for a work week. Ed, jeads, Chris, Ryan, dave, and mauro have been neck deep in making decisions about the structure of a new version of TBPL. By eavesdropping in their conference room I have learned a bit about how Ed and RyanVM and others watch the tree (sheriffing). Also, dkl and gerv and I met up to talk about bugzilla.mozilla.org and I got to bounce some ideas off them about possible ways to tweak the incoming bug triage workflow.

The London office is right between Trafalgar Square, Chinatown, and Covent Garden. It’s very accessible. If you come to Mozilla London offices and are a wheelchair user, you should know that the Tube stations near the office are not accessible. Give up and take the Heathrow Express to Paddington and then a taxi.

Lanterns sky

The BMO and IT teams (glob, dkl, and fox2mike, mostly) are planning to upgrade bugzilla.mozilla.org on March 8th. You can give it a test drive here: bugzilla-dev.allizom.org. This brings Mozilla’s implementation in line with the upstream version of Bugzilla 4.2. In theory, the new server hardware and architecture will also make BMO much faster.

I’m mostly excited about the user and product dashboards in this release. They look extremely cool — great for people who are doing bugmaster and triaging work. Someone who wants to drop in to triage Firefox bugs, or to get a mental image of what’s happening with bugs of interest to them, will be able to do so easily, without having set up a sort of pachinko palace labyrinth of bugmail and filters.

Bugzilla user dashboard 500

So if you would like a sneak preview of the user and product dashboards, take a look on bugzilla-dev.allizom.org and poke around! You can talk to us on #bmo or #bugmasters on irc.mozilla.org if you have feedback. And do please help us by filing bugs!

Besides the upgrade and move, and the archictecture of bzAPI current and possible future — gerv, dkl and I discussed the re-framing of early bug triage as “Bugmaster” or bug management work. We kicked around some ideas and it was very helpful to me to get their advice.

I am adding links to current wiki docs into the show_components.cgi descriptions and dkl has promised to expose those descriptions in show_bug.cgi views of individual bugs. My thought is that within the bug itself, the reporter and triagers, or an aspiring new developer, will have multiple ways to dive deeper into the bug.

We talked about adding common reply templates, which I am collecting in the Bugmaster Guide but which would work well, I think, built into Bugzilla. It turns out that dkl already has an extension started, canned comments, to do exactly this. Very intriguing!

Another thing I’d like to see is something that invites extra information when a bug is filed. This can be context sensitive, so that, if you file a bug in Firefox for Android in a particular component, there can be a link to relevant support forums, wiki pages, the irc channel, and the module owner information. This landing screen could also invite the bug reporter to add bits of information they have not included. If they haven’t attached a screenshot or included a url there could be an attempt to elicit them, or a few “next steps to help make this bug more reproducible” suggestions.

I am still thinking about the READY status flag and other ways to mark “early triaging is happening, or should be happening” vs. “in the hands of dev team”. That is a fuzzy boundary and different conditions would lead to it for different products/components. In this discussion we looked at Gerv’s and Jesse Ruderman‘s proposals for BMO workflow:
* Workflow Proposal 1 which simplifies the status chain.
* Workflow Proposal 2 which more radically changes the flow and statuses to a “next action” framing.

I can see benefits and drawbacks to both models.

It would be helpful from a triaging point of view to be able to declare, in an obvious-to-all way, that a bug is as triaged as we can get it for the moment and it either is ready for a developer to look at or is in some sort of Bug Limbo waiting for later re-assessment. We can do that with some assortment of existing tags and keywords but it may lack clarity and ease of use.

We brought up the idea that if I am doing some triage on a bug but don’t feel it is “ready” yet — for example perhaps I have identified its component, but not reproduced it, or vice versa — I can list myself as the QA contact. What would that indicate, though? Would it keep away other triagers? That is not what I’d want, of course. We could end up with some sort of “needstriage” checkbox, or make a tagging taxonomy that is well documented and evangelize it.

On Sunday I spent some time wandering around in a rented mobility scooter. It is possible now in London to hire a scooter for 70 pounds a week. Very much worth it not to have to push myself over thousands of cobblestones. I have only run over one person’s foot so far in the swarms of tourists, theater-goers, schoolchildren going to museums, and Londoners purposefully striding around in overcoats staring at their mobile phones. Though the scooter delivered is bigger than most cars in this country. It is like an enormous Mecha Gundam Wing suit on wheels so my adventures in the London streets are reminiscent of the Pacific Rim movie trailer.

Lion unicorn palace

In London, when confronted with a giant wheeled exoskeleton, people generally give a tiny gasp and start (theatrically), mutter apologies, and make a show of getting out of the way while looking bewildered. They are relatively good at not acting shocked that I exist. That’s kind of pleasant really. Some buildings and restaurants are somewhat accessible. I get along here as long as I don’t think too hard about how I can’t use the Tube at all and I can afford the glorious taxis.

In Vienna, I used my manual chair. Almost nowhere is accessible even when it is declared to be. People there would loudly gasp, almost a little shriek, and leap forward to grab me, which reminded me of how people act in Beijing when they see an independent person using a wheelchair. They scream, and they leap, like kzinti. More details on hilarious wheelie adventures in the Hofburg, coming soon. Travel is lovely but I’ll be glad to be back in San Francisco at the end of the week.

Bugzilla quicksearch, or else!

Posted on by Liz

Here is a fabulous tip if you are messing around in bugzilla.mozilla.org and are searching for bugs. As, by now, as a reader of my blog, you should be.

You can search Bugzilla right from the location bar. I cannot quite bring myself to say “Awesome bar” as people do at Mozilla because I’ve said “location bar” for many years, and it feels silly.

First you will need to be logged in to a Bugzilla account!

Right(command)-click in the Search box. Choose “Add a keyword for this Search”.

Pick something short that you will remember, like “b” or “bug”. I added both since they both seem intuitive enough to me that I’ll probably forget choosing one or the other.

Command-L is the keystroke on a Mac to move to the location bar.

So, type Command-L, type bug 831552 and you will be whooshed directly to that bug.

Command-L, bug retina will result in a fairly quick list of around 18 bugs (as of right now.)

Here are a bunch of quicksearch tips for bugzilla.mozilla.org!

Take a look at the tips and see what quicksearch looks at by default. There is lots of useful info there and it is worth going through and trying some of the options and noting which field names might be specially useful.

The Advanced Shortcuts are the best thing about quicksearch for me so far. For example, Command-L, bug UNCO retina returns all the unconfirmed bugs with the keyword “retina”. (About 4, currently). Though keywords aren’t case-sensitive, the Advanced shortcut “Status” search terms are. So you have to type bug UNCO retina, not bug unco retina.

At the moment, quicksearch look in comments and various other bug metadata. After January 24th that will change — comments will be excluded by default from quicksearch. That should make it actually quicksearch instead of kinda_slow_search. Or at least quickersearch. Until then, you can type bug --comments retina and your search about retina-related bugs will be a bit faster.

Here is the “or else” part from the title of this post: If you have been calling yourself “The Bugmaster for Mozilla” for several weeks, and you slowly mouse over to a search box to type something, and you do this in front of some kick ass developer, instead of using quicksearch in the location bar, you will be embarrassed. So take it from me and don’t do that.

cats in hats

Thrills, chills, filters, and bugmail

Posted on by Liz

Any bugmail at all is probably way too much bugmail. That means you will need to set up some structures to filter it!

This explanation may be useful for anyone interested in contributing to Mozilla — especially bugmasters, triagers, and developers. Even if you don’t use the same email setup, there’s some good tips.

Byron (aka glob) explained how I could set up my Bugzilla email, or bugmail. Within Bugzilla, in the Email preferences tab, there are a complicated set of checkboxes to control what conditions in Bugzilla trigger your bugmail. Right now, my email notifications are set to fire off email to me whenever anything happens to a bug I may be interested in.

Bugzilla email prefs

I then set up some users to watch, at the bottom of the Email preferences screen. Whenever Matti, Tyler, or Benjamin do anything with a bug, Bugzilla emails me about it. I can also see that Josh is watching my Bugzilla activity. People often refer to this as “stalking” in Bugzilla, without any creepy connotation intended. It is basically TMI about someone else’s bugs (or what bugs they poke at.)

Bugzilla user watching

“If you watch a user, it is as if you are standing in their shoes for the purposes of getting email. Email is sent or not according to your preferences for their relationship to the bug (e.g. Assignee).” The meaning of that takes a while to work out, much like Bilbo Baggins’ famous statement at his eleventy-first birthday party… “I don’t know half of you half as well as I should like; and I like less than half of you half as well as you deserve.”

I have picked two components to watch. Bugs in BMO (bugzilla.mozilla.org) are organized first by Product, such as Firefox, Firefox for Android, Thunderbird, and so on; then by Component, which seems to be a division by who is working on a particular area or project. You can’t pick a Component, or even see it, till you figure out what Product your bug belongs to. Here is a helpful guide from the Mozilla Developer Network with a list of Mozilla Products and their Components, handily all on one page, so it is easily searchable. I have also been using the list of Modules and their owners from the Mozilla.org wiki.

Bugzilla component watching

We don’t even have any bugmail yet, and see how much we have learned about the structure of a giant complicated FLOSS ecosystem! Hurray!!!! *waves pom poms*

Cheerleader cat

At this point, I made some folders in Zimbra inside a general Bugmail folder. While I’m still not sure how I’ll settle on bugmail organization, right now I have separate folders for my watched components and people. Then, in Zimbra preferences,there is a sidebar option for “Filters”.

Bugzilla filters

Create a new filter, then for users you’re watching, filter on header, and set the header name to X-Bugzilla-Watch-Reason. (For other filters, check the full headers and see what X-Bugzilla header info will work best.)

Bugzilla x headers

Since the X-Bugzilla-Watch-Reason filter contains the person’s email, if they change their own bugzilla email address, my filter will break.

Bugzilla user watching

Onward to Thunderbird, which I have set up with IMAP to check my Zimbra account.

Right-click (or command-click for a mac) on your account name in the Thunderbird sidebar, and choose “Subscribe”. This shows you the folders on your IMAP-connected account. Expand the folders and check the tickybox next to the new folders you just created in Zimbra (or whatever else you use). This will create a copy of that folder in Thunderbird.

Bugzilla thunderbird subscribe

One more step. In the Thunderbird sidebar, right-click one of the new folders that was just copied over from your IMAP account. Choose “Properties”. Then check the tickybox labelled “When getting new messages for this account, always check this folder.”

Now your bugmail will nicely filter itself — in both email clients.

That was non-obvious enough that I really wanted to document all the steps. Maybe some other new hire at Mozilla will be helped!

If anyone has bugmail tips for me, I would appreciate that!

Bonus points to anyone reading this who notices my PretendOffice filter and has a good laugh.

Twiddling my email, calendar, irc, and phone notification settings

Posted on by Liz

Calendar and email notifications may sound very boring but they has engrossed me for at least an hour.

For the first time in life I have a work laptop and a personal laptop. For the last 10+ years I’ve come into a job with an existing laptop which I use seamlessly for work and personal stuff. So far, I like having less “personal” things on my work laptop. It is especially nice not to have the distraction of personal email and non-work related mailing lists. It also feels amazingly luxurious to set aside the work laptop at the end of the day.

I have Zimbra for work email, but prefer to read my email in Thunderbird on my work laptop. Zimbra calendar has my work meetings and Google Calendar has the general schedule for my life. This morning I realized Zimbra was nagging me about missing a meeting. I need to know beforehand in some way that isn’t inside a browser tab!

Instead, I’d like my phone to make a special alert noise for meetings 10 minutes beforehand so I know to open up Skype or Vidyo (what Mozilla generally uses for meetings).

BEEP cover

The last bit of information in this scenario: I didn’t want to install some special Zimbra app on my phone.

Here’s what I did:

1. Set up Zimbra to SMS me at (my 10-digit phone number@tmomail.net) before meetings.

In Zimbra, go to Settings, calendar, set up phone number for notifications.
In each meeting there is a checkbox for email notification. This works for recurring meetings as well.

2. Set up my phone so that gmail notifications only make a noise for priority inbox mail. (I realized that my phone makes a noise every time it syncs email. I normally ignore that noise. )

Open Gmail on the phone, Menu>More>Settings>click the email account>Labels to Notify>Inbox ***>Ringtones (set to silent)

*** Tweak the settings for the Priority Inbox too.

4. Go to gmail.com and set up whatever should go into “priority inbox” i.e. filtered to “important”

google calendar already has its own notifications on android phone if you have its app installed. If not you can set up a forwarding address and make the calendar email to SMS you.

5. make sure incoming SMS messages have a different noise than priority emails
Go to messages, menu, then settings, Select ringtone.

It took a little thought to figure out what to use to get the simple result I wanted. And while most of it happens in web services and phone settings, some of it was in my training myself in a different behavior (paying attention to a particular noise on my phone.)

A final note: Long ago I set up voicemail from my phone to Google Voice. I hate listening to voicemail. It takes a long time. Text is so much nicer, and it helps that I read very quickly. All voicemail interfaces suck. The last time I used one, it had a default menu message that took about 15 years to go through that played after every single voicemail. This resulted in my *never* listening to my messages. (Fortunately I have not had a work phone for years; just email.)

People sometimes leave long messages, but the gist of them is just “call me back”. Google Voice is lovely for this as it sends me an email transcript of the voicemail. The transcripts are often hilarious garbled but it’s enough to get the idea of who’s calling, what their number is, and what they want. If I want to hear them, I can press “play”. Their messages are also nicely archived for me in Gmail. Hurrah!