Minutes 05 Sep 2024

Host: Paul Albertella

Participants: Peter Brink, Sebastian Hetze, Vivith Parlattaya, Florian Wuehr

Agenda:

• Conclude Quality discussion from last time
• Update on publishing documents from OSEP using GitHub Pages
• Review status of PRs

Discussion

Pete: TSC yesterday included a rehash of the discussions here about Quality

• Product-focussed definitions of software quality are well-established, but they don’t necessarily map to FOSS, because it is not always developed in the context of a product
• Might need to decouple some of the ideas associated with quality (processes, requirements) from a product focus in order for this to be useful or practical in a FOSS project

Paul: Challenge is that Linux (and other FOSS) does not have a consistent and systematic process for describing its intended behaviour and properties, and verifying that these are achieved.

Igor: If there was a way that a Linux user could reliably determine whether an observed behaviour is a bug or a feature that would be very helpful, but the kernel is so vast (and its behaviour potentially implementation- or context-specific) that this is a huge challenge

Tests (e.g. those run by KernelCI) might be a way to manage and extend this, provided that these tests could be linked back to documentation (a specification) that users can use to understand this

Igor: Quality is not a one-off: there is an ongoing cost of maintaining quality

As a minimum is that you define what your quality criteria are

Gab: Could perhaps interview the people involved in kernel testing and maintenance and ask them what criteria they apply and what tests they run

Paul: Sure, and then document these and check whether they are applied for a given release. And then we can also apply these for our use of the kernel.

Paul: How can we turn these discussions into something that other people can engage with and build on?

Igor: Take a concrete example with a technical reference and illustrate how the abstract ideas might apply to it.

Gab: Look at Kernel CI examples or talk to a subsystem maintainer

Igor: Who would we be trying to target? Safety people, Linux developers ?

Paul: Perhaps need a number of different entry points for different audiences revolving around a common example

• e.g. a given syscall, a given use case

Sebastian: Have we strayed away from the original topic?

• Open Source Good Practice proposal
• Have finalised a first version of the proposal to discuss with other interested parties and as the basis for a funding application
• Needs more time than we can devote to the topic on a weekly call
• Being progressed by the Linux Foundation, may involve others

Paul: Of interest for OSEP to see where it leads, but not clear how / if we can contribute?

Vision is to have a paper that is accepted by a wider community as an ‘official’ description of what quality practices are considered ‘good’ for FOSS, which can be referenced alongside ISO standards, V-model, methods etc in support of certification