RIOT Summit 2021: Virtual Open Assembly

Community Events
, ,
4

Here are the VOA notes

RIOT Open Assembly @ Summit 2021

Attendees

  • Martine
  • maribu
  • aabadie
  • dylad
  • Frank
  • javier
  • saniea
  • Wojtek
  • Oleg
  • Cedric
  • Koen
  • Kaspar
  • Leandro
  • Jürgen
  • Karl
  • Michael
  • Joakim
  • José
  • Kevin
  • Kirk
  • benpicco
  • Cenk
  • Philipp
  • Christian
  • Peter
  • Hauke
  • Ioannis Chatzigiannakis
  • Jelle
  • Emmanuel
  • Daniel Lockau
  • Andrey Kolesnikov
  • Jean Dudey
  • Fabre
  • Gilles
  • Smit Shah
  • Yiannis Christou
  • Hendrik
  • Nils Ollrogge
  • Olaf Bergmann
  • Akshai
  • Matthew Bradbury

Notes

  • Moderator: Oleg
  • Note-taking: Christian, Martine & Kaspar

Agenda

  • Agenda bashing
  • Dropping hardware support
  • Releases: Changing the default round-robin
  • RIOT road map
  • Subsystem maintainers
  • open discussion

Dropping hardware support

  • Oleg:
    • no clear path for removing h/w support
    • supporting unused hardware may slow us down
    • is there a semi-automatic way for that?
    • Last VMA Oleg proposed annonimized usage information
      • Sees the problematics there
  • Kaspar:
    • If people are annoyed, ask around if it is used, if nobody screams: Drop it (the current approach)
    • Effectively decide by maintainance burden
  • Oleg:
    • CPU / Board removal need to be distinguished
  • Kirk: do 8bit/16bit/PIC special cases cause complexity?
  • Kevin: do we keep platforms, where design is flawed from the beginning? (?)
  • Marian: THere is value to having at least 8-bit and one 16-bit platform
  • Oleg: Value only if these kind of platforms are in use. Is this the case?
  • Karl: If we care about 8- and 16-bit now, we might have an advantage when 64-bit support is necessary
  • Marian:
    • from technical side: Lower bit platforms can actually have lower power consumption + AVR is better shielded for radiation (cube sats)
    • Old intel 8-bit is still surprisingly popular. Maybe add that rather than AVR
    • Main point for AVR: Every student has some Arduino flying around => first RIOT platform
  • Hauke:
    • What can be made more efficient when dropping boards?
    • Maintainance, but what else?
    • AVR still well maintained
      1. Easy entry point
      2. Cross-checking
      3. Market (?)
    • As long as there is maintainance there is no reason to drop it
  • Marian: There was just a new AVR-platform added, so there seems to be still maintainance interest
  • Michael: Does RIOT still fit AVR?
  • Kaspar: If not, its a sign of bloat
  • Michael: Ok, but there might be things we want to add that do not fit AVR
  • Kaspar: No compromises for AVR, what doesn’t fit doesn’t fit.
  • karl: Could check for whether there are any ifdefs for these to quantify maintenance burden.
  • Marian: additional use for AVR: it’s easier to judge performance impact there. On ARM there’s luck involved when data is added due to cache hits and misses.
  • benpicco: MIPS (martine: and MSP430) are on the slate, nobody is seriously considering dropping AVR.
  • Marian: but MIPS is 32-bit so do we gain anything from keeping support?
  • Kaspar: All those toolchain special cases!!1! Marian: Let’s call it a gain :wink:
  • Oleg: Time span? benpicco: Standard deprecation cycle for two releases. Marian: Can mark MIPS module as deprecated, and people see it through build system because they use deprecated modules.
  • Oleg: Sounds like a clear plan.
  • Build time? Kaspar: Not building deprecated stuff would worsen code rot.
  • Martine: When removing the MSP-430 platforms currently on slate for removal, is there still a MSP-430 platform? There was a newer TI platform using MSP430 discussed to be ported crickets
  • Oleg: Build times … is this an issue of not having enough hardware? Kaspar: Would get better with more hardware. Marian: Have a server that just needs to be installed. Kaspar: Builds need 1h now, had to wait 5h during sprint day. But that’s different subject. Kevin: How much would it cost to just rent resources? Maybe it’s just a few Euro.
  • benpicco: For quick CI builds, just a curated list of selected boards? Maribu: Also wonder about the 50 flavors of the same board, with different button and LED configurations. Martine: We did this with LLVM builds, had a selection of boards for each CPU type. Hauke: Could we do like blacklisting, “blacklisted because too similar for X” and then build in nightly only? Should be easy to implement. Can then strip down many boards.
  • karl: “skip compile” tests are a thing. Can we do this specifically for an architecture? Maribu: same with new peripherals – would just like to do explorative builds on everything that’s using that platform. Martine: Some people provide paperCI. But doc of access to those is an issue. Kevin: I could offer access for people who want to the one at HAW.
  • Alex: Have some work in the pipe regarding front-end and back-end changes (interaction with github). Able to say what to trigger, but in the end will still go into the same work queue.
  • Kevin: Are we going off track? Alex: was about testing specific set of boards
  • Kevin: Let’s go back to discussing dropping hardware support
  • Kevin: MIPS as a first step, MSP-430 not yet, because a bit controversial
  • Oleg: could the blacklisting strategy work for stm32 variants?
  • Alex: not trivial, there are many variants . ESPs are a bit annoying because they subtly change Ethernet wiring. Would be great to have more if that doesn’t affect the CI time.
  • Kaspar: [?] We have lots of configuration and can’t distinguish between code and configuration.
  • Kaspar: Had this makefile-based, but with ccache it turned out to be faster to rebuild all.
  • Oleg: So to summarize, can get rid of some CI time from new ESP boards, but not for Nucleo
  • Alex: Nucleo is nice because cheap and many variants work, but a pain to maintain because of those variants
  • Oleg: Concluding. Discussion on CI and autospeedup can be continued at end of assembly if time available.

