Set up l10n bumper for ESR Fennec branch
Categories
(Release Engineering :: Release Automation: L10N, task)
Tracking
(firefox70 fixed)
| Tracking | Status | |
|---|---|---|
| firefox70 | --- | fixed |
People
(Reporter: flod, Assigned: mozilla)
References
Details
Attachments
(1 file)
In order to be able to take updated translations in Fennec 68 ESR, we need to uplift the list of changesets used by the build system, e.g. https://hg.mozilla.org/releases/mozilla-beta/file/default/mobile/locales/l10n-changesets.json
Doing it manually is less than ideal.
Would it be possible to set up the l10n bumper on the ESR branch, only for Fennec?
There's a tricky part: Fennec ESR is not available on l10n.mozilla.org, so we'll have an actual version number, and will need to update it periodically in the bumper's config.
That unless we somehow want to map ESR versions to Gecko versions (68.1.x -> 69, 68.2.x -> 70, etc.).
|
Assignee | |
Comment 2•5 years ago
•
|
||
Would it be possible to set up the l10n bumper on the ESR branch, only for Fennec?
I think it's doable.
We've been wanting to port all of the l10n_bumper tasks to treescript + cron hooks. This may be a good opportunity for that long term fix, though that piece of work will likely be larger than just adding esr configs + cron to our existing mozharness+puppet setup. (And if we're significantly updating treescript, we may want to also move it into our scriptworker-scripts monorepo and move to GCP + docker. Filed scriptworker-scripts#5 to track.)
There's a tricky part: Fennec ESR is not available on l10n.mozilla.org, so we'll have an actual version number, and will need to update it periodically in the bumper's config.
That unless we somehow want to map ESR versions to Gecko versions (68.1.x -> 69, 68.2.x -> 70, etc.).
There are a few questions around this.
- How long are we planning on landing new strings for Fennec? If we don't intend on doing to after 68.0esr (first 6 weeks), we may get away with just using 68.
- Currently we're sharing the same l10n-changesets.json file across the nightly, beta, and release Fennec builds. Is that still ok?
- We have 3 different sets of android version files in esr68. Will the release version match m-r, or will it match desktop esr? (e.g., will we have Fennec 69.0, or Fennec 68.1.0?) If the former, we can just use that version. If the latter, yes, we'll need to do something to find which strings to use.
- If the latter, we could potentially add the major and minor versions together (e.g. 68.1.0 -> 68 + 1 -> 69)
I'm out tomorrow (Friday Jul5) through next week, and it looks like I'm going to spend most of my time today dealing with mac notarization issues.
|
Reporter | |
Comment 3•5 years ago
|
||
(In reply to Aki Sasaki [:aki] (he/him) (UTC-7) (Away Jul5-Jul14) from comment #2)
- How long are we planning on landing new strings for Fennec? If we don't intend on doing to after 68.0esr (first 6 weeks), we may get away with just using 68.
https://docs.google.com/document/d/1oRPkwP3l7QzdQYj0Wn7d_3EfTZaakocA_i_pGKlG0dI/edit
The document say Gecko 70, since we want to start removing code in 71.
- Currently we're sharing the same l10n-changesets.json file across the nightly, beta, and release Fennec builds. Is that still ok?
Bumper is not set up for release, so it's frozen on the last version of Beta.
What is Beta using as reference? If it's using Gecko's version, then we should be good.
Having said that, the same sign-off would work for all shipping version.
- We have 3 different sets of android version files in esr68. Will the release version match m-r, or will it match desktop esr? (e.g., will we have Fennec 69.0, or Fennec 68.1.0?) If the former, we can just use that version. If the latter, yes, we'll need to do something to find which strings to use.
Pretty sure it will be 68.x.0, but Ryan can confirm. Also, I don't think desktop and mobile release dates are necessarily tied to each other at this point?
I'm out tomorrow (Friday Jul5) through next week, and it looks like I'm going to spend most of my time today dealing with mac notarization issues.
I think that's still OK, we should be weeks away from a 68.1 release (I assume).
|
||
Comment 4•5 years ago
|
||
(In reply to Aki Sasaki [:aki] (he/him) (UTC-7) (Away Jul5-Jul14) from comment #2)
- How long are we planning on landing new strings for Fennec? If we don't intend on doing to after 68.0esr (first 6 weeks), we may get away with just using 68.
In the project plan doc, we'd previously set a deadline of August 26 for landing any Fennec-affecting strings. Nobody seemed to have objections to that at the time, so maybe we can stick with that? Maybe worth running past the Mobile Product folks.
- Currently we're sharing the same l10n-changesets.json file across the nightly, beta, and release Fennec builds. Is that still ok?
Should be fine. For all 3 channels, we're planning to bump the version number at the start of the cycle. So in the event of a dot release, we'd just end up relbranching off an earlier commit.
- We have 3 different sets of android version files in esr68. Will the release version match m-r, or will it match desktop esr? (e.g., will we have Fennec 69.0, or Fennec 68.1.0?) If the former, we can just use that version. If the latter, yes, we'll need to do something to find which strings to use.
Per above, we can safely assume that all 3 channels will be the same base version (i.e. 68.1, 68.2, etc). The only difference will be the inclusion of a1 for Nightly and bN for Beta.
|
|
Reporter | |
Comment 5•5 years ago
|
||
(In reply to Ryan VanderMeulen [:RyanVM] from comment #4)
(In reply to Aki Sasaki [:aki] (he/him) (UTC-7) (Away Jul5-Jul14) from comment #2)
- How long are we planning on landing new strings for Fennec? If we don't intend on doing to after 68.0esr (first 6 weeks), we may get away with just using 68.
In the project plan doc, we'd previously set a deadline of August 26 for landing any Fennec-affecting strings. Nobody seemed to have objections to that at the time, so maybe we can stick with that? Maybe worth running past the Mobile Product folks.
Andrea, is this still the plan?
|
|
Assignee | |
Comment 6•5 years ago
|
||
I:
-
added l10n_bumper functionality to the new monoscript version of treescript. This will be our future solution for l10n bumping. However, due to outside requirements, we won't switch over soon enough to resolve this bug in the short term. I'll be submitting this patchset for review elsewhere.
-
added a quick hack into l10n_bumper.py to allow for using the major+minor versions in the l10n_dashboard (e.g., 68.1.0 -> 69, 68.2.0 -> 70)
-
added a quick mozilla-esr68 config file
-
tested the config on bb01, without pushing, and got
bn -> 27ef86515251 dsb -> 009dedd9a331 en-CA -> 8b6e7bf5bec0 es-ES -> 35a21d259060 es-MX -> ea2cc1d2aedd eu -> 4e13c883ea55 fi -> c7baaa4b862c fr -> 56cd07059971 gn -> 1bcbf75033e3 hi-IN -> 90ae1a185264 hr -> 09cc31597087 hsb -> 6dc856ea94b9 hu -> 440b6da4ca6d it -> c55b6394e2bd kab -> fb55e6083da0 kk -> 1af4b29f9498 ko -> 264f9c270d44 lij -> 627d91a8ad54 lo -> ff8d31a74e02 nb-NO -> a4a057056cb2 nl -> 231bbcf2c9d2 nn-NO -> 4131e31dc2e9 pt-BR -> cf2331678100 pt-PT -> fb2999fc7104 sk -> 90568ec879bd sl -> 375641b3af29 sr -> bc638c7ea351 sv-SE -> 06134b59b194 tr -> 89e40658b40c trs -> 10ce570995eb uk -> 7384f904aef9 vi -> 94dfd7478544 zh-CN -> d097aa6d35e5 zh-TW -> 118871907695
I'll submit the l10n_bumper.py and mozilla-esr68.py config file for review here.
|
|
Assignee | |
Comment 7•5 years ago
|
||
Pushed by asasaki@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/5b21e285d546 fennec l10n bumping on esr68. r=Callek
|
||
Comment 9•5 years ago
|
||
| bugherder | ||
|
||
Comment 10•5 years ago
|
||
I think there's a misunderstanding.
We don't intend to support 68.x on elmo, and we won't even have automation set up against ESR. The idea behind this bug was to use the sign-off process against mozilla-beta, and to land that l10n-changesets state on esr68 for Fennec.
That is, use 69 right now, and after the next merge day, use 70.
|
|
Assignee | |
Comment 11•5 years ago
|
||
Yes, that's why we're using 68.1.0 -> 68 + 1 -> 69 type logic. When we bump to 68.2.0, that will be 68 + 2 (major + minor) -> 70.
|
|
Assignee | |
Comment 12•5 years ago
|
||
|
|
Assignee | |
Updated•5 years ago
|
|
||
Updated•5 years ago
|
Description
•