Meeting Minutes (TL & Communities & CFTs)

[johannes-esr]

Discussion containing all Meeting Minutes for the TL, Communities & CFT exchange meeting

[johannes-esr]

2025-02-24

Participants

• @johannes-esr
• @masc2023
• @LittleHuba
• @qor-lb
• @arsibo
• @antonkri
• @FScholPer
• @AlexanderLanin
• @guysagnes
• @markert-r

Agenda

1. Feedback from the Technical Leads
   1. How to pass tasks between teams #410
      • Proposal: One Label per Community; Sync Meeting on Monday (this meeting)
   2. Discussion of Roadmap Planning: https://github.com/orgs/eclipse-score/discussions/305
2. Feedback from the Community Leads
   1. Operational
   2. Testing
   3. Software Development Process
   4. Marketing & Communication
3. Feedback from the CFT Leads
   1. Persistency
   2. FEO
   3. Communication
   4. Logging
4. General/Open Points

Meeting Minutes

1. 1. Usage of labels for communities (community:architecture, community:infrastructure, community:testing, community:process, community:marcom) and CFTs (cft:persistency, cft:feo, cft:communication, cft:logging)
   2. Update of Roadmap
   3. Define creation of documentation in processes, @johannes-esr

Milestones	Date	Description
Process & Tools enable Development	31.03.2025	Left side of V-Model done. Acceptance Criteria: - Process & Tooling for requirements & architecture is available (sphinx-needs incl. additional checks for verifying traceability/consistency). - Process & Tooling for Detailed design, implementation & unit verification defined and implemented (e.g. spinx-test-reports). - CI/CD is capable to automatically verify the consistency & traceability. - Tooling for test coverage & static code analysis. Prerequisites: - Selection of tooling (e.g. static code analysis).
Modules Buildable	15.04.2025	All MVP defined features (FEO, IPC, Logging, Common Libraries, Persistency) can be built in software module repositiories. Until then, the modules are handled within the incubation repositories. Acceptance Criteria: - All modules use a common repository template (build, CI, gitlint, README, ...); to be checked by operational whether Git submodule/bazel module can be used to avoid code duplication. - All modules are built with bazel, (C++17: clang for x86 Linux with -Wall, -Wextra, -pedantic; Rust: rustc 1.83.0). - Unit tests are built and run, also via GitHub Actions. - No strict adherence to coding guidelines, but coding guidelines are available. - How to guide for reference build & test environment. - Result: every software module can be built inside of its repository. No common integration so far, no running image. Prerequisites: - MS "Process & Tools enable Development" mostly done
Reference Integration Linux	15.04.2025	Acceptance Criteria: - A reference integration repository is available which depends on all feature/module repositories and the score main repository. - reference Linux image (Docker) is available - There are integration tests available which run on Linux image. - Usecases for the integration tests are defined. Prerequisites: - MS "Process & Tools enable Development" & "Modules Buildable"
Process & Tools enable Testing	31.05.2025	Testing strategy is defined and corresponding tooling is implemented. Acceptance Criteria: - Process and Tooling for Testing (e.g. component or integration tests) are available.
Functional GAP Analysis finished	01.06.2025	- For all existing solutions for Release v0.5 analysis of missing features (GAP analysis) is finished, POCs has confirmed possible implementation solutions and everything is documented in Feature Requests. - Feature Requests are confirmed in the TL round and Software Architecture community, tickets are created and prioritized for implementation accrodingly
QNX Support	01.06.2025	The project supports the QNX toolchain. Acceptance Criteria: - The existing modules can be built with qcc. Prerequisites: - QNX Version and license defined
Reference Integration QNX	01.07.2025	Acceptance Criteria: - reference QNX image (Qemu) is available (ethernet) - There are integration tests available which run on QNX images. - Image is built and tested as part of automated CI/CD pipeline. Prerequisites: - 'QNX support' milestone - 'Reference Integration Linux' milestone
S-CORE v0.5 Release Candidate	01.06.2025	The features of the 0.5 MVP are according to the S-CORE processes and all artefacts are created initially. Acceptance Criteria: - All necessary artifacts (requirements, tests, architecture) exist in S-CORE format and are generated/executed in CI pipeline for the Release v0.5 components
Audit on Processes definition completed	01.07.2025	Acceptance Criteria: - All processes are defined. - Samples are available. - Maturity Level: Managed
S-CORE v1.0 specification	01.08.2025	- scope for Release v1.0 is defined in Software Architecture community and agreed with TL/PL-circle. - Feature requests for missing Release v1.0 modules are created and agreed. - POCs are done to show possible implementation approach
Reference Hardware for Release v0.5	01.10.2025	- Reference hardware and reference OS are defined. - Reference hardware farm is connected to S-CORE CI. - Integration tests on hardware are running periodically (e.g. nightly). - Define hardware relevant integration tests, e.g. performance, and corresponding KPIs
Release v0.5 feature complete	01.10.2025	- All Feature requests that are relevant for Release v0.5, including the ones resulting from the GAP analysis, are implemented according to the S-CORE software development process (requirements, architecture, dd, implementation and unit verification, integration tests)
Audit on Processes execution completed	01.10.2025
Tool Evaluation/Qualification prepared	01.10.2025	- List of all used tools available
Tool Evaluation/Qualification completed	01.11.2025
Release v0.5 certifiable	01.12.2025	The features of the 0.5 MVP are in a state to be safety certifiable. Acceptance Criteria: - Release v0.5 components have all necessary working products (also release and config mgmt documents) according to the S-CORE software development process - All corresponding tools are certified
All Audit findings resolved	01.12.2025
Release 0.5 Use Case implementation

