So, the plan is two fold. We aim to lay foundations for future automation improvements at the same time as fixing immediate-term issues in the overall automation problem space. So, to that end, here is what we aim to do.

Immediate Term - Q1 2013

Solve Immediate term capacity problems

• [jmaher, rail] - Get Linux tests running in VMs to improve our current linux wait times, and free up real linux hardware to be repurposed for windows jobs
  • Needs changes to OF/Tbpl/LogParser/etc (can we make it so it's sustainable to add new platforms in the future (perhaps a version 1.5 vs. 2)) so that we can track intermittent issues and filter them by machine name/type (list of issues only happening on vms/hardware)
• [mcote] - Regenerate the goFaster dashboards to understand where our performance bottlenecks are and to monitor them for regressions/improvements as we make changes to the overall build/test automation
• [jmaher, ted] - Complete work to have manifests on mochitests so that all test harnesses have some kind of manifest file so that we can more easily change the set of tests we are running based on various conditions (i.e. type of machine - vm or hardware) without having to code in those changes to makefiles
• (releng) Possible aid with buildbot schedulers and/or mozharness & mozbase to enable releng to move away from some of the hardcoded assumptions in the buildbot codebase.
• (releng) Per push trychooser style syntax for project branches to control which tests are run?

Longer Term Q1/Q2 2013

TBPL v2 - jeads driving

• Gather requirements from stakeholders, primary requirement is to move to real database, with one pass log parsing, and ability to pull in job result data from other (non-buildbot) sources
• Build TBPL v2
• See https://wiki.mozilla.org/Auto-tools/Projects/TBPL2

Bisect in the Cloud - automatedtester driving

• Gather requirements and needs and ensure that any foundational work is addressed in Q1
• TODO: Follow up with releng to see how to integrate this with their scheduler work changes, and how we can help to lay groundwork for scheduler changes as part of this
• Build system, reporting etc so that it is well-integrated into TBPL v2 but is accessible and usable without working with the TBPL v2 UI interface. (In other words, should be a stand alone REST based web service that is used by TBPL)

User Workflow Integration with Bugzilla - dkl driving

• Gather requirements, understand where Autoland didn't go far enough (and perhaps where it tried to go too far) - Q1
  • Build plan toward a full integration solution where BMO is a central "traffic stop" in the work flow from creating patch, to submitting to review, submitting to try, to getting review, and landing in tree. Break down into full project and determine what the deliverable schedule should be.