811054 - l10n dashboard (or something else) should have correct locale/changeset lists for releases

Status: RESOLVED WONTFIX

(Mozilla Localizations :: Infrastructure, defect)

Description

[[e-mail] (:bhearsum)]

For as long as I can recall, the l10n dashboard has returned incorrect locale lists for release-channel releases. Specifically, it contains locales that are not shipped (and should not be built) for final releases.

We've started automating the kickoff of releases and without accurate l10n information it's not possible to make sure we get things right.

Whether it's on the dashboard or somewhere else, there should be some place that contains the exact l10n changesets to be used for a release. Release automation or engineers should not be special casing locales or doing guesswork to come up with the right list.

I realize that the l10n dashboard was designed explicitly with this use case in mind, but would it be possible to add some secondary view of the same data that would give us what we need? I would be happy to help implement it if pointed to the right place.

Comment 1

[Chris Cooper [:coop] (he/him)]

How hard would it be to create an alternate view here for releng? 

Is the data available via JSON or is the db schema available so that Ben could hack on this as he's offered?

Comment 2

[Axel Hecht [:Pike]]

We don't have the data anywhere outside of human heads, and even there it's not well formalized.

I failed so far to formalize that, given how adding platforms or deliverables change things, and that "beta" means totally different things for 'sw' and 'ta'.

I don't have constructive proposals here. Anything that I've played around with so far opened up scenarios where we'd shoot ourselves in the foot.

Concepts that are hard:

We probably want some tracking for the past.
We need to make decisions for the future. Say, 'sw' *will* go onto the release channel with 21. That of course depends on us keeping that wording/paradigm. Time-based won't work if we slip things or respin firedrills.
Beta for the old 4.0 ones with release-channel beta-web aside with beta-channel-only betas for the new ones is fun.
Should the datascheme also hold the locales we're building, aka, all-locales? maemo-locales? shipped-locales? Right now, neither are proving themselves as good models going forward. Say we change the windows platforms or whatnots.

The whole thing is a weird time-hyper-dimensional thing that has a bunch of unknowns on how things may change in future release concepts and deliverables, and no clear owner on what to rule out/scope in.

Comment 3

[[e-mail] (:bhearsum)]

We worked around this for our release kickoff app, updating deps.

Comment 4

[Lukas Blakk [:lsblakk] use ?needinfo]

We'll talk about this in the RelMan/L10n sync-up meeting on Jan 31 - this has been a constant pain for RelEng, comes up in release Post-Mortesm about kicking off builds, so let's find a solution to implement before Firefox 19 goes to release on Feb 15th.

Comment 5

[Axel Hecht [:Pike]]

Sorry, but assigning a bug to me doesn't enlighten me on what to do. Giving a timeline doesn't matter much either.

Comment 6

[Lukas Blakk [:lsblakk] use ?needinfo]

(In reply to Axel Hecht [:Pike] from comment #5)
> Sorry, but assigning a bug to me doesn't enlighten me on what to do. Giving
> a timeline doesn't matter much either.

Well we can discuss more at the meeting, but it seems like there needs to be a canonical place to get a list of what locales are going to be in a particular version's release - perhaps whatever is in the http://hg.mozilla.org/releases/l10n/mozilla-release list? - and that this can be used to create the custom view of the dashboard for releng (and relman if needed) with a ?product=release tacked on to the url or something like that.  Assigning to you because we need you to confirm and create the way for us to get this information that lives only in your head if you are not reachable in some way during a release.

Comment 7

[Axel Hecht [:Pike]]

We can play this game forever, I'm not taking this bug until I know how to solve it.

Right now, the way to get the data out of my head into the public is by me filing a bug at some reasonable point in time. Anything that I have tested in my head so far is either not working at all, or just as brittle.

Also, I'll be traveling quite a bit in the near future, so I had to cancel the meeting.

Comment 8

[Lukas Blakk [:lsblakk] use ?needinfo]

Let's put this another way - if we didn't remove eg: mn, sw every time we merge beta-> release and instead relied on the dashboard to have those locales not listed in the release l10n changesets, then we could just *not build* those locales - is that possible?

Comment 9

[Axel Hecht [:Pike]]

What happens if shipped-locales is a superset of l10n-changesets in terms of locales in the release automation?

Comment 10

[[e-mail] (:bhearsum)]

(In reply to Axel Hecht [:Pike] from comment #9)
> What happens if shipped-locales is a superset of l10n-changesets in terms of
> locales in the release automation?

If shipped-locales contains locales that aren't in l10n-changesets, release automation will fail in the repack stage when it tries to build those locales (because they won't be tagged).

Comment 11

[Axel Hecht [:Pike]]

'k, that means that for the time being, we can't go without a manual landing as part of release to adjust shipped-locales according to the status on the release channel.

Which, might, impact the idea of repacking the final beta as RC, as they'd be on different changesets conceptually, and the changeset without the only-beta locales would be on release only.

Comment 12

[Francesco Lodolo [:flod]]

I assume this is a WONTFIX at this point?

We have l10n bumper storing changeset information in tree, and I'm not aware of issues with builds and list of locales at this point. If that's not the case, feel free to reopen.