Closed
Bug 485363
Opened 17 years ago
Closed 15 years ago
setting enable_l10n = False in config.py does not completely disable l10n
Categories
(Release Engineering :: General, defect, P3)
Release Engineering
General
Tracking
(Not tracked)
RESOLVED
DUPLICATE
of bug 508672
People
(Reporter: bhearsum, Unassigned)
Details
(Whiteboard: [l10n])
To help cope with a much smaller pool of slaves we set enable_l10n to False for mozilla-central. As it turns out, all this seems to do is not create the builders. The next time someone checked into mozilla-central that was supposed to trigger l10n builds the Scheduler failed to submit it, because the builders did not exist, but kept submitting the job over and over to the dep/unittest/leak test builders.
It looks like all of the l10n bits in master.cfg are protected behind 'if branch['enable_l10n']' code, so I'm not quite certain what's going on here.
It looks like the Scheduler in l10n.py doesn't verify that its builders exist at config time, which isn't very happy making.
Updated•17 years ago
|
Assignee: nobody → ccooper
OS: Mac OS X → All
Priority: -- → P3
Hardware: x86 → All
Comment 1•16 years ago
|
||
Not going to have time to tackle this soon.
Assignee: ccooper → nobody
Component: Release Engineering → Release Engineering: Future
Updated•16 years ago
|
Whiteboard: [l10n]
Comment 2•16 years ago
|
||
Mass move of bugs from Release Engineering:Future -> Release Engineering. See
http://coop.deadsquid.com/2010/02/kiss-the-future-goodbye/ for more details.
Component: Release Engineering: Future → Release Engineering
| Reporter | ||
Comment 3•15 years ago
|
||
This will be fixed when l10n.ini is gone from buildbot-configs, happening in bug 508672
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → DUPLICATE
| Assignee | ||
Updated•12 years ago
|
Product: mozilla.org → Release Engineering
You need to log in
before you can comment on or make changes to this bug.
Description
•