Notes: Virtual Maintainer Assembly (VMA) 2023.11

Community
,
1

2023.11 VMA

Attendees

  • Kaspar
  • Kevin
  • Bennet
  • Koen
  • Marian
  • Oleg
  • chrysn
  • Benpicco
  • Emmanuel
  • Dylan
  • Martine
  • Karl

Note taking: Emmanuel, chrysn, Kaspar, Martine

Agenda

  • VMA 2024.02 Moderation - 2min (Emmanuel)

  • 2023.10 Release debrief from Release Manager - 4min (Kevin)

  • Outlook on upcoming 2024.01 Release - 5min (Koen and Michel)

  • Release 2024.04 Release manager - 3min (Emmanuel)

  • Merge queue migration and lessons learned - 5min (Martine)

  • Clean up “Karteileichen” - 2 min (maribu)

  • Maintaining the BOARD_INSUFFICIENT_MEMORY alternatives - 5 min (Kevin)

  • Request to review STMicroelectronics embedded software activities in May 2024 - 3min (Emmanuel)

  • Roadmap Scan Roadmap · RIOT-OS/RIOT Wiki · GitHub - 15min (Emmanuel)

  • KConfig migration - 20+ min (maribu)

    • keep this at the end of the list, as the discussion may drag on

Notes

Agenda bashing

  • Emmanuel: Agenda bash. Roadmap scan to almost-end.

  • Oleg: what about the license discussion? Is it the place/time here?

  • chrysn: Not seen the divsersity and breadth of discussion I’d like to see in the forum before going to the VMA with it.

  • Oleg: → ping again on the forum

  • Benpicco: when/how was the license discussion brought up again?

  • chrysn: Discussion came again from FrosCon etc.

2023.10 Release debrief from Release Manager - 4min (Kevin)

  • Kevin: was a lot more issue-prone as expected. In particular failing release tests

    • Tests have been failing for a while due to IoT-lab infrastructure troubles. Probably not going to be fixed/maintained, so have to find alternative
    • Currently working on automating Zephyr interop testing. Would be good if people noticed when things are not working.
    • Combination of this w/ bors going down made situation for bugfix backports difficult – so we have what we have. Let’s hope next one is smoother. Will prepare and monitor for that.

  • Emmanuel: What failed on IoTlab, why is it not maintained any more?

  • Kevin: Firefly board was not maintained any more, switched to OpenmoteB (no engineers there any more to fix firmware locks on Firefly boards). Also, we don’t have Firefly boards here any more, so it’s a better fit, and we’re just trying to test the CC25… radio.

  • Emmanuel: So it’s about that board and not IoTlab.

  • Kevin: Hope not. It’s still you-get-what-you-get.

  • Emmanuel: AFAIK some sites are better maintained than others. There is HR bottleneck. Old hardware, and sites other than Saclay, ?.

  • Martine: Just had problem that paper artifacts could not be reviewed successfully b/c registration service didn’t work for weeks (neither did the admin mailing list) and was not noticed. Scared of bitrot there, and consequences for our testing.

Outlook on upcoming 2024.01 Release - 5min (Koen and Michel)

  • Kevin: Michel can’t, he’s too busy, in PhD mode. I can support Koen.
  • Koen: Hoped to be supporter here.
  • Kevin: Can do most tests, and has regular task of improving Everything (a bit).
  • Emmanuel: for the record, Koen is also in PhD mode…
  • Koen: Don’t expect much from the release.
  • Kevin: People do fix bugs when reported; happy with community participation in that respect.

Release 2024.04 Release manager; VMA 2024.02 Moderation - 3min (Emmanuel)

  • VMA 2024.02: Martine is doing it
  • Emmanuel: Anyone voluteering for the release manager?
  • Tumbleweed rolling
  • Martine: Anyone to update their opt-out entry? If not, Teufelchen is the only candidate in the current tier.
  • Teufelchen: Ok
  • Maribu: Do you want a side-kick. I could be.