gantt
   dateFormat YYYY-MM-DD
   title S-CORE Roadmap
   excludes weekends
   tickInterval 1month
   v0.5 Feature Complete : vert, v2, 2025-10-01, 0D
   v0.5 Certifiable : vert, v2, 2025-12-01, 0D

  section Project Milestones
      Release v0.5 feature complete incl. reference QNX integration: milestone, m2, 2025-10-01, 0D
      Release v0.5 Certifiable: milestone, m3, 2025-12-01, 0D
   
  section Software Modules v0.5
      Modules Buildable: done, milestone, m4, 2025-06-02, 0D
      Features follow S-CORE Process: milestone, m5, 2025-10-01, 0D
      GAP Analysis finished: active, milestone, m6, 2025-07-02, 0D

   section Process & Tools
      Process & Tools enable Development: crit, milestone, m7, 2025-07-31, 0D
      Process & Tools enable Testing: crit, milestone, m8, 2025-07-31, 0D
      Audit on Processes definition completed: milestone, m8, 2025-09-01, 0D
      Audit on Processes execution completed: milestone, m8, 2025-10-01, 0D
      Tool Evaluation/Qualification prepared: milestone, m8, 2025-10-01, 0D
      Tool Evaluation/Qualification completed: milestone, m8, 2025-11-01, 0D
      All Audit findings resolved: milestone, m8, 2025-12-01, 0D

   section Reference Environment
      Reference Integration QNX: crit, milestone, m10, 2025-08-01, 0D      
      QNX Support : done, milestone, m11, 2025-06-15, 0D
      Reference Hardware for Release v0.5: milestone, m12, 2025-10-01, 0D

   section Software Modules v1.0
      S-CORE v1.0 specification: active, milestone, m13, 2025-08-01, 0D

Loading

Next Steps:

• Roadmap to be checked by project members, Feedback in meeting next Monday
• @johannes-esr to create tickets for milestones and add milestone description, to be finalized on Monday
• Refinement of first milestones in next meeting on Monday

[johannes-esr]

2024-03-03

Participants

@johannes-esr
@masc2023
@antonkri
@vinodreddy-g
@arsibo
@FScholPer
@AlexanderLanin
@Dk1601

Agenda

1. Review of milestone planning done in https://github.com/orgs/eclipse-score/discussions/434#discussioncomment-12265274

Meeting Minutes

1. • Granularity of planning:
     • Dimension One:
       • Level 0: S-CORE Project (Milestones)
       • Level 1: Sub-Project/Technical committees (Community/CFT via GitHub Label); Level of Project & Technical Leads
       • Level 2: Epic (GitHub Issues) -> assigned to exactly one/multiple Community/CFT via Label; Level of Community/CFT Leads with collaboration of Technical Leads; Planning in common meeting
       • Level 3: Ticket (GitHub Issues) -> assigned to exactly one Community/CFT via Label; Level of Developers/Community Leads/CFT Leads
     • Dimension Two: Roadmap (GitHub Milestones) on Level 0; Epics/Tickets are assigned to the "latest" milestone the Epic has to be done, but can span over multiple Milestones; Level of Technical Leads
   • How to do planning yet open; To be discussed within Process Community & Technical Leads
   • Tasks:
     • Update PMP Planning Document https://eclipse-score.github.io/score/main/platform_management_plan/project_management.html#planning -> @johannes-esr to check in CW11
     • Move created Milestone Tickets to "normal" Milestones -> @johannes-esr before Wednesday
     • Definition of Epics appearing in the first milestones
       • Draft to be prepared in TL meeting on Wednesday
       • Check with Communities/CFTs 10:30 - 12am -> @FScholPer to invite

[LittleHuba]

Missing architecture community label

[HartmannNico]

Just added

[johannes-esr]

2025-03-10

Participants

@johannes-esr
@antonkri
@masc2023
@vinodreddy-g
@AlexanderLanin
@Dk1601
@guysagnes
@markert-r
@LittleHuba

Agenda

• Review TL breakdown of first Milestones https://github.com/eclipse-score/score/milestones
  • https://github.com/eclipse-score/score/milestone/7
  • https://github.com/eclipse-score/score/milestone/8
  • https://github.com/eclipse-score/score/milestone/9
  • https://github.com/eclipse-score/score/milestone/12
  • https://github.com/eclipse-score/score/milestone/13
• Next steps: Breakdown of Epics by CFTs/Communities; Re-Assignment of existing Tasks to Epics

Meeting Minutes

• Epics = Workpackage which can be done in few weeks (1 - 4 weeks), must be assigned to MS, planning granularity for TL
• Tasks = Breakdown of Epic, can also have Subtasks, assigned to same MS as Epic, planning granularity for CFT/Community
• For functional grouping of Epics labels are used
• Maturity Level of a Epic are included in Epic title
• Main planning is done in score Repository

[johannes-esr]

2025-03-17

Participants

• @johannes-esr
• @masc2023
• @antonkri
• @qor-lb
• @Dk1601
• @arsibo
• @timkl7
• @markert-r

Agenda

• Presentation of proposal "How to plan"
• Planning of first milestones
• Where to put Lessons Learned?

Meeting Minutes

