General Assembly @ RIOT Summit 2026

Ann · 2 September 2026 12:28

2026 General Assembly

Date: Sep 2, 2026 (Confirmed!)

Time: 11:00 CET (Confirmed!)

Moderator: Ann (Tom Hert) Miri

Venue: Grenoble

Note taking: Mikolai

Martine volunteers, Ann helps

(Kevin not present)
Tom: Kevin just wanted to support, but then had to take over completely. Several issues found in Release tests which he couldn’t fix in time, next release managers will have to look into them.
Jose: issues found in lorawan part, which have probably been there for some time.
Tom: remember that last release there were also 2 failing tests

Tom: governance.md says that every stakeholder should have an active admin, right now that is not the case
Tom: suggestions were Mikolai (TUD), Teufelchen (HAW)
Karin: stakeholders are TUD, HAW, MLPA, Berlin, Frankfurt, TUHH
Tom: Hauke, miri, cenk, benpicco, leandro, peter, kevin.
benpicco: that’s new to me
Thomas: what about crasbe?
crasbe: not available at this time
Tom: crasbe declined in weekly to not take too much responsibility, currently no other maintainer candidates from TUHH
Tom: so Mikolai?
no one objects
Mikolai agrees
Tom: and Teufelchen?
no one objects
Teufelchen agrees
Martine: what to do about cenk, peter, hauke? just remove them?
everyone agrees

Tom: came up after discussing current release progress, releases use up a lot of resources. especially straining on working students. also some releases have not so much new features?
Kaspar: why does it take longer nowadays?
Tom: some of the release test automation is breaking
Martine: we will try to improve the automation for next release
Thomas: was always the idea to improve the process to reduce the load
Tom: so maybe wait with decision for next release and see how release test fixing works out?
Karin: what was the original reason for current cadence
Kaspar: the longer the cadence, the more we wanted to get into the release, more pressure. fixed cadence was meant to have smaller steps
Thomas: meant to be agile process
Karin: what would fit the current situation?
Thomas: not much has changed IMO
Tom: someone raised before: do people even use releases?
benpicco: MLPA usually based on some commit on master. but every release is a good checkpoint with tests etc.
Tom: proposal to wait for next one
no one objects

Tom: spin out of weekly: sth broke in Rust integration
- crasbe: stuff constantly breaks unfortunately (Mikolai: not just in Rust :P)
chrysn: setting crates out-of-tree was for experimental state, but also that you could use one crate for several RIOT version. from own experience, I just use latest always. So would now be open for moving in-tree. Would make things much easier fixable.
crasbe: before moving in-tree, address the open improvements in the Pull Requests of Rust repos?
chrysn: lately little activity from my side but moving in-tree should also make improvements from PRs easier. Will do, as I have a rough plan.

Koen: currently I am main administrator. I won’t be able to continue. Any volunteers?
Koen: what it means in practice: responding to crasbe when CI stops working, fixing disk-full problems. Couple of hours per month of work. Will do handover. Timeframe a month from now.
Matthias: which services there?
Koen: forum, pretix, pad, CI distribution, parts of the website (apidocs, main, summit, guides), monitoring graphana for CI, crystalball, gitea, some Caddyfiles
Kaspar: some Ariel stuff, one docker-compose stack
Koen: linux with docker-compose, some external monitoring and database in LXC, tried to make it easy to maintain
Mikolai: would volunteer, but only in a team of two people being responsible
Martine: can do technical support at least for the beginning
Mikolai: want a second person permanently
Elena: will be that second person
everyone happy

José: Maybe redo the release specs, back then not many boards, now many boards, many tests try subset of features, many tests directly tied to barely used boards
Jose: proposal to separate features to test from concrete boards. we will not be able to run all on all boards for every release, but we could sweep over boards over different releases
Tom: reminds me of HiL discussion
Mikolai: but does IoTlab support more boards than what we currently use?
Jose: yes, but some of them are broken and are the reason for flaky tests
Mikolai: so rather not run automation on IoTlab anymore?
Jose: e.g. for LoRa, tests are failing because concrete board is not available, would be better to test with another one it that case and succeed.
Mikolai: sounds reasonable
crasbe: I have a lot of Nucleo boards (>20) available, but setting up HiL tests is not documented?
Tom: there is a lot of prior work, but it is really not trivial to get it to work reliably. someone with quite a lot of time has to tackle this.
Thomas: cables are flaky, its difficult. we would need some shield, but that is board-specific.
Marius: had issues with lorawan for our product. proposal for HiL: use boards with standard shield form factor, have global bus to distribute to different boards (?). idea similar to jumperlessboard project. but software support needed, not trivial.
Martine: example of maribu’s peripheral self-test shield
Michel: not the same idea
Tom: due to time, move to Breakout sessions