Road to great justice for schedulerdb!

Test cases

Description	Manually tested?	Automated test in place?	Notes
Builds should happen after a checkin
Nightly en-US build should trigger repacks after build is done
Change to locale repo should trigger a single repack
Nightly builds should get fired
Release l10n repacks should get fired
Queued changes / builds are restored after restarting buildbot master
Multiple masters can share the same database for the same builders
Test that sendchanges between masters is working
Test that nomerge changes aren't getting merged (e.g. talos runs, unittest runs, l10n repacks)

Timeline

Week of March 1st
- deploy new python, twisted toolchain on staging master, talos staging master
- deploy current buildbot tip on staging master and slaves, start testing current patches (see test cases to exercise above)

Week of March 8th
- deploy current buildbot tip on talos staging master and slaves, start testing current patches

TBD Buildbot 0.8.0 release or backporting of db features to 0.7.12+
- would only backport to 0.7.12 if 0.8.0 takes too long to release

TBD Python / twisted upgrade on slaves
- Not strictly necessary to do, but feels right thing to do.
- has the potential to break builds (if e.g. part of build doesn't work with python 2.6). If needed, we could isolate build tools from system tools.

TBD Deployment of buildbot onto production build masters and slaves
- Python / twisted upgrade on production build masters (going to python 2.6.4, twisted 9.0.0 or 9.0.1). twisted can be deferred

TBD Deployment of buildbot onto production talos masters and slaves
- Python / twisted upgrade on production talos masters (going to python 2.6.4, twisted 9.0.0 or 9.0.1). twisted can be deferred

The current try server code doesn't need to be touched, since all that code is going to be integrated into the main configs, which should "just work".

Talos can be handled later if required. Its scheduling is pretty straightforward. It's also a good piece to test in parallel with the build bits.