Closed Bug 863050 Opened 9 years ago Closed 5 years ago

in-tree all-locales for simplified merge days

Categories

(Release Engineering :: General, defect)

x86
macOS
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INCOMPLETE

People

(Reporter: aki, Unassigned)

References

Details

(Whiteboard: [kanban:engops:https://mozilla.kanbanize.com/ctrl_board/6/3416] )

Right now, we have browser/locales/all-locales, and it contains the locales to repack for that branch.

On merge day, any changes that went into that file get merged into the downstream branch, which is fine as long as we want all of those changes merged.
When we consider having a subset of locales upstream, merge day becomes a bit hairy.

To avoid this, Armen landed https://bugzilla.mozilla.org/show_bug.cgi?id=654152 , which points buildbot at buildbot-configs files rather than in-tree files.  We'd like to consider moving those files back into the tree for more visibility and to simplify merge days.

We could have four files:

browser/locales/all-locales-mozilla-central
browser/locales/all-locales-mozilla-aurora
browser/locales/all-locales-mozilla-beta
browser/locales/all-locales-mozilla-release

They all live on all four of those branches.  We only use the branch-specific file, so all-locales-mozilla-beta on beta, for example.  We can also make changes to the downstream-branch-specific files if we want those changes to take effect on merge day. This has the nice property of allowing us to prepare for merge day well in advance.

Some complications:

* It looks like browser/locales/l10n.ini looks at all-locales (sans branch name).
** Maybe on merge day we move a link or edit that file?  That seems less onerous than keeping lists of locales somewhere.
** Is this only used by the dashboard?  Or the repack process as well?

* We also have shipped-locales, which we may need two copies of.
** Shipped-locales was from before rapid-release. Do we ever have shipped-locales be different to the all-locales on mozilla-release? Could we delete shipped-locales, and only use all-locales-mozilla-release?

* ESR branches will most likely require some additional merge day tweaking, since there is no all-locales-mozilla-esr{17,24} in the above list.
** Maybe point at the mozilla-release file?
** Luckily this is a one time hit per 7 release cycles, especially since we do zero locale updates on ESR branches.
** Maybe create all-locales-mozilla-esr (without version#17,24)... and only update the mozilla-esr from mozilla-release every new ESR cycle?

* We have to have release automation, nightly automation, and the l10n dashboard know about these files.
I don't think this is a strict blocker, since we already have a file per branch.
Adding as a soft blocker.
Blocks: 657789
Can we have the discussion on what to do here in .planning or .l10n?
(In reply to Axel Hecht [:Pike] from comment #2)
> Can we have the discussion on what to do here in .planning or .l10n?

Started the thread.
Depends on: 863257
Depends on: 863259
Product: mozilla.org → Release Engineering
No longer blocks: 657789
Whiteboard: [kanban:engops:https://mozilla.kanbanize.com/ctrl_board/6/3416]
I only see the buildbot-configs files being referenced for thunderbird. I'm going to mark this as "INCOMPLETE" right now.

The idea of splitting the all-locales out for merge-day is an interesting one, but I wonder how much that will hold valuable given other improvements/changes coming.

https://dxr.mozilla.org/build-central/source/buildbot-configs/mozilla/thunderbird_config.py#731
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → INCOMPLETE
Component: General Automation → General
You need to log in before you can comment on or make changes to this bug.