This morning I landed bug 486567 - which cleaned up the try server code significantly. There's still more to be done there, particularly running unittests on packaged builds once it's production counterpart lands (bug 383136). Both of these things help us keep the Try Server in sync with the rest of the world - which has always been a problem.

Looking forward a little bit, I'm looking to land a patch that enables e-mail notification for try server builds and unit tests on Tuesday. With this patch, every try submission would result in 6 e-mails to the submitter: (1 per platform/build type combination). Here's what they'll look like:

Build:

Your Try Server build (try-1c170baeac1) was successfully completed on linux. It should be available for download at http://build.mozilla.org/tryserver-builds/bhearsum@mozilla.com-try-1c170baeac1

Visit http://hg.mozilla.org/MozillaTry to view the full logs.

Unit test:

Your Try Server unit test (try-1c170baeac1) completed with warnings on linux. It should be available for download at http://build.mozilla.org/tryserver-builds/bhearsum@mozilla.com-try-1c170baeac1

Summary of unittest results:

check: 2/0

Visit http://hg.mozilla.org/MozillaTry to view the full logs.

(The unittest e-mails will have the full results listed, of course).

E-mail notification has been an oft requested feature so I'm really excited that this will be landing soon.

I'm happy to announce that I've finally updated the publicly available version of our CentOS 5.0 build reference platform. There are many changes to it since the last released version, most notably a Scratchbox installation and Mercurial. For all the details you can have a look at the reference platform wiki page. Everything up to Version 17 is included on the released version.

You can get it here: ftp://ftp.mozilla.org/pub/mozilla/VMs/

...but only those to RelEng infrastructure.

We in Release Engineering always love it when people take the time and effort to fix a bug, cleanup some code, or otherwise enhance our infrastructure. However, it's often difficult to take outside patches because they are generally untested. Because of the nature of our code and systems - how tightly it's tied to infrastructure, limited access to said infrastructure, and how many different systems a single change can touch - it's nearly impossible for outside contributors to do more than the most basic testing. We don't have a Try Server that can test patches to RelEng code, and proper testing requires many different machines and can be very time consuming - especially if you've never done it.

It's always unfortunate to see patches sitting for days, weeks, or in rare cases, months, before they get landed. However, we don't like to land untested patches because it can lead to unnecessary build bustage.

I want to fix this, so over the next few months I'm going to be prioritizing testing your patches every Monday. I will set aside my normal work for a day to help test and get ready to land contributed patches. High priority things such as releases or infrastructure problems will take precedence over this, but that shouldn't be a common occurrence.

I'll be keeping an eye out for things, but if you want to me ping directly about a bug please feel free to do so.

Consider this in an experimental state. I'll be tweaking the process along the way and am very open to improvements here.

It's the start of a new week and the start of my first shift as RelEng sheriff. Do you suspect rando-orange? Talk to me. Do you suspect machine problems? Talk to me. I'll be watching dev.tree-management, the releng triage queue, and #developers for issues.

During this time we will be deploying all of the changes listed on this page as well as two Talos bugs: bug 379233 and bug 458093

This will affect the following trees: Firefox (mozilla-central), Firefox3.1 (mozilla-1.9.1), Tracemonkey (tracemonkey), and Mobile (mobile-browser).

As a heads up please note that the Talos changes could affect numbers and will change the layout of the results on the Tinderbox Waterfall.

If there is any reason why we shouldn't go ahead with this please e-mail release@mozilla.com.

If you are crashing after updating to the latest mozilla-1.9.1 nightly (20090218) try flipping javascript.options.jit.chrome to false - that should fix it. I've filed this as bug 479053 but flipping that pref should fix you up in the meantime.

During this time we will be deploying all of the changes listed on this page. Most notably, clobber support for all Mercurial based builds will be landed tomorrow. More on that soon from Chris AtLee soon.

This will affect all trees: Firefox (mozilla-central), Firefox3.1 (mozilla-1.9.1), Tracemonkey (tracemonkey), and Mobile (mobile-browser).