• @antonkri presented new planning approach
  • accepted
  • S-CORE Roadmap (view)
  • TLs to update planning document: Update Planning in PMP #697
• "Lessons learned" also to be saved in official documentation to be visible on website, mostly in Contribute section

[FScholPer]

2025-03-31

Participants

@qor-lb
@johannes-esr
@AlexanderLanin
@masc2023
@arsibo
@Dk1601
@markert-r

Agenda

• Status of each Community (2 minutes)
• Milestone planning
  • S-CORE Roadmap
  • Do we have blockers?
  • Does each of us reach the timeline goals
  • June Release -> planning?
  • Roadmap of the Epics (priority, start date / due date). Does each epic has a subtask?
• Questions / Problems?

Meeting Minutes

• Status
  • Tooling: Epic: (Initial) Set-up basic repository & build infrastructure #585 (comment)
  • Logging: https://github.com/orgs/eclipse-score/discussions/770 (gap analysis)

[johannes-esr]

2025-04-14

Participants

• @johannes-esr
• @TomFleischmann
• @markert-r
• @antonkri
• @FScholPer
• @masc2023
• @arsibo
• @DanielSteinkeSDV
• Daniel Klotz

Meeting Minutes

• Review of S-CORE Roadmap Project
• TLs need Board for Change Requests (Feature Modification & Component Modification Label) -> @markert-r creates board
• @antonkri checks with @ramceb regarding location of FEO tickets

[johannes-esr]

2025-04-28

Participants

@johannes-esr
@markert-r
@arsibo
@AlexanderLanin
@LittleHuba
@qor-lb
@masc2023
@guysagnes
@dneail1601
@FScholPer
@antonkri

Agenda & Meeting Minutes

• Review of S-CORE Roadmap (view)
  • General: Keep tickets up to date!
  • Communication, Logging & Base Libs will be published until next week
  • FEO: Tickets to be planned
  • Persistency
  • Testing: Current approach shall be presented
  • Process
  • Architecture
  • Infrastructure

[FScholPer]

2025-05-05

Participants

@johannes-esr
@AlexanderLanin
@markert-r
@arsibo
@dneail1601
@LittleHuba
@antonkri
@qor-lb
@masc2023
@FScholPer

Agenda & Meeting Minutes

• Review of S-CORE Roadmap (view)
  • Infrastructure and tooling
    • Community not stuffed enough -> at least 6 full time needed
    • Unclear priorities and scaled like 100 devs -> many wish tickets and no focus
    • gitlint really needed?!
    • https://github.com/orgs/eclipse-score/discussions/977 ??
  • 321 Issues open in main repo
• Multi-repo apprach
  • Enables requirement linkage & traceability between repositories
• Process audit next Monday

[FScholPer]

2025-05-12

Participants

@johannes-esr
@AlexanderLanin
@markert-r
@arsibo
@dneail1601
@LittleHuba
@antonkri
@masc2023
@FScholPer
@guysagnes

Agenda & Meeting Minutes

Review Feature Planning

• Infrastructure & Tooling
  • @AlexanderLanin mentioned that all repositories can now build documentation. Multi repository is still in progress (Will take about about 1 week to finish).
  • Rust on qnx, multirepo setup, linking between repositories.
  • @AlexanderLanin proposed to do a regular demo meeting.
  • Demo proposal : https://sdvworkinggroup.slack.com/archives/C0894QGRZDM/p1747037795081439?thread_ts=1747037764.219969&cid=C0894QGRZDM"
  • Question about state of template repositories from @antonkri. @AlexanderLanin answered that a decision was made that one part tests without and the other with the template
• Testing
  • @dneail1601 mentioned that Concept of C++ is finished. The community wants to wait until real production code is available not only demo code -> https://github.com/qorix-group/Score-Testing/blob/main/Proposal/Data%20flow%20tests%20with%20gtest%20combined%20with%20extended%20unit%20tests%20-%20compilable.cpp
  • @AlexanderLanin said that we should order the tests in order of duration.
  • Daniel said that their is a discussion if only unit tests should be fixed by the developers and the broken other tests should be fixed be the testers
  • @AlexanderLanin asked about release strategy meeting. Daniel proposed to postpone the discussion until their is real code.
  • @antonkri proposed to the test community that we need a test plan who does what and so on.
  • TL will check
• FEO
  • Currently they wait until the Process Pilot is finished
  • @markert-r said they should use the blocking label
  • @antonkri We need feature requirements and epics for described for each release (due date 05.30 for existing and the rest 06.06.)
  • Until next meeting setup cft for common libs should be done -> TL should do that in next TL meeting
• Persistency
  • Feature priority for file system base unclear
    • C++ api & implementation already there in common libs
    • Com & Persistency will make a meeting AI: @LittleHuba & @guysagnes
  • C++ Class Result dependency to common/base libs
  • Security Layer in Persistency should be discussed in the architecture community
• Logging
  • Components Requirements next step
  • Gap Analysis is finished
• Communication
  • Next task Requirements & Architecture fitting to pilots to be created
  • Requirements sync mechanism has to be defined in each company
  • Proposal for Snapshot mechanism to feo already there: https://github.com/orgs/eclipse-score/discussions/861#discussioncomment-13040972
• Question if feature architecture is interconnection between features or if it is high level description -> should be high level description -> discussion with @hoe-jo to be done

[qor-lb]

2025-05-19

Participants

