Revision as of 00:43, 10 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.

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

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.

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

The Release Notes pasted into the release tool are unformatted.
- It's possible to paste raw HTML in, but that seems hacky
- 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...
- At least, we need to be able to link Bug #'s to bug report URLs
- Whatever we do, try to move in a direction of reducing/eliminating manual formatting effort

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.

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 Carrots & Peppers guy. 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

The usual questions about CMYK support. What's the status, what's the plan, can money be used effectively to further it, etc.
Desire for an update on Mac package status. Strong desire for seeing native packaging. Various issues being encountered relating to current packaging systems.

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.

@@ Line 18: / Line 18: @@
 * 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 ==