One of these requires a full Buildbot master restart - so expect some spurious burning. We'll do our best to minimize it and get things green ASAP.

If there is any reason why we shouldn't go ahead with this please e-mail release@mozilla.com.

Someone I know recently expressed interest in translating Firefox into her native language, Tagalog. Being a build guy, I decided to spare her the pain of getting everything setup and let her focus on the translation. Much to my dismay I discovered that the Create a New Localization page hasn't been fully updated for Firefox 3.1 yet. By mashing together information on a couple of pages and a lot of help from #l10n I managed to get an environment up and running that allowed her to dive in.

Here's how to do it. (Note: This has been tested on Mac and Windows. On Windows, this depends on MozillaBuild 1.3; on both it depends on Python setuptools.)

1. Install compare-locales

wget http://pypi.python.org/packages/2.5/c/compare-locales/compare_locales-0.6.1-py2.5.egg#md5=0b939a22d87427d80f5286dc5eb1eab2 easy_install compare_locales-0.6.1-py2.5.egg

2. Clone mozilla-1.9.1

hg clone http://hg.mozilla.org/releases/mozilla-1.9.1

3. Create the barebones localization

mkdir -p tl/browser/installer tl/browser/profile/chrome tl/browser/searchplugins tl/browser/updater tl/toolkit cp mozilla-1.9.1/browser/locales/en-US/defines.inc tl/browser cp mozilla-1.9.1/browser/locales/en-US/profile/chrome/userC* tl/browser/profile/chrome cp mozilla-1.9.1/browser/locales/en-US/firefox-l10n.js tl/browser cp mozilla-1.9.1/browser/locales/en-US/README.txt tl/browser cp mozilla-1.9.1/browser/locales/en-US/searchplugins/list.txt tl/browser/searchplugins cp mozilla-1.9.1/browser/locales/en-US/updater/updater.ini tl/browser/updater/updater.ini cp mozilla-1.9.1/toolkit/locales/en-US/defines.inc tl/toolkit

4. Create a mozconfig file, setup your object directory

cd mozilla-1.9.1 echo "mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/../fx-tl" > .mozconfig echo "ac_add_options --with-l10n-base=../" >> .mozconfig echo "ac_add_options --disable-compile-environment" >> .mozconfig echo "ac_add_options --enable-application=browser" >> .mozconfig make -f client.mk configure

5. Test merge-ab-CD and langpack-ab-CD targets

cd ../fx-tl make -C browser/locales merge-tl LOCALE_MERGEDIR=`pwd`/../merge make -C browser/locales langpack-tl LOCALE_MERGEDIR=`pwd`/../merge LANGPACK_FILE=`pwd`/../firefox-tl.xpi

If everything went well, you should be ready to translate now!

During this time we will be landing the patches listed on this page:

https://wiki.mozilla.org/ReleaseEngineering:BuildbotMasterChanges#Upcoming_changes

And as mentioned in Alice's previous post we will be unthrottling the rest of the Talos machines. (http://groups.google.com/group/mozilla.dev.planning/msg/402afc2bfd2d65f2). This work is being tracked in https://bugzilla.mozilla.org/show_bug.cgi?id=468680.

This will affect all trees: Firefox (mozilla-central), Firefox3.1 (mozilla-1.9.1), Tracemonkey (tracemonkey), and Mobile (mobile-browser).

One of these requires a full Buildbot master restart - so expect some spurious burning. We'll do our best to minimize it and get things green ASAP.

If there is any reason why we shouldn't go ahead with this please e-mail release@mozilla.com.

Both mozilla/tools/buildbotcustom and mozilla/tools/buildbot have now official moved to their new homes in Mercurial, http://hg.mozilla.org/build/buildbotcustom/ and http://hg.mozilla.org/build/buildbot/ respectively. The buildbotcustom CVS module will be deleted at the end of this week. We will be keeping the buildbot one for the time being because we have a Buildbot still using it, but all future work should be done against the Mercurial repository.