Short version:

The switch from cvs to mercurial involves a lot more then just changing all occurrences of “exec cvs” to “exec hg”.

Long version:

1) Removing bootstrap and tinderbox from the release automation.
For Firefox3.0, we have BuildBot+Bootstrap+Tinderbox on cvs. Modifying the existing BuildBot+Bootstrap+Tinderbox code to work on hg would be much more work than just removing the bootstrap+tinderbox layers completely – which is something we want to do anyway. Rather then do slower, throwaway, work, we’re instead removing bootstrap+tinderbox as part of this transition from cvs to hg. This should *significantly* simplify life afterwards, and simplify future development.

2) The way our code is organized in CVS and Mercurial is very different, and worth noting as it forces us to rethink what used to work before.

Background: In cvs, the en-US code is in one repo, and all l10n locales are in one other repo (total of 2 repos). This means that all shipping bits could be uniquely identified by two timestamps. However, in hg, the en-US code is spread across 3 hg repos (moz-central, comm-central and mobile-browser), and all l10n locales are spread across 59 repos and growing. (today’s total is 62 repos and growing).

This means:
a) we have to redo automation to handle additional repos, and do this in a way that can easily support additional repos, as new locales are added. There’s already been 11 new locales in the 8 weeks since the FF3.0 release and we expect this rate of growth to continue.
b) because hg uses changesets, not timestamps, we need to keep track of the 62 different changesets. We used to rely on an email from release-drivers with two timestamps. However, this doesnt scale so well up when dealing with 62 or more unique changesets and risks typos / cut-paste errors. (See thread in dev.planning about “How do we sign-off on Mercurial based releases’ code+locales?”)
c) we need to figure out the branch / tag situation in hg. Whether we branch&tag in the same repo, or create a new “release” cloned repo, or do something completely different, is still being discussed in newsgroups. (See thread in dev.planning about “Decision Time – Re: Branching for Firefox releases in Mercurial”).

I’ve explained this verbally or on whiteboards a few times before and during the summit, so thought it would be useful to blog about here.

Hopefully that answers more questions then it raises!?