SeaMonkey:Release Process:2.1rc2

« SeaMonkey 2.1rc2

Build Harness

SeaMonkey:Release Automation

Bugs

Tracking bug filed as bug 655650TBD

Build Engineer

Justin Wood

Signed-off Revisions

releases/comm-2.0

c4393272ff2d (Tag attempt 2)

5e4d1b9123df (Tag attempt 1)

releases/mozilla-2.0

ac9cf29de0d2 (GECKO201_2011041321_RELBRANCH)

dom-inspector

0bb7db177214

chatzilla

210002e2b7e7 (COMM_2_0_BRANCH)

venkmman

65c389ee756c

L10n revisions according to opt-ins as listed in l10n-changesets (taken from the sign-off tool (with a minor change for nb-NO)

Notes

• rc2 was respun due to an issue with default theme compatibility. And took a few ridealongs
• Have to do the same s/mac/mac64/ work as in SeaMonkey 2.1b2. Will have to look into an easier way for that

Build

• Made sure all build machines have clean release directories.
• Updated l10n-changesets and release-config.py including new file names
• Updated and reconfigured buildmaster
• Kicked off with the following command:

buildbot sendchange --username=Callek --master=localhost:9010 --branch=releases/comm-2.0 -c "SeaMonkey 2.1rc1build1" doit

• Tagging failed, due to being unable to bump comm-2.0 on our relbranch (I had to backout the version change on relbranch, back to 2.1pre and update cset config and respin)
• Tagging failed again, due to automation using the relbranch for all locales, and since we added some, failed on first encountered locale that was not in rc1 (en-GB)
  • adjusted automation to avoid a relbranch for l10n
  • backed out tagging on the few completed locales, to make everything match
• Tagging failed YET AGAIN due to version already bumped... did same as first time around.
• All build (FINALLY) succeeded normally
• L10n repacks on win failed, due to multiple builders getting hg timeouts on first clone, and thus leaving the local repo in a bad state. Clobbered the builders and did a manual clone locally before re-running the automation for this with the force_release_l10n script.

Fake tr locale

We actually have a real tr locale this rc, so no need to fake it.

Signing

• Our mac builds (non en-US) uploaded to mac64/ so I had to move them over to mac/ on stage, for both updates and builds.
  • ran mac64tomac.sh
  • which moves all mac64 files/directories to mac, and removes the mac64 dir.
• We have no signing infrastructure for SeaMonkey right now, so I faked the signing step that is usually done after completion of builds and L10n repacks and before the update generation.
• Logged onto stage-old.mozilla.org and ran sh ~/fakesign.sh

Copy Language Packs

Used langpackmove.sh as documented in 2.0b1 notes to move the langpacks into the directory we want them in for release.

Zipcopy

Used zipcopy.sh as documented in 2.0b1 notes to move the Windows zips into the directory we want them in for release.

Create Checksums

With make-checksums.sh as documented in 2.0.3 notes, created MD5SUMS and SHA1SUMS files containing all files we release - copying the README from last time and replacing the versions as needed, as well as doing the same for Linux x86_64.

Update the README on FTP

The README file we copy over from 2.1 RC 1 needed a manual Update as the PRETTYNAME with version doesn't get updated by the scripts we use. I also noticed that we still referenced PPC in that, so adjusted as well.

Linux64 Readme

• Per what I learned in rc1 (that the readme in contrib/ for linux64 needs a manual prettyname adjustment) I corrected that

Updates and Verification

• _l10n_verify and updates started automatically, triggered by the fake-signing.
  • L10n verification is mostly useless, since we have many new locales, and lots of expected changed strings.
• update completed fine
  • the Update verification was red on windows.
  • Investigation found that we were not packaging optional/ on the win installer for non en-US, and similarly failing to package those extensions in the complete mars, at the least.

Build 2

abridged, due to lots of stuff and not doing due-diligence keeping this page updated.

• nthomas helped identify the issue that caused us to spin build 2
• I got a patch up on m-2.0 for our issue, and respun, repacks failed.
• KaiRo was able to take over during Callek's hectic days (away from Mozilla) and patched the m-2.0 issue, and respun repacks, twice. Looks like we have/had a bad machine in the end, but we got all repacks to finish.

Signing

• Our mac builds (non en-US) uploaded to mac64/ so I had to move them over to mac/ on stage, for both updates and builds.
  • ran mac64tomac.sh
  • which moves all mac64 files/directories to mac, and removes the mac64 dir.
• We have no signing infrastructure for SeaMonkey right now, so I faked the signing step that is usually done after completion of builds and L10n repacks and before the update generation.
• Logged onto stage-old.mozilla.org and ran sh ~/fakesign.sh

Copy Language Packs

Used langpackmove.sh as documented in 2.0b1 notes to move the langpacks into the directory we want them in for release.

Zipcopy

Used zipcopy.sh as documented in 2.0b1 notes to move the Windows zips into the directory we want them in for release.

Create Checksums

With make-checksums.sh as documented in 2.0.3 notes, created MD5SUMS and SHA1SUMS files containing all files we release - copying the README from last time and replacing the versions as needed, as well as doing the same for Linux x86_64.

Update the README on FTP

The README file we copy over from 2.1 RC 1 needed a manual Update as the PRETTYNAME with version doesn't get updated by the scripts we use. I also noticed that we still referenced PPC in that, so adjusted as well.

Linux64 Readme

• Per what I learned in rc1 (that the readme in contrib/ for linux64 needs a manual prettyname adjustment) I corrected that

Updates and Verification

• _l10n_verify and updates started automatically, triggered by the fake-signing.
  • L10n verification is mostly useless, since we have new locales, and lots of expected changed strings.
• update completed fine
• Update Verification completed fine! Verified that no fails/warn's existed (other than the one expected warn on mac builds)

Push To Mirrors

Used mirrorpush.sh as documented in 2.0.3 notes to finally push the files to the public dir for mirrors to pick them up.

Version Number 'pre'

It was pointed out after our mirror push that the version 2.1rc2 reports as is 2.1pre not 2.1, this was due to a faulty cset for c-c on our build2. We'll respin direct to a 2.1 final.

Final Verification

Used 'Force Build' to start the final_verification builder; all tested URLs are HTTP 200 and 302 - ready for going public!

• Well, with the exception of 2.1rc1->2.1rc2 partials which is due to the tr fake actually NEEDING to be done for 2.1rc2 partials. did that and re-kicked.
• Re-Kick results pending

Push Updates to the beta Channel

On aus |/opt/aus2/snippets/staging/|:

~/bin/backupsnip Sea*2.1rc1*build1
~/bin/pushsnip Sea*2.1rc1*build1

Create and publish updates for the release channel

RC1 was, as all RCs, shipped with the "release" channel set, so we also need to provide the RC1->RC2 updates on that channel.

First, create the release snippets by converting the beta snippets:

rsync -av /opt/aus2/snippets/staging/SeaMonkey-2.1rc2/ /opt/aus2/snippets/staging/SeaMonkey-2.0rc2-release
cd /opt/aus2/snippets/staging/SeaMonkey-2.0rc2-release/SeaMonkey/
rm -rf 2.1a* 2.1b*
for dir in 2.1/*/*/*; do mv -v $dir/beta $dir/release; done
cd /opt/aus2/snippets/staging/

Then, push those release snippets:

~/bin/backupsnip SeaMonkey-2.1rc2-release
~/bin/pushsnip SeaMonkey-2.1rc2-release

Push build to TrendMicro

I used the TrendMicro provided staging ftp directory to stage 2.1rc1 en-us win32 for them to scan, and be sure there are no false-positives.