Skip to content

Debrief for 2020.04

Leandro Lanzieri edited this page May 12, 2020 · 2 revisions

Summary

  • All of the identified high priority PRs were included. It's important to be realistic with this.
  • Start running a subset of spec tests some weeks before the freeze helps to find some bugs on early stages.
  • During testing automation has shown again to help a lot => RIOTnode should be pushed.
  • Knowing area maintainers helps when issues pop up.
  • Having the milestone set in PRs helps => Let's mark them when merging.

Prep for release

  • The Managing a Release guide was SUPER useful. Get really familiar with it with time.

  • Write down advance searches from GitHub which you will have to make several times during the release process.

  • Asking for high-priority PRs seemed good. We got all of them in. But take a look on the state before, and be realistic when adding them to the list.

  • Run as many tests as you can before the freezes.

  • Start tagging and adding the milestone to already merged PRs with time. Iterate over this every a couple of days. Followed @fjmolinas advice "tag as minor stuff you wouldn't put in the Release notes". It helps to get acquainted with the ongoing work.

Feature freezes

  • Dates:

    • soft freeze: 1st... but as @fjmolinas pointed out in last release it was not so important
    • hard freeze: 9th, take holidays into account
    • release on the last day of the month
  • There was no hack 'n ack before the freeze in this case, because of the COVID-19 situation.

  • Line between soft and hard freeze should be evaluated case by case. E.g. we got #13349 in the same day as the hard feature freeze was starting.

  • We don't tend to set the impact: major label

Release testing

  • Automation really helps. We should get RIOTnode in for 2020.07.
  • Tests with clear guides (if step-by-step even better) were much easier to run for the first time.
  • Not many maintainers were active during release testing this time.
  • Almost everything was OK in RC1 already.
  • It's useful to do a summary of every RC (tests that should be re-run, merged PRs, etc.) as the first thing for the next one.
  • Knowing area maintainers helps when issues pop up.

Usage of "Reviewed" Labels

Count Label
106 1-fundamentals
100 2-code-design
111 3-testing
98 4-code-style
76 5-documentation
Clone this wiki locally