Platform
Current plans: Platform/2024PlannedWork
The remainder of this page is historical from 2023 and earlier.
Tantek (tantek.com) 22:28, 12 December 2022 (UTC)
HISTORICAL CONTENT 2023 AND EARLIER
HISTORICAL CONTENT 2015 AND EARLIER
This wiki page is devoted to the planning, scheduling, and documenting of meetings, discussions, and status of the Mozilla platform teams.
Contents
Planning
- See The Platform Planning Page for notes on upcoming releases and planning events. (NOTE: this used to be the Post1.9Planning Spreadsheets for all releases after 1.9.).
- See also Firefox/Namoroka#Firefox.next Platform Requirements and its talk page.
- See also the Wanted page for a few items wanted by extension/application developers
Bug Triage
Regression Engineering Owner (REO)
Time Commitment: 1 hour a week for the meeting + 1 hour a week for skimming bugs through bugzilla, over the entire duration of the version from Nightly to Release (usually 8 weeks). Be aware being able to attend the Weekly Regression Triage Meeting is a requirement of being an REO.
Every release has an assigned Regression Engineering Owner whose responsibilities include:
- be a partner for release management's Release Manager assigned to the same release
- ensure a decision is made about each regression reported in the release
- push for the responsible team to fix it
- back related changes out
- ship with it
- delay shipping
- keep a mental state of how we are doing with regressions in a release
- pay close attention to release-drivers mailing list
- run the weekly regression triage meeting
Weekly Regression Triage Meeting
- Weekly on Tues 08:00-09:00 (US/Pacific) in Zoom: https://mozilla.zoom.us/j/683008149
- #reo on Slack for backchannel
- REO for each active release goes through the bug queries for their release and sees if something requires a needinfo or email to a relevant party
- Security bugs are handled in their own triage process
- driving down the numbers on the Release Health Dashboard is a nice output
- in case it's necessary, here are the owners associated with bugzilla components
Asynchronous Regression Tracking
- Engineering managers and component owners keep track of regressions, especially the new ones. They look through the list for bugs in their components and set the tracking flags for a particular release to reflect their plans for the bug, leaving an explanation in the bug when the status is changed:
- affected: this regression should be fixed in this particular release (it must be assigned);
- wontfix: we will not take a fix for this regression in this particular release;
- fix-optional: we will take a fix if one appears, but otherwise it will go unfixed in this release;
- ?: we should talk about this bug in triage
Crash Bug Triage
- 1-10 position in release: needs an owner, tracking release, needs a fix
- 11-30 position in release: needinfo component owner looking for an owner to investigate
- 31-50 position in release: case-by-case, mostly fix-optional
- Above 50: mark as fix-optional
- Check for exploitability - you may want to file the bug as security sensitive
Bugzilla Queries
General Queries
Created Last 90 Days
Modified Last 90 Days
Flagged Bugs
New Regressions
Criteria
Keywords | regression |
status-firefox (this version) | affected |
status-firefox (previous version) | unaffected, implying this is a new regression |
tracking-firefox (this version) | not "-" (tracked or untriaged) |
Carry Over Regressions
Criteria
Keywords | regression |
status-firefox (this version) | affected |
status-firefox (previous version) | affected (or related) |
tracking-firefox (this version) | not "-" (tracked or untriaged) |
Bug Lists
Note: for non-recent regressions (let's say, more than 5 releases old) rather than remove the `regression` keyword please set the status to `fix-optional` across the board. This will remove it from the Regression triage radar, but still allow the bug to be tracked by others as a regression.
Regression Engineering Owner Schedule
Regression Engineering Owners (REOs) are tracked on internally on the REO rotation by director sheet and on the Release Owners wiki page
Platform Team Goals
2015 | Q1 Goals | Q2 Goals | Q3 Goals | Q4 Goals |
---|---|---|---|---|
2014 | Q1 Goals | Q2 Goals | Q3 Goals | Q4 Goals |
2013 | Q1 Goals | Q2 Goals | Q3 Goals | Q4 Goals |
2012 | Q1 Goals | Q2 Goals | Q3 Goals | Q4 Goals |
2011 | Q1 Goals | Q2 Goals | Q3 Goals | Q4 Goals |
2010 | Q1 Goals | Q2 Goals | Q3 Goals | Q4 Goals |
2009 | Q1 Goals | Q2 Goals | Q3 Goals | Q4 Goals |
2008 | Q1 Goals | Q2 Goals | Q3 Goals | Q4 Goals |
2007 | - | Q2 Goals | Q3 Goals | Q4 Goals |
Meeting Notes
Create a new weekly agenda from the template: <createbox> align=left type=create preload=Platform/0-0-0 default=2024-11-12 prefix=Platform/ </createbox>
2015
2014
2013
2012
2011
2010
2009
2008
2007
Mozilla Platform Functional Groups
Some teams have their own meetings during the week to discuss specific issues:
Platform Active Projects
Current major feature or initiatives in Platform
All Platform pages
Visit Special:PrefixIndex/Platform/ to see all subpages of "Platform" on wiki.mozilla.org.