Releases/Firefox 13.0.1/BuildNotes: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
No edit summary
Line 120: Line 120:
Subject: Firefox 13.0.1 coming to mirrors on 15-June-2012
Subject: Firefox 13.0.1 coming to mirrors on 15-June-2012
Body:
Body:
We're planning on pushing our Firefox 13.0.1 release to mirrors 24 hours before 15-June-2012.
We're planning on pushing our Firefox 13.0.1 release to mirrors a little before 5pm PDT on 15-June-2012.
# If this is a chemspill, please mention that in the email as it will mean pinging
# for CDN to be enabled when the push to internal mirrors happens


If you believe these releases or these dates will cause any problems,
If you believe these releases or these dates will cause any problems,

Revision as of 19:11, 14 June 2012

Notes About Releasing

Please update the Notes Template and the Release:Primer for future releases (bug fixes, changes to automation) as needed

Bugs hit

Enter any bugs pre-existing or newly discovered and filed during the release:

  • I started this release thinking that buildbot-master13 was the master to be used
    • this means that reserved_slaves was 0 for this master until just before starting it
  • L10n checks failed:
2012-06-14 11:20:39,654 : INFO : Checking for existence l10n changeset ku af6fed359593 in repo https://hg.mozilla.org/releases/l10n/mozilla-release/ku/file/af6fed359593 ...
2012-06-14 11:20:39,776 : INFO : Checking for existence l10n changeset sl 9762be720183 in repo https://hg.mozilla.org/releases/l10n/mozilla-release/sl/file/9762be720183 ...
2012-06-14 11:20:40,253 : INFO : Comparing l10n changesets on dashboard https://l10n.mozilla.org/shipping/l10n-changesets?ms=fx13.0.1 to on-disk l10n-changesets_mozilla-release ...
2012-06-14 11:20:40,474 : ERROR : cannot find l10n dashboard at https://l10n.mozilla.org/shipping/l10n-changesets?ms=fx13.0.1
2012-06-14 11:20:40,475 : ERROR : Error verifying l10n dashboard changesets
    • skipping checks and talking with Axel about solution
  • while tagging was happening I decided to make sure we had enough slaves
    • I went and attached 5 mw32 slaves to the master
    • I am worried about cross-colo connections

Build Engineers

{armenzg} - Tracking bug: bug 764179

Signed-off Revision(s)

Build 1: 5bd841d76b3a

L10N changesets

  • Nothing for a .1 release

Tags

Manually tag the automation code, then record the generated tags below. (details)

Build # Branch, Tags Changeset
1 GECKO1301_2012061411_RELBRANCH, FIREFOX_13_0_1_BUILD1 FIREFOX_13_0_1_RELEASE f48d675ffa9f

Build data

Firefox

Build # Type Build ID Build machine Time to build
1 Linux linux-ix-slave39
Linux64 linux64-ix-slave06
Mac moz2-darwin10-slave53
Windows mw32-ix-slave04

Notes

Build 1

Set reserved slaves

  • Reserved slaves
[cltbld@buildbot-master12 master]$ pwd
/builds/buildbot/build1/master
[cltbld@buildbot-master12 master]$ cat reserved_slaves
8

Preparing to start Automation

detailed instructions

  • Set clobbers for the appropriate masters. Doing this 24-48 hours in advance should speedup the build.
  • For build1 only, create symlinks:
# ffxbld@stage
cd /pub/mozilla.org/firefox/nightly/
mkdir ../candidates/13.0.1-candidates
ln -s ../candidates/13.0.1-candidates 13.0.1-candidates
  • Land automation configs
  • Tag buildbot-configs, buildbotcustom, & tools with build & release tags.
  • update and reconfigure the master
