General Assembly @ RIOT Summit 2024

Community Events
,
2

Find the notes from the General Assembly below

2024 General Assembly (VMA 2024.09)

Attendees

  • Martine
  • Oleg
  • chrysn
  • Nico
  • Tamme
  • Hannes
  • Mikolai
  • Thomas
  • Teufelchen
  • Matthias
  • Michel
  • Emmanuel
  • Karin
  • Kaspar
  • Lasse
  • Bozheng
  • Tom / AnnsAnn
  • Bahareh
  • Koen
  • Karl
  • Lena

Note taking: chrysn, Mikolai, others please join, thx

Agenda

  • Agenda Bashing - 1min (Martine)
  • VMA 2024.11 Moderation - 2min (Martine)
  • 2024.07 Release debrief from Release Manager - 5min (Mikolai)
  • Outlook on upcoming 2024.10 Release - 5min (Ben)
  • 2025.01 Release Manager - 1min (Martine)
  • RIOT-rs - quo vadis? - 15min (Oleg)
  • Code of Conduct Contacts - 15min (Martine)
  • CI maintenance handover (kaspar), 10min
  • AOB

Notes

Agenda Bashing - 1min (Martine)

Agenda bashed.

VMA 2024.11 Moderation - 2min (Martine)

chrysn volunteers.

2024.07 Release debrief from Release Manager - 5min (Mikolai)

  • Mikolai: Went smoothly.
  • Mikolai: Some release tests are known to fail regularly, some are cumbersome to test (RIOT to Internet at university w/o IPv6).
  • Mikolai: Found and managed mixup with tags: Tag acknowledged to have been misplaced, no additional release activity.

2025.01 Release manager - 1min (Martine)

  • Kevin already volunteered during 2024.05 VMA

RIOT-rs - quo vadis?

  • Oleg: Briefly discussed during last year’s GA, but no clear path forward yet.
  • Oleg, responding to Matthias yesterday (“consensus to call this RIOT-rs, is this a RIOT effort?”): Opinions to that?
  • (all waiting a bit)
  • Kaspar: RIOT-rs started out to improve RIOT with some Rust code; on pure-Rust path now, but still code around eg. for RIOT threading API to have common APIs.
  • Martine: As long as kernel doesn’t work with APIs, don’t see it as RIOT. If APIs are supported, would be fine.
  • Hannes: No opinion, but what changes do you need to make to not call it RIOT? Where is red line?
  • Matthias: Supposedly you also support other APIs, include those all in name? What is RIOT? RIOT is code, community and license. No overlap in this.
  • chrysn: Theres more to it: large overlap in community, and in overall mind-set. And there are other sub-projects under the RIOT organisation that do not fit the same model as RIOT-OS repo (e.g. RIOT summit organization)
  • Matthias: With that you could call all open-source project. Governance model in RIOT-rs is quite different from RIOT
  • Martine: One point on slide was maintenance bottlenecks. Don’t see how that happens when community spread over two projects.
  • Hannes: On overlap, community is mostly elsewhere. Looks like community is elsewhere. People who work on Rust RTOSes.
  • Kaspar: We are collaborating with them, it’s not an either-or.
  • Matthias: Just because some people overlap, doesn’t justify calling it RIOT. If I start a new text editor, wouldn’t call it a RIOT-VI.
  • Emmanuel: Historical reasons for RIOT-rs name (original plan to replace kernel). On bottlenecks, collaboration w/ HW abstraction people is addressing that.
  • Martine: How does that help the RIOT community? Doesn’t get anything out of it right now other than maintainers moving to RIOT-rs. Currently, no API from RIOT-rs to RIOT.
  • chrysn: EDHOC/OSCORE integration is meant to be reusable enough to be combined and used with sock API in RIOT, not there yet. Common Rust APIs help in reusing Rust drivers from other projects
  • Thomas: how are you going to support GNRC?
  • Martine: Not necessary to support GNRC in my opinion, would rather like to see sock API supported on top of RIOT-rs+smoltcp
  • chrysn: Sock API can be provided, and that is what applications use, not GNRC.
  • Hannes: cf. Zephyr have started rewriting something in Rust. @@@ Putting name in there creates fragmentation. What is the endgoal? Rewrite, or compoennts?
  • Kaspar: I want a tech stack to hack nice safe applications.
  • Hannes: Rust doesn’t help you achieve that, doing the wrong thing. Setting yourself for long journa. First talk was 5y, and not even half done.
  • Karin: What should it be?
  • Hannes: Previous efforts had long-term vision, but vision is lacking here.
  • Emmanuel: Dream was to have real bridge for both communities. Started research project trying to build a smooth transition for C to Rust core. Have a short at merging community efforts.
  • Hannes: If that’s the goal, team up with Zephyr and merge with them.
  • Emmanuel: Zephyr is not even envisioning that type of change. Even the comparably small RIOT project has a lot of inertia, and they will have more.
  • Hannes: Similar to OSCORE/EDHOC situation. Fragmentation slows down complete community.
  • Matthias: Agree with the observation. We should not cannibalize. Also, seems like Selbstfindungsphase. Started that on RIOT code, now that is gone.
  • Emmanuel: In C, we are in direct competition with Zephyr. Can we hold this up? Else, should we join them? What we are saying is we have another alternative: with Rust, we can be ahead of the wave.
  • Oleg: So far heard only ppl contributing to RIOT-rs and nobody technically contributing (except Martine). All doesn’t make sense to have contributors involved. Only makes sense if more ppl are willing to switch over. On the long run it doesn’t make sense to maintain two code bases. Either take over things into the new things, otherwise I’m with Hannes.
  • Martine: (pointing at clock)
  • Teufelchen: Confused we’re talking about technical details. We’re a community. If we all decide bicycles are fun, we call them RIOT bicycles. Can have benefits even w/o shared APIs.
  • Oleg: Summarizing that there is no consensus.

