VMA 2019.11 minutes
José Leandro Kevin Emmanuel Francisco Martine Hauke Vincent Marian Peter Ben Robert Ken Koen Cenk Sebastian Alex Michel Matthias Thomas
- Debrief 2019.10 release
- Quick word from 2020.01 release manager
- Release Manager 2020.04?
- Next virtual assembly meeting(s) ?
- Compile Time Configurations roadmap
- NetIf rework
- What do we do about inactive maintainers?
- Debrief RIOT Summit 2019
- Conceptual/architectural integrity
- Ken debriefs the 2019.10 release: https://github.com/RIOT-OS/RIOT/wiki/Debrief-for-2019.10
- Ken: release managing was ~80 hours of work ;)
see https://pad.inria.fr/p/np_yDlc5tycHUjOs31U
- Francisco:
- Will try to improve of the release process
- Coverage of tested boards planned to increased
- Improve publish & visualize of release results
- Proposed dates: Soft freeze: 08.01.20, hard freeze: 15.01.20
- VMA good place to announce ?
- Martine: Would be the next default candidate, but asks for (external?) volunteers
- Leandro: If no other volunteer, he offers to manage 2020.04 release
- Ken: maybe unicast some people? (like I was Emmanuel nudged me for 2019.10 ;)
- smlng proposes to do a long-term decision on github (issue in Release-Specs Repo)
- Emmanuel: How often should we meet?
- smlng suggest every once after a release
- +1 (Marian)
- +1 (Martine)
- +1 (José)
- +1 (Kevin)
- +1 (Leandro)
- +1 (Koen)
- How do we handle organization of this virtual maintainers assembly meeting?
- Oleg proposes to pick one responsible person for the next VMA at the end of previous VMA
- Oleg steps forward to volunteer to organize the 2020.02 VMA
- During TOP8 we decided to use a different tool or different Jitsi server next time
- Leandro presents a quick wrap-up and points to mails to devel and Github for detailed informations
- Leandro asks if we can agree on the proposed approach
- Open for discussion? How do we actually "enforce" the migration?
- Emmanuel: is phase 1 invasive? Or is it optional wrt to the current system?
Leandro: phase 1 is not invasive, but probably later phases.
- Hauke: is there some performance analysis needed first, before we decide/plan on (later) phases?
- Hauke is extreeemly sceptical about this approach and points out open quesions
- Performance analysis?
- Compare it to Laze and the current approach
- José: kconfig is not a build system but rather configuration tool. Don't compare apples with pears
- Hauke: Kconfig has (known?) drawbacks in terms of performance
- Oleg is confused: Are we talking about two separate tools for configuration and build system or about an entangled solution of both? In first case, he wouldn't mind so much about the performance concerns.
(+3 for this from rendez-vous chat, +1 from Marian)
- Matthias: I don't understand the discussion. the tool itself doesn't introduce overhead. as soon as the dependencies are modelled, the build process will be faster.
- Ken: Has anyone talked to Zephyr guys about scaling issues?
- Leandro: Has talked to some people. Their experience was good, that's all he knows.
Local consensus: showcase the first phase (non-invasive), and then reassess impact before moving to next phases.
- Motivation for this work: https://github.com/RIOT-OS/RIOT/issues/12688
- Robert (in rendez-vous chat):at85rf215 driver which is currently under review by myself (https://github.com/RIOT-OS/RIOT/pull/12128) has two PHYs on a single SPI interface, with a single interrupt. Just wanted to draw attention to this specific architecture.
- José: I'll check that. But this should be a requirement for the rework, but some things are not yet designed.
- +1 from Hauke, smlg, Marian; ACK from Robert
- Peter asks for strong objections, no one spoke up
- Jose: Current irq handling issue is blocking <issue no> TODO
- Jose: Also, netbuf PR is required to continue: https://github.com/RIOT-OS/RIOT/pull/12691
-> need to focus in order to proceed. Jose asks for participation
- Hauke: how about a rough prototype (API, pseudo code ?) to gauge where this would be going, and get a feel?
- +1 from Robert, Marian, Koen, Ben
- Jose: There are multiple prototypes and snippets. There are also architecture diagrams. Will put things in order so show off ride away
Local consensus: base next step of discussion on a rough prototype.
Martine: there a lot of "alumni" amongst the maintainer who are completely inactive since a long time. Alex: mimic process from stalebot? Oleg: what's the problem with current procedure? - Martine: in practice, only proactive decommissioning initiated by the maintainer him/herself.. Kevin: no big deal? Let's just email the people Emmanuel: yes but noone does that in practice... Kevin: I volunteer to write the dangling maintainers (every christmas) Cenk on chat: sync GitHub Team "Maintainers" with maintainers@ mailing list
-
Maintainability
Efficiency
Observation: different perspectives
Potential action: align our goals
Scope and focus
Potential action: define the scope
Potential action: manage different focus (academia/research vs. industry)
Modularity (third-party integration)
Question: re-evaluate splitting(?)
Potential action: encourage external repositories (e.g., for boards)
Potential action: automatic testing
-
Reducing PR inertia
Bus factor
spread the knowledge
Quality gates (defining a DoD?)
Question: at which point is anything "good enough"?
Review process
increase test transparency
avoid "works on my machine"
wide spread review/testing for critical code
Potential action: better distribute release testing
-
Policy on merging security features
always ensure proper testing for crypto
security (maturity) tags
datasheet repository
fuzz-testing
Kevin: positive improvements lately from my improvement - testing coverage is increased (in part thanks to Gaetan and Francisco) - release management is improved -
Ken: positive impact and use of review flags - Kevin: yup, but they are not mandatory if a single person reviews all aspects, it's more to facilitate collborative reviewing
- Kevin: feels PR inertia is somewhat decreased since the summit
Kevin: Bus factor is still an issue
- More pair programming? Francisco: it is some overhead, but worth it in the long term
see draft https://pad.inria.fr/p/np_62vQXH4IGkMdFzTc
José: 1. why does this have to be a maintainers role and not developers?
- Jose: having a centralized boards seems unnatural
- Hauke: Stuff is being merged that is not aligned with "RIOT standards" or without the right context
José: 2. Is a subsystem-maintainer approach sufficient?
- Hauke: not really. You need a really high level view.
- Jose has concerns regarding scalability
- Emmanuel: Having subsystem maintainers does not conflict with having "grey-haired architecture board", could complement nicely?
Oleg: I could imagine pairs of experienced + new contributors being very productive.
Emmanuel: Is there consensus that collaboration between newly active maintainer/contributors and longest experience maintainers is suboptimal lately? - people seemed to agree - Emmanuel: so should we explore ways to improve that, possibly adapting our workflow?
Consensus: continue discussion on this on the mailing list. Hauke launches thread.
Francisco: launch thread for feedback about this VMA on mailing list