ReleaseEngineering/Merge Duty

Mergeduty

Mergeduty is responsible for performing branching + code uplifts, and making sure the automation is ready for those branches and merges. The steps that need to be performed alternate; we're basing this on whether mozilla-central will become an odd or even numbered Gecko version after Merge Day. (See: What train is it now? and RapidRelease/Calendar)

• ReleaseEngineering/Merge Duty/Central will become an odd numbered Gecko version
• ReleaseEngineering/Merge Duty/Central will become an even numbered Gecko version

Note that there are several uplifts involved:

beta->release
aurora->beta
central->aurora
(every other)
aurora->b2gXX_vX_X

These may change, especially if we change the cadence to de-emphasize Aurora.

Duties include:

• After the Feb 4 merge day, the actual train merges are on Release Engineering to perform.
• Bumping the gecko_version of main repositories. With bug 884074 now landed, this replaces the "MERGE DAY" comments that we used to go through by hand.
• The week before uplift, contact owners for all of the above to make a final decision of which bits should be uplifted or not.
• Coordinate landing of all the merge patches with owners. Coordinate deployment with buildduty.
• Create new hg bundles for affected repositories after the merges happen. (force build the bundle builders) (see bug 800280)
  • mozilla-aurora
  • mozilla-beta
  • mozilla-release
  • comm-aurora
  • comm-beta
• When we have nightlies from mozilla-central with the new version, update the bouncer location for firefox-nightly-latest (installer) to use the new version
• Re-enable Aurora updates
  • When re-enable updates for Aurora, update the bouncer locations for firefox-aurora-latest (installer) and firefox-aurora-stub (stub installer) to use the new version
  • After bouncer update for nightly and aurora, check if disk space needs cleanup per bug 703559

VCS Sync duties

• We *must* freeze the vcs-syncing of the B2G version migrating into (even gecko number) or out of (odd gecko number) Aurora.
  • This is for gecko.git, and all gecko l10n.
  • This can start syncing after we point vcs-sync at the new repo locations.
    • Even numbered Aurora: gecko.git version will move out of mozilla-central into mozilla-aurora
    • Even numbered Aurora: gecko l10n will all shift (central, aurora, beta, release all increment their minor version numbers)
    • Even numbered Aurora: gaia l10n will have a new set of hg repos for the stability version of b2g, and a new version number for master.
    • Odd numbered Aurora: gecko.git version will move out of mozilla-aurora into mozilla-b2gXX_v1_X
    • Odd numbered Aurora: gecko l10n will stay the same

Release Management will notify Release Engineering when the migration is about to happen; we need to be ready to perform this pause/reenable.

If we miss this freeze, we may be forced to perform a non-fastforwardable push on these repos, which will cause partner unhappiness.

Next merge days

https://wiki.mozilla.org/RapidRelease/Calendar

• bug 962187 Tracking bug for 17-mar-2014 migration work

Mergeduty should start looking at patches/owners the week before. NOTE: the tracking bugs themselves should NOT have patches in them. Dependent bugs should be filed for each thing that needs to be uplifted, and assigned to someone with the context to do it properly. Best practice: the patches are based on gecko_version so they get uplifted automatically.

Future Merge Duty Bugs

Move these under tracking bugs once they are created: