Current Firefox 4 beta plan
Christian Legnitto
Summary
--------------------------
* We'll take the most recent green changeset from mozilla-central this Friday, 2011-01-21 at 2:00 pm PST and call that beta 10
** The tree will close for < 15 minutes for this (if at all)
** We'll freeze nightly updates at or around the changeset we branched from (likely only for the weekend)
** Any problems with the beta will be dealt with on the relbranch
* We will release beta 10 as soon as possible during the week of the 24th
* We'll take the most recent green changeset from mozilla-cental on Friday, 2011-01-28 at 2:00 pm PST (or sooner if the remaining 57 betaN hardblockers[1] are finished) and call that beta 11
** The tree will close for < 15 minutes for this (if at all)
** We'll freeze nightly updates at or around the changeset we branched from (likely only for the weekend)
** Any problems with the beta will be dealt with on the relbranch
* We will release beta 11 as soon as possible during the week of the 31st
Details
--------------------------
Both frontend and platform managers have determined that their 57 betaN hardblockers will not all be finished by this Friday. Additionally, greater than 318 bugs[3] have been marked fixed since beta 9. We need beta coverage for most of those fixes but also need beta coverage for the remaining betaN hardblockers. To control risk for the RC the plan is to do two betas (10 and 11) rather than hold beta 10 for all betaN hardblockers. This will give us a week of beta coverage for the 318 bug fixes while still allowing beta coverage for the remaining betaN hardblockers.
Code freeze for beta 10 and 11 will also be a bit different. Previous betas closed the tree to stabilize and reduce beta risk. At this point in development, every day counts--we cannot shut down mozilla-central over the weekend as we have done before. Instead we'll freeze what's in the tree and run with it, dealing with any beta issues on the relbranch. Instead of metering what goes in before a freeze we will be driving to get as many fixes as possible so they can get more beta coverage.
To enable additional testing of the bits we intend to ship to beta while keeping the tree open for development we will freeze mozilla-central nightlies to the changeset we branched from (likely only for the weekend). Developers can still use hourlies to test and will able to integrate their work with others without waiting a weekend for the tree to reopen.
For those curious, joduinn has provided the the specific plan for the nightly changeset freeze:
1) RelEng will create a nightly ~2pm PST Friday, with same changeset as the beta10 builds
2) RelEng will create the nightly build fri+sat+sun night as usual, but will force the updates to a hidden location. A human can download+install those nightly builds if they want (for regression ranges / reproduction), but no-one will get updated to these nightlies
3) On Monday, once we get "ok to reenable normal nightly operation", we'll revert changes, trigger a mid-day Monday nightly, so people on Friday afternoon nightly will directly update to Monday afternoon (skipping the fri/sat/sun night nightlies)
4) We will then move snippets generated over weekend back to usual locations, and cleanup
5) The change is a small, and we believe safe, change to how updates are created
Explicit Bug/Release dependencies:
* Beta 10: None, time-based release to test what we have done since beta 9
* Beta 11: 57 betaN hardblockers[1]
* RC: 39 final hardblockers[2]
Thanks,
Christian