Merge queue migration and lessons learned - 5min (Martine)

  • Martine: matches earlier discussion. Saw bors-mergequeue migration from IETF, but worried: Since May there was a warning, and nobody provisioned for that case. Hit us mid-release.

  • Christian: We’ve seen it, we talked about it, we assumed it’d stay around for longer b/c so many people do it anyway. Decision may have been bad, or might have needed later revisiting, but it didn’t go unnoticed.

  • Kaspar: Also, Koen started setting it self-hosted bors (just took long b/c it didn’t do IPv6). We just expected they’d raise another warning that it’s now “really” happening, and indeed it worked within a few days of migration.

  • Martine: Worried that people do too much alone.

  • Koen: Just confirming: bors does not support v6only host names, which is what our infrastructure does. So got stuck at step 0.

  • Martine: so more a bad communication on bors part?

  • Koen: Not only us to blame.

  • Kevin: When we got those notices, that was just when Dockerhub sent notices they’d shut stuff down.

  • Martine: So that was all to talk about, and to reflect on. Should learn from that, find alternatives when things don’t work.

  • Kaspar: CI was down for 2 days and 2 ppl dropped everything for that time to fix it. We went to bors b/c we need fast CI and don’t have so much compute. If we had the resources for computing, we wouldn’t have needed bors in the first place. As CI maintainer, that’s frustrating. Don’t want to spend time fixing stuff that isn’t important enough to spend money on. Won’t go for next-bors, put in compute instead.

  • Kevin: Also had bad timing. There is some work that’s not fun but needs to happen. Did notice changes, also in HAW where it’s now only me maintaining RIOT.

  • ben: Also feel that community is more shrinking than growing, lacking resources.

  • Martine: Let’s see if TU Dresden gets us growth back.

  • Oleg: On Kaspar’s point of money for compute, thought about RIOT internal crowd funding for compute hardware? People go to less-time-more-money.

  • Kaspar: It’s not hardware cost, it’s operational cost (putting it somewhere and powering it). Other than universities once-in-a-while can-have-this-server, there is no funding.

  • Martine: Will ask Matthias regarding server @ TUD.

  • Kaspar: Also need fast servers. Anything <16 core doesn’t make sense to set up.

  • Emmanuel: Looking into how we can help from INRIA.

  • Kaspar: Just make sure we get to control the server. Just-a-user-account is a waste of time.

Clean up “Karteileichen” - 2 min (maribu)

  • Maribu: Have members in paper only (code owners), esp. annoying in code owners b/c people are assigned but not responsive.

  • Maribu: What is code owners: Is it to allow people to have an eye on a subsystem, or for having reviews? Think it should be the latter.

  • ben: Many accounts don’t even exist any more.

  • Martine: Also many not working on RIOT any more.

  • Kaspar: All for cleanup, but please let’s not change it into the assumption that automatically assigned reviewers actually do reviews.

  • Marian: Leave comment high-level-looks-fine then and leave review to others. Heart emoji on PR is some reaction.

  • Marian: ?

  • Martine: We have maintainer ping coming up, right?

  • ben: Hasn’t been done in a while, but should be done again. No good machine readable way (Git list → EMail addresses). Manual process.

  • Martine: Could you do the ping again?

  • ben: Yes.

  • Conclusion: We follow through with the PR to clean up the CODEOWNERS and do the yearly maintainer ping

Request to review STMicroelectronics embedded software activities in May 2024 - 3min (Emmanuel)

  • Emmanuel: raising awareness about this (very) recent post on Forum https://forum.riot-os.org/t/message-to-stmicroelectronics/4064

  • Emmanuel: recent post on forum. STM gather feedback on all their activity, mainly software side. Can use that to convey our requests, and maybe also ask for more active support.

  • Martine: Only Dylad is here who contributed to STM; ping them on the forum. (Emmanuel: Alex) Maybe also Hauke.

  • Emmanuel: Yes, but it’s also more general.

