Meeting Minutes - Tech Lead Sync

[johannes-esr]

General Discussion for all Meeting Minutes

[johannes-esr]

2025-02-26

Participants

@johannes-esr
@markert-r
@qor-lb
@antonkri

Meeting Minutes

• New weekly timeslot: Wednesday 9 - 10am, @johannes-esr to ask @FScholPer to invite
• Planning Concept:
  • Milestones are Issues of the type 'Milestone' -> @johannes-esr to add this issue type
  • Milestones only have sub-issues of the type 'Epic' -> @johannes-esr to add this issue type
  • Epics have sub-issues of the type Task

[johannes-esr]

2025-02-28

Participants

@johannes-esr
@markert-r
@vinodreddy-g
@antonkri
@FScholPer

Meeting Minutes

• Additional weekly slot: Friday, 1:30 - 2:30pm -> @FScholPer to invite
• @markert-r to schedule meeting for March 20 for new interested companies
• New agenda points for PL Circle:
  • Date of Townhall
  • Combination of https://eclipse-score.github.io/ & https://eclipse-score.github.io/score/main/ to allow next step of Contribution One Pager

[johannes-esr]

2025-03-06

Participants

@pahmann
@antonkri
@FScholPer
@johannes-esr

Agenda

• Breakdown of first to Milestones in Epics

Meeting Minutes

• Milestone: Process & Tools Enable Development
  • Epic: (Initial) Processes Requirements #581
  • Epic: (Initial) Tooling Requirements & Architecture #582
  • Epic: (Initial) Processes Detailed Design, Implementation #583
  • Epic: (Initial) Tooling Detailed Design, Implementation, Unit Verification #584
• Milestone: S-CORE v0.5 Modules Buildable
  • Epic: (Initial) Set-up basic repository & build infrastructure #585
  • Epic: LoLa buildable & existing tests runnable #586
  • Epic: Logging buildable & existing tests runnable #587
  • Epic: Persistency buildable & existing tests runnable #588
  • Epic: FEO buildable & existing tests runnable #589
  • Epic: ITF buildable & existing tests runnable #590
  • Epic: (Initial) Coding Guidelines C++ #591
  • Epic: (Initial) Coding Guidelines Rust #592
  • Epic: (Initial) Coding Guidelines Python #593
• Tasks for Communities / CFTs:
  • All existing issues which are matching to the Epics of the Milestone shall be attached
  • Add Milestone to all linked Issues

[antonkri]

2025-03-07

Participants

@johannes-esr
@antonkri
@vinodreddy-g
@FScholPer

Agenda

• Breakdown further Milestones

Meeting Minutes

• Milestone: Reference Integration Linux

  • Epic: Linux container x86_64 is up and running
    Acceptance criterias: Linux container (x86_64) is prepared, configured properly (ethernet/ssh access) and uploaded to some location, that is accessible from local builds and CI.
  • Epic: Linux container arm64 is up and running
    Acceptance criterias: Linux container (arm64) is prepared, configured properly (ethernet/ssh access) and uploaded to some location, that is accessible from local builds and CI.
  • Epic: ITF framework is up & running.
    Acceptance criterias: ITF framework is integrated into bazel. ITF test job is set-up in CI and is part of check/gate pipeline. ITF can establish ssh connection to the image. As first test in the CI pipeline, ITF should deploy application under test to the Linux container and ensure, that this one is running.
  • Epic: ITF framework dlt support
    Acceptance criterias: ITF framework can receive dlt streams from the applications and provides infrastructure to evaluate DLT logs in runtime and post-mortem.

• Milestone: QNX Support

  • Epic: Integration of QNX toolchain.
    Acceptance criterias: QNX 8 toolchain is integrated into bazel. Users need to get the license from QNX everywhere program and put it some specific location for being able to use QNX 8 toolchain.
  • Epic: Building with QNX in CI.
    Acceptance criterias: CI jobs for building of applications are set-up for all currently existing applications and documentation is provided how set-up QNX CI jobs for future applications. QNX CI license is stored as GitHub Secret and allows unlimited execution of QNX CI jobs in parallel
  • Epic: QNX Compiler config.
    Acceptance Criteria: compiler config is agreed with Process team and compiler/linker flags are chosen to support ASIL development right from the beginning.

• Milestone: Reference integration QNX

  • Epic: Qemu with QNX image and x86 BSP
    Acceptance Criteria: Qemu with QNX image, x86 BSP and S-CORE applications can be built with bazel locally and in CI. There exist a voting CI job, that builds QNX Qemu image and executes all existing ITF tests with it.
  • Epic: Qemu with QNX image and Qualcomm (ARM) BSP
    Acceptance Criteria: Qemu with QNX image, Qualcomm BSP and S-CORE applications can be built with bazel locally and on demand on CI.

[johannes-esr]

2025-03-14

Participants

• @johannes-esr
• @antonkri
• @qor-lb
• @vinodreddy-g
• @markert-r

