You are currently browsing the archives for the Mozilla category.
The Release Engineering:Future bugzilla component alternately inspires feelings of sadness, loathing, and contempt…and that’s just within the RelEng team!
I’m certain most developers first response to having their bug moved to the Future queue is, “Oh, look, my bug has fallen down a well.” Historically speaking, that may not be far from the truth.
Continue Reading…
This is a follow-up to Ben’s blog post about the RelEng Sheriff back in October. His post described clearly what the RelEng Sheriff (and more generally, the RelEng team) can do to help developers.
Since we implemented the RelEng sheriff (or “buildduty” as it is more informally called) last spring, developers have been getting better about using the buildduty person as the first point of contact for RelEng issues. I’d like to implore people to continue doing so. There are a few exceptions, of course:
Continue Reading…
Recognizing some existing internal group dynamics and the need for the entire Mozilla release engineering (RelEng) team to grow in a more sustainable manner, we recently started an internal reorganization of the RelEng group. John will likely blog about the new structure of the group at some point, but I’ll relate the bits that are pertinent to me.
Continue Reading…
The Mozilla release engineering (RelEng) team has grown substantially over the past two years. Some members of the team have certain domain-specific focuses (e.g. talos, mobile), but one of our primary team goals has been to get our release automation to the point where anyone on our team can handle a release. Given the emerging branch picture for Mozilla code where we might see simultaneous releases on 3+ code branches (a.k.a release-apalooza), this is becoming increasingly important.
I’ve done my share of releases over the past few quarters, and until the current release (3.5.4, still in progress as of writing), I would have said that I understood the process pretty well.
Continue Reading…
The roll-out of nightly l10n updates has been…bumpy. The primary user-visible symptom of this has been that nightly updates for en-US have sometimes been delayed by many hours when compared to when they would have been generated previously.
I hesitate to say that these consequences were unforeseen, but rather that we were initially unsure how/if the various systems we use to generate, store and serve updates would even cope when they had to deal with more than one locale.
Continue Reading…
We’ve reached another milestone in our ongoing effort to elevate localized (l10n) builds to first class citizens within the Mozilla release engineering framework.
Last week, Armen flipped the configuration switch to turn on nightly updates for l10n builds on mozilla-central. After a few downtime-related hiccups last week that tanked nightly builds across the board, this morning we were finally able to serve partial updates to l10n nightly users on all platforms.
This is another huge step forward. Nightly testers who use localized builds no longer have to download an entirely new localized browser every day, but can instead rely on the Firefox update service to automatically download a much smaller binary partial update for them. Aside from allowing us to make sure l10n nightly testers are always testing the most recent code and string changes, this may also allow us to recruit a new batch of nightly l10n testers who were previously worried about the bandwidth involved in helping us test on an ongoing basis.
Over the coming weeks we’re hoping to enable l10n nightly updates on the newly-cut 1.92 branch as well. We are dealing with many more builds passing through the staging server to the update generation machinery now, so there’s some housekeeping to be done first to make sure that no builds, mars, or snippets are piling up in dark dusty corners anywhere.
Thanks to Armen for daring to touch the update code at all, to Nick for his update support, and to Axel for his tireless l10n work.
The Mozilla RelEng team was having one of our patented digressional discussions in IRC yesterday when we got around to the subject of hg irritations. My personal annoyance was that I frequently need to check-in patches for other people who don’t have commit access, but I don’t always remember to check before pushing to make sure I didn’t miss adding any new files created by the patch.
Because Ted is more about solving problems than bitching about them, he suggested I write a hook to prevent myself from missing files. Here it is:
[hooks]
precommit = hg status | (! grep '^?')
Add that to your .hgrc file (and setup some good global hgignore rules) and you’re golden.
What a difference a year makes.
In fact, it was less than a year ago that Armen and John gave this presentation at the Summit in Whistler outlining the then-current problems with the l10n build system as it related to release engineering.
Axel has a new post up about how we’ve been systematically addressing those failings over the last 10 months, and what we’re tackling next.
We’re all about lowering bars to entry into the Mozilla community. I’m thrilled to see our localized Firefox builds approaching parity with the default English (en-US) builds. Not requiring potential localizers to have a complete translation before they can get meaningful feedback, and greatly reducing the turnaround time for that feedback to a few minutes is huge. Taking the stress of generating those builds off of Axel’s shoulders is also a big deal, because it gives him more time to work on other improvements for the l10n community.
There is more work still to do, certainly, but we’re a lot better off than a year ago. Cheers to Aki, Armen, Axel, John, and Seth for their help in getting us this far.
Let me join joduinn in welcoming back Armen to Mozilla, this time as an actual employee.
Armen tackled some pretty hairy stuff during his internship, and he’s not shying away from the tough stuff now either. His first task will be helping me to get nightly updates rolling for l10n builds. This is something we’ve wanted to provide to localizers and non-en-US testers for a long time, and are only finally getting the human bandwidth to tackle now.
So, welcome back, Armen! Let’s get to work! 
NB: Our VP Eng should probably keep a spare shirt on-hand if he’s going to be working in the same office as Armen.
With the “recent” changes to QMO, a lot of the Litmus documentation went missing. It was still available at an archived site if you knew to look there, but there was no automatic migration or visible linkages in place.
I *think* all the relevant docs have been migrated now, and those that were not migrated have been moved back to the wiki. In general, the how-to-use Litmus (including Admin) information is available on QMO, and the how-to-install Litmus information is back in the wiki.
All the information is now properly linked from the Litmus wiki, but here are some quick links for the impatient:
I’m not actively maintaining Litmus any more myself, but I encourage interested parties to participate in the QMO discussion about Improving Litmus.
