Weekly coordination meeting

Community
,
55

RIOT weekly coordination 31.07.2026, at 15:00 CET

Link: Jitsi Meet

Attendees

  • Ann
  • Lasse
  • crasbe
  • Teufelchen
  • Mikolai
  • karl
  • carl
  • maribu
  • Martine

Note-takers

  • Moderation: Ann
  • Notes: Mikolai (GOATED :handshake:)

Agenda

  • Where is Gunar Schorcht?
  • We need more admins :sad_but_relieved_face:
  • What’s the stance on LLM reviews?
  • Pulling the Plug of the Codeberg migration
  • Future of CoAP stacks in RIOT

Notes

Where is Gunar Schorcht?

  • 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 :sad_but_relieved_face:

  • 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
  • Martine: currently 7 admins in Sign in to GitHub · GitHub hauke, martine, Cenk, Leandro, Peter, Kevin, benpicco, also see RIOT - The friendly Operating System for the Internet of Things
  • mikolai: maybe everyone thinks about it until summit, how many admins would be good, and who would be ready for it. then we discuss it there
  • Ann: summarizing: noone objects

LLM Reviews

  • Ann: Why did they suddenly pop up everywhere, did I miss something?
  • maribu: IMO better to use it publically instead of on private machine
  • Ann: just a bit surprised that we suddenly started having those
  • maribu: maybe because a convenient button was recently added
  • crasbe: but you may need a Copilot subscription
  • crasbe: do we want “AI:reviewed” then?
  • Ann: actually a lot of labels already

Review LLM topic happend here

  • 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

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

AOB

General Assembly @ RIOT Summit 2026