Release “As-Is” at high level

[Refer to the main page for additional context.]

Where we are in January 2012

The purpose of this post is to present a very high level picture of the current Firefox build & release process as a set of requirements. Some of these services are provided or supported by groups outside of releng (particularly it & webdev). This diagram will be useful in understanding the impact of changes.

System Scope

Here is how I’m defining the boundaries of the current system:

  • Applies to anything & everything involved in producing artifacts that are directly installed on an end user’s device.
    • In: Firefox, Thunderbird, Seamonkey
    • Not in: services such as browser id, sync, the addons.m.o., apps, and other code that executes on Mozilla’s servers.
    • Not in: extensions themselves (they are installed into FF/TB, not directly onto the end user’s device). Yes, that is a hair I want to split. [1]
  • But only if the entire process happens "inside the Mozilla firewall". (For example, the download mirrors are not in scope.)
[1] There may be some extensions, such as the Thunderbird Lightening, that cross this line. For now, I’ll ignore those.

The Developer Services

N.B. these are only repository related services that a devloper commonly accesses.

With this setup, there is official support for:

  • pulling from Mercurial repositories hosted at mozilla.org (hg.m.o)
  • commit access from developer’s own clone of the Mercurial repository (with committer policy enforcement)
  • "try server" access from developer’s own clone of the Mercurial repository
  • continuous integration based on commits to hg.m.o
  • tracking of results of commit compilation & testing, via tbpl.m.o.
  • web viewing of repositories
  • web cross reference of many repositories on mxr.m.o

The Picture

Block diagram

Comments are closed.