setting enable_l10n = False in config.py does not completely disable l10n

RESOLVED DUPLICATE of bug 508672

Status

Release Engineering
General
P3
normal
RESOLVED DUPLICATE of bug 508672
9 years ago
4 years ago

People

(Reporter: bhearsum, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [l10n])

(Reporter)

Description

9 years ago
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

9 years ago
Assignee: nobody → ccooper
OS: Mac OS X → All
Priority: -- → P3
Hardware: x86 → All

Comment 1

9 years ago
Not going to have time to tackle this soon.
Assignee: ccooper → nobody
Component: Release Engineering → Release Engineering: Future

Updated

8 years ago
Whiteboard: [l10n]

Comment 2

8 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

8 years ago
This will be fixed when l10n.ini is gone from buildbot-configs, happening in bug 508672
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 508672
(Assignee)

Updated

4 years ago
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.