Releases/Thunderbird 13.0.1/BuildNotes: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
No edit summary
Line 7: Line 7:


=Build Engineers=
=Build Engineers=
{name} - Tracking bug: {{bug|#}}
{armenzg} - Tracking bug: {{bug|763683}}


=Signed-off Revision(s)=
=Signed-off Revision(s)=

Revision as of 15:40, 13 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:

Build Engineers

{armenzg} - Tracking bug: bug 763683

Signed-off Revision(s)

Build 1:

L10N changesets

  • None for a .1 release

Tags

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

Build # Branch, Tags Changeset
1 GECKO130_XXX_RELBRANCH THUNDERBIRD_13_0_1_BUILD1 THUNDERBIRD_13_0_1_RELEASE [1]
GECKO130_XXX_RELBRANCH THUNDERBIRD_13_0_1_BUILD1 THUNDERBIRD_13_0_1_RELEASE [2]

Build data

Thunderbird

Build # Type Build ID Build machine Time to build
1 Linux
Linux64
Mac
Windows

Notes

Build 1

Preparing to start Automation

detailed instructions

  • Hit clobber

DONE TO HERE

  • No L10n changes for a .1 release
  • Reserve slaves:
[cltbld@buildbot-master34 master]$ pwd
/builds/buildbot/build1/master
[cltbld@buildbot-master34 master]$ cat reserved_slaves
8
  • create a symlink (since bug 725839 is not resolved)
# tbirdbld@stage
cd /pub/mozilla.org/thunderbird/nightly/
mkdir ../candidates/13.0.1-candidates
ln -s ../candidates/13.0.1-candidates 13.0.1-candidates
  • Land automation configs
  • Tagged buildbot-configs, buildbotcustom, & tools with build & release tags.
  • update and reconfigure the master
cd /builds/buildbot/build1/master/buildbot-configs
# make update does not work on this master due to bm34 having local changes
hg pull -u && cd ..
make checkconfig & make reconfig
<pre>
cd /builds/buildbot/build1/master
source ../bin/activate
PYTHONPATH=. python ../tools/buildbot-helpers/release_sanity.py -u armenzg -V 13.0.1 --branch mozilla-release --build-number 1 \
    --release-config release-thunderbird-comm-release.py --products thunderbird  \
    --dryrun localhost:9001
  • release_sanity might fail due to mozconfig differences. You can skip with -m
  • start automation ← monitor progress on buildbot (e.g. beta)
    • the same command as above but without the "--dryrun"
  • reconfigure other masters (or ask the buildduty person to do this) if you have done a merge (and not double-land) to production

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.

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: Thunderbird 13.0.1 coming to mirrors on {DATE}
Body:
We're planning on pushing our Thunderbird 13.0.1 release to mirrors 24 hours before {DATE}.

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.

For rapid release betas and ESR builds, this is not necessary as there's already an exclude that matches them.

Tag

Bouncer Submitter

Source

Build

Thunderbird

Thunderbird repacks

Checksums

Updates

Update verify

Reset reserved slaves

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

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.

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 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 blacklisting entry 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

Check Throttling

  • XXX: Does this apply to Thunderbird?

See http://update-watch.localgho.st/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.

Retrieved from "https://wiki.mozilla.org/index.php?title=Releases/Thunderbird_13.0.1/BuildNotes&oldid=440842"