Debrief for 2019.10
Useful to have previous release managers available for private unicast questions.
Useful to set up a section of the wiki for the release. Helps with tracking and transparency.
For a 'remote' release manager, the first two points combined with face-to-face meeting background made the process relatively low stress from both sides.
Existing automation for interaction with GitHub is awesome.
As a first time release manager, I learned a lot about qualifying a release with testing and network setup, and became exposed to new areas and people in RIOT.
I spent around 80 hours on the release, mostly in the three weeks since hard freeze.
Almost 1/3 of merged PRs include at least 1 "Reviewed" label. See table at end.
Question: What justifies a point release? See #12652, on debug target failure for sam0 boards.
For release dates, I think it's a simple policy to say:
- soft freeze on the 1st
- hard freeze on the 10th
- release on the last day of the month
Three weeks for testing and release notes works well.
Kevin and Peter agreed to act as advisers, and I also asked Martine since she seems to be the keeper of the release flame.
Worthwhile to identify PRs that had been marked for a few earlier releases, but had no activity since then. This quarterly advancement defeated the stale bot. As a result, I did not advance the release for about 35 PRs. Added this suggestion to release guidelines.
I also learned an informal maintainer guideline: If you make a proposal on to the maintainer's list on a relatively minor topic and no one responds, then it's OK to proceed. In this case, the proposal was to not advance the PRs.
It was a good idea to request high priority PRs. It helped me get in the flow of process coordination among participants. I learned about new technical topics and engaged with other maintainers.
It was a little tricky to decide what qualified. The 'Impact: major' label helps. It was a good first time to just use my judgement for a release decision.
I took off a day and a half from work to track/resolve remaining open PRs and create release branch.
I am impressed at how testing self organizes and the work gets done.
Issue with PR #12486 remove new irq_handler feature during hard freeze. See PR #12500 for an addition to the MAINTAINING.md guidelines to cover the release process. Ultimately, the release manager (me) made the call to not alter the release process, and instead added an item to the release notes about the expected short lifetime of the irq_handler feature.
If you feel it is important to change the release process for the current release, be sure to flag the issue on the maintainers list!
The release notes take quite some effort to assemble. I made some updates to this section of the release guidelines, including use of the 'hub pr' tool to generate a list of PRs in the release, including Area labels. At the same time, this was a really interesting part of the process because I got to explore all the work that was done for the release.
New dump-issues target for riot-release-manager helps with issues lists.
| Count | Label |
|---|---|
| 130 | 1-fundamentals |
| 121 | 2-code-design |
| 116 | 3-testing |
| 116 | 4-code-style |
| 111 | 4-documentation |
| 139 | any |