cd /builds/buildbot/build1
source bin/activate
make update && make checkconfig && make reconfig
cd master
PYTHONPATH=. python ../tools/buildbot-helpers/release_sanity.py -u armenzg -V 13.0.1 --branch mozilla-release --build-number 1 \
    --release-config release-firefox-mozilla-release.py --products firefox  \
    --dryrun localhost:9001
  • failed L10n checks (see bug hit section)
    • no other errors
    • run previous command with -b to skip
  • the same command as above but without the "--dryrun"
  • start automation ← monitor progress on buildbot (e.g. release)

E-mail Metrics

Use the address "metrics-alerts < AT > mozilla < PERIOD > org". Note for first-time-releasers: your email will get held for moderator approval - that is expected. If it happens more than once, get help on #metrics.

Firefox,firefox,firefox,13.0.1,13.0

DONE TO HERE

E-mail mirrors@mozilla.org

They want to know approximately what time push to external mirrors will occur. Ideally this is a 24hr notice to them, with the estimated time.

Subject: Firefox 13.0.1 coming to mirrors on 15-June-2012
Body:
We're planning on pushing our Firefox 13.0.1 release to mirrors a little before 5pm PDT on 15-June-2012.

If you believe these releases or these dates will cause any problems,
please notify release at mozilla.com. If you have any problems with mirror
status/weights/etc, please notify mirror-submissions at mozilla.org.

Edit rsync exclude files

After getting svn setup (auth req'd) edit files/rsync/rsyncd-mozilla-releases.exclude so that it excludes the current release, get review and deploy. This prevents external mirrors from picking up the new release prematurely. Since Thunderbird doesn't inject index.html files into the file hierarchy, adding "- thunderbird/releases/13.0/**" (adjust for version) to the top of the file is all that's needed.

Source

Build

Firefox

Firefox repacks

XULRunner

Source

Build

Push to Mirrors

Partner Repack

Firefox

Checksums

Updates

Update verify

Reset reserved slaves

Needs to be reset to 0.

Check permissions / AV scan

It is supposed to be triggered automatically after updates are done. File a bug if it doesn't. details

Push to internal mirrors

This is done by automation for rapid release betas. Note: if you have to reconfig the release buildbot master in during the release, the uptake monitoring will fail (bug 629648). That means you'll need to manually send the "ready for releasetest" emails when you believe things are "good enough". Refer to a prior release for email details.

For other releases, this should be done manually at this point, after check permissions / AV scan have completed.

Mirrors Policy

Final verification

Record receipt of "completed_final_verification" emails (1 per platform)

Going to Beta

NOTE: Skip to "Before Release Day" for beta releases

Run backupsnip

NOTE: Remember to do this at least 2 hours ahead of the expected "go to beta" email. details

Remember to ssh to aus3-staging using your short LDAP name and then run sudo su - ffxbld once on. If you intend to use screen, initiate your screen session while you are still yourself.

Push to beta

Wait for "go" from release managers
For Firefox:

  • Publish (and record run time here): details
  • on completion, email r-d that VERSION updates are live on the beta channel

Wait for confirmation from QA that each of the above releases is okay, then close the tracking ticket.

Before Release Day

Assuming this is not a chemspill.

Run backupsnip for release snippets

Do this the night before release day as it can take up to two hours.

Push index file to mirrors

Push to external mirrors

If this is a chemspill you will want to ping justdave (or other sysadmin) in #release-drivers and ask them to enable CDN.

  • Remove previously added rsync exclusion from stage.mozilla.org:/pub/mozilla.org/zz/rsyncd-mozilla-releases.exclude
  • Replace old version with the current one in stage.mozilla.org:/pub/mozilla.org/zz/rsyncd-mozilla-current.exclude

See details

Release Day

Update XULRunner wiki page

For major releases or chemspills, update the links on:

Also for older releases:

Check Throttling

See http://people.mozilla.com/~nthomas/update-watch/release/ for example AUS links

Some links to check:

Push to Release Channel (for beta releases and release releases)

Once there is enough uptake and we get "go" from release driver.

Update symlinks

Once we're signed off on the release channel.

Remove index.html files

If you created them earlier to hide the release.

Update browser choice website