Auto-tools/Projects
Welcome to the Automation and Tools Projects Page.
We are the people who write the code that enables all our automated test systems (correctness, performance etc) to run. We are continually expanding, upgrading, and inventing new and better ways to do automated quality analysis at Mozilla. Most of our systems run on a per-checkin basis, and at the time of this writing we do roughly 300 checkins a day, and we run hundreds of thousands of tests per checkin, so you can imagine how many times our code gets run. If you like the idea of that kind of a challenge, we could use your help on some of the projects below. If you don't know how to get started, feel free to hop on irc (irc.mozilla.org), into the channel #ateam and ask some questions.
The Goals
Every calendar quarter, we figure out how best to support Mozilla's efforts and translate that into a set of goals. Most of our goals these days have tracking bugs. So if you want to directly help us the most, look through those tracking bugs and find a bug you can start hacking on. Ask in #ateam if you need help.
2014
| Goal List | Post-Mortem | Notes |
| 2014 Q4 | ||
| 2014 Q3 | ||
| 2014 Q2 | ||
| 2014 Q1 |
2013
| Goal List | Post-Mortem | Notes |
| 2013 Q4 | Awaiting scheduling | Pulled together the highest priority items into the "top list" on goals page to help focus |
| 2013 Q3 | 2013 Q3 Postmortem | Quarter felt very unfocused, company wide goals done differently, had some impact on us. |
| 2013 Q2 | No postmortem performed | |
| 2013 Q1 | No postmortem performed |
Other Projects
Every quarter there are more things we'd like to do than we have time for. Below are some of these projects, broken down by areas and technologies so that you can find something that gets you excited.
Overview
Work in progress effort to create an index for all existing/WIP automation tools - Here.
Guidelines
The guidelines are evaluated based on the link we have to documentation (wiki, readme.md, readthedocs, etc.) This link should contain the information or in the first page of text have a link to additional information so that we can easily learn about the project.
Guidelines for what to include in project documentation:
- The goals of the project
- Why the project is important to Mozilla and/or the A-Team
- Dependencies on other projects/teams, and its place in the greater ecosystem
- List out who to contact, mentors, active developers
- Documentation for how to use the project (or how it will be used)
- How to setup / develop / test the project
- Milestones and features to be developed (bugzilla table, link to well annotated github issues, etc.)
- Good first bugs and how to get started (bugzilla table, link to well annotated github issues, etc.)
- How to submit a patch
- Coding style guidelines and expectations
When setting the priority of a project, consider this scale as a starting point:
- 1 - This is a stated goal for the current quarter | There are active people working on this | Other projects/teams depend on this completing
- 2 - There are active people working on this | We are committed to delivering at least one milestone in the current quarter
- 3 - This is an project that we and others believe would be beneficial to Mozilla, but we haven't promised to deliver it on a specific timeline. There are clear plans and maybe a prototype of one or more milestones to start with
- 4 - This is a good idea or a project that we worked on in the past which could use maintenance. We don't have resources for this now, but still feel it is a valuable project!
Firefox for Android
The Firefox for Android project is a continual expansion of our test harnesses to better support the Android platform. Currently we only release Firefox on that platform (aka Fennec), but we might also begin testing web apps there in the near future. Familiarity with Android and a great knowledge of Python is very useful here.
- Help expand our reach to x86 Android systems by aiding us in debugging and fixing test failures on that platform: see the collection of bugs beneath bug 891959
Firefox Desktop and General Automation Support
The desktop web browser Firefox continues to be our flagship product, and there is always ongoing work needed to ensure that we continue to support the new features that regularly land in Firefox. Many of the bugs here are more tractable simply because the test harnesses and tests involved are older code. This is a good spot for first-time contributors. These will involve Python knowledge and some JavaScript, depending on the bug.
- Complete the fixes required to deploy Structured Logging
- Expand our QA automation infrastructure to test about-to-release and localized versions of Firefox
- Help make mozharness easier for external contributors
Performance
We also maintain all the systems and the code that perform per-checkin testing on performance. There are many performance automation systems at Mozilla, and one of our current efforts is to pull them under one high-level dashboard. Performance will demand a working knowledge of the web, Python, JavaScript, statistics, and great debugging skills.
Tools & Dashboards
We create web-based tools and dashboards to help illustrate how our automation is doing. Datazilla is a performance dashboarding system, and Treeherder surfaces the status of our automation runs. We also maintain and continually improve Mozilla's Bugzilla installation, often contributing patches to the upstream general Bugzilla project. Python, JavaScript, and, in Bugzilla's case, Perl, are all used here, along with both relational and NoSQL databases.
- Help create the next version of TBPL, code named Treeherder
- Help out with Pulse, our message-queuing system
- Help out with bugzilla.mozilla.org
- Uncover trends and patterns by analyzing our failure trends in Ouija
- Help create a tool to triage mozilla performance alerts
- (Mozbench) Help create a cross-browser performance benchmark
- (Autoland) Help create a service that automatically lands changesets that pass try runs
- (Mozregression) Help out on a tool used to track down Firefox regressions
ATeam Handbook
The ATeam Handbook is meant to be the definitive source of information on how we do things in the ateam, useful for new and old contributors alike. Currently in the planning phase.
Mentored Bugs
These bugs are things that we have identified as great starter bugs. Each bug contains a focused technology that is required and a mentor who has volunteered to help out people starting to work on the issue. If you've done a few mentored bugs, talk to your mentors about becoming a mentor yourself!
39 Total; 39 Open (100%); 0 Resolved (0%); 0 Verified (0%);
For reference, the old Projects Page (which is largely out of date, but interesting for historical reasons) is accessible here