We will have our Community’s annual General Assembly during the RIOT Summit in Grenoble. As in the past years, this will also be the annual face-to-face version of our quarter-annual Virtual Maintainer Assembly (VMA) and follow its typical format.
As usual, we collect the agenda items beforehand in a pad. If you have anything to discuss, please add it to the agenda, a rough time estimate, and your name.
2025.07 Release debrief from Release Manager - 5’ (Kevin)
(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
Outlook on upcoming 2025.10 Release (Mikolai)
Mikolai: unicoap, new docker image, any other big things outstanding?
Martine: updating / fixing release tests
2027.01 Release Manager
Crystalball selects Lasse
Lasse agrees , Teufelchen will support him
More active maintainer github admins
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: 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
Should we reduce the release cadence?
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
RIOT & Rust: What is our vision?
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.
Community Server: new maintainers
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
Updating Release Specs
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
Miri
, Teufelchen will support him
(Mikolai: not just in Rust :P)