Agenda

• How to do further planning?

Meeting Minutes

• Meeting this afternoon to update PMP with information decided on https://github.com/orgs/eclipse-score/discussions/434#discussioncomment-12299310 & https://github.com/orgs/eclipse-score/discussions/434#discussioncomment-12445705
  • Breakdown of Workpackages
  • Labels to use
  • ...

[johannes-esr]

2025-03-19

Participants

@johannes-esr
@markert-r
@antonkri
@timkl7
@qor-lb

Meeting Minutes

• Next week alignment meeting regarding Processes & Tools between AUTOSAR & S-CORE in Lüneburg, https://www.autosar.org/news-events/detail?tx_news_pi1%5Baction%5D=detail&tx_news_pi1%5Bcontroller%5D=News&tx_news_pi1%5Bnews%5D=304&cHash=a20923b48d9e091adb600c148ab6948f
  • @AlexanderLanin will attend the meeting
  • @antonkri to check if @aschemmel-tech will attend, too
• Proposal: TL Meeting on 31th March 2025, 9:00 - 12:30
  • Planning/Review of Milestones ending in June 2025, too much in parallel
• Tasks for next meeting:
  • Review of Milestone planning; some Epics are not assigned to a CFT/Community
• Change of Monday Meeting Series:
  • 9 - 10am only TL
  • 10 - 11am TL & Communities & CFTs
  • @qor-lb changed invitation, to check if everybody received the updated invitation

[johannes-esr]

2025-03-21

Participants

@johannes-esr
@FScholPer
@qor-lb
@antonkri

Agenda

• Open points from last discussion

Meeting Minutes

• AUTOSAR / S-CORE Meeting: @aschemmel-tech can just attend online
• TL Workshop: March 28, starting 12 pm (instead of March 31)
• Should Safety Linux be a target platform of S-CORE? -> To be addressed in PL Circle @antonkri
• Point for next PL Circle: Analysis AUTOSAR -> @antonkri

[qor-lb]

2025-03-24

Participants

• Tom Fleischmann
• Rebecca Markert
• Anton Kiroborodov
• Frank Scholter Peres
• Lars Bauhofer

Agenda

1. Current Status S-CORE Logo
2. Agenda for WS on 28th
3. Feedback productivity Tech Lead Sync

Meeting Minutes

to 1.

• An agenda of SteerCo but not update yet

to 2.
Proposals to be prepared until friday:

• More concrete milestone/roadmap planning - @antonkri / @markert-r
  • do we have all the dependencies?
  • how to get a better overview?
• Definition of meeting structure - @markert-r
  • who prepares the meeting?
  • what agenda is discussed
  • How to pass tasks between teams #410,
• How to contribute/how are feature requests managed? - @TomFleischmann / @qor-lb
  • Feature requests are prepared to reflect technical roadmap
  • Case A: FR open but no contributions yet (Feature is on roadmap but not implemented)
  • Case B: Feature not yet on roadmap (functionality not yet targeted by by S-CORE)
• Management of components within S-CORE (who can review & merge) - @FScholPer

misc:

• https://oss-review-toolkit.org/ort/

[qor-lb]

2025-03-26

Participants

• Tom Fleischmann
• Rebecca Markert
• Anton Kiroborodov
• Lars Bauhofer

Agenda

1. Slides for townhall
2. Move invite from zoom to teams

Meeting Minutes

to 1.

1. Welcome and Introduction - 5 min
2. Project Vision - 10 min - @markert-r
   - Goal S-CORE: source code standardization
3. Current Status & Overview Cross Functional Teams - 40 min
   • Content Tech - 20 min - @qor-lb
     • 0.5 components & how they were selected - i.e. Architecture WS, Selection Criteria, Components
     • Hint to 1.0 definitions in following months
   • Content Process & Tools - 20 min - @markert-r
     • Current status process - 5 min
     • Results from ekxida - 15 min
