Services/Process/MergingBetweenBranches

< Services‎ | Process
Revision as of 03:17, 20 April 2011 by Rnewman (talk | contribs) (Created page with "Snapshot of http://etherpad.mozilla.org:9000/services-client-merge-process : * Merging feature branches to s-c ** All changes must be reviewed and have appropriate test coverage...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Snapshot of http://etherpad.mozilla.org:9000/services-client-merge-process :

  • Merging feature branches to s-c
    • 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 m-c to s-c
    • Pull last green changeset into local s-c, merge
    • Push to s-c
    • Verify green build in tbpl, including TPS (formerly Crossweave) — wait for the email.
    • Perform frequently!
  • Merging from s-c to m-c
    • Ensure all required changes have landed and the tree is green
    • Merge last green changeset from m-c to s-c (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 s-c tip anymore) to m-c
  • (Proposed) Timing
    • Hand off to QA on Monday
    • QA smoketests Monday + Tuesday
    • Merge on Tuesday
  • (Proposed) Schedule
    • April 25/26: QA handoff + merge
    • May 9/10: QA handoff + merge
    • May 17: Fx 6 merges to Aurora
  • 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?