Bugzilla

> 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](https://github.com/mozilla-releng/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.)

> 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](https://hg.mozilla.org/releases/mozilla-esr68/file/tip/mobile/android/config/version-files). 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.

> 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](https://github.com/mozilla-releng/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.)

> 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](https://hg.mozilla.org/releases/mozilla-esr68/file/tip/mobile/android/config/version-files). 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.

> 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](https://github.com/mozilla-releng/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](https://github.com/escapewindow/scriptworker-scripts/issues/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](https://hg.mozilla.org/releases/mozilla-esr68/file/tip/mobile/android/config/version-files). 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.