Weekly coordination meeting

Community
,
41

Hello everybody!

2026-03-13T14:00:00Z we will have our next weekly coordination meeting.

The meeting will take place online on Jitsi.

Please add your agenda items to our pad for the meeting minutes, so we know beforehand if there is anything to discuss (some people decide their attendance on that).

Best
Martine

42

Hello everybody!

2026-03-27T14:00:00Z we will have our next weekly coordination meeting.

The meeting will take place online on Jitsi.

Please add your agenda items to our pad for the meeting minutes, so we know beforehand if there is anything to discuss (some people decide their attendance on that).

Most of the people from TU Dresden and HAW Hamburg will be not be able to join, but please, feel free to organize among you.

Best
Martine

43

Hello everybody!

2026-04-10T13:00:00Z we will have our next weekly coordination meeting.

The meeting will take place online on Jitsi.

Please add your agenda items to our pad for the meeting minutes, so we know beforehand if there is anything to discuss (some people decide their attendance on that).

Best Mikolai

44

RIOT weekly coordination 10.04.2026, at 15:00 CET

Link: Jitsi Meet

Attendees

  • crasbe
  • carl
  • mikolai
  • karl

Note-takers

  • Moderation: Mikolai
  • Notes: Mikolai

meeting

Agenda

  • MCR asks: recent addition discussion about new maintainer (EF)… did something go wrong here?
  • CS asks: static const in headers
  • CS asks: SPI API

Notes

static const in headers

  • Carl: seems like black magic, just used to be optimized out
  • Karl: just works because never actually put in binary
  • Carl: is this a coding convention? are we sure optimizing out always works
  • crasbe: can we just try if linker is smart enough
  • Karl: compiler works per definition, linker might depend on implementation
  • mikolai: first step: document why we are using static const in headers

SPI API

  • Carl: API broken: meaning of SPI_DEV(x) not defined in documentation, physical peripherals not always defined as available, why are pins combined with peripherals
  • Karl: same with UART and I2C
  • carl: why?
  • karl: portability to other boards, I2C “just works”
  • crasbe: peripheral instances might differ quite a lot, different configuration etc, pins as defined on board
  • carl: concrete board: adafruit-feather-nrf52840-sense, why second SPI?
  • crasbe: second for flash. speciality for nrf52: you can freely configure pins for peripherals
  • Karl: most boards / MCUs have hard-wired peripherals anyways
  • carl: so again, missing documentation
  • carl: but still, not very beginner-friendly to need to change random headers
  • (some discussion about more user-friendly macro interface, but concerns about compiler optimizations)
  • crasbe: created a PR to improve documentation: drivers/periph/spi: add doc about multiple SPI buses by crasbe · Pull Request #22185 · RIOT-OS/RIOT · GitHub
45

RIOT weekly coordination 24.04.2026, at 15:00 CET

Link: Jitsi Meet

Attendees

  • Karl
  • Marian

Note-takers

  • Moderation: Karl
  • Notes: Marian

Agenda

  • CI / Build System

Notes

CI / Build System

  • Marian: number of workers was quite depleted, dropping mobi6 resulted in PRs no longer mergable
  • Marian: Leandro added new workers, now CI time is acceptable again
  • Marian: might be worth to consider other strategies than throwing more hardware on the problem, specifically improvments in the build system to reduce the number of compilation taks
  • Marian: Currently 164,323 builds each compiles core/init.c, but only a few hand ful of different objects are expected
  • Marian: ccache can improve things, but needs to have 164,323 mostly identical copies of core/init.o due to -DRIOT_BOARD=... -DRIOT_APPLICATION=..., etc.
  • Marian: even if our compilation jobs would be fully cachable, a build system supporting dependencies and multiple outputs could reduce the compilation to just the actually different init.o objects, and link the same object into different outputs. That would be faster than ccache
  • Marian: Josh did sketch how th is could be done with some invasive changes in our build system, but sticking with GNU Make as build system and limited to no user facing changes
  • Marian: We might also look for other solutions. Looking into our build system makes it pretty apparent, that expertise on how to write good Makefiles is pretty scarce within our community. Probably Josh is the only one of us actually knowing how to write proper Makefiles.
  • Karl: Effort of changing the build system would be relatively large, optimizing ccache cachability would be a much faster way to reduce the pressure
  • Karl: We could provide board and app name as extern const char * instead, reducing the impact of them on the cachability
  • Marian: We could also still add flags for preprocessor stuff that is only available with #include "buildinfo/board.h" or #include "buildinfo/app.h". But still, even 99% identical boards such wemos-zero and arduino-zero differ in their module set. We would also need #include "buildinfo/modules.h" for that to have any impact.
  • Karl: That seems like a lot less effort than changing the build system
  • Marian: Miri NACKed on #include "buildinfo/modules.h" hard