Weekly coordination meeting

Community
,
61

Hello everybody!

2026-08-28T13:00:00Z we will have our next weekly coordination meeting.

The meeting will take place online on Jitsi.

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).

Best
Martine

62

Attendees

  • Koen
  • Teufelchen
  • Mikolai
  • Martine
  • Karl

no specific agenda, only

AOB

63

Hello everyone,

since most of us will still be together in person and hack happily at the Hackthon, we will skip the weekly this week.

Best Martine

64

Hello everybody!

2026-09-11T13:00:00Z we will have our next weekly coordination meeting.

The meeting will take place online on Jitsi.

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).

Best
Martine

65

RIOT weekly coordination 11.09.2026, at 15:00 CET

Attendees

  • miri64
  • kfessel
  • teufelchen
  • annsann
  • BasilFX

Note-takers

  • Moderation: Miri64
  • Notes: everyone, pure anarchy without mikolai :fire:

Agenda

  • Enforcing functioning formatter on PRs, reducing manual formatting nitpicks
  • Modernizing review standards for RIOT
    • Do we want to move fast and break things?
    • Do we want to be selective with PRs?
    • What are current pain points?
    • How do we want to handle device specific PRs, esp. if we don’t have the board
  • your item

Notes

Enforcing functioning formatter on PRs, reducing manual formatting nitpicks

  • annsann: wasted manual labor when providing hints on formatting in review
  • annsann: Have looked at clang-fmt because it is more well known by editors and IDEs (compared to uncrustify) and told LLM to improve config
  • martine: should hint about this in some automated comment / PR prep
  • Review Process: Get Formatter to align with coding conventions by AnnsAnns · Pull Request #22679 · RIOT-OS/RIOT · GitHub
  • miri thinks its a good idea
  • basilfx would favor it too
  • miri: maybe later we can remove uncrustify
  • Some more derailed discussions uncrustify vs clang-formatter and coding conventions.
  • Let’s go with this approach for now, re-evaluate if we can use clang-format as our main tool

Modernizing review standards for RIOT

  • Martine: Too big of a topic for such a small meeting
  • Move to 2026.11 VMA?
  • Maybe disseminate this questions to chat so people can start thinking about them and come prepared to the VMA :wink:
66

Hello everybody!

2026-09-25T13:00:00Z we will have our next weekly coordination meeting.

The meeting will take place online on Jitsi.

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).

Best

Ann :left_speech_bubble::frog:

67

RIOT weekly coordination 25.09.2026, at 15:00 CET

Attendees

  • Karl
  • Miri
  • Teufelchen
  • Maribu
  • Ann​:frog:
  • crasbe

Note-takers

  • Moderation: An​:frog:
  • Notes: A​:frog:
  • :frog:: :frog:

Agenda

(A lot from last week)

  • Should auto_init_foo have foo as a dependency?
  • Tree-wide clang format (Ann)
  • Github Maintainer 2FA requirement (Ann/Teufelchen)
  • Wakaama Deprecation
  • a lot of GNRC PRs from Basilfx and more to come
  • a lot of 802.15.4 PRs from Stepan & JosĂ©
  • Positive News: Activity & Murdock Speed

Notes

Desvirt (Resolved already, got removed)

  • Removal of desvirt #22724: Yes, No, Maybe? (crasbe)

    • Seems unmaintained since it was added in 2016

    • desvirt received last update 4 years ago by Oleg

    • Still needs python2, which is no longer available in our Docker

    • What even is desvirt?

    • Oleg provides some insights:

      • I do have an opinion on desvirt though (independent from its Python version): I think very few people in the current RIOT community know about desvirt, what it can do and how to use it. Code and documentation are in a bad spot and IIRC Ben introduced some framework that provides similar functionality. For the record: desvirt provides some scripts to define a network topology. One can define nodes and links. For the nodes you can choose a RIOT application and it will spawn the corresponding native instance. For the links you can define a PDR and whether the link is uni- or bidirectional. It uses ebtables and tc for traffic shaping. I used it during my PhD to emulate RIOT networks with up to 1000 nodes. (1000 is the max. number of TAP devices a Linux bridge can handle in the default Kernel configuration.) Long story short, I consider it useful but only if anyone finds the time to maintain the code base and document it. Since I haven’t been able to do this for the last 10+ years, I consider it unlikely and would vote pro removing it.

    • Ann: In another project we had a similar with a python 2 tool but since Python 2 has become this EOL (Over 6 years by now) at this point, I’d say the minimum baseline is that a tool can not be on Python 2 anymore, at least it should use some abstraction if possible to make it runnable using Python 3 (though idk whether these are still even maintained/exist at this point)

