Thunderbird/Release Driving/Rapid Release Activities/Merge Repositories

Setting up

Warning: The merge scripts download the comm-* repository bundles and create clones from those, and update them. These may use a large amount of data bandwidth to complete. This is done to ensure clean repositories.

You'll need access to:

• Mercurial (level 3)
• treestatus (one of the existing Thunderbird folks should be able to ask the Sheriffs to give you access).

Clone the drivertools repo

hg clone http://hg.mozilla.org/users/bugzilla_standard8.plus.com/drivertools/
cd drivertools/comm-merges

Merges Overview

When merges happen

Merges should be done in the order:

• comm-beta -> comm-release (used by SeaMonkey)
• comm-aurora -> comm-beta
• comm-central -> comm-aurora

The comm-beta -> comm-release merge is typically done a few days before the main merges. Normally the SeaMonkey folks determine when. At the latest it is done on Merge day.

The other two merges happen on Merge Day. This can be determined by looking at the release calendar.

On Merge Day, hook up with RelEng (mergeduty) to check when the mozilla-* repositories are being merged. These typically happen sometime in the morning Pacific Time - we aim to do the comm-* repositories after the mozilla-* ones, so that we don't have broken builds on the branches.

How to close the Trees

Use treestatus for closing trees. Set the "state" to CLOSED with a reason of "for merges" with the "Planned closure" tick box selected.

For each merge ensure the relevant trees are closed, e.g. for comm-beta -> comm-release, ensure:

• comm-beta-thunderbird
• comm-beta-seamonkey
• comm-release-thunderbird
• comm-release-seamonkey

Reopening the Trees

Reopening trees is only done when:

• For central: after the merges are completed and the version numbers have been bumped.
• For aurora: after the merges are completed *and* the builds have been completed.
• For beta: This remains closed after a comm-beta -> comm-release merge until after the comm-aurora -> comm-beta merge has been completed and the builds have been completed.
• For release: This remains closed as developers shouldn't be pushing to it.

When re-opening the tree, ensure you set it to the state that it was previously (generally "approval-required" for aurora/beta and "open" for central). There's a history on the page where you can check.

Doing the actual merges

These assume you've read the previous detail.

The scripts are run from the drivertools/comm-merges directory.

comm-beta -> comm-release

• Close the relevant trees
• Reset the repos (this removes any previous repository & creates a fresh clone)

 ./resetreleaserepos.sh

• Run the script

 ./merge-beta-2-release.sh &> beta2release.log
 less beta2release.log

• Check the log for:
  • Any errors
  • Outgoing tag to comm-beta
  • The diff of changes committed to comm-release looks OK
  • The outgoing changes to comm-release look ok, including closing of the old head, and tagging at the start and end of the list.
• Now push the beta tag (this doesn't cause any builds, as it doesn't change anything)

 hg -R beta push

• and the release changes (we generally haven't clobbered these as SeaMonkey's clobberer hasn't been up and running)

 hg -R release push -f

• Remember, comm-beta stays closed until after the comm-aurora -> comm-beta merges have completed on Merge day (and its built).

comm-aurora -> comm-beta merge

• Close the relevant trees
• Reset the repos (this removes any previous repository & creates a fresh clone)

 ./resetmainrepos.sh

• Run the script

 ./merge-aurora-2-beta.sh &> aurora2beta.log
 less aurora2beta.log

• Check the log for:
  • Any errors
  • Outgoing tag to comm-aurora
  • The diff of changes committed to comm-beta looks OK
  • The outgoing changes to comm-beta look ok, including closing of the old head, and tagging at the start and end of the list.
• Now push the aurora tag (this doesn't cause any builds, as it doesn't change anything)

 hg -R aurora push

• Clobber the beta builds via clobberer
• and then push the beta changes

 hg -R beta push -f

• comm-aurora doesn't get set back to approval required until after comm-central -> comm-aurora merge and builds are completed
• comm-beta doesn't get set back to approval required until after builds are completed

comm-central -> comm-aurora merge

• Close the relevant trees, if not already)
• You don't need to do a reset of the repos for this step if you closed the trees before the comm-aurora -> comm-beta merge and no pushes have happened.
• Run the script

 ./merge-central-2-aurora.sh &> central2aurora.log
 less central2aurora.log

• Check the log for:
  • Any errors
  • Outgoing tag to comm-central
  • The diff of changes committed to comm-aurora looks OK
  • The outgoing changes to comm-aurora look ok, including closing of the old head, and tagging at the start and end of the list.
• Now push the central tag (this doesn't cause any builds, as it doesn't change anything)

 hg -R central push

• Clobber the aurora builds via clobberer
• and then push the aurora changes

 hg -R aurora push -f

• For comm-central, the version bumps now need to happen. First, cd into the directory:

cd central
hg update -r default

• Bump the versions in the following files (look at the history if you're unsure of the standard bumps):

central/mail/config/version.txt
central/suite/config/version.txt

• Commit the version changes with a message: "Version bumps for SeaMonkey and Thunderbird a=auroramerge CLOSED TREE" (note we don't use DONTBUILD to force a cycle through the builders in case there's an issue with tests relying on particular version numbers).
• Push the result.

 hg push

• comm-central can be re-opened if appropriate.
• comm-aurora doesn't get set back to approval required until after builds are completed

Post-Merge tidy

Please commit and push any changes to the drivertools repo, for history purposes.