Oleg:
Kaspar:
Oleg:
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:
Hauke:
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 ;-)
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.
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!
-
Any changes
Be notified of any changes
-
Mention me
Be notified of mention me
-
Unsubscribe
Subscribe