Release Process Debrief

From Inkscape Wiki
Jump to navigation Jump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

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

Announcements

  • Not everyone is subscribed to inkscape-announce@, so need to also send notices to inkscape-devel@ and inkscape-user@
    • inkscape-devel@ should be the _first_ place to announce to. If there are glitches anywhere, better that the devel folks see them first.
    • inkscape-user@ announcement can be more detailed than what we send elsewhere. E.g. Extra details about getting involved in the project, how to file bug reports, direct download links, more detailed descriptions of features, etc.
  • There is less press interest in bugfix point releases than in the main .0 releases. This is good and bad:
    • Being scooped is a bigger worry for .0 releases, and probably non-issue for point releases. Which means last minute delays to polish and perfect are less of a worry in point releases, and we may as well take what time is needed.
    • Places like opensource.com aren't interested in release announcements, but are willing to accept original tutorials, so maybe that's a possibility when we have more writing capacity.
    • Places like phoronix seem to not do point releases, but do seem interested in technical challenges, revolutionary changes, etc. so material that describes noteworthy problems that were overcome in the point release might be more compelling.

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