Feb 24, 2025 ‐ 16:00 UTC - elisa-tech/wg-systems GitHub Wiki

Host:

  • Philipp Ahmann

Participants:

  • Patrick Uven
  • Nicole Pappler
  • Rinat Shagisultanov
  • Kate Stewart
  • Troy Sabin
  • Daniel Weingaertner
  • Sebastian Hetze (2nd half)
  • Karen Bennet (2nd half)

Regrets:

  • ...

Attended Recently

  • Leonardo Rossetti
  • Gabriele Paoloni
  • Walt Miner
  • Steven Carbno
  • Roberto Paccapeli
  • Alfred Strauch
  • Thomas Mittelstädt
  • Stewart Hildebrand
  • Olivier Charrier

Topics & Notes:

Check past action items

  • Previous meeting notes: https://github.com/elisa-tech/wg-systems/wiki/Nov-25,-2024-%E2%80%90-16:00-UTC
  • Removed some items from AIs as no further follow up for now.
  • AI-Sebastian: Involvement of DIN can also be interesting. Sebastian will take a first contact.
    • Communication started. Another meeting scheduled in Feb.
  • AI-Philipp: Response to new Railway WG idea from Sebastian.
    • Mail dropped to interested participants. Invited to TSC.
    • Create a meeting poll.
    • Sebastian created a first draft, but someone from railway should propose it.
    • Some may attend TSC on Wednesday.
  • AI-Philipp: Add architecture picture to Systems-WG repo for better clarity.

Standards Atlas

Continuous compliance on GitHub

  • Story line could be: 1st Zephyr -> 2nd Linux -> 3rd Zephyr+Linux (as a systems argument)
  • Project funded by ARM to come to continuous compliance.
  • Change impact analysis with SBOMs as source including traceability to testing.
  • Different types of tests (unit, integration, ...) link to requirements.
    • Tests could also be manual tests with instructions, but automated wherever possible.
  • SBOM metadata and elements needed by SPDX safety profile.
  • BASIL as tool also in mind.
  • Overall: SBOM v1 vs. SBOM v2 and based on delta, tools should output which compliance checks are needed. E.g. requirements, test cases, etc.
    • This is a feedback to the developer, who can work on the base of the SBOM diff.
  • Continuous Compliance QA engineer to act faster on changes to be compliant to the standard
  • All with Open Source Toolchain.
  • Executive Summary to be prepared based on SoW.
  • Use standard GitHub tools.
  • Publishing PoC results once getting more stable to have them as OSS.
  • Maintenance & Support after release is not discussed yet.
  • Some further updates next week. (as some things still need to be sorted out)

Good Quality Practices in Open Source [cont.]

AoB