Notes: Virtual Maintainer Assembly (VMA) 2024.02

Community
,
1

Here are the notes:

2024.02 VMA

Date: 2024-02-21
Time: 10:00 CET
Moderator: Martine
Venue: Jitsi Meet
VMA forum entry: https://forum.riot-os.org/t/virtual-maintainer-assembly-vma-2024-02/4099
Previous VMA pad: 2023.11 VMA - HedgeDoc
Previous VMA forum entry: Notes: Virtual Maintainer Assembly (VMA) 2023.11

Attendees (TBD)

  • Benjamin (left early)
  • Christian (joined before feature.yaml discussions)
  • Koen
  • Bennet
  • Karl
  • Kaspar (left after coffee break)
  • Kevin
  • Leandro
  • Marian
  • Martine
  • Mikolai

Note taking: Mikolai

Agenda

  • Agenda Bashing - 1min (Martine)
  • VMA 2024.05 Moderation - 2min (Martine)
  • 2024.01 Release debrief from Release Manager - 5min (Kevin)
  • Outlook on upcoming 2024.04 Release - 5min (Teufelchen and Marian)
  • Discussion of Release Manager Selection Process - 10min (Martine)
  • Release 2024.07 Release Manager - 5min (Martine)
  • Twitter/X freeze - 5min (Emmanuel)
  • Release Branch: CI Breakage - 3 min (Marian)
  • Improving onboarding experience - 5min (Marian)
  • Coffee Break - 5min (Everyone)
  • Roadmap - 10min (Koen)
  • Channel for Community Decisions and Fundamental Discussions - 15min (Martine)
  • Kconfig removal - remaining cleanup & next steps - 15min (Ben)

Notes

Agenda Bashing - 1min (Martine)

  • No changes

VMA 2024.05 Moderation - 2min (Martine)

  • Kevin will do it

2024.01 Release debrief from Release Manager - 5min (Kevin)

  • easier than the previous
  • infrastructure issues
  • improve robustness of tests (e.g. non-M3 boards had no proper error handling - random node selection for retries)
  • some work to do on automating Zephyr interop test

Outlook on upcoming 2024.04 Release - 5min (Teufelchen and Marian)

Goals:

  1. Reducing the back-log:
    • Getting old PRs merged / closed (b/c the use case has been addressed in the meantime)
    • Fixing old issue
    • Current State:
      • ~40 open drafts
      • ~330 open PRs
    • Goal for the release: <300 open PRs
  2. Improving the on-boarding experience
    • See separate agenda item
    • Improvments for “Getting Started” in regard to Host OS, e.g. Zephyr
  3. Getting the Home Assistant guys on board
  • Kaspar: good to have goals, but a lot of effort?
  • Teufelchen: just wanted have measurables results

Discussion of Release (Manager Selection) Process - 10min (Martine)

  • Martine:
  • Kevin: current process doesn’t account for new maintainers (normalize over amount of time you’ve been a maintainer)
    • Martine: most maintainers have one release anyway
  • maribu: option to reduce frequency of releases
    • Kaspar: but releases makes us focus on testing
    • Martine: there are weekly tests, but only Martine gets notified
    • Mikolai: someone needs to feel responsible for fixing tests without release
    • Martine: actually one is failing right now (TTN client API broken after Paho update)
  • Kaspar: a lot of work can be delegated, so release management doesn’t have to be too much work. Also release management doesn’t mean “fix all open issues”, just running tests and breakage documenting as “known issue” is acceptable.
  • conclusion: let’s keep everything as is for now

Release 2024.07 Release manager - 5min (Martine)

  • Nobody stepping forward, Mikolai is selected by the script
  • Mikolai asks for assistance: Kevin and Marian step forward

Twitter/X freeze - 5min (Emmanuel)

  • do we want to freeze our account, last post referring to other social media accounts (Mastodon, Bluesky)
  • Kevin: good people leaving increase hell hole
  • Martine: you don’t have to stay in a bad place just to make it better. Not our job

Coffee break - 5 min