• @guysagnes
• @dneail1601
• @markert-r
• @AlexanderLanin
• @antonkri
• @FScholPer
• Padmakumara Malikaarachige Damith Lakmal

Agenda

1. Review Feature Planning

Meeting Minutes

to 1.

• Infrastructure
  • "initial" process & tools enable development done (basic setup)
    • Further development for tool support once concrete gaps are identified
    • Pilots to identify gaps in basic setups
    • Clear responsibilities for infrastructure in both C++ & Rust pilots to enable gap analysis in community
    • Epic: Process Pilot #760
• Communication
  • LoLa is now buildable; 0.5 gap analysis on-going
  • To be clarified: Com API for 0.5 or 1.0 (+ Rust support)
• Testing
  • Testing examples for 0.5 modules in progress and planned until end of May
  • Epic: Process Pilot #760 to also target piloting the verification as a follow-up
• FEO
  • missing attendees, skipped
• Persistency
  • Feature for file system alignment with existing part of baseLib to be taken to Gap analysis
  • Security Layer in Persistency rely on system, no additional security parameter to be handled
  • Requirement review based on: https://eclipse-score.github.io/score/pr-1069/process/process_areas/requirements_engineering/guidance/requirements_inspection_checklist.html
  • Persistence Feature KVS
    • Final review/rework on feature level
    • Draft architecture based on template (Pilot)
    • Draft component requirement based on template (Pilot)
  • C++ KVS implementation
    • PoC Implementation of Wrapper over Rust
    • Decision: specific implementation of C++ Library
• Logging
  • Logging is now buildable; 0.5 gap analysis on-going
  • missing attendees, skipped

[johannes-esr]

2025-05-26

Participants

@johannes-esr
@Dk1601
@timkl7
@antonkri
@AlexanderLanin
@arsibo

Meeting Minutes & Agenda

• Review Roadmap
  • Communication:
    • Epic: LoLa buildable & existing tests runnable #586 can be marked as done
    • Epic: Functional gap analysis for feature "Communication" #881 will be done by @LittleHuba
    • Epic: Create requirements for feature "Communication" #886, Epic: Create architecture artifacts for feature "Communication" #937 will be checked until next Monday
  • Logging:
    • Epic: Logging buildable & existing tests runnable #587 must be cleaned up, to be checked if everything builds
    • Epic: Functional gap analysis for feature "Logging" #884 to be updated in Logging meeting tomorrow
    • Epic: Create requirements for feature "Logging" #939, Epic: Create architecture artifacts for feature "Logging" #942 in progress, to be updated in Logging meeting tomorrow
  • FEO:
    • Overview of what CI jobs are running
    • Epic: Functional gap analysis for feature "Fixed Execution Order" #883, to be checked if something is missing
    • Epic: Create requirements for feature "FEO" #938, Epic: Create architecture artifacts for feature "FEO" #941: first PRs are present
  • Persistency:
    • Update to be checked afterwards
  • Testing:
    • PoC for Persistency in review
    • Will be presented on testing meeting wednesday, afterwards roll out
  • Process: no representative present
  • Infrastructure:
    • Problems with proxies, to be analyzed
    • Workstream meetings organized: https://github.com/orgs/eclipse-score/discussions/1095#discussioncomment-13248530

Offline report
Summary for the Persistency FT

• Feature Request for Persistency · Issue #95 · eclipse-score/score -> closed
  Focus on Key-Value Store, File system aspect will be part of the gap analysis

• Persistency Feature KVS

  • Final release on feature level
  • Review started: architecture based on template (Pilot)
  • Review started: component requirement based on template (Pilot)

• C++ KVS implementation

  • Implementation started: specific implementation of C++ Library

• Info - Requirements handling follows Reference:

  • requirements_inspection_checklist
  • requirements_templates

• Clarification requested

  • How should be the separation on module level in respect to selected language?
    -> Proposition a single repository containing the different language (Rust / C++)
    -> Process adaptation for the template to be adapted
  • Do we have the plan to use at least C++ 2020 and when?
    -> Question related to maps handling inside C++ 2017
  • How is the design constrain to be taken in account for dynamical types (e.g. String, Vector, …)
    -> MISRA rules reported type – Ref. rules 21.6.1 / 21.6.2

[johannes-esr]

2026-06-02

Participants

@johannes-esr
@vinodreddy-g
@guysagnes
@AlexanderLanin
@arsibo
@PiotrKorkus
@Dk1601
@FScholPer
@aschemmel-tech
@markert-r

Meeting Minutes

• Review of S-CORE Roadmap (view)
• Communication: No update available
• Logging:
  • Buildable: Probably can be closed after adding README file
  • Gap Analysis & Requirements ongoing
• FEO:
  • Gap Analysis, Requirements & Architecture ongoing
• Persistency:
  • Also tracked in process pilots
• Testing:
  • ITF set up in progress
  • CFT Lead will be taken over by @PiotrKorkus
• Process:
  • Update tickets that cannot be done to another epic
• Infrastructure:
  • Rust started, overall ongoing
  • C++ Stream needed? -> @eclipse-score/automotive-score-technical-leads
• Baselibs
  • Feature Team needed -> @eclipse-score/automotive-score-technical-leads

[FScholPer]

2025-06-16

Participants

@masc2023
@FScholPer
@markert-r
@antonkri
@qor-lb
@PiotrKorkus
@guysagnes
@TomFleischmann
Daniel Klotz

Agenda

• S-CORE Roadmap

Meeting Minutes

##Modules builable