4. Roadmap (milestones) - 10 min - @FScholPer
5. How to contribute - 5min - @qor-lb
   - (CFT's & work structure)
6. Q&A - 20 min

to 2.

• accepted

misc:

• Preliminary slides: 20250320_S-CORE_Townhall_Meeting.pptx
• Community days slides:

[johannes-esr]

2025-03-28

Participants

• @johannes-esr
• @qor-lb
• @markert-r
• @antonkri
• @FScholPer

Meeting Minutes

• docs: improved how to contribute section #776
• Review of Roadmap Planning
• Tasks for Monday Meeting:
  • https://github.com/eclipse-score/score/milestone/7 -> Status to be checked with Infrastructure Community
  • Status (~2min) of each CFT/Community in Monday Meeting

[FScholPer]

2025-03-31

Participants

• @johannes-esr
• @qor-lb
• @markert-r
• @antonkri
• @FScholPer
• @guysagnes

Agenda

• Feedback for planning milestones

Meeting Minutes

• We need the participants for the architecture workshop A1 @qor-lb

[johannes-esr]

2025-04-02

Participants

@johannes-esr
@antonkri
@FScholPer

Agenda

• Review of Monday Meeting

Meeting Minutes

• Detailed check of tasks of Operational Community on Friday, 1:30 - 2:30pm

[TomFleischmann]

2025-04-07

Participants

@markert-r
@antonkri
@TomFleischmann
@qor-lb
@FScholPer
@guysagnes

Agenda

• Review last weeks cross functional community meeting
• Review roadmap for next meeting
• Craft agenda for next meeting
• Briefly discuss day & topic distribution for arch workshop

Meeting minutes

Review last weeks cross functional community meeting

• Some discussions touched on topics in parallel / double was observed
  -> could be improved to talk alongside the roadmap / epics board roadmap / epics board and teams then deep dive into their more detailed boards
• Invites are not easy to graps / have in every bodies calendar better, potential to improve meeting management for OSS projects (@TomFleischmann to ask EF what other projects successfully do)
• Potentially better: One sends out the invite per meeting and create a meeting overview page (When, Who, What, Link, ..)
• Maybe not good to the whole world in the project lead meeting - makes it hard to get topics done and not helpfull for new parties who want to contribute and join in

Review roadmap for next meeting

• Minor: some items have a wrong end date
• Discussed usage of templates including checks (req linking, ..) for repositories
• Pro: makes it easier for all subprojects to follow the same process (and adhere and enable later safety certification)
• Have a central solution and example for coding, unittest, req links, linting, compiler flags, ... makes sense to avoid "works in my subproject/works on my machine"
• Anton: Consensus of central bazel, yet CI config may need to differ (or define at a later point in time) in order to have 1st steps in the projects made easier and learn first
• A lot of bazel and CI work in repos currently -> Action: Extra discussion with Arch community to unblock @AlexanderLanin and to describe target picture

Craft agenda for next meeting

• Review roadmap and have everybody to give a status update and important dependencies
• Raise topic about central repository template to help prioritize (try-out defined process); needs an extra meeting with tooling community & tech leads & some of the feature teams ; @markert-r to make invite for an hour

Briefly discuss day & topic distribution for arch workshop from Tuesday to Thursday

• As we better know a 1.0 scope the question around what could be used/based on autosar is time wise good to have on Thursday.

[FScholPer]

2025-04-11

Participants

Agenda

• Currently there are many Stakeholder requirements which are outdated and the granularity differs much for example between com & feo.

Meeting minutes

[johannes-esr]

2025-04-11

Participants

@johannes-esr
@TomFleischmann
@FScholPer
@markert-r

Meeting Minutes

• Review Milestone Planning
  • Check with Alexander L. whether this intermediate milestones can be deleted
  • What to do with "Blueprint Definition" Milestone? To be checked in next TL circle

[johannes-esr]

2025-04-14

Participants

@johannes-esr
@TomFleischmann
@antonkri
@markert-r

Agenda

1. Review of TL Sync Meeting Slots
2. Meetings during easter holiday
3. What to do with "Blueprint Definition" Milestone
4. Outcome of Architecture Workshop
5. Agenda TL, CFT, Community Sync
6. General

Meeting Minutes

1. • Monday, 9 - 10 am
   • Wednesday, 9 - 10 am
   • Friday, 8:35 - 9 am
   • Friday, 1:30 - 2:30 pm
   • @qor-lb to delete invitations in Eclipse calender
   • @markert-r to invite for new meetings
2. • Meetings on 2025-04-18 & 2025-04-21 are cancelled
3. • Milestone renamed, https://github.com/eclipse-score/score/milestone/15
   • @FScholPer to break down into epics
4. • Epic: Define scope for S-CORE 1.0 #908
   • Epic: Architectural gap analysis S-CORE v0.5 #904
5. • Deletion of intermedia milestones
6. • Review of "Modules Buildable" on 2025-04-28

[FScholPer]

2025-11-27

Participants

@johannes-esr
@FScholPer
@pawelrutkaq
Christian Rappl
@odra

Agenda & Meeting Minutes

• Creation of Tickets for beta release -> special meeting tomorrow 8:30am
• How to proceed with the platform code like inc_auto_sd
• Toolchain qnx/linux monorepo S-CORE Bazel Platform Definitions #1411
  • Feedback regarding monorepo missing
• [Static Code Analysis] Definition of static code analysis checks (compiler + clang-tidy) #1558

Moved to next meeting:

• How to handle Feature modification requests and api Abstractions(for example CommonAPI<-> mw::service)
• Pull Requests take months to be reviewed https://github.com/eclipse-score/score/pulls
• Garbage Collection of issues -> 694 issues open
  • Proposal: change of template, enforcement of Project has to be evaluated
• Release Management
• Office hour -> no participants. Cadence check
• Support of QNX 7 is in scope or not: qnx: added support for QNX7 toolchains_qnx#37
• Traceability: Issue -> PR -> Code

[FScholPer]

2025-11-28

Participants

@antonkri
@anmittag
@johannes-esr
@qor-lb
@nmohanan31
@FScholPer

Agenda

• How to proceed with the platform code like inc_auto_sd
• Toolchain qnx/linux monorepo S-CORE Bazel Platform Definitions #1411
  • Feedback regarding monorepo missing
• Creation of Tickets for beta release -> special meeting tomorrow 8:30am
• [Static Code Analysis] Definition of static code analysis checks (compiler + clang-tidy) #1558

Moved to next meeting:

• How to handle Feature modification requests and api Abstractions(for example CommonAPI<-> mw::service)
• Pull Requests take months to be reviewed https://github.com/eclipse-score/score/pulls
• Garbage Collection of issues -> 694 issues open
  • Proposal: change of template, enforcement of Project has to be evaluated
• Release Management
• Office hour -> no participants. Cadence check
• Support of QNX 7 is in scope or not: qnx: added support for QNX7 toolchains_qnx#37
• Traceability: Issue -> PR -> Code
• State of qnx rust compiler and https://github.com/orgs/eclipse-score/discussions/1446#discussion-8598074 AoU

Meeting minutes

• fix toolchains for baselibs and communication #1737 -> discuss with infrastructure on monday meeting
  • reference integration automation & module PR feedback #1543
  • reference integration automation & module PR feedback #1543
  • [GCC] Toolchain roll out in I-Gate #1544
  • [QCC] Toolchain roll out in I-Gate #1545
  • [Unit-Test] Toolchain roll out in I-Gate #1546
  • Tooling: Enable C++ development #79
  • Tooling: Enable rust development #80
  • [Rust] Components Feature Complete #1552
  • [Ref Image] S-Core Vanilla QNX image is running on Raspberry PI #1918
  • [R&A] Define & integrate tooling #1560
• Setup Discussion for implementation of process requirements: AI @antonkri
• Discussion started about prosponing 0.5-final
• [Doc] Document generation #1561 -> monday
• Discuss coding guidelines with process community
• Continue on monday...

[nmohanan31]

2025-12-01

Participants

@antonkri
@FScholPer
@sankurm
@ChristianR9911

Agenda

• Release date
• Agenda for next meeting
• Release Management
• Office hours attendance

Moved to next meeting:

• How to handle Feature modification requests and api Abstractions(for example CommonAPI<-> mw::service)
• Pull Requests take months to be reviewed https://github.com/eclipse-score/score/pulls
• Garbage Collection of issues -> 694 issues open
  • Proposal: change of template, enforcement of Project has to be evaluated
• Release Management
• Office hour -> no participants. Cadence check
• Support of QNX 7 is in scope or not: qnx: added support for QNX7 toolchains_qnx#37
• Traceability: Issue -> PR -> Code
• State of qnx rust compiler and https://github.com/orgs/eclipse-score/discussions/1446#discussion-8598074 AoU

Meeting minutes

Beta release

• Release date for the beta version will be 18th of Dec 2025
  • We need at least 2 people for helping out with the release. (Frank is available)
  • Create a check list for everyone to complete i.e. to understand what is in scope for the release
  • We would mostly move the final 0.5 release to end of March 2026
  • Highlights would be -> Better testability via static code analysis and unit test coverage, aarch64(ubuntu linux) support and the pilot for showcasing how to move modules to individual repos.
  • Raspberry-pi support as a stretch goal -> We would need someone to look into this.

Agenda for next meeting:

• Modules to individual repositories -> We have a pilot, baselibs
• Go through the S-Core board and get agreement for what will be in beta release
• To look for support to get raspberry-pi support for the beta release.

Release Management

• We need to talk to sphinx needs for checking for a solution for building artefacts for releases
• For the beta release we would do the same as alpha release i.e. release from master with tags.

Office hours

• We need to have some heads up of new people attending the meeting for information
  • We could have a public slack channel for office hours for people to put topics for office hours
  • Also, to have more info about office hours meeting on the website
  • The best way would be to forward these request to the X-core marketing community

Action items

• To create a branch for the release notes: @antonkri
• To add our release plan to the agenda of X-core meeting to see if it aligns with their plans: @FScholPer
• To check with the X-core marketing community about the office hours: @FScholPer

[johannes-esr]

2025-12-04

Participants

@johannes-esr
@anmittag
@nmohanan31
@FScholPer
@thilo-schmitt
Tarek (Appraid-tech)
@pawelrutkaq
@thilo-schmitt

Agenda

• Modules to individual repositories -> done
• Go through the S-Core board and get agreement for what will be in beta release
• To look for support to get raspberry-pi support for the beta release.
• Traceability: Issue -> PR -> Code
• How to handle Feature modification requests and api Abstractions(for example CommonAPI<-> mw::service) Improvement: Define Release workflow #2231

Moved to next meeting:

• Pull Requests take months to be reviewed https://github.com/eclipse-score/score/pulls
• Garbage Collection of issues -> 694 issues open
• Proposal: change of template, enforcement of Project has to be evaluated
• Support of QNX 7 is in scope or not: qnx: added support for QNX7 toolchains_qnx#37
• State of qnx rust compiler and https://github.com/orgs/eclipse-score/discussions/1446#discussion-8598074 AoU
• How do we complete the PMP?

Meeting Minutes

• The pilot of moving baselibs to an individual repo can not be completed for the beta release -> Anton will confirm

• fix toolchains for baselibs and communication #1737 will be reviewed today to check if it will be ready for the beta release

• Monthly milestone releases vs trunk based development

  • Given the fact that we have external repos like SOVD, trunk based development could be difficult to implement
  • We could still have a consistency checks with all the repos in the development process?
  • It would have to be the responsibility of the repo owners to make sure all the fixes are made if there are any breaking changes for reference integration.
  • The repo owners will give a tag for the best point on the development branch for the release
  • Unify the CI/CD workflows across all repos -> We need to propose this.
  • We could have rep from every repo to give us a Go-No go status for the releases well ahead of time.
  • Final state of the 0.5 final release
    • We need to adhere to the Eclipse release process
    • We need to agree what processes would be implemented for the 0.5 final release probably for communication, baselibs

• Traceability from issue to PR to Code is required. -> Question to the process community

• Should we have mw::com in a special branch?

  • Will discuss this in the next architecture meeting to agree on the proposal Improvement: Define Release workflow #2231

Action items

• To check on the Monday meeting for volunteers for release team: @nmohanan31
• To check internally who would volunteer for release team and then work on a proposal for the releases: @tls
• To change the meeting time from 1.30 pm to 3pm on Thursdays: @nmohanan31
• To create a checklist for the beta release: @antonkri
• To bring Improvement: Define Release workflow #2231 to architecture community meeting: @FScholPer

[anmittag]

2025-12-11

Participants

@johannes-esr
@anmittag
@FScholPer
@nmohanan31
@thilo-schmitt
@pawelrutkaq
@antonkri

Agenda

• Pull Requests take months to be reviewed https://github.com/eclipse-score/score/pulls

  • Review open PRs with Communities/FTs -> on Agenda for next meeting

• Garbage Collection of issues -> 694 issues open

  • Script created to ping owner of issue if it's still relevant -> run this script regulary @FScholPer

• Support of QNX 7 is in scope or not: qnx: added support for QNX7 toolchains_qnx#37 -> Alignment with @nradakovic & @dcalavrezo-qorix (@antonkri to organize meeting)

• State of qnx rust compiler and https://github.com/orgs/eclipse-score/discussions/1446#discussion-8598074 AoU -> @nmohanan31 to check with @qor-lb

• How do we complete the PMP?

  • traceability with sphinx (all processes covered in the pmp?)
  • @anmittag will review the existing pmp
  • OKRs suggestions (@nmohanan31 )

• Status 0.5-Beta (@anmittag)

  • Canceling?
    • there is not to much progress/delta from alpha to now?
    • no additional features / breaking changes
    • requirements/design/etc. improvements
    • decision: so a release shall be done
  • currently
    • rust-issue: platforms: align platform declarations bazel_platforms#5
    • use score_bazel_platforms for consistency toolchains_qnx#39
    • Guard test job with workflow approval toolchains_qnx#8
  • timeline: Dec. 18: risky
  • for toolchain topic, @antonkri will setup a meeting with @nradakovic , @pawelrutkaq and @AlexanderLanin tomorrow

• Bypasses of processes (@FScholPer / @antonkri )

  • Request: BMW wants to treat the Configuration Management Repos similar as LOLA
  • Why: Pipelines are not generating the sufficient quality
  • PRO: Series Code SYNCHED
  • CON: Not following the Open Source Idea
  • COPYBARA can be used

[anmittag]

2025-12-15

Participants

@opajonk
@nmohanan31
@odra
@FScholPer
@ChristianR9911
@johannes-esr
@anmittag

Agenda - topic / issuer / prio

• Qorix will withdraw pitches for SOME/IP Gateway, ABI compatible datatypes, Diagnostics Fault Library / @nmohanan31 / B
  • ramping down contribution in the corresponding feature teams as well
• Lifecycle Maintainer / @anmittag / A
  • currently the Team has a lack of approvers, how to get initial contribruters to committers/maintainers?
  • [Contribution Request] Lifecycle and Health #1739
    "Consensus on contribution is reached by 5th December 2025 (fallback voting by TLs on 8th December 2025)"
  • https://github.com/orgs/eclipse-score/discussions/1699 MM-Nov-12: "Step 1: Merge etas contribution to main of inc_lifecycle --> done"
  • process see: "Merge rights & code ownership"
    => PR with CodeOwner File etc.
• Review Open Point List / @anmittag / A
  • Question: shifting of tickets into dedicated repositories? e.g. ft:feo labeled to feo repository? what to do with issues touching multiple teams?
  • Decision: all issues shall be in "score" main repository
• Review of Pull Requests / @anmittag / A
• Creating a (Reference) Integration Team / @anmittag / B
  • decsision: yes
  • some volenteers are already available: @opajonk @odra etc.
  • we have to found a new interest group
  • contact @chheis : @anmittag for kickoff, etc.
    => Creation of an Integration Team #2345
• SCORE Release V0.5Beta / @FScholPer / A

[anmittag]

2025-12-18

---

Participants

• @anmittag
• @antonkri
• @FScholPer
• @johannes-esr
• @nmohanan31
• @pawelrutkaq

---

Agenda

• GitHub Resources
• Release V0.5-Beta
• Open Points
• Open PR

[FScholPer]

2026-01-05

---

Participants

• @anmittag
• @antonkri
• @qor-lb
• @FScholPer
• @johannes-esr
• @nmohanan31
• @pawelrutkaq

---

Agenda

• Open Some/IP next steps.
• 0.5-beta

Meeting Minutes

• Discuss Some/IP implementation steps in architecture community meeting today
• Next steps after beta relese
  • Unit coverage
  • Images
• No Alignment Meeting needed for today
• vajson -> docs: Adding requirements and a component change request for vajson #2358
• trlc dependencies everythere -> fix needed
• Progress Review https://github.com/eclipse-score/score/issues/2224-> next steps needed

[anmittag]

2026-01-08

Participants

• @anmittag
• @antonkri
• @FScholPer
• @nmohanan31
• @pawelrutkaq
• @christanr9911
• @qor-lb

• Runners: ETAS shifted one from another Eclipse Project to S-CORE => ask infrastructure team if this helps (tag: ditto-runner)

  • GitHub: Staff GitHub with enough Resources #2359

• QNX RUST certifications: Pawel is organizing a meeting, each company shall participate to emphasize S-CORE interest => nominate a representative here. Question-sheet would be helpful in advance. Timeline? Commitment? AoU? SafetyManual?

  • Please fill questions in ticket SCORE <-> QNX <-> FERROCENE meeting #2394

• Architecture F2F Workshop? Will be discussed next Monday.

• For next meeting: Logging Feature Complete #633, [Static Code Analysis] Definition of static code analysis checks (compiler + clang-tidy) #1558

[FScholPer]

2026-01-09

Participants

• @anmittag
• @antonkri
• @FScholPer
• @nmohanan31
• @pawelrutkaq
• @christanr9911
• @qor-lb

Agenda

Meeting minutes

• Scope next 0.5 milestone build proposal:
  • Automatic module template sync AI: @FScholPer
  • Unit test coverage AI: @PiotrKorkus
  • Every unit test part of reference integration AI: @antonkri
  • Static code analysis -> Alignment ruleset. Findings leads to build error
  • New bazel toolchain rollout AI: @antonkri
    • Compiler Flags (Santizer)
    • https://github.com/aspect-build/rules_lint/releases -> decision for linter needed
  • S-CORE CLI AI: @FScholPer
  • Testing of Codelinks -> persistency
  • Finalize Metamodel -> AI: @antonkri
  • QCC in Reference integration AI: @AlexanderLanin
  • Cleansing of QEMU QNX Image
  • QNX image artifacts as part of the release
  • Raspberry Image -> AI: @dcalavrezo-qorix
  • SCTF / ITF (VIPER on top?!) https://github.com/eclipse-opendut/opendut/tree/main/opendut-viper
  • Release Notes for main repo as part of release workflow
  • Define Location o Release notes (reference or score repo)
  • First ferrocene build
  • Lifecycle and health
• Progress Review (Todo: Checklist)
• PL Circle: Naming Versions

[anmittag]

2026-01-12

Participants

• @anmittag
• @antonkri
• @FScholPer
• @nmohanan31
• @pawelrutkaq
• @christanr9911
• @qor-lb
• @sankurm
• @johannes-esr
• @odra

Agenda

- Scope next 0.5 milestone - build proposal (E01/2026)

• it looks like it will not be the final version, so we have to align the purpose of the next milestone
• decision: we will continue on a 6 week cadence for releases/milestones (0.6, 0.7, 0.8, ....) with 2 week iterations
  • develop-iteration a, b, release-itearation-c => update the pmp Update Cadence in the PMP #2401
• Automatic module template sync AI: @FScholPer
  • purpose: keep the repos similar
• Unit test coverage AI: @PiotrKorkus
  • purpose: getting overview for C0/C1; being finally able to set limits
• Every unit test part of reference integration AI: @antonkri
  • purpose: all available tests are performed
• Static code analysis -> Alignment ruleset. Findings leads to build error
  • purpose: clean code with same ruleset for all
• New bazel toolchain rollout AI: @antonkri
  • Compiler Flags (Santizer)
  • https://github.com/aspect-build/rules_lint/releases -> decision for linter needed
• S-CORE CLI AI: @FScholPer (as a separate repository) => infrastructure team
  • purpose: ability to create fitting skeletons
• Testing of Codelinks -> persistency as pilot
  • purpose: creating traceability
• Finalize Metamodel (repository and artifacts location) -> AI: @antonkri
  • Decision Record is already there (no5 (?))
• QCC in Reference integration AI: @AlexanderLanin
• Cleaning of QEMU QNX Image (Elektrobit)
• QNX image artifacts as part of the release
• Raspberry Image -> AI: @dcalavrezo-qorix
• SCTF / ITF (VIPER on top?!) https://github.com/eclipse-opendut/opendut/tree/main/opendut-viper (@antonkri)
• Release Notes for main repo as part of release workflow (already discussed)
• Define Location o Release notes (reference or score repo) => Metamodel discussion
• First ferrocene build
• Lifecycle and health
• Progress Review (Todo: Checklist from Eclipse Handbook)
• PL Circle: Naming Versions
• Alignement Meeting Agenda proposal
  • Planning

[anmittag]

2026-01-15

Participants

• @anmittag
• [] @antonkri
• @FScholPer
• @qor-lb
• [] @johannes-esr

Agenda (who / prio)

• PMP-PM planned updates (@anmittag / Prio A)

  • general: prupose of PM is to plan and track work, ensure quality, escalate etc.
    • need to use common templates, checklists, workflows etc. otherwise neither ASPICE, nore ISO26262, ISO21434 can be fulfilled
  • Issues
    - only in repo-score to have all issues in one place
    - unified status flow for all issue types (& projects), avoiding status mismatch
    - project suggestions
    - a) just S-CORE Roadmap with several views
    - b) all have to use the same status flow, automatism has to be introduced to keep status`s in sync
    - why a): https://github.com/orgs/community/discussions/63960, https://github.com/orgs/community/discussions/63823

  @anmittag: decision record to be created for next monday

  • Repostructure unification
    - otterdog-jsonnet (local template for module, infra, web repos)
    - who is the owner of which repo ?
    - remove bypassing, use codeowner as reviewer instead => to be discussed with @antonkri
    - repostructure template to be used
    - consequences????
    @anmittag test changes with test_repo

• How to plan / handle new Module features (@FScholPer)

  • (Epic Issues / Feature Issues...)
    => Epics

• Next steps Time Module (@FScholPer)

  • [Contribution Request] Time #1765

• INFO: QNX Rust Certification Meeting (@FScholPer)

  • 21.01. 16:00-17:00 [Toolchain]Safety qualifiable Rust toolchain #2434

• Diagnostic FaultLib -> next steps (@FScholPer)

  • Qorix will provide an initial implementation

• INFO: F2F shift to March/April => Time online (probably next Monday)

[anmittag]

2026-01-19

Participants

• @anmittag
• @antonkri
• @FScholPer
• @qor-lb
• [] @johannes-esr
• @nmohanan31
• @DanielSteinkeSDV
• @chheis
• @opajonk

Agenda

• PlugFest HS Esslingen 28.-29. April (@chheis)

  • https://docs.google.com/presentation/d/1HyA4op0l0SQXvDg22sIxt5XPsj4rXtj6/edit?slide=id.g3affca47248_0_493#slide=id.g3affca47248_0_493
  • Idea: having S-CORE running on a RASPI (in advance) best with EB-Coros / AutoSD to avoid license issue
  • Adding OpenSOVD on S-CORE and get it running
  • Need from S-CORE: RASPI-HW, RASPI - Images, Participants (10-15)

[antonkri]

2026-01-22

Participants

• @anmittag
• @antonkri
• @FScholPer
• @qor-lb
• @johannes-esr
• @nmohanan31
• @DanielSteinkeSDV
• @chheis
• @opajonk
• @thilo-schmitt

Agenda

[14:00 - 14:30] Committer election for newly added components with existing code base

1. Adding Software Developers as Committers for Recently Added Code:

• Question:
  Should we be able to add software developers as committers for code recently added to the project (initial commit based on an existing contribution) even if those developers have not actively participated in the S-Core project before?
  This is similar to how new Eclipse projects are created.

• If not:
  Who will have sufficient technical understanding of the contributed code to perform the technical review?
  Who decides whether a Pull Request (PR) should be merged in such cases?

2. Understanding of the Committer Role in the Project and S-Core project itself:

• Proposal:
  • The S-Core project should not be treated as an "integration project" but as a platform.
  • Therefore, most components (where technically feasible) should be part of the same GitHub organization, avoiding the creation of separate Eclipse projects for every module/component.
  • Committers should be nominated per component/repository and access restricted using CODEOWNERS files accordingly.
  • Project Leads (currently also the technical leads) should handle project-wide maintenance tasks.

3. Voting and Decision-Making:

• Every vote with a “-1” (disapproval) should include a well-founded argument explaining the reason.

[14:30 - 15:00] Create release ticket for v0.6 (or we do the same in the milestone description)

• Provide brief description of main achievements planned for v0.6
• link existing tickets / double check whether we have tickets for everything.

[opajonk]

Unfortunately I cannot join today.

• "Committer election for newly added components" and the restriction per component/repository via CODEOWNERS sounds reasonable.
• "Create release ticket for v0.6" --> doing more releases on the way to 1.0.0 is definitely a good idea.

[anmittag]

Committer election for newly added components with existing code base: proposal supported from my side

[thilo-schmitt]

Documenting my thoughts. We can discuss all of this in the meeting.

to 1.

As stated this is similar to the creation of a new project. It's only "similar", because it doesn't leverage the existing processes established and supported by Eclipse workflows. Those processes and workflows have already a proven track record and are well designed, tuned and refined over time. In contrast we would be adding our own private process around this, which will be naturally not as mature. We would gain similar functional characteristics but will also have quite some areas that are undefined. And even the functional characteristics will be based on a weaker technical measures. Concretely and as an example, this will be based on the CODEOWNERS mechanism which is not specifically designed for this, is weaker than dedicated project boundaries (i.e. GitHub organization) and on top there is no well-defined way of "electing" a person for inclusion as a code owner. Essentially, we don't gain any benefits (actually, it's more of the opposite) and recreate a process/mechanism that already exists and is proven working.

to 2.

I disagree with the direction S-CORE not being an integration project. In fact, this is exactly the opposite to how the project was proposed and intended to be when we created it. And this was not a minor thing, we were pretty loudly communicating this - there is even dedicated slides for this in the canonical S-CORE slide deck we've used and shown basically everywhere. When we initiated this project, it being an "integration project" was one of the things we intentionally decided and signed up for. I'm not willing to reverse such a fundamental decision as a by-product in a discussion how we handle onboarding new components and their maintainers.

Furthermore, even if we were to say S-CORE is not an integration project, the deduction that separate Eclipse projects per module/component have to be avoided and everything must live in one GitHub organization, is not necessarily valid. Granted, I can see it would create some kind of impression that S-CORE would be an integration project when we don't want it to be one. In any case, it's not necessarily a must to have everything under one GitHub org. That's simply a decision how we want to structure things technically - and whether we want to leverage existing proven-working processes or not.

Also, the proposal redefines the roles of a Committer and Project Lead, while this is fixed terms and definitions in Eclipse Foundation's governance and ruleset under which we are sailing. It's not in this project's power to redefine it, nor to re-interpret or bend it. I would argue, we all have willfully entered into this ruleset, by being members of Eclipse / Eclipse SDV WG, or having executed the ECA or agreed to it on project creation. Let's embrace it, not fight it.

Conclusion

I am strongly opposing the proposal. Instead I suggest following the defined rulesets, processes and mechanisms by Eclipse - using and leveraging it, not creating a weaker duplicate. Also in the spirit of the fundamental design decision of S-CORE to be an integration project, I would create separate projects for each module/component. Initial committer setup and committer elections can then follow Eclipse standards gracefully, without any conflicts or PMC interventions, while achieving the same functional characteristics.

[opajonk]

Well argued, I have to say. I am unhappy I cannot fully join the round. I will try to.

[FScholPer]

Statement from PMC: https://www.eclipse.org/lists/automotive-pmc/msg00989.html

[johannes-esr]

2026-01-26

Participants

@antonkri
@FScholPer
@qor-lb
@johannes-esr

Agenda & Meeting Minutes

• Content of next Release, based on https://github.com/orgs/eclipse-score/discussions/516#discussioncomment-15472882
  • Rollout of automatic module template sync for every module
  • Rollout of new C++ toolchain for every C++ module (gcc_x86, qcc_x86, qcc_arm, unit_test gcc_x86)
  • Unit test coverage measurement als CI job in module's repo and reference_integration repo
    • Check with @PiotrKorkus/@MaximilianSoerenPollak how we can visualize unit-test coverage in the reference_integration repo
  • Static code analysis with clang-tidy for C++
    • rollout checks with clang-tidy as CI job in every module repo and in reference_integration
    • create an overview for clang-tidy configuration and which Misra checks are covered by the clang-tidy checks
  • Code formatting for C++
    • rollout checks with clang-format in every module repo and in reference_integration
  • Dynamic code analysis for C++
    • rollout sanitizers in every module repo and in reference_integration
  • Buildifier
    • rollout buildifier in every module repo and in reference_integration
  • Images
    • Extend scrample application with test for datarouter and persistency
    • Collect DLT logs and document the demo application properly
    • Automated generation of "hello world" application and with support in dev container.
    • Provide images for downloading: QNX@raspberry PI, EB/RedHat/AGL Linux@raspberry PI