Reading/Web/Notes/2016-Q3 Branching strategy post-mortem

What we did

1. Shared our opinions about the future of our release process and voted on the way forward.
2. Ran an experiment on Gather, QuickSurveys, Cards and RelatedArticles

Current Strategy

• Using a default dev branch for current development
• Use topic branches for patches/features
• When dev is stable, tag release and merge to master

Why

To decouple +2ing chains of patches from going to production before signoff, which caused many problems in the past (regressions that needed SWAT deploys, unfinished features, ...).

Pros

1. Allowed us to ship better
   1. Code had been signed off by designer and product owner before rolling to production.
   2. Controlled versioned and properly documented with a changelog releases.
   3. Control over what goes to production when.
2. Resulted in a lot less SWAT deploys for the extensions following this release process.
3. Exposed bug in translatewiki bot (https://phabricator.wikimedia.org/T120581) - arguably good as this bot should be flexible to fit in with whatever release process a team follows.

Cons

1. With our many extensions in maintenance it requires responsible  periodic releases to roll out changes (like i18n messages for example). We didn’t do it and some extensions were stalled for some time.
2. Impedance mismatch with the expectations in the MediaWiki developer community.

Conclusions

1. General agreement that the current process is not working for the team right now.
2. Voted to go back to the Mediawiki Way™: Use master and topic branches on gerrit.
   1. No need to remember to release less maintained extensions, patches get auto released when merged (like i18n patches).
   2. No impedance mismatch with the expectations in the MediaWiki developer community. MediaWiki developers will be immediately familiar with our process
   3. We can still keep the same SO process, it just requires a little more work
   4. Critical bug fixes will go to master ASAP
3. Change our release notes to reflect the above choices.
   1. Discuss how to handle work that needs CR but shouldn’t be released until sign off
      1. Option 1: +2 means a feature has been OK’d by a PO (signoff). Bug fixes and hygiene patches do not need PO’s blessing.
      2. Option 2: Normal code review process, but: On first commit of topic branches related to a task that will require PO/design signoff, apply a self -2 to avoid automatic rollout to production until the task has been signed off by PO/design. When verified, remove -2 and merge the chain.

How to do the Switcheroo

• We will switch all default branches back to master (.gitreview).
• Update documentation. (and our “Subject to release process” template)
• Cards dev branch (may be other branches) is currently in an undeployable state, how to go about this:
  • Option 1: Keep working on those tasks on dev and merge to master when done (new patches go to master?)
  • Option 2: Switch default to master, send dev as patch chain over master to gerrit, block the chain with a -2 at the beginning and fix the chain to be stable enough to merge. [< do this]

Releasing going forward

• We’ve been merging to master and doing a release. How will we do this going forward?
• Should we aim to do a release at the end of every sprint for example?
• Super Release Day Monday? :)
• Or do we just want to do this randomly when we feel we need one?