Notes: Virtual Maintainer Assembly (VMA) 2025.05

Community
,
1

I noticed, these were never released, so here they are

2025.05 VMA

Attendees

  • Martine
  • Teufelchen
  • Kevin
  • chrysn
  • benpicco
  • mikolai
  • crasbe
  • Koen
  • Micheal Richardson
  • Karl :clock2:

Agenda

  • Agenda Bashing - 5’ (Kevin)
  • 2025.04 Release Debrief - 5’ (Mikolai)
  • Outlook on Upcoming 2025.07 Release - 5’ (Teufelchen)
  • Upcoming Roles - 5’ (Kevin)
  • Deprecating old boards - 15’ (Kevin/Teufelchen)
  • Finding a new spot for the weekly - 5’ (Martine/Maribu)
  • Reducing the bus factor (and better documenting the process) of doing a booth for RIOT (maribu/chrysn)
    • FrOSCon ‘25 – 3’ (chrysn)

Notes

Agenda Bashing

Kevin moderating.

2025.04 Release Debrief

Mikolai published Spring Clean.

  • m: no complaints received about the native->native64 change. Also can go on with aliasing now (can be picked up by anybody for any board).
  • m: smooth release. (Martine: good, given how build system was changed)

Outlook on Upcoming 2025.07 Release

  • Teufelchen: No planning happened so far.
  • Teufelchen: Maybe getting rid of release specs that have been unused.
  • Martine: Beware of deprecation cycle!
  • Teufelchen: Guides will be in next release.

Upcoming Roles

2025.10 Release Manager

benpicco volunteering

2025.09 GA Moderator (summit)

Martine: Maybe one of the hosts? Mikolai will do it.

Deprecating old boards

  • benpicco: As long as someone cares, keep it. If nobody maintains and causes trouble, fine to remove.
  • mikolai: Question was about boards that don’t cause trouble.
  • Martine: Would anyone ever go “I want to try RIOT, I have this ages old board … sitting around”?
  • Kevin: What is testing? Build tests is what we do mostly in CI.
  • benpicco: Same about drivers, we have drivers for years-ago EoL’d hardware.
  • Karl: It gets testing when people try it.
  • Kevin: How do we want to be viewed in this case? Be more accurate about “it might work”? Example, GBA, or boards with sentimental value (MSBA2), where even CPU is hard to get. Some might have value as “if it’s still a good example on how to port”.
  • crasbe: Specify in docs? Support grade/level? nrf and nucleo are well tested, some even don’t have a docs page. (lots of nodding)
  • crasbe: We did kick out a board nr6…(?) that had only maintenance commits in years. Unobtainable even on ebay.
  • Martine: talked about years for this – just someone has to do it.
  • benpicco: CPU grades would already work; boards inherit a lot of CPUs.
  • chrysn: We might collectively make it easier for whoever does this first step by saying that it’s fine for the initial classification to be overly defensive – whoever uses something can then easily move up the thing a tier.
  • Karl: zig has nice classification. Flags for properties such as “is in HIL”, “is in builds”.
  • Kevin: Good. Original reason was “should we put in effort to deprecate things”, community is on “doesn’t hurt to have old”, so (?) … does anybody want to pick up levels?
  • Martine: Might be good as a start: On every board docs put some level: “builds”, “occasionally used”, “daily use”, “tested in CI”. Rough point of reference.
  • crasbe: Can look into whether we can do doxygen magic. Docs go out of sync quickly; wiki list maintainer<->devboard is outdated.
  • Martine: few levels won’t outdate that fast.
  • crasbe: Point is, it has to be in the board docs (separate page only if it’s generated).
  • Karl: Put support table into features?
  • Kevin: Two axes, “usage” and “how much of it is in”.
  • Martine: Keep it simple.
  • benpicco: CPU/MCU is probably better level.
  • Karl: Not true b/c wiring-up is sometimes strange.
  • Kevin: For board creator, CPU table is useful. Have 3 directions now. One obvious one (are people using it?).
  • crasbe: Could import CPU status into the board, show both CPU and board support.
  • chrysn: Can we do that? Doxygen is terrible for that kind of inclusions.
  • Martine: If we go through the XML…
  • Mikolai: Reminder that we also have the board overview table: Boards.
  • Karl: With new doc.md import, we can do support table-templates (file: like support.doc.md) for (board/mcu) easy to copy around allways the same filename.
  • crasbe: Would have to look into how markdown groups can be reused. Board overview is what I was not aiming for b/c that has risk of going out of date.

Kevin: Losing scope here. Action points:

  • crasbe looks at possible Doxygen magic
  • everybody check out board supported page (maybe RM can send ping on “are you using this board”?)
  • Only deprecate boards that are causing problems

Finding a new spot for the weekly

Booth organization

  • chrysn: (not sure what maribu planned, but) as we’re running booths we’re trying to enhance documentation on what we do and how we register.
  • chrysn: FrOSCon to be registered today, both for RIOT OS and Ariel OS, companion booths with embedded devroom.

AOB

  • Martine: BTW, summit coming up, CfP open!