Releases: Changing the default round-robin

  • Martine: Background: Normal way to find release manager is to have volunteer in best case (might be passive volunteering); lacking one, the founding organizations go round robin and pick an employee. Right now at FU it’s me and Hauke, with the latter declining, so it’s always me. So maybe change and update to more community based approach: For whom was it the longest to RM, or who has never? (LRU maintainers)
  • Oleg: Time estimates for RM’ing? Martine: Not as time consuming as it used to be, but still some work. Brought this up for 2022.01, can still do that but every 3 releases is not scalable even with all automation.
  • Kaspar: Also takes time to read up and get familiar again, takes research time; 2 weeks?
  • Oleg: 2 weeks is a lot of time for everyone not getting paid.
  • Kaspar: We’d still accept “sorry can’t do”. Maybe pool of maintainers who can do, and round-robin there?
  • MCR: Apprentice program for RMs?
  • Kaspar: Yes, and/or co-RM who can ACK your stuff. Next time I’d pick a RM buddy right away.
  • Benpicco: Maybe ask previous RM? Martine: Sometimes done like that, but sometimes not available any more.
  • Oleg: Pool is good. Benpicco: Should be opt-out. Martine: Need to organize that pool in a document, or just track opt-outs? Oleg: Do we even have a list of all maintainers? Martine: Maintainer group in forum. Oleg: Lists can get out-of-sync. Martine: Opt-out list is less likely to.
  • Oleg: Maintainer list growing outdated. Martine: There was an idea of having a maintainer ping on summits.
  • Oleg: So, opt-out list? Kaspar: Makes sense, drop institutions for Martine’s sake. Martine: And for Kaspar when Schleiser Inc. comes back :stuck_out_tongue_winking_eye:
  • Opt-Out list was created as a Wiki post on the forum