Outlook on upcoming 2024.15 Release - 5min (Ben)

  • Ben: There is going to be a release. Hope it will be uneventful.

Code of Conduct contacts (Martine)

  • Martine: Yesterday, mentioned EMail address, Oleg and me. Oleg was surprised, I was surprised I was the only one.
  • Martine: Not much to do, but bus factor.
  • Oleg: Just surprise. Am fine doing it.
  • Martine: Tell us if you want to join the team.

CI maintenance (Kaspar)

  • Kaspar: Can’t maintain CI any more. Some people said they’re taking over, but nothing precise.
  • Martine: From older discussions, Teufelchen takes over and is supported by Kevin.
  • Teufelchen: OK

We have time, continuing RIOT-rs discussion

  • Matthias: Should find a way of convergence, not just wait-wait-wait, and have clear statement.
  • Martine: Some points were made on API.
  • Emmanuel: Why urgency? What is confusing is also future of RIOT as a whole (?), difficult to address in 15 minutes.
  • Thomas: Hannes gave clear answer. It harms. Fragmentation endangers community and development forces.
  • Hannes: Is intention on long run that Rust based RIOT replaces regular RIOT. What should users choose? Question will come up. I’m always in favor of collaboration. Propose to reach out to other RTOS communities. Example of crypto APIs on embedded, nowadays still very hard to get right as user.
  • Matthias: Nobody is objecting collaboration. But encoding collab partners in name doesnt’ help.
  • Francisco (kYc0o): When I saw Rust port it was interesting for me, but goal was unclear. Transition due to Rust’s benefits, and evolve from there on? From user perspective, tell me whether C code is maintained and will move on, I’ll stick with C code. Hard to tell; we try things all the time and see what works. ???@@@
  • Martine: That’s what Matthias meant with confusion.
  • Oleg: It is somewhat urgent to clarify. Are we aiming for a smooth transition into a Rust code base, or currently having a 2nd OS code base in parallel, potentially under same umbrella organization/community, and maybe do transition in 5 years?
  • Martine: Or have glue between the projects.
  • Oleg: At least make it visible that they are separate with certain overlap.
  • Emmanuel: So we’re back to the RIOT question. What future do we see for RIOT? Stick with C, continue we’ve been doing so far?
  • Kaspar: From technical perspective, there are issues. Code base is getting larger, contributors are getting fewer, hard to get stuff done (ZTimer took 3 years, KConfig stagnating). Mismatch between “GNRC is the diamond of RIOT” (Thomas) but maintainers don’t change it, consider it unamintained mess.
  • Emmanuel: Can we get to future from past? To answer Hannes’ question, we do propose transition to Rust as bright future for RIOT. From Martine, see potential for having continuity for C APIs for the good stuff (sock and other things); that makes sense. That’s something we can master. What I’d like to hear from people is what do they propose.
  • Ben: This is unrelated. How does moving to Rust solve maintenance and governance issues? Once you have users you can’t make changes that easily any more. Projects that used RIOT will not move to RIOT-rs immediately
  • Thomas: There is vision of as-soon-as-you-use-Rust-it-gets-golden. Not compatible license-wise. Ongoing work on Rust bindings in RIOT. That’s soft expansion. PErsonally, that’s way that makes sense.
  • Karin: Zooming out. Psychological aspect of change. What are gains and losses of a change to Rust? Gains and losses have been discussed. Simple accounting. Might be difficult to do, but could serve as a possible framework.
  • Kaspar: No license incompatibility between LGPLv2.1 and Apache2
  • chrysn: -wrappers is an even easier collab point. Can do more there if that helps keep communities together.
  • Thomas nodding.
  • Hannes: Going Rust could open new possibilities, like drop support for phased out CPUs (8bit, 16bit)
  • chrysn: concrete proposal: suppose we add APIs that are built on riot-wrappers and could be easily used both on RIOT-rs and RIOT, ???
  • Hannes: question for user community
  • chrysn: portability is big plus for RIOT, don’t know how often that happens in practice, serves as inspiration for RIOT-rs design. transition using riot-wrappers is doable, not sure if used in practice.
  • Bozheng: Would emphasize importance of market. Will market stay with C or prefer us to move to Rust?
  • Bozheng: I do studies in BLE. From what I know, I don’t find Rust library for BLE. How should we implement such communication protocols in RIOT?
  • Emmanuel: from market PoV, if we continue our route, the market chooses Zephyr and FreeRTOS. What we propose has traction.
  • Matthias: Kaspar said RIOT community failed. [minute taker note: didn’t hear that, see above] Emmanuel has a proposal to be super successful. So just go with it.
  • Ben: As long as people will develop C code with RIOT, there will be C-RIOT. Not something that can be decided.
  • Matthias: If your road is so successful, why ask about RIOT community?
  • Emmanuel: Don’t claim we win with Rust, just saying we loose with C.
  • Oleg: What leads to more fragmentation, separate project where people leave to, or two projects in common community that share ideas under the same umbrella? From my PoV, latter is more viable approach. Name of 2nd project, don’t care. You said RIOT is both code and community. I say there is RIOT community and its project RIOT OS. No reason against two projects against community.
  • Kaspar: If it’s just about the name…
  • Matthias: pick a new name, state as a collaboration. try to reduce confusion.
  • Hannes: Looking into future, what is future of microcontrollers, in light of PQC?
  • chrysn: At least verify part is (as used for SUIT). Hannes: That’s cheating.
  • Martine: Support Oleg. Mozilla community has different projects. As Bennet said, a Rust project called RIOT might draw in Rust people in here; more collaboration. However, making (current) incompatibilities more clearer might help with the confusion.
  • Emmanuel: Answering Hannes, are we doing away with that type of hardware? Are low-power constraints going away?
  • Karl: One issue on compatibility of RIOT-rs on being compatible and sharing community is name. If we did Mozilla thing, how would RIOT-rs be placed on webpage? Even Mozilla does not name projects the same.
  • chrysn: I think we agree that it will not stay RIOT-rs in the long run. Better example than Mozilla is Apache: people say Apache and people think of httpd, but e.g. mynewt is also part of it.
  • Karin: Strawman. Change name, “it started from RIOT”, FAQ from riot-os.org entry on this entry. Matthias, Hannes: +1
  • Martine: Consensus on name, mutual linking. chrysn, clarifying: Question of whether it is part of RIOT project is left open for that consensus call? Martine: That’s left open.

AOB

None.