bhearsum@mozilla.com (:bhearsum) Reporter
	Description • 14 years ago

Once bug 608004 is fixed we can find some way to divide nightly repack work (per platform) across multiple builders, triggering 1 build on each for a set of repacks.

	Armen [:armenzg]
	Comment 1 • 14 years ago

What is the ETA for this?

I would like to know if it is worth adding retry ability to the current L10n nightly code or wait for this to happen.

	Aki Sasaki (not active)
	Comment 2 • 14 years ago

Ben already got this working for mobile:
http://hg.mozilla.org/build/tools/file/default/scripts/l10n/nightly_mobile_repacks.sh

I think this should be a usable model for desktop.

	John O'Duinn [:joduinn] (please use "needinfo?" flag)
	Comment 3 • 13 years ago

found in triage.

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

Part of the motivation behind this bug is to get the nightly l10n builders using the same code as the release ones again. We could fix _that_ part by using these scripts but not chunking: eg, 1 locale per job, just like the current nightly builders. That could be a nice way to do it until we figure out the Tinderbox reporting story.

	Chris Cooper [:coop] (he/him)
	Comment 5 • 12 years ago

Now that tinderbox is out of the picture for l10n, our reporting story is much simpler.

What I'd like to see here as an end state, which is an amalgam of many bugs:
* chunked nightly repacks (this bug)
* single script for nightly and release repacks, preferably in mozharness
* use pre-built mar and bsdiff (bug 785392)
* use mozconfigs (bug 774947)
* Windows release repacks on Win64 (bug 849019)

I don't want to explicitly block this bug on the above, but it seems like a logical (if large) chunk of work. It also seems pretty well-defined with known-good end states to match against. Intern project?

	bhearsum@mozilla.com (:bhearsum) Reporter
	Comment 6 • 10 years ago

bug 740142 is moving nightly l10n to mozharness, and chunking them.