Should auto_init_foo have foo as a dependency?

  • Teufelchen encountered a user that was using auto_init_gnrc_netif but not gnrc who was confused why it wasn’t working as intended. => Major UX issue.

  • Teufelchen made a poll on Matrix/RIOT:

    • Without looking it up, what is your gut feeling: If I add auto_init_gnrc_netif to my USEMODULE will it pull in gnrc as a dependency?
      • Yes it does! If I want to auto init foo, foo should be a dependency of the auto init. (As of 25.09. 9 votes)
      • No! Auto init is just a setting for a module, if that module is not selected it should be a no-op! (4 votes)

  • Teufelchen: asked in general chat, most were for it

  • Miri: Question felt more like a vibe check

  • Miri: What about a warning “you want to include autoinit, u sure?”

  • Maribu: Whats the advantage instead of simply including?

  • Miri: Talk about :wheel:, different choices to pick from

  • Maribu: Then it should just use the default (?)

  • Teufelchen: maybe use default, add warning if unclear (?)

  • Miri: netifs often unclear what to pick from exactly

  • Maribu: Maybe in that case makes sense to do warnings, otherwise not

    • If it compiles it should work, if not it shouldn’t compile

Conclusion: If autoinit choice is clear, automatically just import, otherwise error

Teufelchen will look into it

Tree-wide clang format

  • Ann: Please let me run a tree-wide clang format so people stop looking at our own code only to see a bunch of formatting that isnt even allowed (would also make it more feasible to make clang format mandatory for PRs)

  • Ann: I will take the blame for the git history if we do :frog::kitchen_knife:

  • Miri: If somebody can’t deal with git blame its their fault

  • Maribu: What about gitattributes

  • Ann: Unsure whether it gets applied for all clones

  • Maribu: Definitely just include it either way

  • Teufelchen: Go iteratively from old code to newer, hopefully only break old PRs through that

  • Karl: alignment of values was good, clang will take it away

  • Maribu: Only aligns when more than 2 values are close

  • Miri: Are there clang format ignore commands

  • Teufelchen/Maribu: Haven’t seen instances where clang-format broke alignments yet

  • Ann: “Some of your code might get ugly but it’s a sacrifice I’m willing to make” - Lord Farquaad

  • Maribu: If we do exceptions we will lose one of their main advantages of clang format

  • Karl: Ignore statements ugly

  • Maribu/Miri: But they don’t break tool flow, exceptions without do

  • Ann: Looks like this:

    /* clang-format off */
const suit_manifest_handler_t suit_command_sequence_handlers[] = {
    [SUIT_COND_VENDOR_ID]        = _cond_vendor_handler,
    [SUIT_COND_CLASS_ID]         = _cond_class_handler,
    [SUIT_DIR_RUN_SEQUENCE]      = _dtv_run_seq_cond,
};
/* clang-format on */

  • Teufelchen: This is the formatted (potentially, might have errors / wrong clang version)

    const suit_manifest_handler_t suit_command_sequence_handlers[] = {
    [SUIT_COND_VENDOR_ID] = _cond_vendor_handler,
    [SUIT_COND_CLASS_ID] = _cond_class_handler,
    [SUIT_DIR_RUN_SEQUENCE] = _dtv_run_seq_cond,
};

  • Maribu: could be aligned to the longest element per config

  • Martine: No problem with the config Maribu proposes

  • Teufelchen: Proposes idea of a make format that automatically does it, future discussion around git hooks

General agreement in the room about make format

General agreement to start iteratively formatting non-active folders

  • Miri: Be loud about first PR, Maintainers should voice their opinions then or suffer the consequences :slight_smile:

  • Teufelchen: Which version are we currently using

  • Ann: 17, soon 18, directly after that 20 :slight_smile:

  • Karl: Is it forwards compatible

  • Maribu: Yes, has option for that / to ignore configs that don’t exist yet

