ReleaseEngineering:MergeDuty

Mergeduty

Mergeduty is responsible for making sure we're prepared for the next source code uplift. Merge duty bugs are assigned to the person on the point for current release.

Note that there are several uplifts involved:

beta->release
aurora->beta
central->aurora

For example, if mozilla-central currently contains Firefox 19, a bug may say "do xyz when FF19 merges to beta". Wait for that uplift to happen, then have the bug owner land the patch.

Be sure to have a clear understanding of which patches are landing for which uplift.

Duties include:

• 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
• 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
• Re-enable Aurora updates

B2G Branching

Also see this etherpad.

Aurora is an even numbered Gecko version

When an even-numbered gecko version is merging into mozilla-aurora, the B2G version on mozilla-central will migrate into mozilla-aurora, and a new B2G version will start on mozilla-central. For B2G 1.3, when Gecko 28 merges into mozilla-aurora, mozilla-central will become 1.4 and mozilla-aurora will be 1.3.

This means we'll have to turn on B2G builds+tests for mozilla-aurora. See bug 913992 for an example.

• We'll need a new Gaia hg repository, e.g. https://hg.mozilla.org/integration/gaia-1_2/
  • This will have to be added to vcs-sync
• We'll probably need new Gaia l10n hg repositories, e.g. https://hg.mozilla.org/releases/gaia-l10n/v1_2
  • These will have to be added to vcs-sync
• The versions in the releng*.py files in mozharness/configs/b2g will need to have their versions updated, e.g. here:

'mozilla-central': '1.3.0',

would become

'mozilla-aurora': '1.3.0',
'mozilla-central': '1.4.0',

• The gaia-bumper config will grow to three repositories: central, aurora, and the most recent mozilla-b2gXX branch.
• We'll need new b2g branches
  • Rail has a script

Aurora is an odd numbered Gecko version

See this bug.

The B2G version in Aurora will move to a new mozilla-b2gXX_v1_X repo.

• file the TBPL page bug ahead of time
• don't forget the graphserver entries
• have the hg repo created ahead of time

Gecko L10n is a special case

Gaia l10n will be in version-specific hg repos, e.g. https://hg.mozilla.org/releases/gaia-l10n/v1_2

Gecko l10n will be in:

• l10n-central - new version. On dec 9 this will be 1.4
• releases/l10n/mozilla-aurora - stabilizing version. On dec 9 this will be 1.3
• releases/l10n/mozilla-beta mozilla-beta - maintenance version. On dec 9 this will be 1.2
• releases/l10n/mozilla-release mozilla-release - EOL version. On dec 9 this will be 1.1

However, b2g gecko l10n only changes repos on even-numbered gecko's in Aurora... meaning b2g gecko l10n migrates every 2 train migrations.

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

Next merge days

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

• bug 842863 Tracking bug for 02-apr-2013 migration work
• bug 842864 Tracking bug for 14-may-2013 migration work
• bug 842865 Tracking bug for 25-jun-2013 migration work
• bug 842866 Tracking bug for 06-aug-2013 migration work
• bug 842868 Tracking bug for 17-sep-2013 migration work
• bug 842870 Tracking bug for 29-oct-2013 migration work
• bug 842872 Tracking bug for 10-dec-2013 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.

Future Merge Duty Bugs

Move these under tracking bugs once they are created:

ESR 17 EOL

• bug 809314 - Enable enable_pymake for ESR 17+