Find the notes from the assembly below
RIOT Summit 2023 - General Assembly
Agenda
- VMA Moderation 2023.11 (Martine, 2min)
- 2024.01 Release Manager (Martine, 4min)
- 2023.07 Release Debrief (Ben, 4min)
- 2023.10 Release Outlook (Kevin & Bennet, 5min)
- Decision making process RIOT community (Karin, 20min)
- Runtime Configuration (Ben, 20min)
- Where Do We Want to be with RIOT in 5 Years? (Karin, 20min)
- Demo time (Kevin, Bennet, 6min)
Notes
(Note taking: chrysn, Martine helping)
Intro
Martine bashing agenda.
VMA Moderation 2023.11 (Martine, 2min)
Emmanuel volunteering.
2024.01 Release Manager (Martine, 4min)
Koen and Michel, with support from Kevin.
2023.07 Release Debrief (Ben, 4min)
Ben summarizing the change log.
The release was uneventful. Some automated tests are failing and it’s neither clear why nor is it clear who is responsible for them. The failures were new compared to the last release.
Oleg: In the last releases we had discussions about Contiki interop / whether they make still sense.
Martine: IIRC those tests were deprecated.
Kevin: They’re in while they’re easy, but wanted to switch to contiki-ng.
Martine: moved to outlook.
2023.10 Release Outlook (Kevin & Bennet, 5min)
Kevin: Dates are on the forum. Will move release testing into RIOT repo so it’s not that separate (currently it’s in weeklies). Noted that lots of boards fail random self tests (experience from previous releases). My nice new tool should get a lot of them public again. Also, boards should be parametrized a bit more (“provides this and that” instead of “BOARD=iotlab-m3”).
Emmanuel: Interop tests?
Kevin: Will be the last we do. Tests with Zephyr are getting too big, so they need some configuration tuning (that may also need more understanding of Zephyr).
Decision making process RIOT community (Karin, 20min)
Impressed how things get done without much structure. Wondering: How is the decision making process done? Would be happy to write up documentation on it. So it is just as clear as the CoC.
Kevin: Historically, “rough consensus” idea. More realistically: If you’re willing to maintain it, and you’re responsible, people go with it. But you have to be willing to champion an idea to the point of completion.
Emmanuel: Differences in “on what”. On PRs, we have clear policy on “number of ACKs”, and that’s well documented and works well.
Oleg: Even there, […]?
Emmanuel: More fuzzy is higher level decisions. […]
Ben: Can’t make decisions and make someone do something – if there’s nobody to do it, it will not happen.
Karin: more aiming for high-level decisions, like Rust/C. How are things like “where does RIOT focus” made? Should it be me made more explicit or not? May be that it’s working out fine without being explicit.
Kevin: Once it’s explicit people have to do it that way. We could even agree to “all go for KConfig”, and it still doesn’t happen. Even when explicit decisions are made, doesn’t mean it’s followed. So unsure what’s the value is of writing them down. Emmanuel: This is more about process, how decisions are made and not how they’re followed through.
Karin: For example, is this meeting where decisions are made? Is the VMA where directions are set?
Emmanuel: These are arenas where consensus can be gauged, and consensus can be noted. But it’s not more precise than that.
Kevin: Usually someone has a big architectural proposal, […].
Leandro: RDMs never got merged. Once a year, or at VMAs, we go over specific proposed areas.
Karin: And does it work?
Koen: There are times when we don’t agree on the path forward, and currently there is not something in place to break ties, so nothing happens.
Kevin: For example, subsystem maintainers got stuck.
Martine: Alternatively, two differing ideas, two teams work on this, better idea in the end “wins”.
Ben: Also happens that you propose something, nobody cares and then it’s just silence.
Oleg: On “next CI tool”, a third team (none of those proposing the alternatives) implemented both and tried. In past discussions I think we came up with a writedown about the process, but apparently noone remembers.
Koen: Subsystems were the last thing that got stuck.
Oleg: What can we do, set up a task force of people not directly involved?
Lenadro: What stalled it was concerns about giving more power to certain people. Oleg: Not about setting up jury for everything, but choose for specific decision.
Jose: Remember 2018 Amsterdam discussion. There was an issue w/ 3-4 topics stalled due to one item. Things got better overall since then, we have more agreement power. We just don’t have people that work on one thing for two years. (Esp. with bus factor.) (Karin: What made it improve?) Jose: Increased bus factor, increased involvement maybe. Maybe also that we’ve discussed it many times.
Karin: Is it desirable to write things down? Where
Matthias: Contributing.MD, maintainers’ guide.
Martine: We say “rough consensus”, but apart from vague reference to IETF, not really what that means
chrysn: IETF has good descriptions of rough consensus, can find references.
Emmanuel: Would be interesting to see outside perspective of processes and read that as a mirror.
Karin: So, “come up with something, and put it on the forum”?
rough consensus on having a forum post with initial understanding from Karin.
Emmanuel: So rough impression is that our decision making processes have improved over the last years?
(Some nodding)
Oleg: Might also be because people have gotten tired of fighting.
Maribu: Process has not improved. Just burned up to the point of not caring about some things.
(Some nodding)
Emmanuel: So less noise, but not necessarily good sign.
Runtime Configuration (Ben?, 20min)
[Ben beforehand] high risk of bikeshedding: We can have a smaller meeting for technical discussion as a break-out session
Ben: Fabian and Lasse both proposed a config system, and Koen talked about CoREconf. The need has been there forever.
Martine: Leandro and Jose also had an RDM proposal.
chrysn: Wiggle room in schedule to have 20min discussion slot after the upcoming presentation? Oleg: It’s at the end, no space.
Emmanuel: Has overlap been looked into?
Lasse: We have some overlap (get/set/commit/export/storage backends). Differences are in type safety (Fabian is more using strings).
Kevin: A comparative list would be good.
Michel: Could be interchangable.
Ben: Would be pulled by other modules.
Martine: Could consolidate work?
Kevin: How hard and how much time needed for consolidation? We have need for that.
chrysn: Some decisions still have to be made. Like type safey, type of keys.
Emmanuel: How does CoREconf overlap? Koen: CoREconf would hook into any backend. CoREconf uses SIDs that are numeric values; challenge is to translate those into internal. Leandro: LwM2M also has numbers for options.
Ben: Good to exchange details and determine requirements.
Koen: Defer those parts to breakout?
Kevin: “consensus: Work together as a happy family?”
Ben: breakout would be good for tech aspects.
Koen: Given the manpower, rater have “a” than “the best” solution. (Martine: Just days difference)
Michel: Who would use it, what are their requirements.
Leandro: It’s in RDM. Revise it?
Oleg: Add what the two implementers chose.
Martine: So, breakout session?
Lasse, Fabian: Breakout session.
Emmanuel: When stalls, could still gather task force. Oleg: Let’s try “happy family” approach first.
Where Do We Want to be with RIOT in 5 Years? (Karin, 20min)
Oleg: Want to not have people frustrated about decision processes.
Karin: Also: “What should not happen in that time frame”, b/c we have lots of ideas, but what are focus points?
Emmanuel: Want more enthusiasm. Influencing factors: “happy family factor”, sense of mission (got fuzzy). Would help for maintaining unity.
Karl: Reduction in clarity due to diversification – used to be mainly academic, now there is more hobbyists and more companies.
Emmanuel: I think of that more of a strength. Never experienced case where industry contributors pushed in a direction that caused chaos (but knew that from academia).
Koen: Would prefer it to be more opinionated on technical issues. We now try to support everything (and nothing well). Karl: So need to get decision making process done?
Jose: Less common ground
Karl: Hobbyists may want to put ther config into config files…
Jose: more use case dependent, could be tradeoff which is not as flexible.
Karl: Focus-point is different. Resistance for one-use solution in academia not as high as e.g. with home users.
Jose: …
Ben: Fundamentally different requirements from academia and industry: e.g., low-power not as important to academia
Karl: Current example – our energy system is not suitable right now for 10y on a single battery. Emmanuel: Are solution approaches being impeded? Karl: More lack of focus / understanding.
Michel: What is the problem exactly?
Ben: ZTimer appropriates RTT timer, but could be solved.
Karin: “3 User groups academia, companies and hobbyists. Common ground is there and not clear”? How do we get to that common ground? Gather requirements from reps groups?
chrysn: Sounds good!
Emmanuel: Some parts of community lack focus. Other parts have high focus on specific problems. Time scales are different.
Karin: There will be dying parts. How to deal with that?
chrysn: We have deprecation processes.
Karin: Also emotional aspect.
Emmanuel: Long time ago we had culture of being proud of removing lines. Applause for many lines removed. Get back to that. Could help with ego and loss.
Karin: Summarizing. 1: get a common ground from the three user groups. 2: turn specific problems that need to be solved into focus points. 3: remove lines / close off parts that are not used much anymore.
CA: On the common goals, we should also focus on high-level goals to priorize? Like, open-standards-based networking and security.
Emmanuel: Security. Have well-expressed goals in terms of open standards and open source; security is lacking. Question of Rust v. C is super fundamental in terms of security. Some things were too fuzzy in terms of goals and policy there. That could shape some new energy.
Emmanuel: Christmas wishlist: License. INRIA would be happy to switch to more permissive license. Getting more and more difficulties to get funding for LGPL C code, whereas it’s easier to get funding for Rust code w/ permissive license.
Emmanuel: Also, more Rust is more of a distinctive property.
Karin: Is taking-note-here enough?
Koen: Another roadmap? Have something like a vision like chrysn mentioned. Having something on the wiki or so.
Oleg: Align releases to roadmap? Karl: Focus points come from release maintainers. Kevin: More “do you want to get this in before release?” RM could do some more effort in distinguishing “this advances our vision” vs “this is a cool project”
Karin: How will the vision be updated?
Koen: Vision document can help resolve conflict.
Emmanuel: Trying to understand Oleg and Koen … makes sense to use VMA cycle to go through roadmap, where was progress made, and update together?
Demo time (Kevin, Bennet, 6min)
Bennet raises a GameBoy Advance with RIOT games. Kevin wants to show his testing setup upstairs.