Aug 26, 2024 ‐ 15:00 UTC

Host:

• Philipp Ahmann

Participants:

• Alfred Strauch
• Steven Carbno
• Gabriele Paoloni
• Walt Miner
• Nicole Pappler (2nd half)

Regrets:

• Sebastian Hetze

Attended Recently

• Karen Bennet

• Daniel Weingaertner

• Axel

• Kate Stewart

• Olivier Charrier

• Thomas Mittelstädt

• Andreas Bartelt

• Guy Lunardi

• Stewart Hildebrand

Topics & Notes:

Check past action items

• ...

Project Proposal: Good Quality Practices in Open Source [cont.]

• Draft
• Conclusion from previous meeting: Bring the "objective of proposal" forward so that it can form a base for "whatever kind of funding/financing".
• Related paper: Open source software development process: A systematic review
• Kept from last meeting:
  • What are quality practices and what is quality? How is the relationship between safety and quality?
  • Can it be easier to say what is insufficient? This may be far easier to say: If you don't meet this threshold it is clearly insufficient.
  • Karen may be able to share some references for papers also handling the topic.
• Last week discussion in TSC meeting and OSEP Meeting
  • Minutes from TSC meeting: https://github.com/elisa-tech/tsc/wiki/21-Aug-2024
  • Minutes from OSEP: https://github.com/elisa-tech/wg-osep/wiki/Minutes-22-Aug-2024
    • Definition about Quality from IEEE computer society: https://www.computer.org/resources/what-is-software-quality
    • Software need to behave as defined
  • Due to parallel work streams there is a strong risk in double work and missing alignment between WGs.
    • Currently work is properly split with the Proposal for research funding and first documentation of existing processes in the Systems WG and with discussions on definition of quality in the OSEP WG.
    • Clear alignment also needed within TSC.
    • AI-Philipp: Add alignment and work split about Open Source Good Practices to the TSC meeting agenda (Sep 4th)
• We might need to consider assumptions towards quality.
  • Cluster the assumptions towards architecture, protocols, structures, etc.
  • Assumptions may be derived based on the collection of data available (e.g. from Linux Kernel, IEEE activities)
    • The Linux Kernel as an example has no requirements, but only a specification.
    • Argumentation/Assumption in this case could be that the integrator needs to write requirements.
    • This assumption need to be validated as a valid gap and as the right approach.
  • Come from the base on how the kernel code evolves, identify gaps and create a map with responsibilities (ELISA, Kernel, Integrator, ...)
    • For best options and decisions proper understanding is needed in order to make assumptions.
    • Things which have been done in the past, are done now and will be done in the future are not necessarily the same.
• Remark: Started a WIP/RFC PR to allow commenting and proposal by WG members: https://github.com/elisa-tech/wg-systems/pull/16/
• The standard talks about Open Source, but mainly speaks about Software, but there is also open Hardware
  • Systematic behaviour is similar to software.
  • Mechanisms implemented to be fault tolerant (random HW failures) is not available in software -> Difference!
  • There is a clause about mass production for HW in ISO26262 -> Claim for systematic probabilities (a bit different to proven in use)
  • Starting point is SW development (e.g. in Kernel as very mature project) and try to abstract from there and based on this tell what to apply to hardware.
  • Open hardware is just kicking off and is still growing. The level of maturity is unclear.

AoB

• meta-elisa CI is failing currently. It runs on 14.0.5 and we should at least switch to 17.1.1 (LTS version)