3.13.0 Schedule | 3.13 Branching Process | 3.13.0 TODO | 3.13.0 DONE
3.12.1 TODO | 3.12.1 DONE | CI Overview
3.11.4 TODO | 3.11.4 DONE | CI Overview
Present: @pcreech, @qcjames53, @iballou, @sbible, @ColeHiggins2, @ekohl
This was a rocky release process and we had some discussion on how to make it smoother. Since many of those things aren’t specific to 3.11, I’ll add those in its own section.
We’ve noticed that often the Foreman release process depends on @ekohl and that’s undesirable. I like being able to go on vacation without having to worry.
The most common pain point is writing & reviewing the release notes. @ColeHiggins2 indicates he struggles with knowing what to write (like headline features). This is how I always look at it:
For an X.Y release we always write 3 sections
Then for every X.Y.Z we include a list of all the Redmine issues. These are mostly autogenerated, though I usually go though all the issues and verify the components and if the title makes sense. Then I mark them as triaged so I can filter out what I’ve already done.
The 3 sections should be gathered from all the maintainers. The responsibility of the releases owners is that they’re written, not to necessarily write them. Right now I often end up helping here, but ideally anyone can help. The community demo agendas and Redmine features can be a good start, but ideally people who write a feature will also submit a PR to nightly’s release notes.
A more practical blocker: not the entirety of the release team has permissions to merge the release notes. While you don’t need any permissions to submit a review, it’s not great.
It’s agreed that we’ll try to work more as a team on this to improve our bus factor. While it wasn’t mentioned in the meeting, I later realized we can also ask @docs on how to collaborate on this topic.