Release Branch: CI Breakage - 3 min (Marian)

  • CI-workers (murdock) do not pin docker containers to run on the release branch
    • a long overdue RISC-V toolchain upgrade incompatible with the obsolete tool chain used before broke CI on the release branch
    • two PRs fix the issue, need to be backported in tandem to fix the issue
  • Independently: Since PR 20269 tests on native are not re-run on failure up to three times
    • It currently is a huge pain in the ass to get all the flaky native tests passing for both GNU and LLVM toolchains on the first try
  • So: Backport both fixed and all PRs disabling flaky tests in a signle run, or both fixes and revert PR 20269 in the release branch?
    • no expert veto on first option
  • short-term: fix, long-term: pin murdock containers (currently not possible)
    • Martine: is it possible with docker at all? Containers need to exist in at least two versions: Release and master.
    • maribu: I think so
  • Kevin: just re-run flaky tests until they all succeed?
    • maribu: a lot of them fail

Improving Onboarding Experience - 5 min (Marian)

  • Martine: README + website first info, first page in doc should be README
  • maribu: README and website same content?
  • Martine: no, different target audiences - website for higher-level/community/etc., README for technical getting started
  • maribu: point doxygen to README.md as first page in doc.riot-os.org
  • Koen: README very concise / tight getting started, emphasize on easy start; doc startpage with more info
  • maribu: “quickest start” in doc will be dropped in favor of README
  • decision by lack of expert veto

Roadmap - 10 min (Koen)

  • Recap of what is now on the Roadmap
    • Old maintainers still on a number of subjects (Peter, Hauke)
  • Martine suggests Jose for lower layer network - Jose [offline] declined
  • JĂĽrgen(?) was suggested for power modes ? - already asked, no response
  • power modes: benpicco
  • periph drivers: maribu
  • maribu opens PR to change it
  • Add Home-assistant integration? ACK, Koen is doing a PR
  • 6LBR as goal. ACK

Channel for Community Decisions and Fundamental Discussions - 15min (Martine)

  • Martine: many discussions take place in Matrix channel nowadays, but it’s hard to link to and hard to follow, proposal to have important discussions in forum
  • Teufelchen: wiki discussion was minor, not sure what else is meant
  • Teufelchen: nobody reacts in forum
  • maribu: no issue with decisions made in Matrix, as long as they are documented / summarized afterwards somewhere else
  • Martine: but discussion is part of decision making
  • maribu: already standard to document decisions in follow-up PRs (always expected anyway)
  • Martine: then it’s probably a non-issue
  • Martine: be aware of preexisting processes and do not contradict them (example: VMA poll vs friday meeting)
  • Martine: state of rough consensus as decision making process?
    • Koen: just confused from the way it was done today (looking for “no expert veto”), much less fighting today
  • Mikolai: lack of responsiveness in forum, especially for new
  • Martine: mailinglist was more active from community side, forum now has more questions from the outside
  • maribu: at least we get questions in the forum
  • Martine: lets get community activeness from mailinglist into forum
  • Koen volunteers to take care of new forum posts, and to delegate for answers

Kconfig removal - remaining cleanup & next steps - 15min (Ben)

Ben’s notes:

  • Kconfig dependency modeling is now disabled - what can be removed?
  • Should we drop all Kconfig?
    • currently provided as opt-in for menuconfig for select modules
    • there is no pain in keeping it, but it will bit-rot away (no tests)
  • features.yaml
    • Are we OK with a custom (machine and human readable) format?
      • Background: Generation of doc from a Makefile with Doxygen results in ugly doc and lots of boilerplate
    • If not dropping all of Kconfig: Dropping duplication to features.yaml? When?

Kconfig configuration modelling

  • [Ben and Kaspar left the meeting earlier]
  • Kevin: we can start removing dependency modeling, keep configuration parts - when we talked about removing Kconfig dependency modeling, we never talked about removing all of Kconfig, Kconfig is good for configuration (thats what its made for), example: clock tree with nested defines
  • Martine: whole reason for starting with Kconfig dep modeling was hoping to get rid of flaky builds
  • Kevin: config not flaky in itself, but hard to grasp what can be configured
  • Leandro: configuration documentation generated from Kconfig (thats how it all started), Zephyr as example: Kconfig Search — Zephyr Project Documentation
    • wouldn’t make sense to drop all the work that has been put into configuration part
  • Martine: kconfig variables can be set via CLI by prepending RIOT_CONFIG_ and use that as an environment variable
  • maribu: strong opinion, we don’t use it
  • Martine, Kevin, Leandro: all using this
  • Leandro: Kconfig is not default for anything except tests, back then decision to not bother anyone
  • Martine: if we want …
  • Leandro: we should …
  • Kevin: to clarify: some configuration in headerfile, some in Kconfig - by removing from headerfile, we don’t have bitrot, but we loose automatic doxygen documentation
    • maribu: trick to have #ifdef DOXYGEN for documentation
    • Leandro: first step, makes sense, but much more information from Kconfig - we should include that information in doc in long term
  • maribu: agreement on use it or loose it
    • Leandro: what means “use it”
    • maribu: it should be default way of configuring things
  • conclusion: use it or loose it, Kevin will make sure we can use it as defaults
    • Main people that might have been against it left early, please voice your opinion in the forum under the notes!
  • chrysn (in chat): +1 on “use it or lose it” (whatever is the ground truth, it should be used in default builds)

