Auto-tools/Goals/2014Q4

	THIS PAGE IS A WORKING DRAFT
	The page may be difficult to navigate, and some information on its subject might be incomplete and/or evolving rapidly. If you have any questions or ideas, please add them as a new topic on the discussion page.

Top Level Goals

A list of high priority goals we're committed to achieving in Q4. This is a draft version; a final version will be posted by Oct 14, 2014.

Firefox

Multi-binary devtools harness [ted]

Prototype a test harness which enables developers to run tests involving Firefox and another binary, such as Chrome, Safari, or a Firefox OS Device.

• why: So we can provide a mechanism to test devtools against targets other than self in continuous integration; currently most testing is semi-manual.
• bug 1064253
• Project page: TBD

Mozmill e10s [TBD]

QA runs a valuable set of release tests on Firefox using Mozmill, which is not e10s compatible. More details TBD.

Developer Productivity

Autoland [dminor]

Deliver a functional prototype of the Autoland service that can be used for dogfooding.

• why: Developer productivity gains across the board, since this would reduce the amount of time required by developers to land a patch.
• bug 1043010
• Project page: https://wiki.mozilla.org/Auto-tools/Projects/Autoland

ReviewBoard [mcote]

Deploy ReviewBoard for developers to start using (joint with RelEng) (carryover from Q3)

• why: across the board improvement in developer ergonomics for all gecko developers
• bug 515210
• Project page: https://wiki.mozilla.org/Auto-tools/Projects/CodeReviewTool

Investigation of a wiki plugin for bug charts [ekyle]

Investigate the work needed to deliver a self-serve wiki feature to do simple bugzilla charting, like burn-down rates based on searches.

• why: Sustainability: make some types of charts self-serve, so we don't have to implement every request ourselves.
• bug: N/A
• Project page: will be created as a deliverable for this work.

Performance

Games benchmarking on Firefox OS [dminor]

Port an existing mozbench games benchmark to work with a FirefoxOS device.

• why: Performance of these benchmarks on Firefox OS devices is important to the Platform group, and this will allow us to measure that.
• bug 1066657
• Project page: https://wiki.mozilla.org/Auto-tools/Projects/Mozbench

Deploy the dzAlerts server to production [ekyle]

Deploy the server that hosts dzAlerts (performance alerts based on Datazilla data) into production, so it's more accessible and maintainable.

• why: Sustainability: currently, the server that hosts these is accessible only by its developer, and is thus a maintenance risk.
• bug 1023372
• Project page: https://wiki.mozilla.org/Auto-tools/Projects/Alerts

Make Talos compatible with e10s [wlach]

Adapt Talos to work with Firefox in e10s mode, and get Talos tests running in e10s mode scheduled on trunk branches.

• why: Allow engineering to run Talos tests in e10s mode, so they can quantify performance issues.
• bug 1050706
• Project pages: https://wiki.mozilla.org/Electrolysis, https://wiki.mozilla.org/Buildbot/Talos

Monitor and file bugs for Talos performance regressions [jmaher]

We will monitor the Alert Manager for regressions in Talos tests and file bugs as needed. Sometime post-Q4 we will roll this into the normal sheriffing workflow, after we have the tooling to support that.

• why: To make performance regressions actionable.
• bug: N/A
• Project page: https://wiki.mozilla.org/Auto-tools/Projects/AlertManager

Treeherder

Sheriff and developer improvements [jeads, mdoglio, camd, edmorley]

Continue to improve sheriff and developer workflows in Treeherder so we can effectively obsolete TBPL in the future.

• why: To make sheriffing easier with Treeherder and to make Treeherder a suitable replacement for TBPL for the general Mozilla community.
• bugs: bug 1059400
• Project page: https://wiki.mozilla.org/Auto-tools/Projects/Treeherder

Bugzilla

Support for gmail transition [glob]

Identify and implement bugzilla features that are needed for the company to transition to using gmail as our mail service.

• why: To support the company's Gmail transition.
• bug: TBD
• Project page: https://mana.mozilla.org/wiki/display/IPPP/GMAIL+Project+Page

Prototype alternate bug views [glob]

Prototype some alternate bug views which can both decrease page load times and improve the user experience for specific use cases.

• why: Improve Bugzilla's speed and usability.
• bug: bug 1068655
• Project page: N/A

General Automation

mochitest-chrome for B2G [gbrown]

Developers have requested that we add support for running the mochitest-chrome harness on FirefoxOS, so that they can write chrome-related tests without using hacky and problematic SpecialPowers workarounds in mochitest-plain.

• why: This would allow developers to write better mochitests for B2G.
• bug 797164
• Project page: N/A

Scope the consolidation of non-buildbot tests [bc]

We have several separate test suites that run on independent systems, like Autophone, Eideticker, mozbench, power profiling tests, etc. Each of these requires separate maintenance and feature development. We will scope the effort involved in consolidating different aspects of these, including test scheduling, test reporting, Android and Firefox OS device maintenance, and the use of buildbot for desktop tests, so we can determine whether or not we should attempt such a consolidation in 2015.

• why: Sustainability: each of our non-buildbot systems has a separate set of maintenance costs. By consolidating, we could reduce these, and potentially make the creation of new non-buildbot harnesses easier and faster.
• bug: N/A
• Project page: will be created as a deliverable for this work.

Move more mozharness config info into the tree [armenzg]

We want to move more config details that mozharness uses from the mozharness repo into the tree.

• why: It helps us move faster by allowing us to test a greater number of things on try; it reduces the review burden on RelEng; it sets the stage for unifying mach and mozharness.
• bugs: bug 1067535, bug 1070041
• Project page: https://wiki.mozilla.org/User:Armenzg/Proposals/Mozharness_changes

Community

A-Team Boot Camp [wlach]

Create a set of documentation to help onboard new contributors and others to working with the automation that the A-Team maintains.

• why: Make the A-Team more accessible to community members, and reduce the time we spend mentoring contributors on basic tasks.
• bug: N/A
• Project page: TBD

Make our projects contributor-friendly [jgriffin, all]

By the end of the quarter, all projects which are continuing to Q1 should be "contributor-friendly"...with a Project Page, up-to-date docs, etc.

• why: Make the A-Team's projects more accessible to community members, with the hope of increasing community engagement in more complex projects, and extending the span of a contributor's involvement.
• bug: N/A
• Project page: N/A

Potential Goals

These are set of goals we're considering for top-level goals in Q4:

• Adding more features to Test Informer
• C++ code coverage
• Additional ReviewBoard work
• TBD depending Platform Planning meetings

Supporting and Ongoing Tasks

A list of ongoing and supporting tasks that the A*Team is actively engaged in. The delivery date for these will vary depending on the resource requirements of our Top Level goals, as well as the amount of support requests that come in during the quarter, and their respective priorities.

See the list in our Trello board.

Backlog

We maintain a sizable backlog of tasks that we think are important to do, or that we've been asked to do, but for which we don't have resources to work on this quarter.

See the list in our Trello board.