Github 2fa

  • Ann:
  • Miri:
    • Not enabled, 17+ ppl don’t have 2fa, outside contributors that don’t have 2fa will automatically be kicked due to this
    • Won’t enable it now but we should give a warning and then enable it

Agreement to warn till next week, next week we enable it

Github scares Miri with fake enabling it due to vibecoding while it wasn’t enabled

Miri will post the following message in #RIOT and the forum.

@room Please activate 2FA for your Github account until Friday, Oct 2, 2026, 15:00 CET. We will make it mandatory for the RIOT-OS organization until then. Here is what GitHub says:

Organization members who do not have two-factor authentication enabled will be unable to access resources owned by the RIOT organization, but will remain a member of RIOT until they update their settings. Outside collaborators who do not have two-factor authentication enabled will be removed from the organization and notified. View organization membership to see which users will be impacted.

Waakama

General consensus (of 4 people in forum of which 3 are here and one is leandro) was to deprecate in next release (after the current one)

Discussion about whether patch needs to be applied or not or we just deprecate, Conclusion: Just deprecate

  • Maribu: Side-note, Zephyr seem to have their own lwm2m

a lot of GNRC PRs from Basilfx and more to come

  • crasbe: I can’t review them for content, just do the usual crasbe-format and some plausibility checks as well as general hints/improvements
  • crasbe: volunteers for reviewing? :innocent:
  • crasbe: I asked Bas to flag all his open PRs with waiting for author or waiting for maintainer to distinguish who has to do what

Miri will do it :slight_smile:

a lot of 802.15.4 PRs from Stepan & José

  • crasbe: similar issue to above, but that seems to be going on alright?
  • crasbe: would be nice to get some more eyes on there too

Miri will also do it :wink:

Positive News: Activity & Murdock Speed

  • crasbe: The period between July-September 2026 has been the most active period since January-March 2024 :partying_face:
  • crasbe: 604 commits so far and September is not over yet
  • crasbe: Bas was also busy optimizing our Make system (e.g. remove unnecessary shell calls) and reduced the CPU time by about 1d (from >9d to right around 8d (sometimes more sometimes less))
  • crasbe: Overall build time reduced by 30-45min (difficult to pinpoint)
  • Ann: Static Tests also getting speed increase, tools-build-test is hopefully also getting reworked soon

Group is happy hoooray :tada:

1 Like
68

Hello everybody!

2026-10-02T13:00:00Z we will have our next weekly coordination meeting.

The meeting will take place online on Jitsi.

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).

Ann :fire::left_speech_bubble::frog:

69

RIOT weekly coordination 02.10.2026, at 15:00 CET

Link: Jitsi Meet

Attendees

  • Martine
  • maribu
  • BasilFX
  • Ann
  • Karl
  • Carl

Note-takers

  • Moderation: Ann / Miri
  • Notes: Ann (but deeply misses Mikolai :cry:)

Agenda

Notes

Clownfish: New Logging in RIOT

  • sys/log, core/debug: Grand Enrichment by carl-tud · Pull Request #22799 · RIOT-OS/RIOT · GitHub
  • Ann: Looked cool like Rust Logging, Carl not here, look at PR for some feedback to it
  • Karl: I thought we had a rule that core can’t depend on sys
  • Miri: Not sure, but makes sense I guess, seems a bit broken
  • Karl: Maybe don’t make it default
  • Ann: Afaik that’s how it works right now, you have declare that you wan’t to use it
  • Karl: Afaik the other way around that you want not clownfish?
  • Miri: Is clownfish pulling sys into core?
  • Maribu: I think already happens either way due to Log
  • Karl: I think so, currently carl has a config for that
  • Miri: I think there is an old PR that also tried to put LOG into Debug, don’t remember fully
  • Karl: Also reserves double score, extremely reserved by C
  • Miri: Identifiers can be renamed
  • Karl does not like log to be reunified

Consensus: Look at PR and give feedback no point discussing right here since Carl is not here