features.yaml / saving dependency modelling efforts we like to keep

  • Kevin: is it really good idea to have custom format for feature documentation? - grouping can also be done there with menuconfig
  • maribu: but features part of dep modeling, so will be removed?
  • Kevin: its just documentation, could be used
  • maribu: we could use Kconfig as long as it is single source of truth, machine-readable
  • Leandro: […]
  • maribu: asks chrysn whether features.yaml was easier to use than Kconfig
  • chrysn: was easy because using python scrip from maribu, if there were tooling/parsing for Kconfig already, would be same effort
  • chrysn: yaml maybe personally more straightforward to extend, but maybe just lack of experience with kconfig (example for information to be added: meta-info such as coloring or logo of features, maybe easier in yaml, but we would probably manage in kconfig too)
    • karl: would that be possible in kconfig?
    • Leandro: abuse description or extend kconfiglib to have “custom information”
    • Martine: configuration + extra meta-information should maybe anyway separated, pointer with identifier
      • chrysn: would work for me
      • karl: documentation is also meta-information, if we have custom information inside Kconfig files wouldn’t work with other kconfig tooling
      • Leandro: it would, description is free-text, can even be yaml
      • Martine: Documentation should be kept with code, meta-information maybe not so much
      • Karl: same could be argued for documentation…
  • maribu: summary - yaml has easy syntax, easy parsing - kconfig doesn’t and it is unclear whether we can express everything we want
  • karl: voting for more flexible format (yaml)
  • Martine: sounds like two different things in one?
  • karl: kconfig sounds like two things: docs + dep modeling, chrysn is example that yaml was easier to work with
  • maribu: what we want: 1) documentation of features and 2) testing features provided and requested against known features. The info (mostly) exists partially in kconfig (but no grouping (kevin: grouping possible, but currently not done)), argument: kconfig information hasn’t been used for a year or so, presumeably because yaml much easier to parse
  • chrysn: yes, yaml is easier to use, but big feature was the existing python script, if kconfig script had been around, same effort
  • maribu: Info was in Kconfig, but not made into documentation for a year. So maybe pain in the ass for maintainers?
  • Leandro: dangerous to speak for all maintainers when talking mostly about themself, okay if features are not in kconfig since dep modelling is dropped
  • maribu: there was agreement during VMA 2023.11 on dropping “this”
  • Martine: there seem to be disagreement on what we agreed there (see config part), maybe discussion was not clear in VMA 2023.11?
  • Leandro: no discussion about documentation of features
  • maribu: yes, there was, we agreed on salvaging what is worth for documentation
  • maribu: why kconfig instead of yaml/json/toml/whatever? emotional attachement? would like to understand
  • Kevin: it was in there, can we use it?
  • maribu: yaml is there, ready to merge
  • Kevin: yaml is custom schema, not standardized as kconfig, but I won’t block
  • Kevin: there are no blockers for features.yaml
  • Leandro: cheap to have schema for yaml
  • conclusion: go ahead with features.yaml but have matching schema
  • chrysn volunteers to help with schema
3 Likes
2

Thanks for sharing the notes here!

I like to join on this one. Have already gathered a lot of information about onboarding experiences from newcomers by the conversations I have had about RIOT learning solutions. I will reply on the GitHub issue about this. @maribu maybe we can call somewhere in the coming times about what we have both found out so far?

3

Sure! :slight_smile:

4

I’ve made a tweet with the following content

Miss us? You can still find us on https://fosstodon.org/@RIOT_OS and https://bsky.app/profile/riot-os.org.

and pinned that to our profile there.

`

Miss us? You can still find us on https://t.co/pvjv6mr8fN and https://t.co/NHJ772b1ql.

— RIOT (@RIOT_OS) February 23, 2024

`

1 Like