Skip to content

Minutes 25 Jul 2024

Jump to bottom
Paul Albertella edited this page Jul 25, 2024 · 1 revision

Host: Paul Albertella

Participants: Pete Brink, Florian Wuehr, Daniel Weingaertner, Mikel Akarate, Vivith Parlattaya, Sebastian Hetze

Agenda:

Discussion

Note: Paul will be away on vacation next week and the week after, so next meeting after this one will be 15th August

Daniel: Some strong statements in the PRs that might discourage people from using Linux

Pete: Yes, there are some fundamental issue with the way that Linux is organised raise some concerns from a safety critical perspective

  • If there were an execution fault in the kernel itself we have no protections

Paul: The framing of the problem could be different - less discouraging

Daniel: Have not finished reviewing all of the PRs, but a lot of potentially valuable information

Vivith: AGL are targeting ADAS. Is there any collaboration between ELISA and AGL? Can we learn from the approach they are taking?

  • Action: Raise this at the TSC

Paul: ‘First Principles’ might be better as way to navigate and digest the deeper and more detailed content

Pete: Need to understand why the statement is being made

Daniel: Not clear whether some of the problems are solvable from just the one-liners

  • Go over the reasons and technical details first, and then summarise and point to possible solutions

List the ‘known challenges / risks’ and the background material to enable you to understand them fully, so that you can then understand their relevance in your particular design / integration. The ‘one-liner’ should point to a bigger explanation.

Daniel: Not returning to the ‘one-liners’ until I have digested the detailed texts

One thing missing in the texts is inline / in-context references to the sources of technical reference material.

Pointers to this material could be added in the PR (or later) by someone (else) who is knowledgeable about the kernel

How we organise the documents themselves is a topic to consider e.g. we could adopt the same approach to the kernel community and use RST / ReadTheDocs to build and structure

Call to action for people to contribute the technical links in the supporting documentation.

Daniel: The organisation of the text is also not amenable to adding references. Might be better to think about a different way to build the documents such that we can e.g. add links to footnotes, or references.

Paul: Action to think about a way to build docs based on markdown

Sebastian: Open Source Good Practice document being worked on in an initiative that was suggested in hallway discussions at the Lund workshop

  • Equivalent of the V-model or similar, but describing the ‘modern’ techniques in common usage by FOSS projects
  • Hoping to turn this into a more concrete project, and secure funding from e.g. EU Horizon
  • Currently drafting a proposal

Pete: Happy to review the paper / proposal

Daniel: Also need to get some companies / organisations interested in demonstrating that the ‘good quality’ practises actually lead to valuable outcomes

Sebastian: Identify which practise lead to good outcomes

  • i.e. Not “open source in general is good”, but “these practises lead to good outcomes if they are applied in this way”
  • Describe the techniques that FOSS use and argue why they are good

Pete: Start with a definition of what quality is, then think about how to achieve that

  • Key goal: minimise systematic errors
  • CMMI is a way of thinking about this on a grander scale

Pete: A list of ‘high quality’ OS projects would be useful - e.g. have heard that Xen some good

Sebastian: Also SAMBA

Daniel: Also look at the software we would like to use and consider what is good about their practices and what needs complementary processes to address gaps

Vivith: Also are there quality open source tools?

Sebastian: Focus of this is on quality rather than safety - wider set of possible contributors and organisations that may be interested

  • Quality is a baseline for both safety and security
Clone this wiki locally