Firefox 3.1 and 3.2 branching point coming up
Axel Hecht
we're going to branch Firefox 3.1 and the next major release, which is
currently listening to Firefox 3.2 (alpha pre, that is).
Now, with hg, we're going for a different branching strategy than we did
for CVS, as in, we're going to use different repositories.
This kinda works nicely, as you can pull and push revisions from repo to
repo, and the different repositories remember where the revision should
go in the other repo. Pretty much like we do with the repositories on
hg.m.o and your local clones right now.
What does that mean for localizers?
All apps (but fennec, fwiw) will focus on the 1.9.1 tree for
development. I'll detail for Firefox and leave thosee details up for the
comm-central heads.
Those repos are
http://hg.mozilla.org/releases/mozilla-1.9.1/ (corresponding to
mozilla-central)
and
http://hg.mozilla.org/releases/l10n-mozilla-1.9.1/af/ etc, corresponding
to l10n-central.
Now, you don't need to pull and clone and whatnot from scratch. Just go
into your mozilla-central clone, and open .hg/hgrc in an editor. Replace
the mozilla-central url with the releases/mozilla-1.9.1 one, and then
just pull and update as usual. I'd recommend not updating the
mozilla-central clone before you do that.
Same goes for your l10n repository, just edit .hg/hgrc there, and
replace the l10n-central url with your releases/l10n-mozilla-1.9.1 one.
In TortoiseHG, you can just right click on the top level dir, select
TortoiseHG, Settings, Repository..., and then edit the Paths tab.
One thing you can do here, you can add a peer repository path to point
to your central repo ssh: url. This helps you with ...
Updating your l10n-central work with work from 1.9.1:
As long as you're not making independent commits to the central repo,
you can just occasionally push from your 1.9.1 repository to the
l10n-central one. In TortoiseHG, you'd go to Synchronize, and then
select your central repo from the drop down, and then check outgoing and
push from there.
On the commandline, you have to specify the full repo ssh urls each time
you want to push to the other repo.
As soon as you actually start seeing other landings, the central repos
will bark at you and refuse you adding new heads. Then you have to push
to a local clone of your central repo, hg merge in that clone
explicitly, and then commit and push that.
Please don't start working on the 1.9.1 repositories just yet, we're
going to update them with the state of the central trees on Monday,
before actually hitting the builds.
On other infrastructure notes, the build team is working on getting some
kinds of builds up, not sure which and how often they will run. That's
apparently scheduled for Monday, too. The dashboard will start to see
both fx31x and fx32x builds as soon as there is a final push done on the
hg server side, which I hope will come today.
We're still having half a week, and we're having another beta freezing
sometime early January (separate post I should do), so this sounds like
a good idea to get some of the more brave localizers to step in first.
Help should be available on #l10n, and #hg in tough cases. Or follow up
to this thread.
And now we'll take questions...
Axel
Nick Thomas
Robert Kaiser
> All apps (but fennec, fwiw) will focus on the 1.9.1 tree for
> development. I'll detail for Firefox and leave thosee details up for the
> comm-central heads.
If you're pulling the en-US files (i.e. the source code) from
comm-central, you will automatically have the mozilla/ subdirectory
moving to 1.9.1, possibly renaming the current copy of mozilla-central
that is in there to .mozilla.trunk/ (this latter part is currently being
worked out and not final yet).
In any case, comm-central will not branch itself yet, but use the 1.9.1
copy of the core Mozilla repository - and also the l10n-mozilla-1.9.1
localizations.
At some later point, when Thunderbird and SeaMonkey (and Sunbird) will
be stabilizing more towards the releases, we will branch as well and
move comm-central back to mozilla-central as well as L10n back to
l10n-central. You can either keep your mail, suite and calendar
localizations up to date on both l10n-mozilla-1.9.1 and l10n-central or
only copy your updated work from 1.9.1 back to -central when we branch,
that's up to your localization teams.
This is the first time we're going through this process, so problems
might come up here and there, but we're learning as we go and trying to
make this as smooth as possible.
Any open questions about the comm-central part of this? Simon and me
will be happy to help you with advice as far as we can.
Robert Kaiser