I wanted to get your opinion on what reviews etc I should get for
changes to all-locales.
That file is somewhat NPOB, as it doesn't affect the en-US build even
As for the l10n build, it does affect the hg poller on the buildbot, and
it causes builds to be run, but in today's infrastructure, it shouldn't
have an impact on builds of other locales.
Let alone that it's a file like
and thus really hard to break.
I'd love to just treat it as NPOB and be able to land on non-busted
trees, and with proper approval on 1.9.1.
What do you think?
Obviously shipped-locales is different.
> dev-tree-management mailing list
Which leads to the next question, what's a good policy for
shipped-locales ? (And l10n-changesets  for that matter, ignoring
the fact that we have fragments of the same information in two files in
two different repos)
In the end, those patches just implement paper work based on more
complex patches and procedures that, if applicable, have undergone review.
The information coming in would be
- opt-in of the localizer to be shipping, with a given changeset
- green builds on various build systems (which is in flux)
- some level of cross platform testing, per traction of mail discussions
between l10n-drivers and the localization team
- traction on the bugs towards de-beta, in case of adding to beta
Addition and removal of locales actually requires follow up to change
product-details on the web to actually expose the changes to the builds
on the web.
The one line changes in shipped-locales and/or l10n-changesets don't
really reflect any of that.
What they do reflect would be
- for shipped-locales:
platform specifics, i.e., platform specific rendering bugs (aside
ja-JP-mac). Hard to actually gauge when/if those are blocking shipping
- for l10n-changesets:
which source stamp to actually build. helps us to separate non-Firefox
landings from testing Firefox source stamps.
As per our previous discussion on how to do stable releases on hg,
changes to l10n-changesets should actually depend on testing of the
nightlies, and a technical source-level review of the changes of the
localizer by the techies in l10n-drivers.
I'm far from claiming that I like the current setup of shipped-locales
here and l10n-changesets here,
maybe my confusion in thinking about the right policy is just a sign of
having unfortunate implementation in the back end?