Axel Hecht [:Pike] Reporter
	Description • 15 years ago

There should be a try-server setup to create all our l10n deliverables with the corresponding test runs for a patch, for example to the build system.

All platforms for that branch should be run, as well as all code paths we use to build, including langpacks, zips, installers, mars, branding choices as suitable for that branch.

This should be set up such that the try server can't diverge from the non-try setup.

Not sure which set of locales would be good. all-locales would be one choice, but it's unlikely that we're actually testing all locales, so some intersection between all-locales and "common suspects" sounds more appropriate. Possibly "ar de es-ES fr he ja ja-JP-mac x-testing". That covers the languages I and my folks speak as well as some edgecases, and x-testing if we need something special.

	Armen [:armenzg] Assignee
	Comment 1 • 15 years ago

Futuring for now but I have added it for possible Q4 goals since this is good to avoid surprises for releases

	Chris Cooper [:coop] (he/him)
	Comment 2 • 15 years ago

Mass move of bugs from Release Engineering:Future -> Release Engineering. See
http://coop.deadsquid.com/2010/02/kiss-the-future-goodbye/ for more details.

	Armen [:armenzg] Assignee
	Comment 3 • 14 years ago

Hi Axel,
I am looking at this bug and would like to understand better how do you see this system functioning.
From reading it I get the impression that you want these to be run every time a developer checks in OR at least for every change that modifies the build system. For the later, which files should we watch for? Should this be for the release path?
Why do you want this for the try server instead of for branches?

	Axel Hecht [:Pike] Reporter
	Comment 4 • 14 years ago

I guess in today's world, it should be an option as are the test and talos runs. Either all or selected locales, or maybe just selected locales.

Recent examples would be: Layout fixes for RTL, or the omnijar builds.

The example back then was l10n repack failures on windows, IIRC.

For the code path, the nightly factories would probably be nice, I guess with incremental updates generated against the latest mozilla-central build.

And yes, this should be try, and not project branch, those should work out of the box if someone wanted to switch them on, right?

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

Axel: given that l10n happens as a repack, would you want the facility to point at an existing en-US base build or build en-US from source (or both)? Using an existing en-US build would obvious speed things up.

Armen: as we discussed, in terms of TryChooser syntax we'd probably want something like "--l10n LIST" where LIST would default to a short list, possibly just x-testing. How we implement that on the back-end will be interesting.

	Axel Hecht [:Pike] Reporter
	Comment 6 • 14 years ago

I expect the common use-case for this to be repacks of try-server builds. I don't think that there's an overwhelming use-case for that to happen post-hoc.

Also, I expect that try-syntax get's really ugly if you end up having to specify the ftp dir explicitly.

There are two design features I'd like to see here:

- the sourcestamp of the repacks should be that of the try build.
- we probably don't want three slaves to take off and clone the try repo to do repacks. So setting up the repack-on-try such that it's dispatching repacks to slaves cleverly might be the trickiest piece.

I'd not default the locales list to anything, fwiw. If you really had to, maybe to 'it,he', italian is somehting that folks can still read and usually quite up-to-date, and then add a RTL locale. But really, I'd try to kill the try-request if there's no list of locales given.

	bhearsum@mozilla.com (:bhearsum)
	Comment 7 • 14 years ago

It will be a lot easier to do these kind of tweaks after bug 608005 lands.

	Armen [:armenzg] Assignee
	Comment 8 • 14 years ago

I still would like to work on this old bug if possible (in case any releng wanted to grab one of my old bugs)

	Armen [:armenzg] Assignee
	Comment 9 • 14 years ago

@triagefollowup

On this bug we are trying to have l10n builders to test changes that can affect repackaging of locales.

The triggered try jobs should trigger L10n repackages to see if anything has been regressed.

I suggest the number of locales triggered be:
- "ar de es-ES fr he ja ja-JP-mac x-testing" if no locale is specified
- "all" if all locales are specified
- custom list - if a list of locales are given

	Lukas Blakk [:lsblakk] use ?needinfo
	Comment 10 • 14 years ago

I'm putting this to WONTFIX. I don't believe try is the right place for enabling this kind of pre-check. Bug 545742 addresses having nightly release automation runs and once that is enabled it will catch all kinds of potential regressions in our automation including repack issues. When that bug is resolved we will gain more coverage without doing the work of turning something on in try that could drain resources available and lengthen result wait times or be a lot of work for minimal use. Either scenario is not as appealing as release automation regression coverage.