Release Process Debrief

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).

• It would pay off to be a bit stricter at checking that packages are done for the pre-release. If any platform is missing for a pre-release, that could be a warning sign that there may be hidden problems that could delay the release.
  • Especially give attention to any breakages in auto-build systems like the PPAs

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.
  • When this happens, it is important to touch base with everyone in case someone is still working on something, to avoid a miscommunication leading to a premature announcement.

• A roster of people to run through would be useful, keyed to the topic they're involved with. A LOT of people are involved in prepping a release, all important in various ways, and it's too easy to forget someone.
  • Contact early in cycle, "Is there anything you're concerned about for the upcoming release, that we need to account for?"
  • At pre0, contact again "How is <topic> coming along? Have you had a chance to make sure it's ready?" Make note of problem areas for followup.
  • Another touch point a day or so before the final tarball. "Is <topic> done?"
  • After the tarball but before the announcement is another touch point.

Packaging

• The 0.92.x branch is still supporting autotools, so we need to remember to continue updating configure.ac.

Website

• The Release Notes pasted into the release tool are unformatted. Fixed for 0.92.2 by copy-pasting html from Wiki, fixed for future releases by addition of a WYSIWYG editor widget for entering the html.
  • It's possible to paste raw HTML in, but that seems hacky Still possible, but also allows usage of js text editor now.
  • Markdown would be nice to have. Would need either a wiki->markdown script (e.g. modify mkNEWS), or even move Release Notes out of wiki to a markdown-based shared editing system. Need some deeper thinking on this...
    • Perhaps use a git repo, or even the respective Inkscape branch's git repo? Similar to a changelog? Make a template, and have a file for it that is relevant to the respective branch? Easy access for devs, no time lost converting to html for copy-pasting on website.
  • At least, we need to be able to link Bug #'s to bug report URLs Was possible for 0.92.2 already.
  • How should images be added to release notes? Currently, they need to be uploaded 'somewhere', and linked, e.g. from the Wiki. It would be nice to be able to upload them directly when adding to the text. That's a problem not only for the releases app, but also for the git option above.
  • Whatever we do, try to move in a direction of reducing/eliminating manual formatting effort

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

• A 0.92.2 post on deviantArt is still needed.
• Knowing a few journalists personally might help in getting press releases pushed out better.
• 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.
• Worthwhile to do some organized recruitment. Maybe organizing a meetup would be good? Build a roster of 1-2 active posters on each media platform, and ask them to do the honors of posting our announcement?
• We have influential VIP users with large followings on their blogs. E.g. the Pepper & Carrot author. Outreach to them might be worthwhile to get word of releases, fundraisers, etc. spread more broadly. Periodically touching base with these users to gather their input could be useful by itself.

Social media discussion is happening here: https://teams.freecreatives.org/inkscape

Feedback from Users

• The usual questions about CMYK support. What's the status, what's the plan, can money be used effectively to further it, etc.
  • http://codewideopen.blogspot.com/2009/12/inkscape-should-not-support-cmyk.html
• Desire for an update on Mac package status. Strong desire for seeing native packaging. Various issues being encountered relating to current packaging systems.

Other Ideas

• The Vectors team needs a landing page to point prospective members at. Something that explains what the team is, how to join mattermost, and when the next meetup is scheduled, etc.
  • what about this one: https://inkscape.org/en/*inkscape-vectors? It can hold various documents for the team.

• Vector Team's gitlab repo is partly private. Should it be?
  • https://gitlab.com/inkscape/inkscape-vectors/press/issues/1#note_37038992
  • https://gitlab.com/inkscape/inkscape-vectors/press/issues/1#note_37063210

• Need to mark bugs in launchpad Fix Released that closed by 0.92.2

• Part of the process for doing a release, should be to also set up the infrastructure for the next release
  • Add new milestones in Launchpad
  • Start a "desired bugs to fix" list to help focus efforts
  • Start a new Release_Notes page
  • Start a release checklist
  • Prep a kickoff email