Services/Process/MergingBetweenBranches

From MozillaWiki
Jump to: navigation, search

Click here for more information on the Code Review Process

Merging feature branches to services-central

  • All changes must be reviewed and have appropriate test coverage
  • All changes requiring additional testing (read: QA) must have a documented test plan in place
  • Any features requiring server-side deployments/changes must wait until those pieces are live on stage before merging

Merging from mozilla-central to services-central

  • Pull last green changeset into local services-central
hg pull ssh://hg.mozilla.org/mozilla-central/
  • If necessary (hg reports +1 heads), merge pulled changeset into local services-central
hg merge
  • If necessary, commit the merge
hg commit -m "Merge m-c to s-c"
  • Push to services-central (Does services-ops need to do this?)
hg push ssh://hg.mozilla.org/services/services-central
  • Verify green build on Treeherder (note: services-central is currently disabled in buildbot and Treeherder).
  • Perform frequently!

Merging from services-central to mozilla-central

  • Ensure all required changes have landed and the tree is green
  • Merge last green changeset from m-c to services-central (see above)
  • Ensure everything stays green, including TPS (formerly Crossweave)
  • Close the tree (see below)
  • Hand off tinderbox builds to QA
  • Once QA signs off, merge the signed off changeset (not necessarily the services-central tip anymore) to mozilla-central
  • Reopen the tree
  • Use the automated m-cMerge tool (linked to from Treeherder]) to RESOLVE FIX corresponding bugs in Bugzilla, setting appropriate Target Milestone (e.g., mozilla5 if the destination m-c will become Firefox 5)
  • When a change reaches mozilla-aurora for a particular release, set the relevant "status-firefoxN" flag to "fixed".

Note that the last two steps also apply for transplanted changes that are independently landed on mozilla-central or mozilla-aurora (e.g., a small, limited impact fix for a user-impacting bug).

Timing

  • Hand off to QA on Monday
  • QA runs test plan Monday + Tuesday
  • Merge on Tuesday

Closing the tree

We close the tree to avoid a more complicated merge after QA handoff. Wait to land patches until the merge to m-c has completed.

  • Put the reason the tree is closed in the tree reason section ("mozilla-central train has left the station", for example), and add a name to the sheriff if necessary:
var treeReason = "mozilla-central train has left the station";
var treeSheriff = 'rnewman on #services';
  • Update the tree status in #services (either in the topic, or just announce it).

Opening the tree

  • Reverse the closure steps, clearing the treeReason and the name of the treeSheriff (leave the treeSheriff pointing to #services, as that will be displayed when the tree is busted or orange).

Open questions:

  • Is there any situation in which we would accede to a release driver's request for a merge? With or without urgent QA smoketesting?
  • What about small fixes that are desirable for m-c?
    • Land on m-c and merge
    • Land on s-c and transplant
    • Do we need any process around transplanting?