383297 - only Repack the shipped locales

Status: RESOLVED WONTFIX

(Release Engineering :: General, defect, P3)

Description

[Nick Thomas [:nthomas] (UTC+12)]

In the mozconfigs for the l10n repack we have set
  mk_add_options MOZ_CO_LOCALES=all
which usually includes a few languages that didn't make the cut and leads to "busted" entries in the log.

If we teach the TinderConfig step to set the list of shipped locales then we save a little time on the repack process, and any busted will be for real. Special care will be needed with the ja/ja-JP-mac and other special cases.

Comment 1

[Robert Helmer [:rhelmer]]

Nick, could we use Bootstrap::Config::Bump() for this (the same way we bump versions in the tinder-config.pl)?

Comment 2

[Robert Helmer [:rhelmer]]

(In reply to comment #1)
> Nick, could we use Bootstrap::Config::Bump() for this (the same way we bump
> versions in the tinder-config.pl)?

Er, yeah you mention using TinderConfig so that must be what you're thinking :)
Yes I think we can do that, I'd set this to block the tracking bug but set it P3 (not going to do optimization until we get end-to-end up and working).

Comment 3

[[e-mail] (:bhearsum)]

This is more important than it was before; currently, anytime 'ar' doesn't get tagged Repack will fail to do _any_ repacking because the val-tags CVS file isn't updated. This looks like an old, known issue. Preed blogged about it awhile ago: http://weblogs.mozillazine.org/preed/2006/10/a_case_of_the_mondays_on_a_wed.html

I'm working around this right now, but I'd like to fix this soon.

Comment 4

[Robert Helmer [:rhelmer]]

(In reply to comment #0)
> In the mozconfigs for the l10n repack we have set
>   mk_add_options MOZ_CO_LOCALES=all
> which usually includes a few languages that didn't make the cut and leads to
> "busted" entries in the log.
> 
> If we teach the TinderConfig step to set the list of shipped locales then we
> save a little time on the repack process, and any busted will be for real.
> Special care will be needed with the ja/ja-JP-mac and other special cases.


The substitution is easy (we already bump mozconfig for l10n for tag and CVSROOT), the only wrinkle here is that the config bumper is only able to substitute values that exist in the config file.

I guess what we need is for Config::Bump to intercept a particular variable like "%shipped-locales%", and process shipped-locales file, returning the valid locales for the current platform.

Comment 5

[Robert Helmer [:rhelmer]]

So maybe this will seem a little nutty; but why don't we just track the locales we want to ship in the mozconfig, instead of using shipped-locales? Either that, or let's get shipped-locales directly supported from the l10n target.. any thoughts?

Comment 6

[Axel Hecht [:Pike]]

I suggest to WONTFIX this one. The idea that we only build those locales that we actually ship is way too optimistic.

What we need to do is build, then QA, and then decide what we ship. I'm not saying that shipped-locales is the right solution, really. All I'm saying is that we don't know the number of shipped locales before build time in general.

Comment 7

[Robert Helmer [:rhelmer]]

(In reply to comment #6)
> I suggest to WONTFIX this one. The idea that we only build those locales that
> we actually ship is way too optimistic.
> 
> What we need to do is build, then QA, and then decide what we ship. I'm not
> saying that shipped-locales is the right solution, really. All I'm saying is
> that we don't know the number of shipped locales before build time in general.

Axel, are you suggesting that we build all locales? Currently, what we do is tag only those locale directories in l10n/l10n that we intend to ship, which causes all of the undesired locales to fail during build.

This is a very clunky way of doing it :) However we need a list somewhere to check against. We've been using shipped-locales, and making sure that it is landed and tagged with the initial release tag; but if we do it the way I think you're suggesting, then we need to build everything have a post-QA list of locales that we intend to ship, and key updates and verification off of that (we could retag shipped-locales I suppose).

Comment 8

[Axel Hecht [:Pike]]

I wonder if we should cut the discussion out of this bug, but just to not let this bitrot.

We have a chicken-egg problem for new languages. Build wants the set of good locales, QA wants good builds. Sounds like a Gordian knot, anyone got a knife?

On the stable branch, this is only pretty bad, but I blame part of our suckage in taking new languages to this knot. On trunk, where things are more agile and fragile, we should just really build all.

Not sure, maybe we should tag with candidate first, and then retag after we have the final set or something.

Comment 9

[Robert Helmer [:rhelmer]]

Not sure about what to do here, sounds like maybe this is WONTFIX and a process change, but need to discuss further.

Returning this to the pool for now.

Comment 10

[Nick Thomas [:nthomas] (UTC+12)]

Not a useful optimisation --> WONTFIX