Difference between revisions of "Release Process Debrief"
Jump to navigation
Jump to search
| Line 20: | Line 20: | ||
== Social Media == | == Social Media == | ||
* We could use someone at the helm on Twitter. Ryan's responding to the bug reports with his personal Twitter account because he hates to see those go so long unaddressed. | |||
== Other Ideas == | == Other Ideas == | ||
Revision as of 23:39, 9 August 2017
Release Process Debrief
This is for capturing braindumps and random observations/ideas on streamlining and improving our release processes.
As ideas gel into actionable tasks they can be moved off this page into bug trackers or todo lists.
Development
- We need to be more encouraging/insistent that the release notes get updated as stuff is landed. Especially for point releases, whenever we cherrypick a fix we should make a practice of entering it into the release notes. For 0.92.2, this wasn't done so writing them was a rush job done last minute (which in turn caused a schedule delay).
Scheduling
- 0.92.2 had just one pre-release, but given the switch to git and the introduction of the releases app, it may have been beneficial to do one or two more pre-releases.
- Objectively we're getting better at establishing and following a schedule, but for 0.92.2 there was still delays at the end. In each of 0.92.0, 0.92.1, and 0.92.2 the delays were caused by unique causes; *something* always piles up at the end and it's difficult to predict what it'll be.
Packaging
Website Releases App
Social Media
- We could use someone at the helm on Twitter. Ryan's responding to the bug reports with his personal Twitter account because he hates to see those go so long unaddressed.