RIOT road map

  • Oleg: Who is aware of road map existence? (Some unaware, others forgot)
  • Emmanuel: Idea was to have collaborative updates; what happened was attempts to delegate maintenance and that didn’t work. Tied to topic of more offical steering people for subsystems (who’d track and update roadmap). Map is important to have and maintain, maybe takeaway is that [?] that needs better organization.
  • Jose: There’s some in the forum, with dedicated entries. Maybe use that, and establish how to maintain.
  • Kaspar: Endeavors category opened for that.
  • Oleg: Important to have roadmap – for us as community (people get too deep into one issue), and to outsiders (esp. coming from industry, to see what is unsupported and what’s close on roadmap).
  • Alex: [?]
  • Benpicco: Industry can implement and contribute.
  • Alex: With the list we can identify people that work on them. As insiders we know that, from the outside it’s not clear, and then several people start on WolfSSL.
  • Benpicco: But that’s more in the direction of having subsystem maintainers.
  • [ MCR on chat ] Celebrate what has been already crossed out (with many +1s on chat)
  • Karl: maintainer-to-subsystem matrix?
  • Emmanuel: Prototype roadmap tried to do that.
  • Leandro: … code owners?
  • Oleg: Subsystems and roadmap are obviously closely related – but anyhow would like to discuss future of roadmap first. Important to have it visible, also from web (but needs better shape). HBO adding to default VMA agenda a roadmap step? Need initial showable version, but then can table that on every VMA / release. Alex: +1.
  • Kaspar: But need to discuss what’s to be there.
  • Benpicco: Focused to subsystems. 802.15.4 stack, CoAP stack, etc.
  • Kaspar: But need to agree on what to put there. Maybe there’s even different opinions on where to go there.
  • Oleg: Roadmap task force for initial text for next VMA? Kaspar: Discussed much in last VMA, and breakout session already planned.
  • Alex: Make sense to have wishlist, putting things to roadmap in time?
  • Leandro: Feature request issues? Emmanuel: Central place. […]
  • Emmanuel: When there’s lead-up time (Kconfig decision to implementation), the roadmap entry is handle for that. On VMA, can be time consuming, will need moderation.
  • Oleg: Survey current colleagues on what they expect of IoT OS.
  • Kaspar: Right now different people would write up different things there. Alex: But there’d be overlap.
  • Oleg: Maybe two different versions, one short/high-level for website, and details.
  • Kaspar: […] voting in forum for who’d like to see which feature.
  • Karl: Didn’t know about roadmap page.
  • … next steps / task force? Oleg: Breakout session tomorrow.
  • Oleg: What’s process for breakout session scheduling? Martine: Planned in evening, but not all maintainers can’t be in a single session.
  • Martine: Breakout attendance maybe problematic due to maintainers also having other breakouts in parallel
  • Kaspar: Talked a lot with Francisco, so moved to breakout session there – but if there’s not enough attendance … but maybe subgroup can make proposals and then bring them to all.
  • Oleg: there will likely be more discussions on this to come, but having a (mini) breakout to spark discussion is good!

Subsystem Maintainers

  • Benpicco: Subsystem roadmaps can only be written by those on the subsystem. Roadmap can’t be imposed from outside
  • Emmanuel: So start with a list of subsystems?
  • Kaspar: The only thing having a subsystem maintainer does is that people come to you for help. Oleg: Does that work? Martine: I get some, and at least can redirect them. Kaspar: Reviews do get assigned.
  • Oleg: Maybe add to PR procedure to get subsystem maintainer ACK? Doesn’t need detail review, just for “does it make sense?”. [?]: Would make a lot of sense. Oleg: So then (re)identify subsystems and assign people.
  • Emmanuel: Have Github labels on areas. Martine: Can be used as template for list of subsystems. Emmanuel: Maybe some areas in same subsystem, but at least used successfully to group PRs so far. More solid base than structure in current roadmap. Kaspar: Tooling would be great, so that github pings subsystem people when subsys is assigned. [?]: Codeowners? Kaspar: Doesn’t always map to code. Martine: Triage bot could ping based on subsystem / maintainer matrix? Or is the bot too restricted? Alex: Think could be hacked, but needs work, basically “write your own tool” is as complex
  • Karl: How managed ACK-counting-wise? Maribu: Subsystem maintainer review can be fast, often based on title and PR description alone.
  • Koen: happens naturally now, it’d just be more official. Kaspar: But if you don’t watch closely things can slip through. Formalizing subsystems would help b/c someone has vision and can direct.
  • Oleg: Sequence things to not waste reviews on things rejected on conceptual level? How do we get good responsivity?
  • Kaspar: Even if it gets a bit slower, it’d be an improvement unless we’re driving-people-away unresponsive. ?: A flag, not an ACK. Oleg: Or a NACK. Maribu: Implicit ACK if no NACK? Kaspar: No, rather escalate. Maribu: Myself, I react (based on codeowners) on things that disturb me.
  • Kaspar: A flag that has to be set to be merged would be easy to implement.
  • Benpicco: Is it a problem that controversial stuff gets merged too soon?
  • Kaspar: Makes stalls more explicit, and makes better procedure for decisions.
  • Alex: How to promote sub-system maintainers? How to coordinate between subsystems?
  • Kaspar: VMA could promote them? Coordination could happen naturally. Let’s go the first step and let’s figure the details out by doing
  • Oleg: Yes let’s give it a try. Worried about responsiveness issue
  • Oleg: Another problem: People might think of them as sub-system maintainers, but are not seen as such by others. Maybe making it official might help.
  • Oleg: Postpone final decision to breakout session.

Open Discussion

  • Kirk: OpenCollective
    • Would need 2-3 approvers e.g. on forum. Much easier than university finance systems. Take small fees but way less than university overheads.
    • Kaspar: Started years ago but got nowhere, maybe start over after people turnover. (NVM, different stuff)
  • Oleg: AOB? No