Notes: Virtual Maintainer Assembly 2026.02

Date: 2026-02-10
Time: 14:00 CET
Moderator: Kevin
Venue: Jitsi Meet
This VMA planning forum entry: https://forum.riot-os.org/t/2026-02-vma-planning/4759/14
Previous VMA notes forum entry: Notes: Virtual Maintainer Assembly (VMA) 2025.11

Attendees

  • Kevin
  • maribu
  • Mikolai
  • Martine
  • benpicco
  • Karl
  • Ann
  • Leandro

Agenda

  • Agenda Bashing - 5’ (Kevin)
  • 2026.01 Release Debrief - 5’ (Leandro)
  • Outlook on Upcoming 2026.04 Release - 5’ (Ann)
  • Upcoming Roles - 5’ (Kevin)
  • Github Enshittification: What are our next steps with Codeberg?

Notes

2026.01 Release Debrief

  • Leandro: relatively smooth, 1 week of delay due to ESP bugs, Gunnar was really fast providing fixes.
  • Leandro: how to handle merge queue to prioritize release?
  • Martine: just did shunting of outstanding merges instead of using Github “skip queue”
  • Leandro: want to improve some documentation + check some IoT-Lab-related (tooling?) issues

Outlook on Upcoming 2026.04 Release

  • Ann: would be great to have 2nd unicoap PR in by then. what’s current status?
  • Mikolai: just another review roundtrip missing from my side, other reviews always still welcome?
  • Martine: bugfixes upcoming with asan enabled on core and networking
  • Ann: Teufelchen will hopefully help out

Upcoming Roles

  • https://crystalball.riot-os.org/
  • 2026.07 Release Manager
    • crystalball suggested Leandro (again :pensive:)
    • Kevin will ask @mcr as he volunteered last time
    • if not, Mikolai (or big maybe Martine) would step up
  • 2026.05 VMA Moderator
    • Ann volunteers :tada:

Github Enshittification: What are our next steps with Codeberg?

  • Kevin: Github now charging for self-hosted runners. RIOT doesn’t use them, but one more on the pile of enshittification
  • Ann: I’ve been advocating for codeberg together with chrysn
  • Ann: How to proceed with mirror? Do we want to accept PRs on codeberg, too? Or do we just stick with Github?
  • Kevin: Managing PRs on both sides could be challenging, but I would support shift overall.
  • Ann: merge queue + github actions makes us dependant on Github, rewriting actions should be easy. merge queue is Github-specific
  • Kevin: release tools are very Github-specific
  • Kevin: merge queue itself is not great anyways, we could have something better
  • Martine: merge queue at least avoids semantic merge conflicts
  • Ann: why did bors stop working?
  • benpicco: project is archived
  • maribu: plan would be to accept PRs on both platforms?
  • Martine: there should be transition period
  • Karl: would leave a lot of Github users behind
  • Ann: but specifically for RIOT, there are not that many bypassing PR authors anyways, right?
  • maribu: maybe PR quality would improve by moving away :slight_smile:
  • Martine: in any case, keep mirror on Github
  • Ann: there are pretty good mirroring tools for Codeberg - Github
  • maribu: I would have feared this to be non-trivial
  • Ann: with this system
  • benpicco: let’s step back: do we have people who are commited to work on required tooling?
  • Kevin: first question: do we agree on idea of moving away?
  • maribu: mirror tooling over to the repo mirror then we can decide
  • benpicco: but who is actually going to do it?
  • Kevin: Good point. Don’t want to fracture community and then be left in an unfinished state
  • Ann: Currently done with by bachelor thesis, so prime position to do it
  • Kevin: maybe not commit yet and gauge the cost while doing it, as long it is not interrupting the current workflows
  • Martine: Maybe a good idea to have the aforementioned transition period and do the mirroring during that
  • technical discussions about a bors clone to have merge queues on codeberg
  • Kevin: summarizing Most agree, Ben wants accountability, Tom might provide that, let’s try to do a soft transition

Just talked to @mcr and it looks like we will have a 2026.07 release manager!

1 Like