Continued after Carl joined at the end

  • Carl: What I read is correct, if you don’t use selective variable nothing changes, opt-in for DEBUG redirect to LOG
  • Carl: Tried to compile something for esp boards, logging really weird on esp, there is completely different logging module for esp, adapts on what other log modules are used, extremely weird, you cant use your own logging func with esp boards due to that, looking into how to integrate our logging into the esp-idf thingy, uses closed source library, would like feedback
  • Fixing, will dump into PR, can create another PR for ESP logging later - just want to keep eagle eye picture in the meantime so ESP won’t be afterthought
  • Maribu: The IDF is making stuff weird, have no chance of seeing some stuff due to decisions they made, which is why we have to kinda use it because RIOT is forced to work along the existing idf platform, e.g. implemented FreeRTOS Threads
  • Maribu: If somebody was to clean up, e.g. FreeRTOS threads as a general abstraction in RIOT, would make more PKGs portable to RIOT
  • Miri: I remember some PR for that?
  • Carl: Macro magic, debug invocation can change timings can also cause unsafe stuff to happen, my idea is in refactor you can specify the log level & unit, can optimize the rest out, added small feature flag for platforms such as the esp, dynamic control (for ESP compatibility) and static control of log levels
  • Ann: Sounds like a good thing for RIOT
  • Miri: If we can get rid of the circular dependency
  • Maribu: [I forgor what he said :(]
  • Carl: What was the reason for this?
  • Miri: Causes iffy behaviour, try to avoid because of that
  • Carl: Would option be to put debug header into core / move to module that sys & core can depend on
  • Miri: Make log its own root, e.g. ./log ./core ./sys
  • Carl: Would presumably be a source breaking change, e.g. for MLPA
  • Discussion about why that would(n’t) break anything

Consensus: think about this more and how to structure

Murdock: How does this even work anymore

  • Ann: So crasbe tried to understand and update Murdock potentially, we discovered that workers were extremely outdated (e.g. avr-gcc jumped from 7 to 14), spiraled into rabbit hole of trying to fix a lot of issues that Murdock was supposed to catch

  • Ann: Ends with a rabbit hole at the end of the rabbit hole of Murdock suddenly breaking unrelated to the Murdock work we did before that

  • Miri: Tried a lot of stuff,

    • in the end: something:tm: in the gitea image itself seems to have been broken. I moved over to forgejo, see /srv/docker-compose/forgejo, with keeping both the gitea database and the data from /srv/docker-compose/gitea in place. I did not port the maze yet nor provide any functionality beyond the one needed for CI.
    • I suspect something is broken in /srv/docker-compose/gitea/data, which might be the culprit though if someone wants to pick up forensics.
    • Claude (via duck.ai) suggests git-upload-pack might be overwritten by Gitea and broken, as
      • docker exec -u git gitea sh -c 'SSH_ORIGINAL_COMMAND="git-upload-pack /murdock/riot.git" /app/gitea/gitea serv user-agent=git/2.43.0' returned some weird output

  • Miri: Makes clear that she is not the maintainer of CI and/or Tatooine, just stepping in for the admins

  • Ann: everything will be fine :fire::teacup_without_handle: Crasbe still looking into this a bit, we will try to understand Murdock a bit more, shouldn’t break anything hopefully at this point anymore

Consensus: Never touch Murdock again for the next 5-10 years so the next wave of Maintainers has to deal with it /s

RIOT Org Permissions: Why are maintainer permissions per-repo

  • Ann: Maintainer role only gives access to push in the main repo and some others, e.g. riot website, rust crate and so on appears to have different policies, kinda silly, if we trust people to be maintainers we should be able to trust them with everything, esp. since RIOT as the core repo is probably the most important
  • Miri: Yes, but don’t want to decide in this group, higher ppl probably need to be here
  • Maribu: Doesn’t need to be binary, could be some middleground

off topic discussion about website repo

Consensus: Move to VMA

RIOT Summit Orga: More transparent planning, videos look like from 1990, etc

  • Ann: Came from Chrysn and Oleg afaik, setup was intransparent
  • Miri: Was a bit chaotic, we tried to at least do a pretix documentation for next year at least
  • Ann: Chrysn idea was to have some public communication channel at least, discussed into forum
  • Miri: Now does a forum post about questioning current process
  • Maribu: Makes sense for ppl not on Matrix, Forum easier to understand
  • Maribu: Have a great joke about Matrix, not sure whether you can decrypt itg
  • Ann: Also Chrsyn complained about audio/video quality of videos
  • Miri: Was confused, Chrysn did a lot of high quality stuff but videos ended up being the Webex stream
  • Ann: What happened to high quality?
  • Miri: On SD card of Chrysn, did the mixing for the summit in vienna

Consensus: Wait for Chrysn post, better syncing about vids

Discontinuing security@riot-os.org

  • Miri: Thought about this a while, easiest solution would be to just send a mail onto this, wait for 2 weeks and then just deprecate it when demand isnt there
  • Ann: Could we then also just ask why they would be against it
  • Maribu: If you have a security email there is an expectation that we read and react to them and we don’t really do that
  • Miri: I read them, with more time right now I might react but it’s generally true
  • Ann: Can we just do auto-replies that they should contact on github?
  • Miri: Not sure mailman can do that but generally maybe
  • Maribu: Maybe checkmark “I invested more than 10m of human time on this”
  • Miri: Hard to have checkmark in mail :pensive_face: Maybe in Agents.md “Hey human has to review security stuff”
  • Karl: Maybe have declaration of AI in security report?
  • Ann: Afaik basically everything has been LLM at this point
  • Maribu: Problem is time invested by people, security reports are often way too complicated, could be single line PRs
  • Ann: Do we have a “Please open a PR instead” line in our security guidelines
  • Maribu: Would be in favour of this
  • Miri: Many security ppl still like responsible disclosure

Consensus: Add the line to security guidelines, ask whether autoreply is possible for now

AOB

  • Martine: Activated 2FA for GitHub RIOT-OS org right now
    • Maribu: SMS counts as unsafe 2fa for Github btw

This was followed by debugging the CI issue further for quite some while, if you want further details about that look here: https://youtu.be/YAgJ9XugGBo

70

Hello everybody!

2026-10-09T13:00:00Z we will have our next weekly coordination meeting. Hopefully shorter than last time :wink:

The meeting will take place online on Jitsi.

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).