• Persistency Full test Coverage will be there until next week

QNX Support

• Process for : Safe Use of QNX -> AI: @aschemmel-tech
• QNX Support -> Refinement Meeting should be set up -> AI: @antonkri

Functional Gap Analysis

• Architectural Gap Analysis is in Progress currently
• Persistency: KVS already done but Filesystem open
• Communication -> no update

Process Definition Audit Completed

• ITF will probably not feasible until End of July -> Change to another milestone because not needed for next Audit

Process and Tools Enable Development

• Rust is ongoing
• @markert-r will request @FScholPer to get some support for initial Setup

Functional Gap Analysis S-CORE v.0.5 Completed

• Also Planning finished is needed for implementation of the gaps
• Persistency: Filesystem is part of 1.0 and should be created as feature request

Other Questions

• Bypass of review -> posponed until next TL Onsite workshop
• Persistency is lacking Committers -> Current comitters are https://github.com/orgs/eclipse-score/teams/automotive-score-committers
• @antonkri raised some concerns about the current implementation of the multirepo -> @markert-r will invite to a meeting

[FScholPer]

2026-06-23

Participants

@FScholPer
@qor-lb
@PiotrKorkus
@masc2023

Agenda

• S-CORE Roadmap

Meeting Minutes

Testing

• The duedate of some ITF Tickets have been moved to later date. Could be last week of July

Process

• Friday Audit needs Quality Management until end of this week
• @qor-lb asked about the status of the Audit findings: Tickets created -> https://github.com/eclipse-score/process_description/releases/tag/v1.0.0 & https://github.com/eclipse-score/process_description/releases/tag/v1.0.1
• Infrastructure Community had meeting with Process Community to align gap analysis
• Where is the first Assessment to go over the Pilots -> October
• First Version of Tool Requirements already merged in doc-as-code repository
• Could be an overlap between Tool Requirements and Sphinx Needs Extension Implementation / Commercial Offering
• Doc-as-Code not acessible from main S-CORE page

[johannes-esr]

2025-08-04

Participants

@FScholPer
Paul Sherwood
Sorin Moloveanu
@antonkri
Alekhya
Lakmal
@PiotrKorkus
Sorin Moldoveanu
@johannes-esr
@hth9fe
@qor-lb
Artem Mygaiev

Agenda

• Vacation Period: Meeting cancelled in CW35 & CW37
• Proxy should be present in meetings, in case Community or FT Teams are not available
• S-CORE Roadmap (view)

Meeting Minutes

• Communicatin
  • Blocker right now TRLC Concept -> no decision
• Logging
  • Gabs identified but no epics created
  • Daemon should be created in new repo
• FEO
  • Rust binding of logging and com missing -> should be fixed now
• Persistency
  • No update
• ITF
  • Documentation still ongoing
  • SCTF shoed
• Process
  • No update right now because of vacation time
• Architecture
  • Feature Requests should be closed until end of this week
  • Talk about Incident Management in next TL sync
• Infrastructure
• TRLC & Lobster inspect
• Need some planing meeting in respect to future capacity
• Baselibs
  • Documents are still in progress
• Task Force: Build Toolchain
  • Tickets discussed in the kickoff of Reference Integration Meeting
• Task Force: Detailed Design
  • No update
• Navin Introduced himself

[johannes-esr]

2025-08-18

Participants

• @nmohanan31
• @hth9fe
• @igorostrowskiq
• @arsibo
• @MaximilianSoerenPollak
• @qor-lb
• @AlexanderLanin

Agenda

• Presentation of tool qualification/classification idea -> Schedule Kick-Off Meeting
• Review S-CORE Roadmap (view)

[nmohanan31]

2025-08-18

Participants

• @nmohanan31
• @hth9fe
• @igorostrowskiq
• @arsibo
• @MaximilianSoerenPollak
• @qor-lb

Agenda

• Presentation of tool qualification/classification idea -> Schedule Kick-Off Meeting
• Review S-CORE Roadmap (view)

Meeting minutes

• Validas gave us the presentation in the TL circle
• The work will be kicked off via a tool readiness work where they will assess all out tools and give us an assessment of which tools need classification and what are the gaps
• Then based on the output of the readiness check, we will start the tool qualification
• This will need approval from the project lead circle as the project will need to be financed.
• Project status:
  • Comms and Logging:
    • Process artifacts has been identified and soon there will be call out for contributions
  • Persistency
    • No attendance
  • Feo
  • no attendance
  • Testing
    • Was able to run reference integration testing
    • Next: working on component tests on Persistency and Orchestration
  • Process
    • no attendance
  • Architecture
    • will complete the scope for S-Core 1.0 and then call for contributions
  • Infra
    • First use case for auto code generation is done
    • Linters are available
      • not for C++ or Rust yet but available for python
      • We do not have a tools list that are identified for the project
  • Task force
    • GCC/C++ tool chain volunteer is unclear . Max was not formally informed for agreement

Open question:

• How feature flags will be used overall in S-Core 1.0 release for variant management and trunk based development? @antonkri

ACs:

• Send email to create a list of tools to be identified for qualification @qor-lb
• Clarify GCC/C++ tool task force ownership: @antonkri

[FScholPer]

@nmohanan31 can you please link the validas presentation for the people which were on holidays?

[nmohanan31]

@FScholPer , There was no presentation shown to us during the meeting, unfortunately. The Validas rep simply talked about what they do.
@qor-lb , Since you were in touch with them, did they share any presentation with you?

