Thunderbird/Release Driving/Rapid Release Activities/Beta Release Procedure

From MozillaWiki
Jump to: navigation, search

Note: This guide is written from the perspective of the Release Manager. It refers to rolls performed by other members of the team.

TODO: Document the web activities for the first beta in a series.

Bug Triage

  • Bug Triage is done by thunderbird-drivers
    • Use the Bug Tracking page
    • The beta branch is the one to be interested in.
    • Review:
      • Nominations & Current bugs being tracked
      • Approvals
    • Check:
      • Needs Landing
        • for any bugs that need landing, and land them (or get them landed) on aurora/beta as appropriate.

Go for Build

Normally happens on a Tuesday, aim for early-mid PDT.

  • Decision
    • Ensure Bug Triage is completed
    • Generally based on amount of changes in comm-beta, mozilla-beta and L10n updates.
  • Send go to build to thunderbird-drivers
    • For the changesets generally use the tip of the default branch for each repository.
    • For the final beta, use the same changeset as used by Firefox, to ensure no differences in the gecko version.
<bit of info about the release>
<bit of info about scheduled release time, typically on a Thursday>

Changesets:
  * comm-beta: <Link to changeset to use>
  * mozilla-beta: <Link to changeset to use>
  * L10n changesets: Ship the beta release on the L10n dashboard.
  • Send email to Linux distros
    • (currently separate step, may be integrated into go for build at some stage).

Build (Releng)

  • At this stage, the releng guys on thunderbird-drivers take the go for build, build it and generate updates. This is all automated and they have their own steps for doing it.
  • Once Build is complete, an email gets sent to thunderbird-drivers with a statement similar to 'Thunderbird <version> Build is available on betatest'.

QA

  • QA takes the builds that are on betatest and tests the builds and the updates.
  • QA will respond to the releng email with the fact the builds & updates are signed off (assuming no issues).

Website Preparation

This step needs to be done by someone with access to the svn for the www.mozilla.org site.

First Beta of a version series

All betas of a version series

This step has to be done after the signed builds have been completed 

cd mozilla.org/branches/staging/thunderbird
  • Run
python /path/to/generateThunderbirdDetails.py --version <version> --build <build number> --do-beta --autoland

Note: --build defaults to '1' so can generally be omitted.

This will update includes/thunderbirdBetaBuildDetails.php and commit it for you. The staging website normally picks up changes within 10-20 minutes.

Release Part

Betas are generally released on a Thursday, though may be released on a Wednesday if builds are complete, signed off and everyone is about.

Betas are automatically pushed to internal mirrors at the end of the build process. You'll get an "ready for release" email once the mirror stage has completed.

  • Check the all-beta.html page on the staging site is updated and that the links work (or get QA to do it).
  • When QA is ready, ask releng (via email/irc) to push Thunderbird <version> updates to the beta channel
Please push Thunderbird <version> updates to the beta channel
  • When push is complete, ensure that QA knows, and QA will verify updates are correct on the beta channel.
  • Ask webdev or whoever has access to the svn to mozilla.org to merge the revision of thunderbirdBetaBuildDetails.php that was created above from staging to trunk, i.e. push it to production.
  • The website updates about 10-20 minutes after a commit, so check that the production all-beta.html page is up to date and active after that period.

The release is then complete.

Retrieved from "https://wiki.mozilla.org/index.php?title=Thunderbird/Release_Driving/Rapid_Release_Activities/Beta_Release_Procedure&oldid=475785"