Closed Bug 959215 Opened 8 years ago Closed 8 years ago
Missing locales from multi-locale Fennec on mozilla-aurora/android/locales/maemo-locales
The new locales that were added to Aurora in that last year have somehow been reverted. There's no changeset that explains the difference between default and the last edit and the repo graph is linear. Seems like the default branch has been reset somehow, but we have no visibility.
http://hg.mozilla.org/releases/mozilla-aurora/rev/20af7fbd96c1 is the l10n-fixup change from dec 9, and it only changed browser/locales/all-locales http://hg.mozilla.org/releases/mozilla-aurora/rev/d4e29ddb3225 is the l10n-fixup change from Aug 05, and it changed all of browser/locales/[all|shipped]-locales and mobile/android/locales/[all|maemo]-locales. Looks like this is affecting both Desktop and Android 28. FWIW, the reason why we're not seeing anything in history is likely that the merge merge isn't actually a merge, but a ancestor modification, so the meta data in the merge changeset isn't correct. Otherwise, I would expect the merge commit to actually show up in the history here.
In the meantime, should we get a patch that updates maemo-locales with what we want? I assume using the version in mozilla-beta would be fine? Jeff - You make the patch and I review? Unless you want to get someone to do an investigation on the merge and what happened first.
I'm going to take a stab at this, based on https://wiki.mozilla.org/Release_Management/Merge_Documentation#L10n_data_changes. It'll require a bit of tricky as the reset will conflict with what we do in bug 958703
Assignee: nobody → l10n
The actual instructions are https://wiki.mozilla.org/Release_Management/Merge_Documentation#L10n_data_changes_2, fwiw. Those don't work today, as the setancestors step actually drops the tags that are used there. But I figured out the tags, so that's cool. There are two ways to fix this bug, both effectively making the change the attached patch does. One: Use the patch. I found that ugly, and hard. The reason for that is that we have two landings after the l10n data revert, adding xh and an, e0c328d99742, bug 946719; and bug 958703, which removed a host of locales. Two: Use hg. I updated my repo to http://hg.mozilla.org/releases/mozilla-aurora/rev/20af7fbd96c1, which was Alex' "l10n revert", and put a corrected l10n revert on top, creating a new head. I've then merged that, which mostly applied, and makes me actually create a sane patch. Lukas, I've filed bug 959651 to get a working user repo for aurora, so that I can actually show what I have locally. Would landing this as a two-changeset fix make sense to you?
(In reply to Axel Hecht [:Pike] from comment #4) > > Lukas, I've filed bug 959651 to get a working user repo for aurora, so that > I can actually show what I have locally. Would landing this as a > two-changeset fix make sense to you? Yes, whatever we can do so that as much of this merge work can be automated in our helper script would be preferable to having to land a patch each merge. Please do show me what you do and I can get it into the scripts for next merge.
http://hg.mozilla.org/users/axel_mozilla.com/mozilla-aurora/graph/169218 is up now, thanks to Kendall. The merge instructions still imply the right thing, not sure why they didn't work last time. The loss-of-tags issue is something I chatted with aki about in #release-drivers, probably worth catching up with him on that. I'm requesting review/approval on the actual `hg out -p` for this, based on the hg graph. I'll pull --rebase before pushing, which pushes the merge changeset out. Requesting review from Lukas, as well as approval.
Actually, the patch queue. Sorry.
Comment on attachment 8360126 [details] 959215-patch-queue.patch thanks!
https://hg.mozilla.org/releases/mozilla-aurora/rev/abec7056f1ee https://hg.mozilla.org/releases/mozilla-aurora/rev/08fc9fa0a0be Landed, marking FIXED and fixed28
Fantastic! Thank you everyone!
You need to log in before you can comment on or make changes to this bug.