Weekly coordination meeting

Community
,
59

RIOT weekly coordination 14.08.2026, at 15:00 CET

Link: Jitsi Meet

Attendees

  • Karl
  • Crasbe
  • Ann
  • Tri-State Tom
  • Lasse
  • Teufelchen

Note-takers

  • Moderation: Anarchy :bomb::fire::firefighter:
  • Notes: Tristate Tom, Ann​:frog: & Friends

Agenda

  • Assessment of the Rust integration of RIOT
  • Build System/CI: Introduce Build Variants
  • riotdocker update to Ubuntu 26.04 LTS :raccoon:
  • Release Update

Notes

Assessment of the Rust integration of RIOT

  • maribu: The rust integration of RIOT is causing a lot of maintance effort, because
    • interdependent code split over three repos:
      • Parts of the rust infrastructure in RIOT, parts in rust-riot-sys, parts in rust-riot-wrappers
      • often having to juggle PRs between three repos
      • cargo’s patch.crates-io is a footgun: changes to riot-sys need to be patched in both RIOT and rust-riot-wrappers repos, otherwise fixes do not actually get deployed
    • c2rust is not meant to be used to provide a stable interface: it targets a “fire and forget” conversion of a C codebase
      • updates of c2rust often break rust-riot-sys
      • changes in C code that are extremely unlikely to break any C code users (e.g. converting a function argument from char * to const char * or to const void *) do reliably break rust-riot-sys
    • rust breakage often taking a “PR hostage” by virtue of a failing CI
      • specialized knowlege and skills needed to fix
      • a single line change in C code that is extremely unlikely to break C call sides has a tendency to burn half a work day on the rust fallout
  • maribu: mixed stories about success of rust integration
    • there were initially some public examples for use of rust in RIOT, maybe worth checking out what happend
    • tests of writing rust code for RIOT at my employer were rolled back to C code, as crucial C APIs were not available to rust
  • maribu: Maybe it is time for a sober cost-benefit analysis to see if the current approach is sustainable
  • maribu: Possible options forward:
    • double down on rust
      • stakeholders agree to allocate some serious person hours on this
      • move rust into the RIOT repo, so that the public rust API becomes the stable interface, not how c2rust interprets C code
      • phase out use of c2rust
      • expose more RIOT APIs as rust interfaces
    • move rust support out of the RIOT repo
      • no more failing CI taking PRs hostage
      • high risk that rust integration will not be maintained adequately and depend on old RIOT releases for ages
    • drop rust support entirely
    • accept the maintenance cost and continue with the current approach
    • ???

Ann: Maribu not here, would make sense to at least wait for Chrsyn

Ann: Hard to understand the how to even get the rust PRs running

crasbe: You need to update in the right order in order to test.

Ann: We should discuss this at the summit, since it has long term impact on the future of RIOT (Also discussing without Chrsyn is wack)

Karl: Rust stability issues, does anyone know about C2rust? What about const vars, how it treats them so on? ignore const in headers when c->rust might yield more flexible rust c integration

Group agrees that we have no clue about this

Action Point: Add to summit agenda

Build System/CI: Introduce Build Variants

  • crasbe: prepared RFC: build system/CI: Support for Build Variants · Issue #22555 · RIOT-OS/RIOT · GitHub
  • crasbe: Many tests/examples have configuration options, but only one variant is ever built.
    • Can lead to bitrot
    • Especially when code paths are guarded with #ifndef ...
  • crasbe: Build Variants Support:
    • Introduce an additional Makefile.variants.ci that includes environment variable settings for different variants
    • Read by CI script(s), added to job list
  • crasbe: Tribal Knowledge required: where to add the code for the CI side?
    • RIOT-OS/RIOT/.murdock?
    • RIOT-OS/murdock-scripts?
    • Both?

crasbe: At least Kaspar or maribu should hopefully know this, both not here :frowning:

Tom: Maybe you can ping Leandro or José, they should have experience from past stuff multiplication of builds can be iffy when testing more stuff Used to be on mobi, now tatooine, when something updates it will be updated there Not sure whether its automatic, remember “watchtower” that updates the docker image for runner

crasbe: Appears to not be part of that repository, not sure whether guarded by watchtower, not aware of repository that might host it

Tom: Tough, back when ??? did React stuff

Teufelchen: I have access to that repository

Tom: There was discussion how you can add different configs into different job queues prev. how we solved, different tests with different makefiles Would add to tests, copy everything but makefile/super, was dirty

crasbe: Maybe if you have time, look at my proposal :wink: Have configuartion makefile that gets set before application makefile Dont have to do any copying, deep changes, simple additions to job scripts

crasbe: Would like to have idea where to look, everything really really complicated

Karl: I think Murdock gets variances by calling makefile info commands, very overengineered/stretched

Tom: Looking through Murdock scripts right now, uggh, maybe instead of sep. jobs still have one for caching

Karl: We have internal potential solution work right now (no esp for now tho) Murdock is already quite full (queue), maybe not increase too much but also want more stuff to be tested

Teufelchen: Agrees, Murdock has problems Karl: Might also be our build system and Murdock just has to fight against it

Teufelchen: Not directly my problem with Murdock, biggest problem is nobody understands Murdock, nobody knows how to do anything with it

Crasbe: Variants would not increase build time by 2x over night, maribus work to make caching better could mitigate this Proposal should/is also compatible with most other build systems

Agree to move on since we need more input from other people like Kaspar

riotdocker update to Ubuntu 26.04 LTS :raccoon:

Release Update

  • Tom: Tacking on, release backporting right now, doing RC2 right now Will make clear that some release tests had issues Hopefully should warn next release manager
  • Ann: Just put in RIOT issues, worst case warn next release manager again when they start working
General Assembly @ RIOT Summit 2026