Confirm
4,971
edits
Changes
Created page with "{{Release Engineering How To|Merge Duty}} = Mergeduty = Mergeduty is responsible for performing branching + code uplifts, and making sure the automation is ready for those br..."
{{Release Engineering How To|Merge Duty}}
= Mergeduty =
Mergeduty is responsible for performing branching + code uplifts, and making sure the automation is ready for those branches and merges.
Note that there are several uplifts involved:
beta->release
aurora->beta
central->aurora
(every other)
aurora->b2gXX_vX_X
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:
* After the Feb 4 merge day, the actual train merges are on Release Engineering to perform.
* Bumping the [https://hg.mozilla.org/build/buildbot-configs/file/97b9e0b83e84/mozilla/master_common.py#l226 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}})
** [http://buildbot-master57.srv.releng.use1.mozilla.com:8001/builders/mozilla-aurora%20hg%20bundle mozilla-aurora]
** [http://buildbot-master57.srv.releng.use1.mozilla.com:8001/builders/mozilla-beta%20hg%20bundle mozilla-beta]
** [http://buildbot-master57.srv.releng.use1.mozilla.com:8001/builders/mozilla-release%20hg%20bundle mozilla-release]
** [http://buildbot-master57.srv.releng.use1.mozilla.com:8001/builders/comm-aurora%20hg%20bundle comm-aurora]
** [http://buildbot-master57.srv.releng.use1.mozilla.com:8001/builders/comm-beta%20hg%20bundle comm-beta]
* When we have nightlies from mozilla-central with the new version, update the bouncer location for [https://bounceradmin.mozilla.com/admin/mirror/location/9379/ firefox-nightly-latest] (installer) to use the new version
* [[ReleaseEngineering/How_To/Enable_or_Disable_Updates_on_Aurora#Enabling_Updates | Re-enable Aurora updates]]
** When re-enable updates for Aurora, update the bouncer locations for [https://bounceradmin.mozilla.com/admin/mirror/location/9380/ firefox-aurora-latest] (installer) and [https://bounceradmin.mozilla.com/admin/mirror/location/9717/ 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}}
== B2G Branching ==
Also see [https://releng.etherpad.mozilla.org/214 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 [https://bugzilla.mozilla.org/show_bug.cgi?id=913992 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 [http://hg.mozilla.org/build/mozharness/file/19ccf160cb4e/configs/b2g mozharness/configs/b2g] will need to have their versions updated, e.g. [http://hg.mozilla.org/build/mozharness/file/19ccf160cb4e/configs/b2g/releng.py#l46 here]:
<pre>
'mozilla-central': '1.3.0',
</pre>
would become
<pre>
'mozilla-aurora': '1.3.0',
'mozilla-central': '1.4.0',
</pre>
* The [http://hg.mozilla.org/build/mozharness/file/19ccf160cb4e/configs/gaia_bumper/gaia_json.py#l15 gaia-bumper config] will grow to three repositories: central, aurora, and the most recent mozilla-b2gXX branch.
* We'll need new [https://bugzilla.mozilla.org/show_bug.cgi?id=916911 b2g branches]
** Rail has a [http://hg.mozilla.org/build/braindump/file/a889899ca778/git-related/b2g-branching/b2g_branch_repos.py script]
* The device configs in aurora need updating to point to the new b2g manifest branch. e.g. http://hg.mozilla.org/releases/mozilla-aurora/rev/b1c4f85913d1 ''(see {{bug|950166}} for example)''
* The device configs also need updating to point to gecko aurora repositories and the new gaia l10n repositories (see {{bug|957411}})
* the mozilla-central b2g version will need bumping, e.g. http://hg.mozilla.org/mozilla-central/rev/289d0d34ded7 This should be done by RelMan, but worth the double check.
* Don't forget the [[#VCS_Sync_duties|VCS Sync duties]]!
* [https://intranet.mozilla.org/Auto-tools/B2G_Automation/Adding_New_Update_URLs|update.boot2gecko.org needs new versioned update channels]
* tag gecko+gaia for security team
=== Aurora is an odd numbered Gecko version ===
See [https://bugzilla.mozilla.org/show_bug.cgi?id=917433 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
* The device configs also need updating to point to gecko beta repositories (see bug 957411)
* Don't forget the [[#VCS_Sync_duties|VCS Sync duties]]!
* tag gecko+gaia for security team
=== 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:
* [http://hg.mozilla.org/l10n-central l10n-central] - new version. On dec 9 this will be 1.4
* [http://hg.mozilla.org/releases/l10n/mozilla-aurora releases/l10n/mozilla-aurora] - stabilizing version. On dec 9 this will be 1.3
* [http://hg.mozilla.org/releases/l10n/mozilla-beta releases/l10n/mozilla-beta mozilla-beta] - maintenance version. On dec 9 this will be 1.2
* [http://hg.mozilla.org/releases/l10n/mozilla-beta 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
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.
= Future Merge Duty Bugs =
Move these under tracking bugs once they are created:
= Mergeduty =
Mergeduty is responsible for performing branching + code uplifts, and making sure the automation is ready for those branches and merges.
Note that there are several uplifts involved:
beta->release
aurora->beta
central->aurora
(every other)
aurora->b2gXX_vX_X
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:
* After the Feb 4 merge day, the actual train merges are on Release Engineering to perform.
* Bumping the [https://hg.mozilla.org/build/buildbot-configs/file/97b9e0b83e84/mozilla/master_common.py#l226 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}})
** [http://buildbot-master57.srv.releng.use1.mozilla.com:8001/builders/mozilla-aurora%20hg%20bundle mozilla-aurora]
** [http://buildbot-master57.srv.releng.use1.mozilla.com:8001/builders/mozilla-beta%20hg%20bundle mozilla-beta]
** [http://buildbot-master57.srv.releng.use1.mozilla.com:8001/builders/mozilla-release%20hg%20bundle mozilla-release]
** [http://buildbot-master57.srv.releng.use1.mozilla.com:8001/builders/comm-aurora%20hg%20bundle comm-aurora]
** [http://buildbot-master57.srv.releng.use1.mozilla.com:8001/builders/comm-beta%20hg%20bundle comm-beta]
* When we have nightlies from mozilla-central with the new version, update the bouncer location for [https://bounceradmin.mozilla.com/admin/mirror/location/9379/ firefox-nightly-latest] (installer) to use the new version
* [[ReleaseEngineering/How_To/Enable_or_Disable_Updates_on_Aurora#Enabling_Updates | Re-enable Aurora updates]]
** When re-enable updates for Aurora, update the bouncer locations for [https://bounceradmin.mozilla.com/admin/mirror/location/9380/ firefox-aurora-latest] (installer) and [https://bounceradmin.mozilla.com/admin/mirror/location/9717/ 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}}
== B2G Branching ==
Also see [https://releng.etherpad.mozilla.org/214 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 [https://bugzilla.mozilla.org/show_bug.cgi?id=913992 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 [http://hg.mozilla.org/build/mozharness/file/19ccf160cb4e/configs/b2g mozharness/configs/b2g] will need to have their versions updated, e.g. [http://hg.mozilla.org/build/mozharness/file/19ccf160cb4e/configs/b2g/releng.py#l46 here]:
<pre>
'mozilla-central': '1.3.0',
</pre>
would become
<pre>
'mozilla-aurora': '1.3.0',
'mozilla-central': '1.4.0',
</pre>
* The [http://hg.mozilla.org/build/mozharness/file/19ccf160cb4e/configs/gaia_bumper/gaia_json.py#l15 gaia-bumper config] will grow to three repositories: central, aurora, and the most recent mozilla-b2gXX branch.
* We'll need new [https://bugzilla.mozilla.org/show_bug.cgi?id=916911 b2g branches]
** Rail has a [http://hg.mozilla.org/build/braindump/file/a889899ca778/git-related/b2g-branching/b2g_branch_repos.py script]
* The device configs in aurora need updating to point to the new b2g manifest branch. e.g. http://hg.mozilla.org/releases/mozilla-aurora/rev/b1c4f85913d1 ''(see {{bug|950166}} for example)''
* The device configs also need updating to point to gecko aurora repositories and the new gaia l10n repositories (see {{bug|957411}})
* the mozilla-central b2g version will need bumping, e.g. http://hg.mozilla.org/mozilla-central/rev/289d0d34ded7 This should be done by RelMan, but worth the double check.
* Don't forget the [[#VCS_Sync_duties|VCS Sync duties]]!
* [https://intranet.mozilla.org/Auto-tools/B2G_Automation/Adding_New_Update_URLs|update.boot2gecko.org needs new versioned update channels]
* tag gecko+gaia for security team
=== Aurora is an odd numbered Gecko version ===
See [https://bugzilla.mozilla.org/show_bug.cgi?id=917433 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
* The device configs also need updating to point to gecko beta repositories (see bug 957411)
* Don't forget the [[#VCS_Sync_duties|VCS Sync duties]]!
* tag gecko+gaia for security team
=== 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:
* [http://hg.mozilla.org/l10n-central l10n-central] - new version. On dec 9 this will be 1.4
* [http://hg.mozilla.org/releases/l10n/mozilla-aurora releases/l10n/mozilla-aurora] - stabilizing version. On dec 9 this will be 1.3
* [http://hg.mozilla.org/releases/l10n/mozilla-beta releases/l10n/mozilla-beta mozilla-beta] - maintenance version. On dec 9 this will be 1.2
* [http://hg.mozilla.org/releases/l10n/mozilla-beta 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
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.
= Future Merge Duty Bugs =
Move these under tracking bugs once they are created:
