ReleaseEngineering/How To/Create new ESR branch

ESR17 process was tracked by bug 796995 and the dependent bugs. The process can be split into 2 major parts: internal and external

Internal changes

This covers changes to configs, buildbotcustom and tools.

buildbotcustom changes for ESR17 were not critical and are not ESR specific.

tools changes

tools changes

• adds new release branch to production-masters.json file
• adds new branch to buildapi's production-branches.json file
• since the config patch introduces new configurations file which are need to be symlinked to the build/scheduler master there is a need for a fabric methods to create the links
• mozconfig whitelist changes (tested in bug 808077)
• preproduction tweaks

buildbot-configs changes

Some highlights:

• Explicitly list the platforms (and use lock_platforms) since we don't ship ESR to all mozilla-central/release platforms (android, for example)
• Copy mozilla-beta configs, compare them to the previous ESR release and check if you understand what they stand for
• No dep/nightly L10N builds required, as a result no need to create Tinderbox trees
• check mozilla-beta exceptions (loops) and check if they are aplicable to the current ESR
• for every exception (MERGE DAY exceptions) file a bug to track it

New release configs

• Make sure that the following variables set

releaseConfig['partialUpdates'] = {}
releaseConfig['skip_updates'] = True
releaseConfig['verifyConfigs'] = {}
releaseConfig['ftpSymlinkName'] = 'latest-esr'

• File new tracking bug for the next minor esr release (17.0.1esr) to update these variables
• update previous release configs and set

releaseConfig['ftpSymlinkName'] = 'latest-10.0esr'

• add mozilla2/*/comm-esr17/release/l10n-mozconfig for every platform. Copy them from mozilla-beta and compare to the previous esr configs
• add mozilla2/linux/comm-esr17/release/mozconfig (linux only). We need this for source builder. Will be fixed by bug 748796

External changes

Ask IT to clone repos

See bug 807979 for the details. We usually clone ~1-2 weeks in advance off beta to test how automation works.

Add new branches to treestatus.m.o

Login to treestatus.m.o and create the trees. Notice that Thunderbird trees have -thunderbird suffix (comm-esr17-thunderbird)

Update tree closure hooks

See bug 807983 for the details (fyi, ted has given us blanket approval to land branch-name-only updates - have someone else double check). Requires deployment by IT (see bug 807694).

Update graphs.m.o and graphs.allizom.org with

Graph server schema changes. Requires both sql update (bug 808007) & IT deployment (bug 808537). (Use copy/modify/paste for all elements. Note that branch name is given in tbpl capitalization format.

Update TBPL

1. Add new trees to TBPL. See bug 808017 for the details (filed in webtools::tinderboxpushlog).
2. Test after landing by seeing trees displayed as expected on tbpl staging.
3. Requires IT deployment (see bug 809543, be sure to cc ":edmorley" on IT bug if you choose to file - often worth also checking for any other undeployed changes, in case they are not ready to push).

Deployment process & details from Ed.

Update AUS2

Adds new entries for nightly builds. See bug 808543 for the details. Requires IT deployment (see bug 808543)

Also need to create some symlinks for mac:

 ssh aus3-staging.mozilla.org    # using your ldap username, VPN running
 sudo su - ffxbld
 cd /opt/aus2/incoming/2/Firefox
 mkdir mozilla-esrNN             # where NN is your new version
 ln -s Darwin_x86_64-gcc3 Darwin_x86_64-gcc3-u-i386-x86_64
 ln -s Darwin_x86_64-gcc3 Darwin_x86-gcc3-u-i386-x86_64

Testing

CI builds

Make sure to run all esr and some other builds in staging. Run leak test and nightly builds 2 times to allow them to generate leak log and partial updates.

Release builds

Make sure to run a staging release. It takes less time then usual build, because there are no updates to be generated.

Ship it!

Close the bug and have some tea. :)