Notes: Virtual Maintainer Assembly 2026.05

Community
,
1

2026.05 VMA

Date: 2026-06-02
Time: 15:00 CET
Moderator: Ann
Notes: Mikolai
Venue: Jitsi Meet
This VMA planning forum entry: https://forum.riot-os.org/t/2026-04-vma-planning/4878
Previous VMA notes forum entry: Notes: Virtual Maintainer Assembly 2026.02

Attendees

  • Koen
  • Ann
  • crasbe
  • Martine
  • Tom
  • maribu
  • Teufelchen
  • Karl
  • Lasse
  • Mikolai
  • benpicco (+12)

Agenda

  • Agenda Bashing - (Ann) 3’
  • 2026.04 Release Debrief - (Ann) 4’
  • 2026.04.01 Release Debrief - (Ann) 1’
  • Outlook on Upcoming 2026.07 Release - (MCR) 3’
  • Upcoming Roles - (Ann) 5’
    • 2026.07 Release Manager MCR
    • 2026.10 Release Manager
    • 2026.07 VMA Moderator
  • How do we deal with AI in RIOT - (Ann) ?’
  • How do we deal with doxygen errors - (Karl) ?’
  • LTO - (Is this you Maribu?) ?’
  • Codeberg: RIOT or RIOT-OS as Org name? - (emailed to Ann) 3’
  • RIOT Security List & Repo Ownership (Teufelchen) ?’
  • Python: Inline Metadata based on PEP 723 (Previous PR discussion) - 3’
  • Ariel OS community day (Koen) - 5’
  • AOB

Notes

2026.04 Release Debrief

  • Ann: Release-Specs annoying, some part didn’t work with IoT-lab, was unable to register at IoT-Lab
  • Mikolai: Notes?
  • Ann: yes, in release issue
  • Tom: did you nag other people to help with testing? it’s not manager’s job to do everything alone
  • Ann: yes, had some help

2026.04.01 Release Debrief

  • Ann: released tarball was broken since some releases back, fixed that for this release

Outlook on Upcoming 2026.07 Release

  • Ann: MCR absent
  • Tom: will help doing practical tests, have yet to start coordinating with MCR, seems responsive

Upcoming Roles

  • 2026.07 Release Manager
    • MCR (+Tom) already, hurray
  • 2026.10 Release Manager
  • 2026.08 VMA Moderator
    • AnnsAnn volunteered, Martine as backup

How do we deal with AI in RIOT

=> Action Item: Steal^w copy LLVM policy, file a PR with that, discuss last details in PR

  • Ann will open PR

How do we deal with doxygen errors - (Karl)

  • Karl: “not-documented” errors handled by exclusion scripts, but we don’t tell doxygen that we accept not-documented stuff
  • Martine: originally because of doxygen version jump, all of the sudden required much more documentation - if that’s not the case anymore, we should fix it
  • maribu: so without this workaround we would be stuck with 20-year-old doxygen
  • Teufelchen: got a plant
  • Mikolai: not relaxing doxygen in general, not document unnecessary stuff → have clear guidance on what can/should be excluded with the script
  • karl: agree, script sometimes hides real errors
  • maribu: one problem is static inline in headers, with need copy documentation every implementation of the same API (e.g. once in every board)
  • Martine: wouldn’t we like to switch away from doxygen if some alternative is available? so don’t put too much effort in it
  • crasbe: guidance in coding convention could be extended

LTO - (Is this you Maribu?)

  • maribu: not my topic, but happy to speak about it
  • maribu: we could stop using static inline if we behaved like we had LTO, static inline also harms C++/Rust integration
  • karl: not supported at all by some strange architectures?
  • maribu: I think it is mostly bugs on our side that prevent it from working
  • maribu: start avoiding static inlines, that increases pressure to fix LTO bugs
  • Mikolai: list of issues with LTO?
  • Teufelchen: need to adapt old code for better integration?
  • benpicco: what are benefits?
  • karl: so above: better documentation
  • Mikolai: also better Rust integration
  • Ann: who volunteers to adapt coding convention for static inline?
  • karl: better other way around: start using LTO, then maybe remove static inlines
  • maribu: but first way would put pressure on fixing LTO bugs
  • Teufelchen: action item - enable LTO on master, maybe include in next release
  • maribu: instead of LTO=1 Makefile flag, we could declare LTO as feature, disable for specific cases
  • Benpiccos test PR: buildsystem: enable LTO by default by benpicco · Pull Request #22338 · RIOT-OS/RIOT · GitHub
  • revisit at next VMA?

