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

From MediaWiki.org
< Reading‎ | Web
Jump to navigation Jump to search

What we did[edit]

  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[edit]

  • 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[edit]

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[edit]

  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.[1]
  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[edit]

  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[edit]

  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][3][4][5]
      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[edit]

  • 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[6][7][8] (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[edit]

  • 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?

Comments[edit]

  1. B: This is debatable. To be honest we haven't been developing actively for a couple of quarters now as we used to do before.
  2. JR: Should we mark patches with [needs S/O] or some similar tag to make it easier for code reviewers to know whether they can merge or not?I'd at least like us to get in the habit of doing that, to ensure big changes e.g. redoing language overlay have had input from more people.
  3. S: I don't mind. Let's not solve problems that we don't have right now though, eh?
  4. JO: That's the problem of this approach. I've added another option that seems much simpler and adapted to the tools we have and how people work, see option 2
  5. B: Why not just leave a comment in the patch?
  6. JO: I'd rather send the current `dev` branch as a topic branch on top of master, and -2 the first commit on the chain until it is more stable. I'll add options here to select too.
  7. S: Yup. That's also fairly trivial to do with `git review`.
  8. JR: i'm fine with that.