Skip to content

VMA 2019.11 minutes

Emmanuel Baccelli edited this page Feb 20, 2020 · 1 revision

RIOT VMA 2019.11

Attendees:

José Leandro Kevin Emmanuel Francisco Martine Hauke Vincent Marian Peter Ben Robert Ken Koen Cenk Sebastian Alex Michel Matthias Thomas

Agenda:

  1. Debrief 2019.10 release
  2. Quick word from 2020.01 release manager
  3. Release Manager 2020.04?
  4. Next virtual assembly meeting(s) ?
  5. Compile Time Configurations roadmap
  6. NetIf rework
  7. What do we do about inactive maintainers?
  8. Debrief RIOT Summit 2019
  9. Conceptual/architectural integrity

Notes

Debrief 2019.10 release

Quick word from 2020.01 release manager

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

Release Manager 2020.04?

- 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)

Next virtual assembly meeting

- 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

Compile Time Configurations Roadmap

- 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.

NetIf rework

- 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.

What do we do about inactive maintainers?

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

Debrief RIOT Summit 2019

  • 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

Conceptual/architectural integrity

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

Clone this wiki locally