Skip to content

21 Aug 2024

Jump to bottom
Philipp Ahmann edited this page Aug 21, 2024 · 2 revisions

Roll call

* indicates TSC voting members

Host

  • *Philipp Ahmann

Attended this meeting

  • Olivier Charrier
  • Pete Brink
  • *Matt Kelly
  • *Matt Weber
  • *Alessandro Carminati
  • *Gabriele Paoloni
  • *Paul Albertella
  • *Kate Stewart

Regrets

  • *Christopher Temple

Attended recently in the past

  • *Lukas Bulwahn
  • Naresh Ravuri
  • Steve VanderLeest
  • *Sudip Mukherjee
  • Youssef Hajjioui
  • JE[A]Y
  • Vipul Gupta

Topics & Notes

Check past action items

Next workshop timing/location considerations

  • Survey to confirm availability is still open.
  • https://forms.gle/n2uphHagQa4wB4Ek8
  • Location is not set yet.
  • so far after first response December 10th to 12th fits most (... but the survey is still open)

Systems WG: Good Quality Practices in Open Source [cont.]

  • "Project proposal" to seek wider support is under refinement
  • Red Hat is looking for further formal commitment and start to approach universities.
  • Link to document
  • Related read to be checked: OPEN SOURCE SOFTWARE DEVELOPMENT PROCESS: A SYSTEMATIC REVIEW
  • Are there already other activities which are targeting the same or similar problem space?
    • We need to have a clear view on which efforts it takes and how it refers to other (upcoming) standards.
    • A literature research may be first step.
    • Set the terms and have the literature research first.
    • Have existing standards been applied to open source projects? -> We are not aware that they were.
  • (CHIBI OS is an example in open source following a quality management process)
  • A small project may be able to be reversed engineered to existing standards. But larger projects are typically code driven and not requirements driven.
  • CI/CD practises are applied to the code first projects which includes testing and are meant to improve the quality of the software.
  • A quality management system at first needs to define what quality means.
  • CI/CD typically is not only testing, but includes human reviews against implicit and enforced quality criteria.
  • What are these criteria, how they are applied and enforced and how can they be made coherent.
  • Come up with guidelines which help the user/consumer and the creator of the open source project output.
  • At least for Linux Community, 80% of the contributors are also customers from companies. People of the community are customers and put in requirements.
    • Conservative assumption: For 1 person upstream there are 10 people using it
    • Are people using it and not contributing to it, are they really a customer?
  • Safety people have established processes and could actively participate to become customer and get their requirements being heard.
    • We could contribute Documentation, requirements and test cases.
  • It is important to reduce the systematic errors by the quality management process being established. Existing processes used implicitly may have gaps. These gaps differ in different projects.
  • Manpages and Linux Kernel Docs describe the specification of the code. You can extract requirements from there.
  • PRs, e-mails and discussions are requirements which are not documented in a systematic way as quality management standard users expect it.
  • You need to explain in a PR why you want to get something in. If you cannot explain why you want it in, you don't get it in.
  • ISO9001: Document what you do. It is a low bar, but it also adds value. It can be a start point for discussions.
    • The start point is the documentation.
  • Xen and Zephyr need to be kept in mind.
  • This great discussion will continue tomorrow in the OSEP working group (due to time reasons today).

The core parts of the kernel [cont.]

  • Last TSC meeting discussion 26 June 2024
  • LFSCS and ARCH collaborating with little tiny application which just start
    • What is needed for an application just to start (not doing someting actually).
  • small repo prepared with buildroot patch to build bare minimal kernel with only initramfs (no mem or storage devices).
  • Couple of programs: Tracing application (to start minimal application and minimize interference).
  • Looking into the config some features where used which were not meant to be there.
  • Config started with the arch default tiny. It was not as minimal as assumed.
  • Review required to come to a more minimal configuration.
    • Why are they in the tiny arch specific config?
  • Boeing got the premission to publish their minimal config which is not based on tiny, but extreme tiny.
    • Defconfig version will come via mailing list.
    • Closer to RTOS look and feel without virtual filesystem and no shell.
    • Question of testability need to be answered when using the config, because you need increase code size. (e.g. ktest and selftest)

Short status from WGs [skipped]

Up to 3 bullet points

  • Aerospace
  • Automotive
  • Medical
  • Arch
  • OSEP
  • Tools
  • Systems
  • Linux Features

AoB

Announcements

First half year topics for seminar series

Upcoming events

Clone this wiki locally