tree and review rules for all-locales changes
Axel Hecht
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
remotely.
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
af
de
zh-CN
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?
Axel
mco...@mozilla.com
mostly irrelevant to anyone except l10n, so I'm fine with checkins by
you at any time on any branch.
Obviously shipped-locales is different.
-- Mike
> _______________________________________________
> dev-tree-management mailing list
> dev-tree-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tree-management
Axel Hecht
> My take is that where the file lives isn't really relevant, and it's
> mostly irrelevant to anyone except l10n, so I'm fine with checkins by
> you at any time on any branch.
>
> Obviously shipped-locales is different.
Cool, thanks.
Which leads to the next question, what's a good policy for
shipped-locales [1]? (And l10n-changesets [2] 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,
[1]
http://hg.mozilla.org/releases/mozilla-1.9.1/file/tip/browser/locales/shipped-locales
[2]
http://hg.mozilla.org/build/buildbot-configs/file/tip/mozilla2/l10n-changesets
maybe my confusion in thinking about the right policy is just a sign of
having unfortunate implementation in the back end?
Axel