Minutes 09 01 2025

Host: Paul Albertella

Participants: Pete Brink, Igor Stoppa, Florian Wuehr, Sebastian Hetze, Gab Paoloni, Daniel Krippner, Daniel Weingaertner

Agenda

Goals for this year

• Sebastian: Start a Rail WG in ELISA
• Pete: Publish evaluation criteria for published docs
  • Igor: Build on existing criteria? e.g. ACM
  • Pete: Yes, but criteria may be different to e.g. research papers
  • Is the content academic or practical / commercially applicable
  • Provide evidence
• Paul: Publish Igor’s documents
  • Incorporating the input and crediting the originators
• Gab: Arch group plan to produce docs for the tracing subsystem
  • Not feasible to document every design element
  • No pre-defined process for reverse engineering this
    • PAS only enables to to classify pre-existing components
  • Integration context may define the requirements, but this is from the perspective of a Linux subsystem - aiming to help an integrator to correlate with their particular context
  • Pete: Like a SEooC?
  • Paul: Yes, but with a different intent: helping integrators to define their specific context and requirements, rather than making a safety claim with constraints and assumptions of use
  • Igor: And not with (only) safety in mind! Functional requirements!
  • Pete: Should we look at some other (no-safety) standards describing common software engineering processes and best practices (ASPICE, etc)
  • Daniel K: Starting to do this in Eclipse SDV
    • Article here
    • Mapping open source best practices to this kind of standard
  • Gab: Challenge is that existing standards are written with commercial software or software developed from scratch
    • Daniel K: This is why what SCORE is doing may not help with this: guidance for FOSS projects developing from scratch, but not advising how to apply to existing projects
• Daniel K: Would it be useful to describe how different responsibilities can be assigned amongst a supply chain involving open source software?
  • Sebastian: SPDX thinking about how to record this
  • Daniel K: Would be happy to help write something like this
• Igor: If we create documentation based on the code, how do we keep it aligned with the code when it changes?
  • What is the value-add of this kind of documentation (requirements)
  • Can we define this for the tracing subsystem?
  • Daniel K: Achieving an iterative ‘requirements’ process would be valuable