Disk space has been getting pretty tight with all of these active codelines. Things are looking a little better going forward.

Hi All,

To follow-up on my post yesterday, here’s then when and how of branching:
* Tag mozilla-central and l10n repositories with GECKO_1_9_1_BASE so we know where we branched going forward
* File IT bugs to have mozilla-central, l10n repositories cloned and a Firefox 3.1 Tinderbox created.
* While this is happening RelEng will do as much setup of infrastructure as possible.
* Once the clones are finished we will do some tests in our staging environment.
* When were satisfied with those results we will start push those infrastructure changes to production.

ETA on being fully up and running (that is to say: parity with mozilla-central) is early in the PST day Monday, November 24th. We do expect to have infrastructure up this week but some baking time, especially for Talos, is important.

Other important information:
* mozilla-central will NOT be used for trunk development until after we tag for Firefox 3.1b2. Once that happens we will bump mozilla-central versions to 1.9.2a1pre/3.2a1pre.
* The new mozilla-1.9.1 repository will be rebranded to Shiretoko to avoid confusion

https://bugzilla.mozilla.org/show_bug.cgi?id=464640 is the tracking bug for branching, for those interested in tracking the blow-by-blow.

Rob Helmer talked a lot about AUS and updates, mostly regarding releases. What he did not mention the silly path that our nightly updates take.

All of our nightly updates currently take the following path:

1. Nightly build happens – this includes a complete MAR and complete AUS snippet
2. Cronjob on a specific build machine performs some magic and generates a partial MAR and partial AUS snippet

Once these changes land our 3.1 builds will take the following path:

1. Nightly build happens – this includes complete AND partial MAR, complete AND partial AUS snippet

(We could probably support Tinderbox driven builds (2.x, 3.x) pretty easily too, if someone wants to write the patch.)

I think it’s pretty obvious that this is a more sensible way to do things. As it stands now if we lose the VM that generates partials we lose all nightly updates. The hidden benefit here is that updates for releases and nightlies will have fewer differences between them. This means that problems with that system will be caught in the nightlies and *not* during a live release. (NB: We will still need to do snippets for older than n-1 builds, eg. 3.0->3.0.2 during the release process).

I’m still doing testing of this but I hope to land these changes in mozilla-central/tools/update-packaging by the end of next week.

Special note for build folks from SeaMonkey and Thunderbird: I will be replacing the CreateCompleteUpdateSnippet and snippet uploading ShellCommands with a couple Makefile targets – you may want to do the same.

Many thanks to Vlad, who did most of the work on this.

* All Firefox 3.0.x/Gecko 1.9.0.x/CVS trunk tinderboxes will report to the soon-to-be-created “Firefox3.0″ tree. (http://tinderbox.mozilla.org/Firefox3.0/)

* All Firefox 3.1/Gecko 1.9.1/mozilla-central tinderboxes will report to the “Firefox” tree.
(http://tinderbox.mozilla.org/Firefox/)

* The ‘Mozilla2′ tree will be deleted.

Mobile builds are done on Linux ARM, inside of Scratchbox. For more details about the Mobile platform setup, see the ref platform doc. Builds are not yet being published, but we hope to get them going soon. Details are in bug 418852.

We have very very basic Mozilla2 infrastructure up. Linux and Windows builds are going, Mac is pending. Currently, actionmonkey and mozilla-central are built. There is no unit or perf testing as of yet. You can find these builds here and here. These builds are labeled as Firefox 4.0a1pre to avoid confusion with the current CVS trunk but that’s the _only_ reason they are named as such. We are a ways off from Firefox 4 and these builds should not be considered as previews of it. I’ve seen some blog posts about “Firefox 4 Alpha 1″ being released and I want to stress that this is NOT the case. The ‘pre’ in the version strings means ‘prerelease’ – aka. not yet released. For all of the nitty gritty details on Moz2 builds, see this tracking bug.

Last but not least, Linux 64-bit builds have been set-up. They are built on CentOS 5.0 with GCC 4.2.3 and follow the same mozconfig as 32-bit dep/nightly builds. You can see them on the MozillaExperimental tinderbox for now, but they should be pushed to the Firefox tree by the end of the week. You can find the hourly builds here and the nightly builds here (the same place as 32-bit Firefox builds). These builds are being done primarily to “catch bugs in visibility handling” and make sure we don’t break x86_64. At this time, there is no plans to do 64-bit releases.