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

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.

• 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.

Aurora is an odd numbered Gecko version

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

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+