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.
Assignee: nobody → ccooper
OS: Mac OS X → All
Priority: -- → P3
Hardware: x86 → All
Not going to have time to tackle this soon.
Assignee: ccooper → nobody
Component: Release Engineering → Release Engineering: Future
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
This will be fixed when l10n.ini is gone from buildbot-configs, happening in bug 508672
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 508672
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.