You are currently browsing the archives for the Mozilla category.
Posted 1 week ago at 17:19. 0 comments
A few weeks ago, dria blogged about the format she had adopted for conducting 1-on-1 meetings with her manager. As a nascent manager myself, I had been struggling to come up with a better framework for my own meetings. I ran dria’s chosen format by Armen and he was supportive, so for the past two weeks we’ve been giving it a try.
The new meeting format is working pretty well for us so far. Here are some of the key things I like about it:
- The framework makes it easy to decide when in the meeting to discuss which issues. The project-based agenda I used previously tended to encourage digression, but that’s kept to a minimum now. Certain meeting sections are pure reporting (e.g. accomplishments) and others are meant for discussion (e.g. blockers).
- It puts an onus on both parties to be prepared. Armen sends his notes to me the night before so I always have a chance to prepare help/advice beforehand.
- The video chat is great as a remotie. Armen has an office he can go in to in Toronto, but I have no such luxury. Having these meetings “face-to-face” (i.e. Skype) is a big win, at least for me. Non-verbal communication can help us move faster through the agenda at times. Conversely, it can also allow me to pick up on signs that something may be amiss. Both functions are invaluable.
Our success with the format has encouraged me to push the format back up the chain: John and I are going to try the format next week for our 1-on-1.
Posted 3 weeks ago at 18:29. 2 comments
This has been a pet peeve of mine for a while. Assuming you’re not editing the attachment as a comment, Bugzilla gives you a very small window in which to leave a comment when reviewing a patch: the textarea is 5 rows high and only 25 columns wide by default. I’ve found it hard to add coherent commentary in a box that small, and my efforts almost always come out poorly formatted because I just can’t tell how the text is wrapping.
I whipped up a dead-simple greasemonkey script today that increases the size of the comment box when you click on it, and then shrinks it back down again when you click elsewhere.
Posted 1 month ago at 19:49. 1 comment
Let it never be said that we don’t listen.
In response to the comments on my previous entry about Tackling the Release Engineering:Future queue and a number of conversations I’ve had out-of-band over the past few months, the release engineering team has decided to do away with the Future component. We will be merging all of the bugs therein back into the regular Release Engineering component.
Aside from the simplicity inherent in having fewer components to worry about, there were three main reasons we chose to do this: Continue Reading…
Current Tunes: New Order - Blue Monday | Filed under Build/Release, Mozilla
Posted 1 month, 1 week ago at 17:22. 4 comments
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…
Current Tunes: Above and Beyond - Trance Around The World 306 - Andy Moor - 2010-02-05 | Filed under Build/Release, Mozilla
Posted 1 month, 1 week ago at 15:37. 0 comments
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…
Posted 4 months, 4 weeks ago at 11:03. 9 comments
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…
Current Tunes: Digitalism - Echoes | Filed under Build/Release, Mozilla
Posted 5 months ago at 11:05. 1 comment
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…
Posted 6 months, 2 weeks ago at 21:56. 1 comment
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…
Posted 7 months ago at 17:22. 4 comments
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.
Posted 8 months, 1 week ago at 17:46. 7 comments
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.
