User:NThomas:Process changes
bug 908134 is set to change the release process around the final beta and release builds. The aim is to take the exact bits release users will get and give them to beta users, to catch the Radeon crash problem early. This is for desktop only, mobile will still have a beta 10.
Contents
Current process
Here's the current state of process, sketch-style, for the 27.0 cycle. D-Day is relative to when we release the build to the world. All activities are in column for the source repository used to create that build.
| D-Day | This cycle | mozilla-beta | mozilla-release |
| -8 days | Mon 27 Jan | Last changes for 27.0 land here | |
| Build last beta (27.0b10) | |||
| QA tests (functional, updates on releasetest) | |||
| Merge code from mozilla-beta to mozilla-release | |||
| Build 27.0 build1 | |||
| -7 days | Tue 28 Jan | QA sign off on b10 testing | |
| Enable updates on beta channel, QA verify updates | |||
| QA tests (functional, updates on betatest) | |||
| -4 days ? | Friday ? | QA signoff | |
| -1 day | Monday 3 Feb | Final signoff checks | |
| Push to mirrors | |||
| QA check updates on releasetest | |||
| This is it | Tue 4 Feb | Push to release channel, QA verifies |
New process
Here's how it would look after we change things. Additions are marked with a green background, removals just removed.
In words - we don't create a (desktop) beta 10 build, instead we offer the release build on the beta channel as soon as we complete the normal beta-level of testing. Then continue with regular release testing and ship as before.
| D-Day | This cycle | mozilla-beta | mozilla-release |
| -8 days | Mon 27 Jan | Last changes for 27.0 land here | |
| Build last beta (27.0b10) for MOBILE ONLY | |||
| Merge code from mozilla-beta to mozilla-release | |||
| Build 27.0 build1 | |||
| QA tests (functional, updates on releasetest using beta builds) | |||
| -7 days | Tue 28 Jan | QA sign off on initial testing | |
| Enable updates on beta channel, QA verify updates | |||
| QA continues tests (updates on betatest using release builds) | |||
| -6 days | Wed 29 Jan | QA sign off on mobile b10 testing | |
| Push b10 Mobile to beta product on stores, QA verify | |||
| -4 days ? | Friday ? | QA full signoff | |
| -1 day | Monday 3 Feb | Final signoff checks | |
| Push to mirrors | |||
| QA check updates on releasetest using release builds | |||
| This is it | Tue 4 Feb | Push to release channel, QA verifies |
The release build will still be at http://ftp.mozilla.org/pub/mozilla.org/firefox/candidates/27.0-candidates/build1/. Other systems that are expecting a corresponding 27.0b10-candidates directory will need to be adjusted.
Will it take longer for builds/updates to be available ?
Yes, a little. A beta build takes about 8 hours from tagging to updates available, and we estimate it will take 10.5 hours for the release build (currently 10 hours, but we'll add a 27.0b9 -> 27.0 partial update to get beta users on the final build ASAP).
What about respins ?
Suppose we find some bugs in 27.0 build1, what then ? I'm assuming we will want the fix on both beta and release channels. The code changes need to land in mozilla-release and we will spin a 27.0 build2. The release automation will run the same as build1 from the point of view of updates - we will be ready to push build2 to the beta channel if we think there is value. There may not be, eg too close to release to get crash feedback and 28.0b1 coming soon, but we'll have the option.
Repeat as required up to buildN.
What about chemspills ?
No change from current process. We cannot 'downgrade' beta users from 28.0bN to 27.0.1 via an update. The chemspill will ship without any pre-verification of crash issues, which is no different from the status quo, and we're probably in a hurry anyway.
