Axel Hecht [:Pike] Assignee
	Description • 14 years ago

For the drop from aurora to beta, we'll need to make sure that l10n does the right thing in a fashion that doesn't require humans.

Details in http://etherpad.mozilla.com:9000/SBFhPavxMN.

I'll start hacking up on this.

	Axel Hecht [:Pike] Assignee
	Comment 1 • 14 years ago

http://hg.mozilla.org/users/axel_mozilla.com/branch-l10n/

This is an hg extension (merge-l10n) that does the actual closing of the head if necessary on default. It also pulls from default. Here's how the process would work:

In an hg with merge-l10n on:

hg clone mozilla-beta/ab-CD
cd ab-CD
hg merge-l10n http://hg.mozilla.org/releases/l10n/mozilla-aurora/ab-CD/
hg push -f

The -f is necessary because push is creating a new head.

This comes with tests for four scenarios, building on top of each other. There are upstream repos, and working clones for localizers and release. Scenarios are

Empty repos. (Fails in a defined way, as there's no default revision to pull, *)
One commit on aurora
Two commits on aurora, pulled into beta each
One commit on aurora, pulled into beta, another hg changeset landed on both beta and aurora, and pulled
One commit on aurora, pulled into beta, one commit on aurora, other commit on beta, pulled, beta head dropped
One commit on aurora, pulled, one commit on beta and none on aurora. Pulled and does nothing. (**)

This is all automated in tests.py, which also installed the default hooks and all. There's a webdir.conf to show all repos at the end of the test run. Only the latest working copies for localizer and release stay.

Tested on a virtualenv with hg 1.5.4, which according to ted is what we're running on hg.m.o right now.

(*) the empty fail is due to me pulling explicitly just 'default'. That's more of a design decision than anything else. We can change that. I don't have good arguments other than "don't pollute beta repos with stuff we won't build".
(**) The scenario in which nothing landed on aurora, but a fix landed on beta is edge case. Closing the head would happen as soon as it's a distinct leaf on a later cycle. The right revisions to use are still available through signoffs. Sounds like the right thing to just leave the beta repo as is in this case. Counter arguments?
(***) Do we need an explicit revision to pull as an option? I could hack up an API on the dashboard to get "current push state at specified time for all repos", but I'm not sure if this is really a problem. The whole process shouldn't take all that long, in particular if run close to hg.m.o. How long does tagging all locales usually take? Should be the same order of magnitude. Also, having a particular version would be nice if we end up running the merge at a significantly later time than announced.

Whom should I flag for review and comments how?

	Armen [:armenzg]
	Comment 2 • 14 years ago

(In reply to comment #1)
> (***) Do we need an explicit revision to pull as an option? I could hack up an
> API on the dashboard to get "current push state at specified time for all
> repos", but I'm not sure if this is really a problem. The whole process
> shouldn't take all that long, in particular if run close to hg.m.o. How long
> does tagging all locales usually take? Should be the same order of magnitude.
> Also, having a particular version would be nice if we end up running the merge
> at a significantly later time than announced.
> 
I can only answer the question wrt how long tagging takes. That is around 25 mins for 1.9.1, 22 mins for 1.9.2/2.0.

	bhearsum@mozilla.com (:bhearsum)
	Comment 3 • 13 years ago

Mass move of bugs to Release Automation component.

	bhearsum@mozilla.com (:bhearsum)
	Comment 4 • 12 years ago

These merges are handled by humans on the RelMgmt team.