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).
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.
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).
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)
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
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).
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).
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).
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).
Teufelchen: we havenât decided on one of Mikolais proposal on how to get this unstuck
maribu: lets try the sensible option, Iâll push the commit
mikolai: may be there will be more issues coming up
â
Teufelchen: related: stack protection by default, PR from 2020, should we just go forward with this? any volunteers to bring the default module selection mechanism up-to-date?
people generally agree
â
mikolai: requesting help for LTO bugfixing before next release in case something is broken
Teufelchen: commits on doing that
Vibe Coded Unicoap PR
crasbe: 4 lines, a lot of LLM-generated documentation
Ann: I was in contact with carl back then, I think I remember he was not amused by the bad quality of the LLM-contribution
crasbe: I want to see it closed >:)
Ann: Iâll double-check and will close it
maribu: Donât waste human time on llm slop
Security Report Apocalypse: How to handle the load?
Teufelchen: load has increased. LLMs have become better, so often valid bugs, but badly documented/explained, and way to high CVE score
Teufelchen: maribu suggested to drop the security mailing list and the github security advisories and just use regular issues to streamline the process
Teufelchen: started tagging other maintainers when unsure / no expert
Teufelchen: would propose to âextendâ special security group, send security reports to all maintainers
mikolai: but if everyone is responsible, noone feels anymore. prefer your old process of pinging people
Teufelchen: counter-argument: pinging didnât work in the past @mikolai
mikolai: rather ping me outside / out-of-band
Ann: Maybe we should just stop doing it and move to suggested fix / PR, LLM makes finding these trivial and PR backlog is getting infinite
Teufelchen: current security group: Kasper, chrysn, maribu, Ann, Teufelchen, miri
Teufelchen: reducing security theatre would make things simpler (not assigning CVE, downgrading CVE levels)
mikolai, Ann: +1
Teufelchen: also more public disclosure? no âsneaking inâ fix commits, no backlog of disclosure
maribu: default to CVE calculator?
Teufelchen: will do as discussed, letâs revisit in some weeks / on Summit for future strategy
Build System and CI Improvements
crasbe: speeding up make info-boards-* targets, which can greatly profit CI time in !22355 - those targets are extremely slow (24s can be reduced to 5s)
mikolai: what do you need?
crasbe: one open remark, then ACK
Teufelchen: a lot of overhead still spawning shells?
â
maribu: is trying to improve ccache efficiency by reducing configuration exposure to the compiler (e.g. board name, app name, etc) in stale !21954. Plans to reboot this together with !22467
maribu: cache key depends on cflags, which change for every single board/application
maribu: two simple improvements: board/application in header instead of as CFLAGS, only cfiles importing that header will need to be rebuilt
maribu: second: USEMODULE list appears to be somewhat random in the module order, putting those in header may break since IS_USED does just return false if undefined (not imported in c-file). proposal: always define module to true or false, error out when not defined (so include header)
maribu: ccache at home will not work anyways because bin dir is different for absolute paths, but it is constant in Murdock, so should work there
crasbe: IS_USED migration sounds like a good task for remaining LLM tokens
maribu: there is already a PR, will rebase, hopefully this weekend, will trim it down to minimal invasive changes
karl: just provide IS_USED within module header, will break at compile time
â
Teufelchen: should we aim for including more defines in those new headers
karl: no, keep them separate, otherwise we end up with a single riotbuild.h that we need everywhere?
AOB
maribu: Someone⢠should become an Admin from the HAW/TUD group, bus factor too low
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).
crasbe: A lot of ESP32 related PRs were happening in the last couple of months and Gunar is the expert in that regard. I havenât read or heard from him in a while. Should we try to reach out?
Martine: heâs a professor and might be busy with exams
maribu: has been like that periodically before
crasbe: no activity at all on Github, no responses to pings
Ann: was same before, e.g. in 2024
Martine: maybe try on Matrix? but maybe wait until September?
karl: do we need him or are we just concerned?
crasbe: no pressing issues right now
We need more (Github) admins
Ann: but Martine may be back soon?
Ann: who else is active and has admin rights?
Martine: community decision, bigger bus factor always better
Ann: proposing crasbe
crasbe: gut feeling: rather not, would prefer not having too much (public) presence and liability
Martine: proposing Mikolai
Martine: iirc, every stakeholder should have at least one admin according to governance.md
maribu: any summary for this? do we want to allow AI-codereview for others, not just for ourselves?
Ann: maybe just on vibe-coded contributions?
maribu: 50c-1⏠per review. would be cheaper with AGENTS.md
Ann: read that agents start to do the opposite of what they are asked to do in AGENTS.md
Review LLM
carl: general question: how to handle AI slop descriptions for AI contributions, example of recent unicoap PR
maribu: Agents.md with âplease reduce the description to 150 wordsâ
Ann: maybe not too bad to have Agents.md in general but makes project feel like AI slop even when agents.md anti-llm constraints
Teufelchen: disagrees (with having one)
Karl: just close AI:vibed?
Teufelchen: AI policy already disallows LLM-generated PR descriptions
Ann: so just close when âextractive PRsâ according to AI policy, just not worth spending time on them
Pulling the Plug of the Codeberg migration
maribu: Codeberg recently updated their terms of use to ban projects that mostly consist of LLM generated code
maribu: The reasoning is given in an blog article and is mostly about heavy LLM users externalizing the cost to everyone else - a problem we see in RIOT as well
maribu: The blog article has some informal guidelines that are vague and difficult to apply. It also hints that further restrictions are still in dicussion.
maribu: The problem I have with that is that the codeberg is using the terms of use to get engaged into the technical decision making process of projects it hosts. That is IMO a transgression that is completely unacceptable. A git forge needs to stay technically neutral and leave the technical decision making to the projects.
maribu: IMO by injecting themselves into the technical decision making, Codeberg is no longer an acceptable forge for an independent project that strives to stay at the steering wheel of technical decision making
carl: agree. also added ban on cryptocurrency
Martine: feedback from codeberg community?
Mikolai: They decided it based on a democratic vote of the active members of the Codeberg e.V.
maribu: somewhat controversial internally, vote was fairly split, but the vote on what is acceptable Terms of Use retroactively is a bit dangerous
Mikolai: Disagrees with the fact that it should have been something from the start and not retroactively, LLM became a thing after foundation, they also argued that you can easily transfer your repository somewhere else, thus the question is whether or not we want to migrate and whether we are fine with the current ToS of codeberg, we all agree that github is not where we want to stay
Mikolai: the question is whether Codeberg is the right place to go for now, not in the future
Mikolai/Martine: We canât make decisions based on potential future changes, we have to decide on what the current situation is
Karl: technical point that harms codeberg: LLM-scraping, LLM-agent resource use (extra dowloads, extra CI time)
Martine: but thats the scanning side, not the fact that projects are vibe-coded
Mikolai: In blog post they also talked about projects that used giant CI time but no one actually uses the project, causing issues for everyone
maribu: but CI quotas are easy to enforce
Martine: but maybe difficult to distinguish between LLM and humans
maribu: but same problem with their new policy
Martine, summarizing: consensus seems to be that we view this retroactive technical change of their ToS as a dangerous precedent, so we should reconsider our plans to migrate there
Future of CoAP stacks in RIOT
Preparatory notes
PLEASE BE NICE TO EACH OTHER!
now have: gcoap, nanocoap(_sock), unicoap, libcoap
can we reduce the home-grown ones to a manageable number, preferably one?
supported in async requests, copy needed in sync requests
(no?) async requests
Discussion
maribu: agree with dropping gcoap: little maintenance, similar codebase. do not agree with nanocoap: trade-off is different: smaller stacksize
carl: overhead in unicoap is event-loop,âŚ
carl: use-case for smaller stack?
Karl: bootloader, little applications
carl: but unicoap is much smaller than grnc in the stack below, especially for ip-based protocols
Martine: libraries should be smaller than application, especially relevant for bootloader
carl: agree with the argument, but not with the conclusion. reasons: 1) from user-perspective confusing to have to stacks, 2) (not mentioned since interrupted)
Martine: we also have two network stacks with gnrc and lwip
Martine: for non-ip-based protocols unicoap is smaller, as recently seen with slipmux
maribu: we have coap-over-can downstream, nanocoap is very small
carl: asking for numbers (KiB). overhead of unicoap is separate thread (async) + layering. could be further reduced with more configurations / optional modules etc
Karl: we can strive for one stack in the longer term, but not remove nanocoap right away. If it gets similarily small and we have numbers, we can discuss it then
Teufelchen: why do we have this discussion right now? unicoap is not ready yet to replace nanocoap. gcoap has no stakeholders present. but we can also just have several coap stacks next to each other
Martine: regarding downstream coap-over-can, unicoap might make it easier to integrate OSCORE for future-proofing
carl: finishing unicoap is further down the road, we talk about migration in 2 years from now, we could then have compatibility layer for nanocoap parser
Ann: agrees. cool about unicoap for beginners: a lot of documentation
Mikolai: reason for discussion in face-to-face meeting was the recent discussion on Matrix, which is always harder to have IMO. I disagree that we should have a large number of different CoAP implementations, maintainer time is limited.
carl: thereâs a lot happening in the CoAP world, a lot of RFCs, we are far from feature-complete in all of our coap stacks. so agree that we should reasonably focus on not too many parallel stacks.
maribu: argument is unverschämt. you added a new CoAP stack while we already had 2 available ones.
carl: there was a tracking issue. you made your points there, but nanocoap was not a good ground to build on. people were complaining about out-of-buffer reads in nanocoap parser. messaging api of nanocoap_sock was not flexible enough. we didnât start from scratch just because it was fun. adding all those features to nanocoap would have resulted in a lot of changes. I actually started from nanocoap source code and arrived eventually at unicoap.
Ann: understand maribu, but unicoap development was very public. discussion would maybe have had more sense two years ago, but here we are and I see that unicoap makes sense to have
Karl: we have migrated subsystems before, so we could adapt eventually. had these migrations before, looking at you ztimer. compatibility layers might help for that.
Martine: to be fair: every migration takes a lot of time
Karl: but can be done gradually once unicoap is merged. ztimer also took 3 years
maribu: disagrees that unicoap was developed openly. tracking issue, then huge PR that was not reviewable. small steps PRs starting from nanocoap would have been possible to get whole community on-board
carl: 1) was a thesis, not enough time to make all small-step improvements. 2) IMO source-breaking changes should be as minimal as possible to be user-friendly
Martine: changes to existing codebase always bear the question of sunken cost, when a lot of source-breaking changes need to happen that might be already the case
Karl: initial port of ztimer: 57 files changed. developing a new API in the open is already more hassle, so I understand that it makes sense to not develop fully in the public
Ann: unicoap was officially a Bachelor thesis, we cannot ask for more development in the public IMO
carl: comment on âunreviewable PR because of sizeâ. maybe not reviewable in a given time. but adding a new subsystem will always be non-trivial.
Teufelchen: I had the feeling that the development was quite public, but I am biased since I am at HAW Hamburg. If maribu does not agree with that feeling, we should try to understand what we could do better for future projects. not something for this meeting, but carl and maribu could sit together at some point and try to find points to improve the process for the future.
Ann: should we have the discussion now?
maribu: first step would have been to have a small first PR with serializing
carl: we had that
Teufelchen: we need to first hear out maribu, lets not start discussion on whatâs past
maribu: the PR was too big for me to review (already included all options accessors), asked it to be reduced, that did not happen. it is okay, but if I do not get involved I will also not be fine with someone taking nanocoap away from me
Ann: maybe I misheared, didnât sound like it to me (people taking nanocoap away)
maribu: we can have that discussion when unicoap can cover our use-cases
Mikolai: When time comes, please provide these use cases. you may start from the list above
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).
Tom: Release have been halter for some time. Two major problems left
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
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
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â: 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
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 )
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â (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.
@miri64
)
)
)