1083893 - Enable l10n repacks for Alder from 33.0 release branch

Status: RESOLVED FIXED

(Release Engineering :: General, defect)

Description

[Chris AtLee [:catlee]]

For Alder we want to use the strings associated with the 33.0 release.

the repack factory supports an l10nTag argument, but we don't pass that in anywhere. It's probably sufficient to add an "if branch == 'alder':" block in misc.py for this.

Comment 1

[Axel Hecht [:Pike]]

cp-n-paste from the main alder bug:

It'd be nice to get builds for all locales off of the 33 release tag/branch on the l10n release repos.

In case that doesn't work, we should use a reduced list on the default branch of the l10n release repos, for a reduced list of languages for which we have a good state on default.

That's the list with the privacy button:

ast, da, de, en-GB, es-AR, es-CL, es-ES, es-MX, fi, fr, fy-NL, he, hu, it, ja, ja-JP-mac, ko, lv, nb-NO, nn-NO, pa-IN, pl, pt-BR, rm, ru, sk, sl, zh-TW

plus some to test that the privacy buttons switches off if the localization doesn't have it. Let's use 

ach, af

for that, we should be good with spot-testing that, and those two have their sign-off on the latest revision.

Comment 2

[Justin Wood (:Callek)]

Per IRC with dolske,

This doesn't directly block any work on alder today, however is a nice to have.

I will try to accomplish today, before my EOD, but I won't "stay late" to accomplish, as such I expect to get this done no later than monday, and will plan on triggering new nightlies+repacks once done.

Comment 3

[Justin Wood (:Callek)]

Attachment: [configs] add alder l10n

...yes this file being in buildbot-configs stinks.

Comment 4

[Rail Aliiev [:rail]]

Comment on attachment 8507985 [details] [diff] [review]
[configs] add alder l10n

Do we still want to repacks using in-tree branches for l10n?

Comment 5

[Justin Wood (:Callek)]

(In reply to Rail Aliiev [:rail] from comment #4)
> Comment on attachment 8507985 [details] [diff] [review]
> [configs] add alder l10n

https://hg.mozilla.org/build/buildbot-configs/rev/80b33b478a80


> Do we still want to repacks using in-tree branches for l10n?

Not sure what this question means...

Comment 6

[Rail Aliiev [:rail]]

(In reply to Justin Wood (:Callek) from comment #5)
> > Do we still want to repacks using in-tree branches for l10n?
> 
> Not sure what this question means...

I thought that the idea behind this bug is to use in-tree branches (not default) for the l10n repos, so we can land the 33.1-specific string changes to those branches without touching default.

Comment 7

[Justin Wood (:Callek)]

(In reply to Rail Aliiev [:rail] from comment #6)
> (In reply to Justin Wood (:Callek) from comment #5)
> > > Do we still want to repacks using in-tree branches for l10n?
> > 
> > Not sure what this question means...
> 
> I thought that the idea behind this bug is to use in-tree branches (not
> default) for the l10n repos, so we can land the 33.1-specific string changes
> to those branches without touching default.

Ahh, I couldn't find a good way to do relbranches for l10n here.

Specifically we are using localeURL which does support |'revision' or self.baseTag| however at http://mxr.mozilla.org/build/source/buildbotcustom/l10n.py#199 we are explicitly passing revision as 'ss.revision' which is the sourcestamp of the nightly itself, ala the alder rev, which won't give us a valid rev, or a valid locales file.

Thus we're stuck on `default` here.

Per IRC and above, Pike is ok with using default as long as the list of locales match that in c#1.

Comment 8

[Chris Cooper [:coop] (he/him)]

In production: https://hg.mozilla.org/build/buildbot-configs/rev/80b33b478a80

Comment 9

[Chris AtLee [:catlee]]

Had to land https://hg.mozilla.org/build/buildbot-configs/rev/32f8aadb2a94 for obscure reasons that we'll fix up later.

Comment 10

[Chris Cooper [:coop] (he/him)]

In production: https://hg.mozilla.org/build/buildbot-configs/rev/32f8aadb2a94

Comment 11

[Justin Wood (:Callek)]

Ok, based on current ftp, this last change worked. We have a full set of alder l10n now.

Only untested thing is that they update, but I don't expect *any* issues there.