Services/Process/MergingBetweenBranches

Snapshot of http://etherpad.mozilla.org:9000/services-client-merge-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, merge
• Push to services-central (Does services-ops need to do this?)
• Verify green build in tbpl, including TPS (formerly Crossweave) — wait for the email.
• 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)
• 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

• Hand off to QA on Monday
• QA smoketests Monday + Tuesday
• Merge on Tuesday

(Proposed) Schedule

(To-do - add a link to a schedule or transclude a schedule)

• May 2/3: QA handoff + merge
• May 16/17: QA handoff + merge
• May 24: Fx 6 merges to Aurora
• May 30/31: QA handoff + merge

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?