Closed
Bug 917990
Opened 12 years ago
Closed 9 years ago
compare-locales merge automation
Categories
(Release Engineering :: General, defect)
Release Engineering
General
Tracking
(Not tracked)
RESOLVED
INVALID
People
(Reporter: mozilla, Unassigned)
Details
Currently build/compare-locales is static.
Everything uses the RELEASE_AUTOMATION tag, which has been pointing at the RELEASE_0_9_5 tag since February 2012. No other changes have gone into the repo since, other than release tags. All releng automation uses this repository for l10n.
http://hg.mozilla.org/l10n/compare-locales is the RoR for compare-locales. That's currently on version 0.9.6+. There is no standing plan to merge these changes into build/compare-locales that I know of.
I'd like some way to automatically merge in the l10n/compare-locales changes into build/compare-locales, and auto-bump the revision we use in build/compare-locales.
The latter requirement is tricky: nightly, aurora, beta, release all use RELEASE_AUTOMATION (esr is pointing to RELEASE_0_9_5, which shields it from the RELEASE_AUTOMATION tag moving). Ideally we have a way to bump which revision we use, and have that bump ride the trains. Also, if we can avoid moving tags, that should help with hg-git syncing, since git doesn't support silently updating tags.
Potentially:
* auto-merge l10n/compare-locales to build/compare-locales
** this will hit .hgtags conflicts at first, so we may have to do the below first so we can stop relying on RELEASE_AUTOMATION
* in-tree compare-locales revision
* all automation needs to respect that in-tree compare-locales revision -- release automation especially, but b2g build system, mozharness multilocale, all single locale repacks as well
** the above may allow us to stop tagging compare-locales at all during releases, since tagging the tree will effectively tag which compare-locales revision we use. If so, we might be able to merge the build/compare-locales and l10n/compare-locales fork. (That would be complicated by the fact that we already sync build/compare-locales to git.m.o, and can't have a non-fastforward merge there, but it's possible.)
Reporter | ||
Comment 1•12 years ago
|
||
Looking more like a General Automation bug now.
Component: Repos and Hooks → General Automation
QA Contact: hwine → catlee
Comment 2•11 years ago
|
||
In bug 940103, we're talking about landing compare-locales in mozilla-central. I'm about to do a rather major refactor to get rid of old-days-python-mistakes, and then probably move that ahead.
Maybe that's the better solution than this? Prolly gonna be tedious to get that uplifted to all the places where we'll need it, though.
Reporter | ||
Comment 3•11 years ago
|
||
Hm, I *think* we always have the tree when we do l10n repacks, so that seems fine.
We'll need to keep new compare-locales changes backwards compatible, since the same buildbot automation will be running it against esr as central.
Comment 4•11 years ago
|
||
Noteworthy: I've just cut the (probably) last release on 0.9.x, and I'm now hitting a major refactor towards 1.0.
Things might turn out to be incompatible on that version jump.
0.9.x has a bookmark for reference, and in the case we need a 0.9.x-specific follow up fix.
Comment 5•9 years ago
|
||
This is no longer wanted, compare-locales lives in tree, and code to use it in-tree is riding the trains.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → INVALID
Assignee | ||
Updated•7 years ago
|
Component: General Automation → General
You need to log in
before you can comment on or make changes to this bug.
Description
•