Firefox 4 RC, Blocking Nominations, and "RC ridealongs"
Mike Beltzner
Yesterday we ordered release candidate builds for Firefox 4, which have been duly produced and are now being validated by our QA team before we ship them to our beta audience. Once the release candidate is in the hands of our more than 3 million daily beta users, we expect to spend another period of time doing intense QA validation before ship. Please note: the release candidate represents the code we *intend to ship* as Firefox 4 - it is not yet validated and supported, but if all goes well, those are the bits we intend to "put on the wire."
// Blocking nominations - criteria has changed!
Daily triage of blocking nominations will continue, but the criteria has changed. Now that we have produced what we believe to be the final build of Firefox 4, in order for something to block the release it must be an issue that would be serious enough for us to "pull the release" off the wire and stop shipping it. When nominating something to block please include a full explanation of why you believe the issue is a "stop-ship" issue.
// Beyond Firefox 4 RC and on the topic of "ride alongs" ...
Granting blocking2.0:final+ is not the only option available to the product drivers, though. We can also grant ".x+" which means "an issue we would like to see fixed in a stability release, requiring no beta coverage". Further, while we *do not expect* to rebuild the release candidate, an absolutely zero-risk, high-value change can be tagged [fx4-rc-ridealong] as well as ".x+" meaning that it could be included in a rebuild. To get these markings, please explain how you know there is NO RISK from your change, and illustrate the DEMONSTRATED benefit.
The finish line on Firefox 4 is in site. Let's keep running hard towards it.
cheers,
mike