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.

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!

Joey

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.

Here is the new list of bugzilla components for Release Engineering (under Product: mozilla.org), complete with descriptions, QA contacts, and templates for filing bugs:

1. Release Engineering (existing)
   QA contact: release@mozilla-org.bugs
   Description: For bugs related to all aspects of the Release Engineering process, including Release Build Automation, nightly build machines, Tinderbox and/or buildbot.
2. Release Engineering: Automation
   QA contact: catlee
   Description: This component tracks bugs related to release automation and continuous integration.
3. Release Engineering: Custom Builds (existing)
   QA contact: custom-builds@mozilla-org.bugs
   Description: This component tracks partner builds, funnelcake builds, special builds for conferences, usbkey builds, ISO builds for CDs, etc. Some of this work, like signing builds, updating bouncer, etc is work which we already handle just fine in RelEng.
4. Release Engineering: Developer Tools
   QA contact: lsblakk
   Description: This component tracks bugs related to developer-facing
   release engineering tools such as tryserver, autoland, buildapi, and
   self-serve.
5. Release Engineering: Machine Management
   QA contact: armenzg
   Description: This component tracks bugs related to specific master,scheduler, builder, or test machines.
6. Release Engineering: Platform Support
   QA contact: coop
   Description: This component tracks bugs related to supporting new platforms/operating systems for building or testing, and also systemic improvements or additions to existing platforms.
7. Release Engineering: Releases
   QA contact: bhearsum
   Description: This component tracks bugs related to specific releases, or updates to those releases.

Please try to file new bugs against the new components when it is clear where the new bug should go, but by default, please continue to file bugs against the existing, general Release Engineering component when it’s *not* clear.

Today’s component split follows in the spirit of a recent component split by the Server Operations group. Our team is not as large as the IT group and doesn’t have the same kind of sub-team breakdown (yet). If the release engineering team does continue to grow as planned, we may see further component creation. We intentionally erred on the side of creating fewer sub-components rather than more on this pass, but we will re-evaluate the state of our component use after a few months.

To be brutally honest, having separate components triaged by separate people will help to defray the monumental task that I’ve been facing of triaging all incoming release engineering bugs. I also hope that allowing de-facto project leaders more control over their bugzilla destiny by making them responsible for new sub-components will increase their feeling of ownership for their particular areas.

Happy Friday!

He’s doing thankless work in documenting the existing build config system. Of course, it’s all building up to Joey’s work on container makefiles where he’s going to change it all.

You can scream “JUNKET” as much as you want, and I will gleefully ignore you. We (and by “we,” I mean Lukas – exceptional job, BTW) actually did the groundwork to make sure that this trip was cost-comparable or better to meeting in a city that had an established Mozilla office, e.g. Toronto or San Francisco. Keep that in mind next time you’re planning a work meeting, but do expect management to require you to show your work.

While in Honolulu, the release engineering team set up shop at a local co-working space, The Box Jelly. The staff there were very supportive and helpful during our stay. I can’t recommend them enough.

Despite the location, the work week was challenging for me for a number of reasons, so I was really glad to have the weekend free after the work week was done to explore Oahu before I had to fly home.

A bunch of us were still around on Saturday, so Aki and I organized a trip to Hanauma Bay, one of the premiere snorkeling destinations in Hawaii.

On Sunday, I was pretty much on my own, so I rented a car and endeavored to see as much of Oahu as I possibly could.

I left early in the morning and made my way first to the west coast of the island for some snorkeling at Kahe Beach Park. Kahe Beach is immediately adjacent to an electrical generating plant, and there is a large outflow pipe of warmer water than the fish love. The snorkeling here didn’t disappoint, but the surf was very active. As long as I didn’t fight the currents, I was fine, but it was quite vigorous. Can’t expect much different in winter time.

After that, I headed up to the North Shore to watch some surfing, stopping briefly at the Hale’iwa Farmer’s Market to pick up gifts for people back home. There was actually a surfing competition in progress at Sunset Beach, so finding parking was a challenge, but I did eventually find some near the Three Tables area.

I hadn’t planned on actually surfing myself on the North Shore because generally I don’t consider myself crazy, but as I drove past Wiaimea Bay, it looked so gorgeous that I just couldn’t pass it up. After watching some surfers along the Banzai pipeline for a good long while, I gradually hiked back to Waimea Bay along the road. Without fins or a board, I must say that bodysurfing at Waimea Bay was a hell of a lot of work, but OMG was it worth it. If I was the sort of person to make a bucket list, “bodysurfing on the North Shore of Hawaii” is one gigantic checkmark.

From Waimea Bay, I drove a little further up the coast to Giovanni’s Shrimp Truck for lunch. After lunch, I continued up the highway to Kuilima cove, right beside the Turtle Bay resort. This was reported as one of the best spots for beginner snorkeling in Hawaii, so I figured I could still hack it despite not being able to feel my arms. Alas, I outlasted the battery on my camera and I only got one good picture of some fish before the battery died. This is a shame, because I ended up swimming with a large Hawaiian green sea turtle shortly thereafter.

After that, I continued my way southeast along the coastal highway, not expecting much adventure, just trying to get back to the rental car centre in time for my flight. (Un)fortunately, traffic slowed to a crawl near Kaneohe due to a bad accident, which had the happy side-effect of causing me to divert onto the H3 bypass. This major highway just happened to cut directly through the volcanic mountains in a gigantic tunnel, and comes out the other side in a lush, tropical valley. Makes me wish I was driving something more sporty than a Camry at the time, although I tried to make due.

‘Twas truly a weekend well-seized, although I was absolutely dead-tired by the time I boarded my flight home. Wouldn’t have it any other way though.

I also don’t think we’ve ever publicized the links to our buildduty resource wiki before. The curious and/or masochistic may be interested to see just how much our buildduty representative is responsible for in a given week. It’s not a small list.

Yes, we’re looking to automate everything on that list, but hopefully you’ll keep the list in the back of your mind the next time you need some buildduty help.

I can dream, can’t I?

His first post on make-makefile is up now, and there is more coming soon.