Firefox/4/Triage/Retriage: Difference between revisions
(→Teams) |
(→Teams) |
||
Line 47: | Line 47: | ||
** '''Blockers:''' [http://bit.ly/f5ic9V] | ** '''Blockers:''' [http://bit.ly/f5ic9V] | ||
* '''Layout:''' roc | * '''Layout:''' roc | ||
** '''Nominations:'''[http://bit.ly/ | ** '''Nominations:'''[http://bit.ly/g6aQ8L] | ||
** '''Blockers:''' [http://bit.ly/ | ** '''Blockers:''' [http://bit.ly/eMp6s2] | ||
* '''JS:''' sayrer | * '''JS:''' sayrer | ||
** '''Nominations:''' [http://bit.ly/g6ayRd] | ** '''Nominations:''' [http://bit.ly/g6ayRd] |
Revision as of 18:06, 10 December 2010
Context
It is widely felt that the existing blocking list does not reflect the actual critical set of bugs required to complete work on Firefox 4
Action
During the Mozilla Corporation work week of December 13-17, component leads will meet and re-triage all open blockers and nominations to reduce the set to those bugs required to complete critical functionality, repair regressions, and ship the product as soon as possible.
Blocking Criteria
A bug must block Firefox 4 if it...
- is an unintentional regression introduced by Firefox 4,
- is a new crash introduced by Firefox 4,
- is a reproducible sg:crit.
A bug may block Firefox 4 if the triage team believes that it is critical for the completion of the implementation of a feature required for Firefox 4. (Note that in some cases, the appropriate action would be to "unblock" several bugs and back out previous changes, deciding to not ship a half-completed feature.)
Method
Triage teams (see below) will walk through all existing blockers and nominations, marking bugs using the blocking2.0 flag as follows:
- betaN+ bug blocks, and requires a beta cycle for feedback
- final+ bug blocks, does not require beta cycle for feedback
- - bug does not block
Additionally, teams must add the following keywords where appropriate:
- regression for cases where the bug was newly introduced by Firefox 4
- perf for cases where the bug affects performance
- crash for cases where the bug results in a crash
This is so that we can construct queries to see what number of blockers are regressions, or performance issues, as opposed to blockers which are simply work that needs to be done to complete implementation on a feature.
If a triage team wishes to indicate that a bug should be fixed via a maintenance release after shipping Firefox 4, they must:
- set the blocking2.0 flag to .x,
- set the appropriate keywords (regression, perf, crash),
- include a comment indicating if the fix would be "nice to have" or "required"
At some point we will need to triage that list, so the keywords and comments would be very helpful.
Teams
The following teams will meet during the week to work through the following queries:
Firefox Front End
Platform
- Content: jst
- Layout: roc
- JS: sayrer
- Graphics: joe
- Other: bsmedberg
Platform items to be triaged by johath: [13]