This is the current working Firefox 4 beta plan so you can plan accordingly. Feel free to email me directly with any questions.

Summary

  1. 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
  2. We will release beta 10 as soon as possible during the week of the 24th
  3. 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 betaN hardblockers 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
  4. 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 betaN hardblockers will not all be finished by this Friday. Additionally, greater than 318 bugs 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, release drivers will send the “ok to reenable normal nightly operation”. RelEng will revert changes and 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

I’ll keep the various mailing lists and planet updated if anything changes. Again feel free to shoot me an email (or find me on IRC) with any questions you have.

Tagged with: