use l10n-changesets.json for all mobile l10n fx53+

RESOLVED FIXED

Status

defect
RESOLVED FIXED
3 years ago
6 months ago

People

(Reporter: aki, Assigned: aki)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(7 attachments, 3 obsolete attachments)

59 bytes, text/x-review-board-request
rail
: review+
Details
59 bytes, text/x-review-board-request
rail
: review+
Details
59 bytes, text/x-review-board-request
rail
: review+
Details
798 bytes, patch
mtabara
: review+
Details | Diff | Splinter Review
707 bytes, patch
mtabara
: review+
Details | Diff | Splinter Review
3.45 KB, patch
rail
: review+
Details | Diff | Splinter Review
901 bytes, patch
rail
: review+
Details | Diff | Splinter Review
We have 3 types of locale files for mobile:

- all-locales is a flatfile with the locales to single-locale repack in CI/nightly
- maemo-locales is a flatfile with the locales to multilocale build in nightly
- the l10n changesets json with the locales, revision, and platform list (multi / single)

mozharness doesn't particularly care which one you use; they're all equally parseable.

Since we're going to do TC nightlies and TC releases in a very similar manner, and since we're bumping the l10n-changesets.json on mozilla-beta (meaning we can point at the in-tree copy during releases), let's point at that file for everything mobile on Fx53+.  Single locale, multilocale, and releases.
(In reply to Rail Aliiev [:rail] ⌚️ET from comment #2)
> You also need to touch the merge day scripts, where we revert the list of
> locales when uplift to aurora:
> 
> https://dxr.mozilla.org/mozilla-central/source/testing/mozharness/configs/
> merge_day/central_to_aurora.py#59-64
> https://dxr.mozilla.org/mozilla-central/source/testing/mozharness/scripts/
> merge_day/gecko_migration.py#328-334

I think I covered that in https://hg.mozilla.org/try/rev/4fe13b1059847803d3e9759a304fb2123f3b7829 :)
Duplicate of this bug: 1337875
Axel, would you be open to this approach? It does require some l10n.ini and compare-locales changes.
Flags: needinfo?(l10n)
Removing the ni? since it's covered by the r?
Flags: needinfo?(l10n)
See Also: → 1337825
Sorry, but we decided a while ago that we'll go the other way around, and filed bug 1280730 to implement that.
Comment on attachment 8837938 [details]
bug 1339706 - remove maemo-locales.

https://reviewboard.mozilla.org/r/112936/#review114486
Attachment #8837938 - Flags: review?(l10n) → review-
Comment on attachment 8837936 [details]
bug 1339706 - use l10n-changesets.json for everything mobile l10n.

https://reviewboard.mozilla.org/r/112932/#review114488
Attachment #8837936 - Flags: review?(l10n) → review-
Attachment #8837937 - Flags: review?(rail)
Keywords: leave-open
Attachment #8837936 - Attachment is obsolete: true
Attachment #8837937 - Attachment is obsolete: true
Attachment #8837938 - Attachment is obsolete: true
Oops, I forgot to add l10n-changesets.json to the list of files.  Updated patchset incoming.
Ok. Latest try graph went green for multilocale.  Signing failed on Try, because we don't have automatic scope setting yet (I have an idea how to do this) and Chain of Trust refuses to do nightly signing on Try.  Ready for review!
Comment on attachment 8838273 [details]
bug 1339706 - update mozharness configs and scripts for l10n-changesets.json.  a=release

https://reviewboard.mozilla.org/r/113222/#review114820

::: testing/mozharness/scripts/merge_day/gecko_migration.py:366
(Diff revision 2)
> +            self.run_command(
> +                hg + ["revert", "-r", end_tag, f],
> +                cwd=dirs['abs_to_dir'],
> +                error_list=HgErrorList,
> +                halt_on_failure=True,
> +            )

I think we could also invoke the l10n bouncer here, the l10n dashboard should have all the right data.

"Here" being after the version bump, I guess?

No idea if that's readily approachable from the merge script, just putting this out there.

Reverting the l10n-changesets may be OK for the B1 build, but obviously we really want to the l10n bouncer to have done its work before we go to build for B1.
I didn't do a full review, but I glanced at the patches, and haven't found anything unexpected after our chat yesterday.

Just left one food-for-thought about aurora->beta merge above.
Comment on attachment 8838272 [details]
bug 1339706 - l10n-bumper should build platforms from in-tree files.  a=release

https://reviewboard.mozilla.org/r/113220/#review114912
Attachment #8838272 - Flags: review?(rail) → review+
Comment on attachment 8838307 [details]
bug 1339706 - add l10n-changesets.json.  a=release

https://reviewboard.mozilla.org/r/113262/#review114914
Attachment #8838307 - Flags: review?(rail) → review+
Comment on attachment 8838273 [details]
bug 1339706 - update mozharness configs and scripts for l10n-changesets.json.  a=release

https://reviewboard.mozilla.org/r/113222/#review114916

::: testing/mozharness/scripts/merge_day/gecko_migration.py:366
(Diff revision 2)
> +            self.run_command(
> +                hg + ["revert", "-r", end_tag, f],
> +                cwd=dirs['abs_to_dir'],
> +                error_list=HgErrorList,
> +                halt_on_failure=True,
> +            )

I'm a bit concerned about this part. We rarely want to keep the same list of beta-only locales for multiple cycles, and sometimes we add new locales in aurora. If we have new locales in aurora, they would be killed by this block, but re-added right away in an hour or so after the next l10n bumper run. In this case we don't probably want to start a release build using the reverted list of locales and the old changesets. I'd say kill this block.

Otherwise lookg great to me!
(In reply to Rail Aliiev [:rail] ⌚️ET from comment #29)
> Comment on attachment 8838273 [details]
> bug 1339706 - update mozharness configs and scripts for l10n-changesets.json.
> 
> https://reviewboard.mozilla.org/r/113222/#review114916
> 
> ::: testing/mozharness/scripts/merge_day/gecko_migration.py:366
> (Diff revision 2)
> > +            self.run_command(
> > +                hg + ["revert", "-r", end_tag, f],
> > +                cwd=dirs['abs_to_dir'],
> > +                error_list=HgErrorList,
> > +                halt_on_failure=True,
> > +            )
> 
> I'm a bit concerned about this part. We rarely want to keep the same list of
> beta-only locales for multiple cycles, and sometimes we add new locales in
> aurora. If we have new locales in aurora, they would be killed by this
> block, but re-added right away in an hour or so after the next l10n bumper
> run. In this case we don't probably want to start a release build using the
> reverted list of locales and the old changesets. I'd say kill this block.

Ok. I'll submit a new patch.  This will mean that after we run the merge script and before the bumper runs, we'll have the same locale list as aurora, but they'll all be pinned to "default", which is not what we want on beta.  So we'll need to run the bumper after we run the merge day script either way.
(In reply to Axel Hecht [:Pike] from comment #25)
> ::: testing/mozharness/scripts/merge_day/gecko_migration.py:366
> (Diff revision 2)
> > +            self.run_command(
> > +                hg + ["revert", "-r", end_tag, f],
> > +                cwd=dirs['abs_to_dir'],
> > +                error_list=HgErrorList,
> > +                halt_on_failure=True,
> > +            )
> 
> I think we could also invoke the l10n bouncer here, the l10n dashboard
> should have all the right data.
> 
> "Here" being after the version bump, I guess?
> 
> No idea if that's readily approachable from the merge script, just putting
> this out there.
> 
> Reverting the l10n-changesets may be OK for the B1 build, but obviously we
> really want to the l10n bouncer to have done its work before we go to build
> for B1.

I think I agree with you if we s,bouncer,bumper, :)  I think the bumper needs to run after the merge day script.
Comment on attachment 8838273 [details]
bug 1339706 - update mozharness configs and scripts for l10n-changesets.json.  a=release

https://reviewboard.mozilla.org/r/113222/#review114956
Attachment #8838273 - Flags: review?(rail) → review+
https://hg.mozilla.org/projects/jamun/rev/08e73179637619eec3df1e5fa03f932be4c4b2dd
bug 1339706 - l10n-bumper should build platforms from in-tree files. r=rail a=release

https://hg.mozilla.org/projects/jamun/rev/5676335379597329b8c4208d3087ed02742df5dd
bug 1339706 - update mozharness configs and scripts for l10n-changesets.json. r=rail a=release
Let's start bumping jamun with the new jamun revision.
Attachment #8838672 - Flags: review?(mtabara)
Comment on attachment 8838672 [details] [diff] [review]
puppet-jamun-bumper.diff

Sure you don't want to grab the latest one 8a757bcfe789 containing the multi configs fix?
Attachment #8838672 - Flags: review?(mtabara) → review+
Either way. I just need the l10n bumper changes.
Oops, let's also use the new jamun config, rather than bumping mozilla-beta.
Attachment #8838701 - Flags: review?(mtabara)
Comment on attachment 8838701 [details] [diff] [review]
jamun-config.diff

Review of attachment 8838701 [details] [diff] [review]:
-----------------------------------------------------------------

Sorry for having missed that at prior r? ! O_O
Attachment #8838701 - Flags: review?(mtabara) → review+
Enable l10n_bumper on central and aurora.  This is based on the latest mozilla-central mozharness, which has configs for all branches.

This also removes the "creates" in download_mozharness, so a revision/repo change reruns the script even if /builds/l10n-bumper/mozharness already exists.
Attachment #8839252 - Flags: review?(rail)
Attachment #8839252 - Flags: review?(rail) → review+
Duplicate of this bug: 1280730
Status:

* update merge duty + release duty docs
* schedule mozilla-beta l10n-bumper

Those should happen sometime next week.  Otherwise we're done here.
Blocks: 1343393
Two things:
1. is it ok to use a linux test buildmaster for this? all the non-try build masters already have something else going on.
2. do you think it's best to turn this on today/tomorrow, so we have beta l10n bumper before merge day, or turn it on next monday?
Attachment #8843031 - Flags: review?(rail)
Attachment #8843031 - Flags: review?(rail) → review+
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Removing leave-open keyword from resolved bugs, per :sylvestre.
Keywords: leave-open
Component: General Automation → General
You need to log in before you can comment on or make changes to this bug.