Maintainer Assembly RIOT Summit 2019 Minutes

RIOT Summit 2019 Maintainer Assembly

• Date : 2019-09-07

• Pad link: https://pad.inria.fr/p/np_GUWjV5eYZWsy4MHR

• Meeting Stream: https://youtu.be/p4gY54N0SXE?t=14702

Uncomplete notes, (marks rough consensus)

Maintainability

• Many people think we are slow because we are inefficient

• What features do we want in RIOT?

  • No consensus or clarity on whether feature set should be restricted
  • For some focus should be Industry/state-of-the-art features for other no, for some this is not an issue

• Centralization vs modularization

  • Easier to have it all centralized as a user
  • Easier to modularize to leave every module progress at it’s on pace

• Make it easy to have external boards, applications, drivers, modules

  • Need to support outside of tree
  • Need to have board in friendly space but not master
  • There are still big technical difficulties that hinder this effort

Reducing PR inertia

• Improve bus factor

  • Don't replace trust with more procedure, find more ways to improve trust
  • Remove develop Branch, release more often. People will use development branch as master branch, master will
    stale
  • Look for good enough, not for perfect
    • MW: "good enough" as long as minimal quality is met
  • Since the focus is research/education, then the code is by nature not-perfect.
    • MW: we don't have consensus here. i would definitely argue that the software (or activties in general) contributed by FU and HAW do not focus on research. as a matter of fact, we are spending a lot of human resources on making the RIOT software basis production ready. other research institutes may have other motivations. obviously, code contributed by companies does not focus on resarch/education either.
    • EB: I agree with MW here, RIOT is not only used for research/education, but also in production. Quite some efforts we put into RIOT go beyond what's required for research/education.
  • Do not be paranoid of breaking something

• Review Process

  • Labels Helped somehow. Some of them might need some re-wording, or add some.
  • All PR's need to be properly documented and the testing procedure explicitly, specially for half solutions or hacks.
    This way if someone comes across the issue he will be more willing to fix.
  • State in the PR the reasoning for the contribution.
  • Everyone should document the reasoning behind his feature he did, if he didn't test, and force the contributor to put his test output in the PR. (not doing this angers a lot of contributors)
  • Don’t got for the last percent (speaking of tests, unit-tests)
  • Ask contributor to test on a different machine.
  • It's harder to fix a bug on bad code or old code but easier to introduce new things (possible bugs)
  • Merge self contained PR's even if unable to test, but make sure the contributor post proper test output.
  • Patches affecting many platforms need wide spread review and should have deeper testing.
  • Every maintainer should join Release testing

Policy on merging security features

• What happens when we need a security evaluation and we have no security expert?

  • Add a tag pointing out that it's not security tested/verified or other
  • Ask for SCVI blocks
  • Crypto should always be tested, easy to standardly unit-test
  • Tag as experimental as long as it not security evaluated
  • Don't block because there is no expert

• How to handle security issues

  • Non archived security mailing-list
  • Private repository with datasheet (Hauke)

• How to improve security

  • fuzz-testing (don't let other people do it)
  • keep pushing hiring or attracting security experts to the community