Codeberg: RIOT or RIOT-OS as Org name? - (emailed to Ann)

  • Ann: got approached by people who were wondering about it
  • Martine: Riot Games? :zany_face:
  • Mikolai: reason?
  • Ann: consistency with RIOT-OS name on Github
  • Mikolai: but doesn’t fit with general stance of RIOT being umbrella and RIOT-OS being one part of it
  • postponed to next VMA

RIOT Security List & Repo Ownership (Teufelchen)

  • Teufelchen: Ann couldn’t see security, we noticed that repo ownership is all over the place. We probably need a cleanup.
  • Teufelchen: main important is security, currently only 4 people (chrysn, kaspar, koen, Teufelchen), so effectively only Teufelchen
  • Ann: why having separate security level?
  • Martine: IMO all maintainers should see them
  • rough consensus in the room
  • Martine: will change it
  • Koen (on chat): Handling GitHub Security Advisories
  • Martine: also admins can see it
  • benpicco: why do we have admins that haven’t been active in RIOT for years
  • Ann: even owners
  • Martine: owners are Matthias, Thomas, Oleg, Emmanuel and Kaspar
  • Martine: we have maintainer ping, we can do an admin ping
  • Ann: has it ever been done?
  • Teufelchen: propose new rule: automatically remove after 2 years of inactivity on Github. much easier than maintainer ping
  • Martine: leave forum list of maintainers, but remove Github rights after 2 years
  • Martine: probably need to adapt governance doc accordingly, and someone should go through maintainer list
  • Ann: could just introduce new policy over time, benpicco can do maintainer ping again
  • karl: can we open “maintainer-ping PR”, everyone who does not ACK is removed

Looks like we have consensus to remove poeple from github-access-roles (e.g. Maintainers group) once they are inactive on github for more than two years

Maribu idea:

#### Removing a Maintainer

Maintainers may resign at any time if they feel that they will not be able to continue fulfilling
their project duties.

Maintainers may also be removed after being inactive, upon failure to fulfill their Maintainer
responsibilities or because of violating the Code of Conduct. This also includes actively,
persistently, and intentionally trying to harm or successfully harming the code base of RIOT.
Especially, but not limited to, endangering the security or safety of RIOT.

#### Retiring a Maintainer

A maintainer that has not shown a single interaction in a pull request or issue that took more than
5 minutes of effort over a period of 2 years will be retired and all permissions to the repository
will be revoked. The reason is that any account can be compromised. For maintainers that make
active use of the permissions, this risk is justified.

A retired maintainer will keep their permissions in the forum and their access to the internal
maintainer matrix room. In addition, a retired maintainer may return to active maintainer duty
at any point in time by reaching out to an admin to restore their permissions. A retired
maintainer that returned to active duty can be retired again for inactivy in the past 2 years,
but sooner than three months after restoring their permission.

Python: Inline Metadata based on PEP 723 (Previous PR discussion)

  • Ann: dependencies can nowadays be inlined in Python files, standardized way understood by many environments

  • Mikolai: iirc, ubuntu 22.04 does not support it, thats what we use in riotdocker

  • Karl: but its only python comment, so should be ignored

  • Mikolai: true

  • Ann: so no opposition in room to move to this

  • crasbe: regarding riotdocker, could be updated, but things will probably break

Ariel OS Community Day

See: The 1st Ariel OS Community Day (1AD)

The other IoT OS written in Rust picked September 1 for its first community day in a pleasant venue in Grenoble. Co-hosting is nice and keeps the community together while allowing visitors for only one of the OS’s to also see the other.

In the mean time Tock OS / OxidOS is interested in hosting a day on the Monday (31st of August) and making it a week of IoT OS’s. Depends on whether the venue is also available on Monday.

Koen: would be nice to make it a collaborative event week Teufelchen: indeed. hackathon could be framed like shared social/interaction event Koen: could lead to increase attendees count for all three events Ann: IMO valuable for all three events

AOB

2 Likes