Mister:Home Page
Introduction
Mozilla releases have historically been small, consisting of no more than 10-20 official files. With Firefox 1.0, we crossed a threshold that led us to managing 300+ files. With Firefox 1.0.1, we found ourselves pushing 450+ official files along with updates to all of our Firefox 1.0 clients. We need a better story for how we do releases, track them, and offer them to our users.
Mister is an integration piece between UMO, Bouncer, the build systems, QA, and the release process. It closes the gap between these services so we can push out new releases and updates in a timely and uniform manner for all of our users (across products, versions, platforms, and locales).
Our Story
Build Registration
Mister should allow registration of new builds (given some token for auth and authz) to prepopulate the release data store. For example, a simple Perl script could parse a release directory and then submit some RPC to add new records for each file and group them together under a (product, version) tuple.
Automating Registration for Our Build Systems
Build systems should issue a notice to Mister when a new build is available. Similarly to how such a build registration script could be invoked from the command-line, Mister could receive a notice directly from the build systems that new files are available. Automating this build registration dovetails nicely with the holy grail of a "nightly update channel" for our early adopters and QA/testing community.
We should transmit this registration from our build systems to Mister via email. It works incredibly well for the Tinderbox systems (though with the occasional, generally tolerable hiccup, of course) and we should allow the same delayed delivery announcement from the build systems to the central release store.
Issuing Updates to Our Users
Where now the update RDF files are written and modified by hand (by me), we should move to a place where they are generated automatically upon request by the client. We can mitigate the hit we take generating these dynamically by placing a caching mechanism between this service and the client.
Client Capabilities
The capabilities of the client should be encoded in Mister so that RDFs it generates work correctly with our deployed clients. We will require excellent communication between the server- and client-side engineers to ensure that we have a proper handle on what functionality we have available to us.
Localisations
When we have such a system in place, trusted localisers should be given access to customize the strings that are presented to the user. Creating this set of localised strings would be included in the required steps to stand-up any new localisation that a volunteer sought to bring online.
As the master en-US strings are changed, all localised strings should be flagged as needing translation to simplify the job of noticing when a locale requires an update.