Services/Process/MergingBetweenBranches: Difference between revisions

← Older edit

Services/Process/MergingBetweenBranches (view source)

Revision as of 17:14, 21 December 2014

1,603 bytes added , 21 December 2014

m

Bug 1082602

Edmorley

canmove, Confirmed users

1,126

edits

@@ Line 1: / Line 1: @@
-Snapshot of http://etherpad.mozilla.org:9000/services-client-merge-process :
+Click here for more information on the [[Services/Code_Review|Code Review Process]]
 == Merging feature branches to services-central ==
@@ Line 6: / Line 6: @@
 * 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, merge
+* 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?)
-* Verify green build in tbpl, including TPS (formerly Crossweave) — wait for the email.
+ 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
-== (Proposed) Timing ==
+* 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 smoketests Monday + Tuesday
+* QA runs [https://wiki.mozilla.org/QA/Sync/Test_Plan#Client test plan] Monday + Tuesday
 * Merge on Tuesday
-== (Proposed) Schedule ==
-(To-do - add a link to a schedule or transclude a schedule)
+== Closing the tree ==
-* May 2/3: QA handoff + merge
-* May 16/17: QA handoff + merge
+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.
-* May 24: Fx 6 merges to Aurora
-* May 30/31: QA handoff + merge
+* Go to the [http://tinderbox.mozilla.org/admintree.cgi?tree=Services-Central tinderbox admin page], and change the status message as described in the comments.
+* 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:
+ <nowiki>var treeReason = "mozilla-central train has left the station";
+var treeSheriff = 'rnewman on #services';</nowiki>
+* 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: ==