User:NThomas:Process changes

Revision as of 03:32, 16 January 2014 by NThomas (talk | contribs) (Created page with "{{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 us...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

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.

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. Removals are marked with a red background, additions with a green one.

In words - we don't create a 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)
QA tests (functional, updates on releasetest)
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 b10 testing QA sign off on initial testing
Enable updates on beta channel, QA verify updates Enable updates on beta channel, QA verify updates
QA continues tests (updates on betatest using release builds)
-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

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.