ReleaseEngineering:MergeDuty: Difference between revisions
No edit summary |
|||
| Line 26: | Line 26: | ||
* 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 | * 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 | ||
* [[ReleaseEngineering/How_To/Enable_or_Disable_Updates_on_Aurora#Enabling_Updates | Re-enable Aurora updates]] | * [[ReleaseEngineering/How_To/Enable_or_Disable_Updates_on_Aurora#Enabling_Updates | Re-enable Aurora updates]] | ||
== B2G Branching == | == B2G Branching == | ||
| Line 33: | Line 31: | ||
=== Aurora is an odd numbered Gecko version === | === Aurora is an odd numbered Gecko version === | ||
== VCS Sync duties == | |||
= Next merge days = | = Next merge days = | ||
Revision as of 01:13, 2 November 2013
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)
- 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
Aurora is an odd numbered Gecko version
VCS Sync duties
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+