[johannes-esr]

2025-09-01

Participants

@johannes-esr
@PiotrKorkus
@masc2023
@opajonk
@AlekhyaBendhi
Mohamed Bejijou
@nmohanan31
@antonkri
@4og
@FScholPer

Agenda & Meeting Minutes

• Review S-CORE Roadmap (view)
  • Communication:
    • Feedback on Rust API open
    • Working on further features & testability
  • Logging: no representative available in call
  • FEO
    • Communication Integration: Struggling with Rust API -> to be documented in FEO Meeting
    • Logging: No Rust API available
    • Requirements: To be discussed in FEO Meeting
    • Start of documentation work
• Persistency: no representative available in call
• Testing: More progress on integration tests, details see tickets
• Process: no progress due to vacation period
• Architecture: no representative available in call
• Infrastructure: no representative available in call
• Baselibs: Details see tickets
• Task Forces: to be updated

[johannes-esr]

2025-09-15

Participants

@masc2023
@crimson11
@AlexanderLanin
@hth9fe
@FScholPer
Mohamed Bejijou (Valeo)
@PiotrKorkus
@LakmalBMW
@antonkri
@devcurmudgeon
@pahmann
@qor-lb
@arsibo
Eduard Metzker

Agenda & Meeting Minutes

• new planning approach presentation
  • New idea: "Product Increment" -> also new Issue type
  • S-CORE Roadmap (view)
  • Iteration: Not like a sprint, more like a release when a product increment shall be finished
  • Please review, then meeting with each FT to define Product Increments
• Seperate Meeting with TL and Process Community regarding goal of Audit & Planning

[johannes-esr]

2025-09-22

Participants

@johannes-esr
@PiotrKorkus
@masc2023
@4og
@nmohanan31
@hth9fe
@antonkri
@AlexanderLanin
Mohamed Bejijou (Valeo)
@FScholPer
Manuel Fehlhammer (BMW)
@4og
@arsibo

Meeting Minutes & Agenda

• Review S-CORE Roadmap (view)
  • new Iteration-based planning
  • Meeting with Infrastrcuture & TL to be scheduled to align on integration approach
  • Seperate meeting to align on static and dynamic code analysis -> @FScholPer
  • Seperate meeting regarding automatic checks & tooling on requirements & architecture with Feature Teams -> @antonkri
  • Clarification needed on Feature, Component and Module naming -> @johannes-esr

[nmohanan31]

2025-09-29

Participants

Manuel Fehlhammer
@FScholPer
@PiotrKorkus
@masc2023
@AlexanderLanin
Bogdan Badicu
@4og
@hth9fe
@arsibo
TSI - C.A.Brayan

Meeting Minutes & Agenda

• Review S-CORE Roadmap (view)
  • [QCC] Toolchain roll out in I-Gate #1545 - Tool chain roll out in I-gate is in progress but complier flag work will take more then 2 weeks time
  • fix toolchains for baselibs and communication #1737 - C++ tool chain Nikola R is currently working on it and is having issues with baselibs and communication
  • [Rust] Compilation for Linux in I-Gate #1550 - Compilation for Linux and QNX is in progress
  • [R&A] Checks roll out in I-Gate #1587 and [R&A] Execution of checks for every C++ component in I-Gate #1588 is work planned in iteration 5 to perform automated and manual checks in I-gate
  • [FIT] Introduce framework #1562 - Test framework is currently in progress
  • [Doc] Document generation #1561 - The second acceptance criteria is basically a new feature
  • Agree on S-Core v0.5 "must have" process requirements #1782 - Discussion is required to make it clear what the developer needs to do with the requirements. Especially the manual requirements

Action items

• Discuss in architecture community that all new tickets should be aligned to a feature epic: @qor-lb
• Find a meeting slot for Static code analysis: @FScholPer
• Add test tickets to the parent epics: @PiotrKorkus
• To split [Doc] Document generation #1561 and generally the documentation work into separate tickets and align them to the iterations: @AlexanderLanin
• Schedule a meeting with @antonkri for clarifying Agree on S-Core v0.5 "must have" process requirements #1782 - @FScholPer
• Use the Thursday slot to review the PR from Thomas and Johannes for planning: @FScholPer @nmohanan31

[johannes-esr]

2025-10-06

Participants

@johannes-esr
@PiotrKorkus
@masc2023
@arsibo
Mohamed Bejijou (Valeo)
@4og
@AlexanderLanin
@hth9fe
@FScholPer
@antonkri
@nmohanan31

Meeting Minutes & Agenda

• https://github.com/orgs/eclipse-score/discussions/516#discussioncomment-14602060
• Review of S-CORE Roadmap (view)

[johannes-esr]

2025-10-06 / Iteration Planning Infrastructure

Participants

@johannes-esr
@antonkri
@AlexanderLanin
@olivembo
@hth9fe
@nick-hildebrant-etas
@nmohanan31

Agenda & Meeting Minutes

• Review of S-CORE Roadmap (view), especially regarding Infrastructure Tickets

[johannes-esr]

2025-10-07 / Iteration Planning Testing

Participants

@johannes-esr
@antonkri
@PiotrKorkus
@draganbjedov
@nmohanan31
@hth9fe

Agenda & Meeting Minutes

• Review of S-CORE Roadmap (view), especially regarding Testing Tickets

[johannes-esr]

2025-10-13

Participants

