Closed
Bug 852553
Opened 12 years ago
Closed 12 years ago
Specify a standard destination dir for l10n clones
Categories
(Release Engineering :: General, defect, P2)
Release Engineering
General
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: coop, Assigned: coop)
Details
(Whiteboard: [l10n])
Attachments
(3 files)
4.78 KB,
patch
|
armenzg
:
review+
coop
:
checked-in+
|
Details | Diff | Splinter Review |
3.06 KB,
patch
|
armenzg
:
review+
coop
:
checked-in+
|
Details | Diff | Splinter Review |
3.05 KB,
patch
|
armenzg
:
review+
coop
:
checked-in+
|
Details | Diff | Splinter Review |
We don't specify a destination dir in the automation, so when we clone the l10n repos, we end up with clones in branch-specific locations.
We are now using mozconfigs for l10n repacks. Because these destination dirs are referenced in these in-tree mozconfigs, we end up with branch-specific entries for --with-l10n-base that need to be modified during uplift on merge days.
We should start specifying a single destination dir for l10n clones that is invariant across branches.
Comment 1•12 years ago
|
||
Assignee | ||
Updated•12 years ago
|
Status: NEW → ASSIGNED
Priority: -- → P2
Assignee | ||
Comment 2•12 years ago
|
||
All l10n repos will now get cloned to a standard l10n/ dir under the base work dir. This removes the need to make branch-specific changes to the l10n-mozconfig files during uplift/merge days.
Patch for the mozilla-central mozconfigs is coming up. I should be able to uplift this patch trivially to aurora, beta, and release because it's NPOTB on beta and release.
Attachment #746551 -
Flags: review?(armenzg)
Assignee | ||
Comment 3•12 years ago
|
||
Attachment #746560 -
Flags: review?(armenzg)
Assignee | ||
Comment 4•12 years ago
|
||
Attachment #746564 -
Flags: review?(armenzg)
Assignee | ||
Comment 5•12 years ago
|
||
re: testing - I've created successful repacks in staging for all platforms for both Firefox and Thunderbird on both central and aurora.
http://dev-master01.build.scl1.mozilla.com:8044/one_line_per_build
Updated•12 years ago
|
Attachment #746551 -
Flags: review?(armenzg) → review+
Updated•12 years ago
|
Attachment #746560 -
Flags: review?(armenzg) → review+
Updated•12 years ago
|
Attachment #746564 -
Flags: review?(armenzg) → review+
Assignee | ||
Comment 6•12 years ago
|
||
Comment on attachment 746551 [details] [diff] [review]
[buildbotcustom] Clone l10n repos to a standard 'l10n' dir regardless of branch
https://hg.mozilla.org/build/buildbotcustom/rev/c0fe7edf6ab7
Attachment #746551 -
Flags: checked-in+
Assignee | ||
Comment 7•12 years ago
|
||
Comment on attachment 746560 [details] [diff] [review]
[mozilla-central] Set l10n base dir to l10n/ in mozconfigs
https://hg.mozilla.org/mozilla-central/rev/8b3f78b002c2
Attachment #746560 -
Flags: checked-in+
Assignee | ||
Comment 8•12 years ago
|
||
Comment on attachment 746564 [details] [diff] [review]
[comm-central] Set l10n base dir to l10n/ in mozconfigs
https://hg.mozilla.org/comm-central/rev/f3ce31d62e7c
Attachment #746564 -
Flags: checked-in+
Assignee | ||
Comment 9•12 years ago
|
||
Landed with DONTBUILD and a=NPOTB on the following branches:
https://hg.mozilla.org/releases/mozilla-aurora/rev/1d3000010fdf
https://hg.mozilla.org/releases/mozilla-beta/rev/f935a7970137
https://hg.mozilla.org/releases/mozilla-release/rev/760eb84d4d7b
https://hg.mozilla.org/releases/comm-aurora/rev/576b6de8e072
https://hg.mozilla.org/releases/comm-beta/rev/ad1616a375e0
l10n builds don't get triggered by regular pushes, so it seemed a waste to do otherwise.
Comment 10•12 years ago
|
||
in production
Assignee | ||
Updated•12 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 11•12 years ago
|
||
(In reply to Alex Keybl [:akeybl] from comment #1)
> https://wiki.mozilla.org/Release_Management/
> Merge_Documentation#Until_bug_852553_is_fixed
I've removed this section from the Merge doc now.
Updated•11 years ago
|
Product: mozilla.org → Release Engineering
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
•