Debrief for 2020.01

Summary

• Testing automation has made release testing much easier. Lets automate release tests.
• Task Force: old + current + future manager ??
• Code/Area maintainers make release testing/debugging/bug-hunting easier.
• Release-manager should be able to reschedule PR's
• Request High Priority PR’s early in the Release, and refresh every month.
• Good labels help writing release notes a lot!
• Good opportunity to learn and know more about the project

Prep for release

• Take a look at deprecation at the start of the release (I did it too late)

• Requesting High Priority PR's was useful to point to PR's that the community thought were interesting but timing wise it didn't work. It could be good to ask people this more often, e.g. monthly basis.

• Reiterate on @kb2ma point "Useful to have previous release managers available for private unicast questions."

• Start tagging PR’s early for the milestone, label PR that have no labels. Tag as minor stuff you wouldn't put in the Release notes.

• Check the hack and ACK date, move it up or down depending on release dates.

Feature freezes

• Regarding dates:
  • soft freeze: … didn't seem that important, but 2 weeks before hard-freeze
  • hard freeze: 1st instead of 10th
  • release on the last day of the month

The line between soft and hard feature freeze is a bit blurry. `in my experience it was more important to have a lot of time before release to find and fix bugs.

• Release manager powers -> should have the right to reschedule PR's (explicit)

  • some days before soft feature freeze
  • from soft feature freeze to release

• Important to have “sprint” days before feature freeze

  • there should always be a hack and ack before soft freeze

• Step out of the box for reviewing, ask a lot of questions but trust the contributor

Release testing

In my experience this is the part where the release manager does most of the work. Testing is heavily release-manager based. This is not necessarily bad, test automation have made this easier

Having explicit/implicit area maintainers is good:

1. some help with testing
2. they are responsive for debugging

This made release testing easy in the sense that when it didn't work, someone else took care of it, and that is fine (especially with easy to run automated tests).

The issue was with cases where the initial contributor was unresponsive.

conclusion: when there is an implicit area maintainer with a well defined area release testing goes smoothly.

Automate Release Tests

I expanded on @jia200x test script and although it took some work, it allowed me to do some release-testing previously to soft feature freeze to test High impact PRs. It made me confident on merging difficult PR's even if close to the deadline.

We need a common base, lets push riotnode, it worked well for me! @leandrolanzieri @miri64 might want to join the effort.

Stale bot

First release with a 'normally' active stale bot: manageable, worth it to take a look.

• 11 Stale PRs pr's marked as stale during the release cycle
• 18 Closed Stale PRs pr's marked as stale and closed during the release cycle
• 01 Stale Issues issues marked as stale during the release cycle
• 13 Closed Stale Issues issues marked as stale and closed during the release cycle