Firefox - Release Engineering infrastructure for Localization (L10n) - Blogging Blitz

In addition to our RelEng's blogging blitz I am going to blog about how our L10n release infrastructure works. In this first blog post I will explain our Firefox's coverage.

Scenarios

We currently have 3 scenarios:

• Repackages on change
• Nightly localized builds
• Release localized builds

Deliverables

What our different deliverables are:

• Langpacks (you can add a language as an add-on)
• Installers (we generate a different one for each platform)
• Complete and partial mars (these are generated for updating from one version to another one)

How many locales do we process:

• More than 70 and depends on each branch
• The number of locales per branch is determined by the all-locale's file of that branch

Key concepts

• compare-locales = it compares en-US strings with the strings of a locale showing the differences between the two of them.
• l10n-merged or merged = when a repackage is merged it means that if the locale has any missing strings then the English strings will be inserted. When we run compare-locales we tell it to create a "merged" directory in case the locale has any missing strings. When we create the installer if the "merged" directory exists the localized repackaged repackage will be based off that directory instead of the locales' repository. This ensures that it won't have any missing entities; avoiding this way any crash due to missing entities

How it works

Before I explain how each scenario works let me explain what makes them distinct:

• compare-locale. We run compare-locales in all 3 scenarios.
• l10n-merge. For releases we don't l10n-merge. We just use plain compare-locales.
  
• triggering. Repackages-on-change are triggered by localizers' pushes while the nightly and releases are triggered when the en-US build finishes.
• upload. Each scenario uploads to a different location (tinderbox-builds, nightly or releases)
• updates. Only nightly and release scenarios have updates
  

How the repack-on-change scenario works:

• We have a poller that polls for changes in all locale's pushlog and we poll every 15 minutes. The reason that we poll every 15 minutes is because it adds a huge load on the master if we did it in smaller periods of time. If we think about mc, 191 and 192 we poll more than 210 different pushlogs and that takes quite some load of our masters.
  
• When a change for that locale is detected it triggers the triggerable L10n builds for all 3 platforms.
• The deliverables for the locale are pushed to the tinderbox-builds directory on ftp.

How the nightly localized scenario works:

• Instead of being triggered by a commit change on one of the locale's repositories, it is triggered by the en-US nightly build for that platform.
• The nightly build triggers as many localized build jobs as the all-locale's file for that branch determines. This is accomplished in special buildbot schedulers that make use of the L10nMixin class by submitting a job per locale.
• The repackages are l10n-merged!
  
• The installers are uploaded to the nightly directories on ftp.
• Unlike the repack-on-change scenario we have updates for this type of builds and that is why you will get to see complete mar files under the latest--l10n dir on ftp and partial mar files under the dated directories on ftp (NOTE that we don't keep the dated directories of localized builds forever as with the en-US builds).

 How the release localized scenario works:

• This scenario is pretty similar to the nightly one but it has few differences.
• The locales involved in the release are determined by shipped-locales and l10n-changesets and the revisions for each locale are specified in there.
  
• The repackages are not l10n-merged.
• We run l10n_verification to cross-check and make sure the repacks worked properly for the release builds.
• We upload each locale's installers in its own subdirectory rather than all of them under an "-l10n" directory.  For instance you can see all the Windows localized builds for 3.5.4 in here. You can also note that en-US is in its own directory and all the langpacks under the xpi directory.
  

I know I have gone way into details but I believe it is worth having it recorded all together for once and for all. More to come on my next blog with regards to Fennec!

EXTRA: What builders we do have:

• Firefox mozilla-{central, 1.9.0, 1.9.1, 1.9.2} {linux, macosx, win32} l10n build <- repack-on-change runs
• Firefox mozilla-{central, 1.9.0, 1.9.1, 1.9.2} {linux, macosx, win32} l10n <- nightly runs
• {linux, macosx, win32}_repack <- release runs
• l10n_verification <- cross checking
  

---

This work by Zambrano Gasparnian, Armen is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.