You are currently browsing the archives for the Mozilla category.
It is rare enough for me to be introducing a new hire, but two in one day is unprecedented.
Michael Shal joins the Mozilla release engineering team today, but will not be working directly on release engineering duties. Instead, Mike will be working to improve the current Mozilla build system.
Continue Reading…
It’s not often I get to introduce someone who requires no introduction.
Carsten Book (Tomcat) has been a long-term contributor to Mozilla. As a community member, and long before the advent of automated testing, Tomcat was the “automated” testing, joining Gavin in the pantheon of early Firefox god/bots.
Tomcat eventually accepted a paid position with QA. Over many years, he made a transition out of QA into a role working with our various Mozilla partners to create custom builds. Due to a recent shuffle, Tomcat has joined the release engineering team, where he will continue to work on existing partner builds, but will also grow to take on releng duties as well.
I haven’t worked with Tomcat directly for over 5 years, but he’s always brought a kind of crazy dedication to all his endeavors at Mozilla. I’m super excited to have him join the team.
Oh, and if you do need QA assistance, I’m sure one of the fine folks over on the current QA team can help you out.
In my previous post, I outlined the four main parts in our plan of attack for making the build system faster. But how will we know how well we’re doing, and how will we know when we’re done? How fast is fast enough?
Continue Reading…
There’s a Mozilla mobile workweek happening in Boston this week, and while I’m sure there will be plenty of exciting news to come out of it, I want to take a moment to highlight something that happened a few weeks ago.
In case you weren’t paying attention to Google groups, wlach, jmaher, Callek and the other folks involved with Mobile testing landed a tegra reboot fix 10 days ago that reduced the intermittent failure rate for tegra tests from 39% to 13%. Subsequent test fixes making their way through the system have now brought that failure rate down to 7%.
While this improvement is impressive enough on its face, these fixes finally bring Android test results into the range where developers can (and should) pay attention to their tegra test results when landing changes. This takes some of the onus off of sheriffs to be able to diagnose and requeue these intermittent failures, freeing them up to do more proactive work.
Given the continued focus of Mozilla on mobile development, this can only be a good thing.
The timing of Greg Szorc’s (gps) blog post about Improving Mozilla’s Build System couldn’t have been better.
In his post, gps outlines a 6-part plan for untangling the build system. After some discussion at our first meeting, we decided that while all six parts are useful, the first four parts accomplish our “short-term” goals. The first four parts are:
Continue Reading…
Without realizing it, a few weeks ago I revived the BuildFaster project.
My initial goal as a manager was simple: get one of my direct reports, Joey, unblocked. However, as is so often the case, that proved to be a very small thread in a very large sweater.
John O’Duinn welcomed Joey to Mozilla with the following note last spring:
Mozilla’s makefiles are used daily by every developer every day, and by RelEng continuous integration machines literally thousands of times every day. Joey will be focused on making these Makefiles more efficient, easier to understand, easier to *safely* change, as well as make them build faster. All super important. Oh, and don’t break anything in the process!
It is decidedly NOT a quick or simple fix. Joey has been trying, but unfortunately it hasn’t been his (or anyone else’s, read: reviewers) only priority.
I am encouraged, however, that within the last 3 weeks alone there have been 3 separate posts by Mozillians (none of whom are part of the current Build:Config peer group) about build system alternatives or how we could go about improving the system:
Management has also bought in, allowing all Build:Config peers some time each week to help with reviews for core Makefile cleanup.
The timing seems ripe to push hard on this, especially if we can enlist some of these other interested parties to help.
While looking for a place to put meeting notes for this effort (we had our first meeting on June 28th), I stumbled across BuildFaster, an effort which largely petered out late last year when the parties involved got distracted by more important things: native Fennec, b2g, colo moves, etc.
Fixing the Makefiles was a part of the initial BuildFaster effort, but because of the complexity involved, it was left as a longer-term goal. Rather than creating a tracking effort from scratch, I’ve decided to simply revive BuildFaster with a Makefile focus, and see where we go from there.
There’s lots more to report, but for now, consider this the official announcement of the Makefile effort that Joey and I will be spearheading under the BuildFaster umbrella. Look forward to more details soon.
Joey is really gathering steam now. His recent blog post about threadsafe mkdir comes complete with the motivation behind making this change, some of the problems he encountered while trying to make this fix, and a whole bunch of code examples.
I botched the initial landing of his code, but all of the relevant bits are in the tree as of bug 746151. Replacing rampant unnecessary shell calls is something that can potentially get us some build speed-ups, especially on Windows where shell ops are particularly slow. I’m excited to see where Joey goes next with this.
Yesterday was Kim Moir’s first day with the Mozilla release engineering team. Honestly, we didn’t hire her just because of her blog title (which is awesome): RelEng of the Nerds.
Kim joins us from IBM where she was well-known for her release engineering work on the Eclipse project. She also has a history of fostering the open source development community around Eclipse, which is the kind of thing we’re always trying to encourage here.
Like me, she is based in Ottawa. It’s been a while since I’ve had a co-worker in the same city — sorry, Kev, Kemptville doesn’t count. How often do we grab lunch? — but plans for an official Mozilla Ottawa office are still MoOt at this point.
As I mentioned previously, if you’re a release engineer looking for work (bonus points if your name is Chris or happen to be based in Ottawa), we are still hiring.
Welcome, Kim!
Pro-tip: if you ping me on IRC to ask me something and don’t ask your question as part of the ping, you have added an asynchronous cycle of indeterminate length to our interaction. Don’t do that.
Joey has another great blog post up about makefile landmines, how to avoid them, and some current examples of *ahem* where we’re not.
Joey is not specifically tasked with fixing these issues…yet. We’re making sure to get bugs on file for these issues so he can circle back once his current work is done and start fixing makefile patterns to help protect us from ourselves.