Ann :fire:đŸ«Ș :crossed_swords: :frog::fire:

71

RIOT weekly coordination 09.10.2026, at 15:00 CET

Link: Jitsi Meet

Attendees

  • Crasbe
  • Maribu
  • karl
  • carl
  • miri64
  • annsann
  • teufelchen
  • mikolai

Note-takers

  • Moderation: Ann​:frog:
  • Notes: mikolai (the goat is back :crown:)

Agenda

  • Coding convention, style, and clang-deformat (carl)
  • Mur​:frog:
  • Murdock issues post mortem (martine)
  • ESP de-mummification (if time permits)
  • unstructured text is not a stable serialization format and must not be assumed to be

Notes

Coding convention, style, and clang-deformat

  • carl: RIOT feels like 90s, some conventions don’t make sense
  • carl: seems like we want to do tree-wide clang-format, sensible idea. But: in some cases it de-formats (ex longer if-clauses). How to turn off for parts?
  • carl: proposing to change some conventions before we start to clang-format treewide
  • carl: first: switch from /* 
 */ to ///, would save 20 lines per file, 1MB in RIOT repo
    • karl: /** looks nicer than /// to me
  • carl: second: /// MARK: in headers is shown nicely in minimap in vscode etc.
  • martine/karl: where is this convention from?
  • carl: not sure, but several editors
  • carl: third, “@ingroup before {” should be “@addtogroup”
  • carl: fourth: in/out param doxygen only make sense on pointers
  • carl: fifth: opening brace for function definition in newline breaks with rest of coding convention (if, switch etc have in same line)
  • carl: sixth: clang-format per default puts function arguments in blocks, instead of one per line (more readible)
  • Ann: indeed clang-format struggles with our convention, personal feeling after testing: just switch to llvm defaults with convention
  • maribu: kernel convention is supported by clang-format
  • maribu: reason for sixth is readibility, not personal taste (better)
  • martine: Parameter per line also better for git diffs: See immediately which parameter was removed/added.
  • karl: clang-format has no support for default 80, max 100 ColumnLimit
    • teufelchen: anyone against just setting 100
    • Ann: already arrived to this in PR
    • karl: suggested a workaround to support softlimit of 80, but hacky
    • mikolai: so adapt coding convention?
    • maribu: do we need coding convention if we just use clang-format?
    • karl/martine: yes, should not depend on tool
    • maribu: clang-format is not a beautifier but meant as canonicalization, uncrustify is beautifier
  • carl: concensus seems to be: update coding convention, then enforce/realize by clang-format
  • martine: we should discuss proposals individually in PR
  • carl: was asking for feedback here in the room
  • Teufelchen: agree with personal feeling, but too insignificant to bother and reformat whole tree
  • carl: I dont linke 90s style – karl: 90s are kinfof ok – miri: 90s style so colorful
  • martine: would refrain from changing too much of coding convention if it results in more changes in tree-wide reformat
  • carl: yes, idea was to piggyback on the tree-wide formatting that was planned anyhow
  • maribu: RIOT has very special coding convention, very different to others. would decrease friction with less special coding convention
  • carl: RIOT should stay cool/hip/new, since C is not hip anymore. improving coding convention could help
  • mikolai: proposal: carl drafts PR with changes to coding convention.md. people familiar with clang-format problems amend stuff that makes it hard to use clang-format to enforce it. Then gather consensus in following weeks.
  • karl: could split doxygen-related stuff and coding convention into two PRs

room agrees to Mikolai’s proposal

Mur​:frog:

  • Ann: fancy fancy riot.annsann.eu, started as improvement of murdock-html, now on a hard-fork :rocket:
  • Ann: not sure what future is.
  • martine: could merge back and update official frontend. maybe change theming :frog:
  • karl: just frontend, using same backend, can coexist?
  • ann: yes, since backend has no CORS configured
  • Ann: could post PR, fair warning, will be gigantic
  • martine: maybe wait until after release

Murdock issues post mortem

  • Martine: as a heads-up: murdock CI broke last week since gitea docker got RCE, interacting with git triggered malicious script
  • Martine: now switched to forgejo, banned malicious IPs
  • Martine: problem yesterday was intermittent murdock database connection problems. probably triggered by updated firewall rules for gitea IPs. replaced drop by reject, will test when murdock queue is empty
  • Ann: access to tatooine for crasbe?
  • crasbe: not sure if I want that. maybe after release. have fix in the pipeline that would have avoided murdock hangup. murdock containers cannot be built anymore because of broken dependencies. game plan: doc for guides by Claude
  • Teufelchen: how about moving to more standard tooling?
  • crasbe: Claude built a buildbot alternative. but not as efficient as Murdock. Murdock actually greatly optimized for our use-case. Problem is mostly missing documentation and outdated deployment.
  • Ann: woodpecker CI as alternative? murdock is a RIOT project and should be more visible and less separate repositories. can we move everything to RIOT orga? maybe 1-2 repos?
  • people seem to agree
  • martine: could improve murdock by switching away from python?
  • crasbe: rather try to pipeline more stuff. and poke maribu to improve ccache. or increase ccache size (improved 10% by increasing 8GB to 16GB)
  • teufelchen: not sure why CI is not as hard-working as possible. 
?

ESP de-mummification (if time permits)

  • carl: sth needs to be done in next years as our Espressif SDK version will not be supported anymore. nothing too pressing, but a problem for the future
  • martine: Gunnar is only intermittently available
  • crasbe: insider info from basilfx. there is a RIOT-OS repo called toolchains, which is still used for msp430. ESP SDK update could be done there as follow-up (?)
  • maribu: ESP is just shitty. also in Zephyr. HW is great, but software is shit. many binary blobs. Also in rust: esp-up instead of rust-up.
  • martine: re LLM decompilation in RIOT Off-Topic?
  • maribu: its even MIT licenced

unstructured text is not a stable serialization format and must not be assumed to be

  • maribu: Pickup up discussion in Matrix that shell command output changes should be considered as API change and handled with care
  • maribu: It is common practice to not consider unspecified and unstructured text output as a stable format
  • maribu: Common practice is to provide either standard serialization formats (e.g. JSON / XML / 
 output) or special flags like --porcelain flag for git
  • maribu: Treating changes in output of shell commands as API change because it is breaking consumers is not acceptable:
    • The consumers take a volatile format without specification as a stable format, which is an invalid assumption
    • Asking contributors/maintainers to treat this as an API change is externalizing the cost of the moot assumption
    • Instead, the external consumers need to be fixed to parse stable output. If no feature is provided by RIOT to get the information, this would need to be upstreamed by the people intending to consume the information.
  • maribu: solution for problem at hand: Maybe add something to RIOT repo, test as murdock, let that expose a stable interface?
  • Martine: shell parser in RIOT repo, but currently not tested afaik against actual RIOT output
  • maribu: can we get that?
  • Martine: will note it down, but for later

AOB