@johannes-esr
@masc2023
@PiotrKorkus
@dcalavrezo-qorix
@antonkri
@hth9fe
@LittleHuba
@nmohanan31
@lurtz
@calbryan1
@4og
@FScholPer
Kai Hudalla
@arsibo
@AlekhyaBendhi

Agenda

10:00 - 10:30 am: Infrastructure & Process Community

• To have the integration repo to be abled to be compiled is the goal to enable the infra team
• Currently BMW is working on making baselibs and communication to be compiled with the current tool chain
• Target QNX 8.X and arm but start with x86
• Should we have linux support with the raspberry-pi?
• The status of the coding guidelines is unclear ([Coding Style] Definition of C++ coding style rules #1548)
  • Easiest would be to set up a clang format check code analysis rules
  • The main task is to setup the CI job
  • Python formatting needs a centralized set of rules from ruff rather that have different ones in each repo.
    • We can use what is currently in Orchestration. This can be discussed once the PR is in
      10:30 - 10:45 am: Testing & Reference Integration
• Qnx QEMU is a separate module currently but needs to a bazel registry. We need a good name for it.
  10:45 - 11:00 am: Feature Teams

Action Items:

• [ ] Define Linux OS distribution from the infra and tool chain point of view: @dcalavrezo-qorix
• [ ] Check with Thilo if he can approve the PR from @dcalavrezo-qorix : @FScholPer
• [ ] To schedule a follow up to discuss the way forward with Clangtidy: @FScholPer , @antonkri

[nmohanan31]

2025-10-27

Participants

@FScholPer
@nmohanan31
@PiotrKorkus
@arsibo
@4og
@AlexanderLanin
@masc2023
@PiotrKorkus
and few more : )

Agenda

0.5 Alpha release
Work flow in Github tickets
module names
Eclipse escalation process

Meeting minutes

0.5 Alpha release

• 0.5 Alpha release scope
  • Communication, base-libs and persistency will be released
  • Please create a separate ticket under [C++] Components Feature Complete #1549 or [Rust] Components Feature Complete #1552 respectively which has the check list from Prepare s-core v0.5 alpha release #1925
    • The expectation on the requirements and architecture is best effort
    • The QNX QEMU image is expected to run on x_86 and aarch64 but to have it working on raspberry pi is a nice to have

Work flow in Github tickets

• We need to describe the workflow in the PMP
• The Epics is created at Score level and the sub issues can be created in the respective repository.
  • As long as the S-Core road map check box is ticked while creating the sub issues in the respective repo, it will show up in the over all S-CORE planning board.

Module names and bazel registry names

• We should all have score_ as the start of the module name
• the names of the module can be decided by the module owners/Feature community
• The only condition is that the module name should not be too long
• We should have v_ for creating bazel registry Release documentation

Eclipse escalation process

• The only current way is via Christian Heissenberger or the Eclipse help desk
• We do not have any other way to speed up the process.

Action Items:

• Update the PMP with the ticket workflow to show people how to create tickets in Github
• To schedule a session to go through the Issue workflow in S-CORE and discuss with the feature teams

[AlexanderLanin]

2025-11-03

Participants

...

Agenda

• 0.5 Alpha release

Meeting minutes

• Release of November -> high expectations from the outside world
• TL changed Scope of the release Prepare s-core v0.5 alpha release #1925 (out of scope is process artifact)
  • c++ logging currently part of baselibs. Rust logging is out of scope
  • Changed the name i-gate to configured PR / Release workflows
• Most of the artifacts should stay in the main repo, except reference_implemenation as "golden example"
• Release Notes needed in the central repo for every module which is in scope.
  • create new template for the release notes
  • link to release notes for the main repo
• New meeting for merging of the modules should be set up

0.5 Alpha release

Current Status

• Prepare s-core v0.5 alpha release #1925
• reference_integration has a manual one time integration of persistency, communication, logging, baselibs, orchestrator (PR in review)
  • multiple pending TODOs for each module
• OS: Linux x86

Open Points

• logging not up to date in https://github.com/eclipse-score/.github/blob/main/profile/README.md
• QNX not yet supported in s-core (do all modules compile? baselibs, communication? QNX qemu not included in reference_integration)
• not yet included: feo, ITF
• modules are not up to date, proposal: module teams push updates via PR to reference_integration (use commit hash in git_override.MODULE.bazel)
• documentation is currently only per module + no versioning --> @AlexanderLanin, @a-zw, @ubmarco
• eclipse release???
• Perform integration test on reference_integration
• tutorial "score book" review

Release:

• release: we'll freeze+tag reference_integration integration (optional: tag in all repos)
• release artifacts not covered yet, e.g:
  • test results
  • bazel registry entry (optional)
  • binaries
  • full package
  • docs: requirements + arch
  • License + OSS scan results
  • SCA

[a-zw]

documentation is currently only per module + no versioning

It is not clear to me what exactly is open here. Could someone create an issue for this?

[AlexanderLanin]

Derived tasks for infrastructure-community:

• Set-up preliminary codeowners on the bazel_registry repository -> @AlexanderLanin @FScholPer
• Convert all TODO statements in reference_integration to actual issues in the respective modules -> @AlexanderLanin
• Provide versioned docs in reference_integration (MVP: downloadable zip with all docs) -> @AlexanderLanin
• Clarify dependencies between scramble and reference_integration -> @AlexanderLanin @antonkri
• Align exact version name. From a technical point of view we have a naming schema in score. The closest we can use is v0.5.0-alpha, which will be followed up by v0.5.0-beta and then v0.5.0. -> @AlexanderLanin @antonkri
• Contrary to all other repos, reference_integration will follow that "marketing naming" -> @AlexanderLanin
• sync reference_integration and qnx_qemu-integration. -> @AlexanderLanin