Roadmap Scan - 15min (Emmanuel)

  • Emmanuel: one of the decisions at the last MA at Summit23 was that at VMAs we scan through the Roadmap Roadmap · RIOT-OS/RIOT Wiki · GitHub

  • Kaspar: we need to clean contacts (e.g. Hauke is not active anymore)

  • Martine: remove “ICN support cleanups”… really? (“support clean-up” is done AFAIK)

  • Kaspar: Should also look at what we can drop.

  • Oleg: Are high level topics still appropriate and complete? Would not drop stuff, but maybe add stuff?

    • E.g. Maybe add a category on Rust support?

  • ben: This should not be a wishlist.

  • Oleg: List of features we have, and they need to be maintained. Not having people is a different problem.

  • Martine: Ad high-level points, isn’t security too coarse-grained?

  • Oleg: Take similar approach to IETF. Has security area, even though it’s cross-layer.

  • Martine: IETF is at least clearly about network security. Here it can also be storge etc.

  • Oleg: Need it in all topics (maybe not in testing). And then extra item for coordinating those efforts. Agree it’s broad, but splitting it up would double the list.

  • Martine: At least consider cryptography, authentication etc. And different buckets of knowledge are needed to address it. (Oleg: Concrete suggestion?) No, esp. given privacy is an extra field.

  • Kaspar: Can treat them as trees. Subtopics operational-, network-, … Unfortunately we don’t have subsys maintainers infrastructure, but…

  • Emmanuel: Move software updates in there?

  • Martine: Yes if we acknowledge it’s treeish.

  • chrysn: won’t clean it all up today. Let’s just start editing in there.

  • ben: Let’s allow people to have their personal roadmaps in there. More valuable if it’s “this is what I plan to do”

  • Marian: Are we happy with this in the wiki? It’s the sourceforge of RIOT.

  • Martine: “The wiki is where documentation goes to die”. Markdown file? Teufelchen only noticed today that it exists.

  • Oleg: So that’d need an ACK for every change?

  • Maribu: Doc changes are ACKed fast. I wouldn’t put stuff in the wiki b/c it feels dead.

  • Teufelchen: Where do people go w/ questions about RIOT? code? docs? wiki? matrix?

  • Emmanuel: So we move from wiki to main repo?

  • Karl: wiki/ folder in repo?

  • chrysn: in the doc in the main tree is the place where it is visible and belongs to (also answering Teufelchen’s question)

  • Kaspar: Add release process item to update it?

  • Kevin: More work for the RM?

  • chrysn: More like “ping people like you do with the release notes”

  • Martine: Put it on every VMA agenda. Emmanuel: We did decide that already at Summit23, hence this discussion :slight_smile:

  • ben: RM could remove items but not add unless taking ownership.

  • Kevin: Big fan of “put own things there”

  • Oleg: If everything is on the roadmap that someone is interested in, but roadmap is for long-term coordinated planning. Is that then a roadmap or collection of stuff?

  • chrysn: the roadmap items is to announce long-term stuff, that is not yet in PR shape, or even very far from it

  • Martine: What good is a long-term goal if nobody is working on it?

  • Oleg: For example, we all have long-term goal of making RIOT more secure. But if nobody works on it, what do we do? Can’t force people to take up work, but at some point someone would have to suffer.

  • Martine: On every section of the discussed vision headers, people could place their individual roadmaps.

  • Kaspar: have to make roadmap more living. People give a one-line status update every release. If not even that happens, it’s dead. eg the Kconfig migration should have some line their, updated at VMA perodicity

  • chrysn: Could take inspiration from IETF’s IoTdir meetings. Before the IETFs, there is a 30min-or-so session in which all chairs give a ~1min update on what’s going on in their area.

  • Emmanuel: so what do we aim to have until next VMA?

  • Kaspar: ties with governance if this is to live, should we revive subsystem maintainers?

  • (?): Why was that blocked?

  • (?): Was blocked by some employers

  • Oleg: Should things be blocked by people not joining in VMAs?

  • Emmanuel: Maybe subsys maintainer structure can naturally appear in effort moving this from the wiki to the main tree. Until next VMA, have provisional(?) version of road map in the main tree.

  • chrysn volunteering to do the initial moving PR: doc: Move roadmap in from the wiki by chrysn · Pull Request #20122 · RIOT-OS/RIOT · GitHub

