Firefox3/StatusMeetings/2007-11-06/ReleaseDrivers
Our goals here are:
- keeping development focus on *must-fix* bugs
- reducing risk by avoiding risky fixes for low-priority issues
- ensuring we're picking bugs which have a high reward vs. risk tradeoff
- keeping our aim on a high-quality, 1Q2008 release
Schrep, beltzner, mconnor, and I had a series of discussions tonite, and this is what we propose:
- Component owners *MUST* prioritize their bugs immediately, using P1 and P2 to represent a minimal set of bugs required for M10.
- We will add blockingM10 and blockingM11 flags to all components; components which have prioritized their blocker lists will have blockingM10 automatically added to their P1 and P2 bugs.
- Endgame drivers can refuse blockingM10 or blockingM11 at their discretion, and will be the sole owners of the approval1.9 flag. Anyone can nominate a bug if they would like it considered as an opportunity win to be included in a given release.
- Only bugs marked blockingM10 or approval1.9 will be allowed to land for M10
- Only bugs marked blockingM11 or approval1.9 will be allowed to land for M11
- All component leads will be expected to participate in endgame driver triage calls.
- Releases will only occur once the respective set of blockers have reached zero.
Criteria for blocking:
M10/Beta 2: Only the top priority bugs, e.g., Must be a security issue, must be an issue that prevents users from browsing the web on a daily basis, a top crasher, a memory leak, a performance issue, is a regression from 2.0, or is functionality in support of a P1 PRD item.
M11/Beta 3: Let people nom P3,P4,P5 blocking bugs, and then we work our way through those via release driver triage. Again, we'll re-prioritize immediately after each release as a sanity check that what we have listed is sane.
(remember: the approval1.9 flag allows people to nominate non-blocking bugs of opportunity, so this won't represent the only work we'll accept for these releases, just the essential set that we want to focus on)
