Releng As Is - January 2012
[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