KConfig migration - 20+ min (maribu)

  • Marian: kevin will not be able to do this alone

  • Kevin: actually, I’m not even working on it

  • Marian: we need commitment, but I don’t see it, me included.

  • Marian: We don’t have the tools to do the jump, moving everything that was not migrated to staging. And I don’t like the tools. RIOT is not easier to use than Zephyr b/c our makefile infra is so cool, but because it spares you the nitty-gritty config steps.

  • Kevin: decision (a while ago) was to go ground-up. But…

  • Benpicco: would be very costly to go forward with this. Not sure if this is the right way anymore.

  • Kevin: we talked about a deadline passed which if no progress we would drop that. Seems we are passed that. Sucks to be stuck with make though…

  • ben: Kaspar has been foreshadowing laze but never made a proposal…

  • Kaspar: It’s capable. It’s missing some convenience features to build all of RIOT. Was aiming for feature completeness, but I think at this point we could start migrating there if Kconfig is not done any further. Would not do that in master repo, rather in a branch. I have a branch somewhere actually with partial migration. I think migrating to laze would be faster, though I could not be doing it alone.

  • Martine: does it have UI / configuration like Kconfig?

  • Kaspar: no UI, but configuration is semantically similar

  • Oleg: if we talk about dropping Kconfig, would be sad, but is there anything useful we were targeting with it that we can nevertheless use? For the dependencies?

  • Kevin: Kconfig manages explicit dependencies. One reason why it’s not so great to select everything explicitly is that we have so many different boards. Scalability is an issue.

  • Marian: Can laze genererate graphviz/dot code? As Alpine user I’m spoiled, typing apk dot to figure out why something is pulled in is so convenient

  • Kaspar: not at the moment, but that’s probably easy to add

  • Martine: Could be a good compromise to explicit dependencies

  • chrysn: …

  • Kaspar: we have to match what we want to do with what we can afford to do (maybe Kconfig was too tall an order)

  • Marian: device tree is complex topic, let’s not mix this into the build system discussion

  • Benpicco: let’s first finish the build-system migration before the device-tree migration

  • kaspar: We shouldn’t just try to play catch-up with Zephyr, can’t compete with that

  • Kevin: If no progress until next release, remove Kconfig altogether? It’s been 3 years, and it’s a huge burdent to remain in limbo in the middle of this migration, still lot of work and techincal debt to resolve

  • Kevin: already many bespoke solutions, very little people know how to use it

  • Benpicco: drop Kconfig from CI?

  • Kevin: if after having asked the community?

  • Kaspar: it’s already clear from the active crowd here that there is no majority, if anyone, on this.

  • Maribu: give it 2 weeks to come forward to pick it up, else pull the plug?

  • Martine: Timing-wise (christmas is coming up) maybe better to say after New Year?

  • Conclusion: Kevin writes the call for people to pick this up with deadline end of the year. Passed that, we’d drop from CI

AOB

  • Koen: Karin is looking for input on the Forum https://forum.riot-os.org/t/riot-learning-solutions-request-for-input/4062/3
    • Oleg: maps to Teufelchen comment on what is the entrypoint for doc…
  • Kaspar: laze will touch thousands of files, and branch will be around. Can’t easily rebase, will need to merge in master instead. Use to be against our conventions
    • chrysn: sounds sensible (here and generally)
    • Maribu: the convention was gone anyway
  • Kevin: So Kconfig goes out and laze goes in?
2 Likes