Most notably:

• Adding or updating modules to reference_integration is to be handled by respective feature teams.

[AlexanderLanin]

2025-11-10

Participants

...

Agenda

• bypass: we are establishing mandatory checks in repositories. Those will fail occasionally and without bypass-ability no-one except eclipse can fix those repositories. On the other hand obviously bypass allows check and process violations. Trigger: add os_images repo .eclipsefdn#100

Meeting minutes

[FScholPer]

2025-11-17

Participants

@vbogdanb
@nmohanan31
@FScholPer
@PiotrKorkus
Mohammed Beijijou
@aschemmel-tech
@arsibo
@LittleHuba

Agenda

• Refinement Roadmap Board

Meeting Minutes

• add feature requirements for logging #1024 move to 1.0
• [C++] Components Feature Complete #1549 -> close epic with belongs to
• mw::com: Full API support in Rust #1214 & mw::com: Full testability for the user facing C++ API #1216 -> move to v1.0
• [Ref Image] Demo applications in Reference QNX Integration #1554 -> close
• [Ref Image] RedHat Linux image in Qemu #1556 -> close
• [Ref Image] (Initial) Linux container arm64 is up and running #598 -> move to beta
• [Ref Image] QNX support #1013 Refinement needed
• [Ref Image] Nightly executions #1327 AI: @AlexanderLanin will merge with the old issue
• [Static Code Analysis] Implementation of automated checks (initial scope) #1744 & [Static Code Analysis] Definition of static code analysis checks (compiler + clang-tidy) #1558 merge
• Tooling: Enable rust development #80 -> Refinement Wednesday Rust meeting
• [R&A] Define & integrate tooling #1560 & [R&A] Implementation of automated checks #1586 -> v0.5 beta
• [FIT] Introduce framework #1562 -> AI: @PiotrKorkus refine
• [Doc] Document generation #1561 -> AI: @AlexanderLanin Refinement
• [Doc] Creation of "how-to" documentation #1599 -> can be closed. Already in the handbook
• Agree on S-Core v0.5 "must have" process requirements #1782 -> check which is done
• create new label for score-0.5 beta and rename the existent to 0.5 alpha
• Certification board: ask @pawelrutkaq to do a meeting
• Epic: (Update) Platform/Project Management Plan #860 TL need plan
• JSON library qualification using TSF (C++) #1460 refinement after decision about nlohmann_json and tsf pilot
• Epic: Rest of "initial setup" #768 -> refinement needed.

[FScholPer]

2025-11-17

Participants

@FScholPer
@antonkri
@arsibo
Fan Yefeng
@masc2023
@PiotrKorkus
Mina Hamdi
@pawelrutkaq

Agenda

Meeting Minutes

• Scope for v0.5 alpha -> https://github.com/orgs/eclipse-score/discussions/516#discussioncomment-15039732
  • @4og will come up with a proposal.
• New Security Meeting in Eclipse Calendar -> everyone please participate if interested
• Image would be a wish
• Scope discussion of v0.5 final
• Branch changes for v0.5 in separate branch -> discuss in infrastructure community
  tps://github.com/orgs/eclipse-score/discussions/516#discussioncomment-15039732

[pawelrutkaq]

We should. Release branches makse sense imho from 0.5-alpha release. We currently have content that is no longer 0.5 compatible on main, still reference integration main shall do Ci/CD on main branches. So basically, I would have no idea how to support beta, final just from main in any scenario but I may be missing bigger picture.

[pawelrutkaq]

I had something similar in mind 👍

Maybe one question regarding the branches release/1_0_alpha, release/1_0_beta: Do we expect bugfix, new features etc. on this branches? I would assume not. Finally we want to have a 1.0 release and the stages are "just" waypoints on the way towards that. So my assumption was, that we have a release branch for each release and for a certain commit in the reference repo we say we want to go with this commit as the alpha version (and tag it accodingly) and from that on every further commit on that release branch belongs to the beta stage. As mentioned, your proposed approach would make sense if we would expect e.g. bugfixes for an alpha release. I would not, but if I am wrong, I would support your proposal

release/1_0_alpha, release/1_0_beta could be optional, tagging those commits is fine because you can create the mentioned branch later if you need fix something in a particular stage from whatever reason. I would then describe that those branches are created only if a need to bugfix/other changes arrise. Sounds good.

[AlexanderLanin]

We currently have content that is no longer 0.5 compatible on main

Why is it not compatible? Breaking change that some other module did not apply? We'll block such breaking changes soonish anyway, so that should not happen anymore.

Or some feature that is not supposed to appear in 0.5? Why not?

etc?

[olivembo]

out of experience I would say you never get a release stable on main or develop. and if you try all others probably have to work on a branch to not „destroy“ something. even if you think you have covered everything withs tests - you‘ll at least miss one case 😉

[opajonk]

Well you certainly can get a stable on main. We have that on a few projects - but certainly not on all. What is the difference? Strong CI. Sounds like from a stupid textbook? Well, what shall I say - it works. But it requires automation for basically everything - and even then discipline, because as you say - you can not catch ALL ALL. But you can try ;-)