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?