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
•