Set up l10n bumper for ESR Fennec branch

RESOLVED FIXED

Status

task
RESOLVED FIXED
2 months ago
13 days ago

People

(Reporter: flod, Assigned: aki)

Tracking

unspecified

Firefox Tracking Flags

(firefox70 fixed)

Details

Attachments

(1 attachment)

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.).

@Aki
Is this doable?

Flags: needinfo?(aki)

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.

Flags: needinfo?(aki)

(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).

(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.

(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?

Flags: needinfo?(abovens)

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.

Pushed by asasaki@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/5b21e285d546
fennec l10n bumping on esr68. r=Callek
Status: NEW → RESOLVED
Closed: Last month
Resolution: --- → FIXED

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.

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: nobody → aki
Flags: needinfo?(abovens)
You need to log in before you can comment on or make changes to this bug.