Minutes 22 Aug 2024

Host: Paul Albertella

Participants: Pete Brink, Igor Stoppa, Olivier Charrier, Gabriele Paoloni

Agenda:

• Conclude Quality discussion from TSC meeting [1]

• Where to put 'Open Source Good Practice' initiative? [2]

• Publishing documents from OSEP using GitHub Pages [3]

• Review status of PRs [4]

Discussion

NOTE: No meeting next week (29th Aug)

Quality discussion form TSC

Pete: Quality comes from a few different things

• What are we trying to deliver?
• How do we know that we have delivered it?
  • How can I show that my process for delivering it was followed?
  • How can I identify problems with the process, and improve it?

Igor: Why are we talking about quality?

• To establish a basis for arguing that FOSS can be used in safety
• Some level of quality management is needed as a basis
• But, the quality criteria are important for a given project may not be the set of criteria that are important for us as a user (integrator) of an open source project’s outputs

Olivier: Integrating components with different quality levels / criteria, which may or may not match my quality criteria, requires us to understand what are the quality processes and criteria applied by each of the components

Paul: A goal might be to identify a set of processes and criteria (at a high level) that FOSS projects can apply, with examples of how they are applied to FOSS projects (and FOSS workflows).

Pete: Common mistake with code-centric projects; focus on what the code does, rather than what it is intended to do, and how it is intended to be used.

• If it’s not obvious how to use something, that suggests that its design is poor
• This commonly applies to commercial software (and other things) too!

Olivier: When software evolves like Linux, the ‘traditional’ requirements-driven approach doesn’t work, but a ‘design contract’ concept can work: retrospectively describe what existing software is intended to do and what is important, what aspects should be either fixed or only changed in a coordinated / managed way.

Gab: If we can suggest a framework that we can apply to Linux, and convince the kernel community that it is useful, this might help

Igor: Usually start with a goal, or a particular problem or application, rather than a set of structured criteria. Could this be a starting point: evidence that shows how such goals are achieved?

Paul: There are aspects of the intended behaviour of the software that are not captured in the code, that can usefully be provided alongside the code to help other users of it. Can be provided by good documentation, but not always possible to know whether the docs accurately reflect the current state of the code.

Olivier: The wider world wanting to use Linux are looking to ELISA to fill this kind of gap. Can we add e.g. requirements or API contracts or test criteria that can help with this. But we should not expect Linux developers to always care about this

• Defining integration and functional contracts can help with this
• Also safety contracts: what failure could occur and how might we detect or mitigate these?

Pete: This is architecture

Paul: Standards are mostly written with the idea that software can be fully specified, but this is no longer a realistic expectation

• ‘Completeness’ is a distant goal for systems beyond a certain level complexity
• What is important is to capture what we have considered and verified

Gab: Need to think about what quality criteria are considered and applied already, and what we can apply, or need to encourage the FOSS originator to apply

• Have the possibility of verifying Linux against its specified behaviour as expressed by man pages and the API

Igor: Tools like checkpatch and sparse are applying quality criteria as a code-first level

Igor: Is English the only ‘correct’ language to write the requirements? Could we not write the requirements / the specification in C?