Location/Dial-In

• Physical location: 650 Castro Street, Mountain View
• Room: C3P0/R2D2 on the 2nd Floor
• Mon, Dec 13th, 2:00pm PDT
• 650-903-0800 x92 Conf# 8605 (US/INTL)
• 1-800-707-2533 (pin 369) Conf# 8605 (US)
• join irc.mozilla.org #planning for back channel

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,
• performance issues,
• crashers,
• or 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.

All bugs MUST be triaged; no punting! If you'd like input from beltzner or other product drivers, [d?] to the whiteboard, and we'll scan those lists regularly throughout the week.

Outcome

• minused
• cleared
• targeted for branch release

Teams

The following teams will meet during the week to work through the following queries:

Firefox Front End (some Core)

• led by: johnath, dietrich, dolske
• blocker query: [1]
• nomination query: [2]

• mossop
  • Nominations: [3]
  • Blockers: [4]
• johnath
  • Nominations: [5]
  • Blockers: [6]

Platform

• Content: jst
  • Nominations: [7]
  • Blockers: [8]
• Layout: roc
  • Nominations:[9]
  • Blockers: [10]
• JS: sayrer
  • Nominations: [11]
  • Blockers: [12]
• Graphics: joe
  • Nomination query: [13]
  • Blocker query: [14]
• Other: bsmedberg
  • Nominations: [15]
  • Blockers: [16]
  • Other Product Noms: [17]
  • Other Product Blockers: [18]

Platform items to be triaged by johnath: [19]