canmove, Confirmed users
1,126
edits
Auto-tools/Projects/Futurama/Draft Plan: Difference between revisions
Auto-tools/Projects/Futurama/Draft Plan (view source)
Revision as of 14:47, 7 January 2013
, 7 January 2013→TBPL v2 - jeads driving: Add link to TBPL2 page
(Created page with "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. S...") |
(→TBPL v2 - jeads driving: Add link to TBPL2 page) |
||
| (4 intermediate revisions by 3 users not shown) | |||
| Line 3: | Line 3: | ||
= Immediate Term - Q1 2013 = | = Immediate Term - Q1 2013 = | ||
=== Solve Immediate term capacity problems === | === Solve Immediate term capacity problems === | ||
* 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 | * [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 so that we can track intermittent issues and filter them by machine name/type (list of issues only happening on vms/hardware) | ** 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) | ||
* 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 | * [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 | ||
* 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 | * [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) 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? | * (releng) Per push trychooser style syntax for project branches to control which tests are run? | ||
= Longer Term Q1/Q2 2013 = | = Longer Term Q1/Q2 2013 = | ||
=== TBPL v2 === | === 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 | * 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 | * Build TBPL v2 | ||
* See https://wiki.mozilla.org/Auto-tools/Projects/TBPL2 | |||
=== Bisect in the Cloud === | === Bisect in the Cloud - automatedtester driving === | ||
* Gather requirements and needs and ensure that any foundational work is addressed in Q1 | * 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 | * 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) | * 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 === | === 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 | * 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. | ** 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. | ||