Weekly coordination meeting

Community
,
57

RIOT weekly coordination 07.08.2026, at 15:00 CET

Link: Jitsi Meet

Attendees

  • Tri-State Tom
  • Ann​:frog:
  • maribu
  • Karl
  • Teufelchen

Note-takers

  • Moderation: Anarchy :bomb:
  • Notes: Maribu & Karl

Agenda

  • Release stuffs
  • Streamlining Security Reports
  • Streamlining Release Process
  • Failing nightly :sleeping_face::bomb: & weekly
  • RIOT, CI and you (HiL, SiL, I am in a loop :clockwise_vertical_arrows:)
  • Github PR Stacks

Notes

Release stuffs

  • Things are not really progressing…
  • Tom: Release have been halter for some time. Two major problems left
    1. Interop Test spec 8 task 8 that has been failing since last release. Probably not complicated, but lack of time to fix. Easy to reproduce, passes in 2026.01, so bisecting is possible
    2. The LoRa one. Not sure about this one. Jose tested a bit, not easy to reproduce. Hardware access is limiting me to address this.
  • Ann: Since you did not volunteer to manage the release, we hardly can ask you to fix this.
  • Tom: But I cannot move the work to Michael
  • Ann: But Michael at least volunteered. It should also be fine to just document the regresssions and ship.
  • Tom: I don’t want to slip on quality here. Release should be reliable and RIOT should be getting better, not get worse over time. Maybe I’ll throw some Tokens on it and see if that helps.
  • maribu: try delegating
  • Tom: Tried, but to no avail. Everyone is busy or has moved on.
  • Karl: On what setup fails it
  • Tom: Running reliable in the FIT IoT Lab testbed for 2026.01, but fails reliable for the RC
  • Ann: Was already failing in the last release spec, wasn’t able to dig depper due to time constraints

Streamlining Security Reports

  • maribu suggested to remove the security mailing list and use Github security advisories exclusively
  • maribu proposes that the email security@riot-os.org could just auto-reply with instructions on how to use the GH SAs
  • Room: test HackerOne

Streamlining Release Process

  • maribu: For compliance reasons, it is good if commercial users base on a release rather than on master, as mandatory vuln management is easier: The “affected versions” field ususally is in terms of releases, not in terms of commits
  • maribu: For compliance reasons, it is good if all security related fixes get backported into a release
  • Ann​:frog:: Release process is already draining a lot of resources. There is little potential increase the frequency without negatively impacting development.
  • maribu: Maybe we should revisit the release process and see, how we can streamline it to the point, that releases become easy enough to manage
  • Tom: It is always good to have as much automation as possible, but it is not easy to get good automation. We had a lot of automation done, but maintenace was starting to pile up (e.g. zephyr started to no longer work on hardware we had etc.)
  • Ann: …
  • Tom: Before adding more tests to the release, require them to be automated reliable. Reducing the release tests is not a good idea, it should rather grow to improve coverage and cover new features
  • Karl: just Patch backport ?
  • Tom: release branch
  • Tom: We did point releases with limited testing by deducing what actually could be broken by the delta
  • Ann: releas usage?
  • Karl: kindof for us ( like to do more )
  • Tom: definently
  • Ann: less releases
  • Maribu: even more relprocess break
  • Tom: hunting for checkmarks
  • Ann: we are missing time – maybe revaluate at summit
  • Tom: any objection to bring it up ?
  • Room: silent No
  • Ann: putting it to agenda

Failing nightly/weekly :sleeping_face::bomb:

nightly

  • maribu: previous failure mode was one test on samr21-xpro failed when compiled with LLVM. New failure mode is timeout until crasbe kills it
  • github flaky
  • ci depend on crasbe
  • 7h
  • Teufelchen: split up ci to not make less fail at once
  • Tom: sub tests kinof exist
  • maribu: need more details
  • Teufelchen: multiple murdocks
  • maribu: splitup might not work
  • Tom: might be configurable
  • Room-disq: some split might be posible an helpfull

Weekly

  • Tom: The output is not easy to understand. Poor signal to noise ratio. If we were able to highlight what the actual issue is (Github runner flaky, connection to FIT IoT Lab flaky, actual issue) would help

RIOT, CI and you (HiL, SiL, I am in a loop :clockwise_vertical_arrows:)

  • crasbe: Idea: Could we have a Docker image for HiL clients based on tinybuild to make the setup less of a pain?
  • crasbe: (yes, looking at the whole Docker situation is on my ToDo, we also need to update the Ubuntu version soon(ish))
  • Ann: simplify industy soulution
  • maribu: the task is not that easy
  • Ann: maybe i should try
  • Tom: been though that
  • Teufelchen: build something to get positive responses
  • Tom: id like to offer some experience

Github PR Stacks

  • Ann​:frog: (on Matrix): Talking about it PR review, they finally added a fairly neat feature that other git forges had for a while, you can finally stack PRs to make them more readable / chunked
  • maribu: The feature requires admin intervention to enable. @maribu and @basilfx have PR stacks ready to submit. Would like to try it to see if it helps managing reviews or dependend change sets.
General Assembly @ RIOT Summit 2026