Auto-tools/Projects: Difference between revisions
No edit summary |
(New firefox ui tests project) |
||
| Line 40: | Line 40: | ||
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. | 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. | ||
* [https://bugzilla.mozilla.org/show_bug.cgi?id=916295 Complete the fixes required to deploy Structured Logging] | * [https://bugzilla.mozilla.org/show_bug.cgi?id=916295 Complete the fixes required to deploy Structured Logging] | ||
* [[Auto-tools | * [[Auto-tools/Projects/Firefox_UI_Tests|Expand our QA automation infrastructure to test about-to-release and localized versions of Firefox]] | ||
* [[Auto-tools/Projects/Mozharness|Help make mozharness easier for external contributors]] | * [[Auto-tools/Projects/Mozharness|Help make mozharness easier for external contributors]] | ||
Revision as of 13:43, 8 August 2015
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
See our goals page.
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
The a-team maintains many of the systems and 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, called Perfherder. A working knowledge of the web, Python, JavaScript, statistics, and great debugging skills would be helpful.
- See: Perfherder
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
- (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!
40 Total; 40 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