Release Community Meeting Minutes

[antonkri]

2025-08-05

Participants

@antonkri

Meeting Minutes & Agenda

• Review proposal for goals and next steps
• What has happened till now
  • Reference integration concept:
    • 
    • The 1st draft of score repository structure proposal #1475
  • Qemu Demo
    • https://github.com/eclipse-score/reference_integration/tree/main/qnx_qemu
• Agreed on who takes over which activity:
  • @rafaelfronza takes over responsibility on documenting and setting-up the reference integration repo and gate and @AlexanderLanin will support him:
    • [I-Gate] Define repo structure & integration strategy #1542
    • https://github.com/eclipse-score/score/issues/1543
  • @odra will take over set-up of RedHat Linux image and its execution in Qemu. For this @odra will contact @mohamed riad to see how it was done for Qnx.
    • [Unit-Test] Toolchain roll out in I-Gate #1546
  • @odra will take over gcc integration and update
    • [GCC] Toolchain roll out in I-Gate #1544
  • @Xinq will take over qcc integration and update
    • [QCC] Toolchain roll out in I-Gate #1545
• Agreed on follow-up date to review planning of activities
  • Follow-up meeting in 3 weeks to present current status and results
  • @antonkri Set-up a special meeting for those who decided to help to give a better overview how the integration into bazel should happen.

[opajonk]

@antonkri Please send me the invite for the next meetings as well; I think I got missed in the first round.

[tmewett]

I would like to join too, if possible

[evinoth1206]

Hello, I would like to also join in the reference integration topic. Is this already discussed in any of the regular exchange meetings?

[AlexanderLanin]

This discussion is quite old. Nevertheless please note that we have a concept discussion at https://github.com/orgs/eclipse-score/discussions/1966

[FScholPer]

2026-02-06 Kickoff Meeting

Participants

@antonkri
@FScholPer
@AlexanderLanin
@anmittag
@opajonk
@PiotrKorkus
@pawelrutkaq
Antonio Rosario Intilisano
@NicolasFussberger
@evinoth1206
@kgraeper
@MaximilianSoerenPollak
@masc2023

Agenda

• timeline
• reference_integration repo reshape into reusable state (already lot done on prep_0.6 branch)
• branching strategy proposal
  • "release/v0.6" on ref_int.
  • force other modules also to create a release branch?
• Unit-test measurement coverage and reporting in reference_integration
• Downloadable image, ideally raspi
• execution of sanitizers in reference_integration for cpp components
• Formal release aspects,
  • https://eclipse score.github.io/process_description//main/process_areas/release_management/release_workflow.html#wf__rel_platform_rel_note
    https://eclipse-score.github.io/process_description//main/process_areas/release_management/release_workflow.html#wf__rel_mod_rel_plan
    https://eclipse-score.github.io/process_description//main/process_areas/quality_management/quality_workflow.html#wf__vy_ap_pltrelease
    https://eclipse-score.github.io/process_description//main/process_areas/release_management/release_workflow.html#wf__rel_mod_rel_plan

Meeting Minutes

• timeline -> freeze begin of 9th of Feb 2026. Release date will be 23th of Feb 2026
• Contents of the release
  • QNX Image
  • Unit test coverage
    • 1. Step @pawelrutkaq will prep a pr of prep_0.6 branch of reference_integration to restructure the repo
    • 2. Step Create a release branch "release/0.6" in reference_integration repo
  • FT can decide if they want to use release branches or master for the release
  • AI: @FScholPer create a polly for two meetings next week in slack
  • Code Coverage: Template in https://github.com/eclipse-score/docs-as-code/blob/main/.github/workflows/test_and_docs.yml
  • @antonkri AI: takes care of the c++
  • @kgraeperAI: Change the unit-test.yaml
• Binary Raspi build eblinux exists but in beta -> next meeting @opajonk keeps update
• Raspi tarball still not accessible -> @antonkri update

[NicolasFussberger]

I would like to know the future of reference_integration/qnx_qemu. Whether this is the correct place to integrate further modules?
Currently, reference_integration/qnx_qemu is using very old versions of dependencies and seems to be independent of the "known_good" module combination.

[antonkri]

Unit-test measurement coverage and reporting in reference_integration

[antonkri]

Downloadable image, ideally raspi

[antonkri]

execution of sanitizers in reference_integration for cpp components

[masc2023]

Formal release aspects,
https://eclipse-score.github.io/process_description//main/process_areas/release_management/release_workflow.html#wf__rel_platform_rel_note
https://eclipse-score.github.io/process_description//main/process_areas/release_management/release_workflow.html#wf__rel_mod_rel_plan
https://eclipse-score.github.io/process_description//main/process_areas/quality_management/quality_workflow.html#wf__vy_ap_pltrelease
https://eclipse-score.github.io/process_description//main/process_areas/release_management/release_workflow.html#wf__rel_mod_rel_plan

[FScholPer]

2026-02-11 Release Team Meeting

Participants

@PiotrKorkus
@masc2023

Agenda

• Bazel.module
• Rust Coverage

Meeting Minutes

• New version in bazel.module will be 0.0.0. Rest still the same
• Rust Coverage please use the ferrocene toolchain
• @PiotrKorkus will align with Eelco to do the next steps for coverage

[FScholPer]

2026-02-13 Release Team Meeting

Participants

Agenda

• Checklist v0.6
• Reference Integration Update

Meeting Minutes

• Reference Integration restructuring still in progress

• Coverage still in progress

[FScholPer]

2026-02-18 Release Team Meeting

Participants

@antonkri
@4og
@pawelrutkaq
@PiotrKorkus
@dcalavrezo-qorix
@AlexanderLanin
@nradakovic
@RolandJentschETAS
@pawelrutkaq
@masc2023
J Lukasz
@MaximilianSoerenPollak
@johannes-esr

Agenda

• FEO part of the release or not
• Release notes
• Current state Reference Integration
• Logging state
• Unit tests (not everything works)- Baselibs
• AutoSD failing
• EB Linux

Meeting Minutes

• AutoSD & EBLinux open
• QNX tarball working
• Updated Release Checklist
• FEO experts are currently not responding via Slack. Will be discussed at tech lead circle tomorrow. Proposal: exclude for now, FEO can raise PR in reference_integration to add it back in. // Update: @johannes-esr will look into it.
• No further blockers identified

[odra]

is this meeting in the shared calendar?

[RolandJentschETAS]

2026-02-18 Release Team Meeting

Participants

@PiotrKorkus
@RolandJentschETAS
@pawelrutkaq
@FScholPer
@MaximilianSoerenPollak
@odra
@opajonk
@AlexanderLanin
@4og
Dan Calavrezo
Glamsch, Johannes

Agenda

Checklist v0.6

Meeting Minutes

• Updated Release Checklist

• Highlights:

• Baselibs is fine
• FEO is not included in V0.6 (also not in reference integration)
• Communication from main latest version shall be used
• Bazel cpp toolchain 0.2.2
• Logging 0.1.0
• Persistancy 1.3.0
• Platform 0.5.3
• test_scenarios 0.4.0
• toolchin v0.4.0
• tooling 1.1.2
• lifecycle 0.1.0

• PR for v0.6 created, but will not be finished until 23.2.2026

[FScholPer]

2026-03-10 Release 0.6 Lessons learned

Participants

• @4og
• @FScholPer
• @thilo-schmitt
• @dcalavrezo-qorix
• @masc2023
• @RolandJentschETAS
• @odra

Agenda

• EPIC: Work Product Reviews process_description#564
• Releases on Thursday instead of Friday(Monday)
• Checklist is inefficient - too much time to get the updates, untraceable who and when marked something
• We need overall definition what common changes are expected from modules in 1st week (e.g. toolchains, supported build configurations, NOT feature implementation scope)
• Create a list of modules and their direct point of contacts (min. 2 people per module, must be a Committer)
• Agreed release process is needed as mandatory for 0.7 or we shall postpone
• docs: release process documentation reference_integration#168
• SCORE announcements channel? Only Leads can send messages, everyone can comment

Meeting Minutes

• Next Steps: yanking of com -> Posponed until next regular meeting
• Regular Meeting: Polly in slack
• Chair of Release Team: @PiotrKorkus will take the lead
• EPIC: Work Product Reviews process_description#564 -> Should be part of PMP -> reopen the Ref PR in score repo as PMP change
  • Qualtity Gate needed
  • Issue template for releasing -> @FScholPer bring in the old as template
• Releases on Thursday instead of Friday(Monday): proposal move to thursday: Polly for the day (Tuesday / Thursday)
• Checklist should be switched to issues(including subissues):
  • Define the checklist in the first Planning meeting of the next release.
• We need overall definition what common changes are expected from modules in 1st week: Start with release letter document and collect there
• Release Responsible(at least 2) of individual FTs: 1. Step PRs in ref, 2.Validation pipeline,...-> docs: release process documentation reference_integration#168. -> Voting should take place inside FTs. Only codeowners of that FTs can voted(Maintainers documented in ref int json)
• Agreed release process is needed as mandatory for 0.7 or we shall postpone: @PiotrKorkus will take the lead
• Announcement Channel for developers(if decision needed) should be created -> Tls bring in proposal
  • Option 1: Mailing list
  • Option 2: Slack Channel
  • Option 3: ???
• Artifacts creation worked good in 0.6
• Crisis creation path needed (communication to outside world)
• @thilo-schmitt -> GO/NO-GO Decision Process.
• Will for go decision should be there -> mitigation in the individual decision
• Release Note template -> @aschemmel-tech https://eclipse-score.github.io/process_description/main/folder_templates/platform/docs/release/release_note.html -> please everybody check if it fits.
• Progress Review -> Create common validation / Scripts to rollout mandatory changes into all repos. -> Oct / Nov we should trigger again.
  • infra - community should come up with a proposal

[PiotrKorkus]

• Releases on Thursday instead of Friday(Monday)
• Checklist is inefficient - too much time to get the updates, untraceable who and when marked something
• We need overall definition what common changes are expected from modules in 1st week (e.g. toolchains, supported build configurations, NOT feature implementation scope)
• Create a list of modules and their direct point of contacts (min. 2 people per module, must be a Committer)
• Agreed release process is needed as mandatory for 0.7 or we shall postpone
  docs: release process documentation reference_integration#168
• SCORE announcements channel? Only Leads can send messages, everyone can comment

[PiotrKorkus]

2026-03-12 Release Team Meeting

Participants

Agenda

v0.6.1 Release

• no release of communication in bazel_registry
  • even if released it wont work: dev_dependencies need to be patched
• score_bazel_cpp_toolchains which version shall be used?

v0.7 Release

• Required agreements to start v0.7 release - all CFTs need to sign-off:
  • Release process description #2671
  • what is run in ref_int - UTs, static code analysis, code coverage, build: linux_x86_64, qnx_arch64, autosd_x86, eb_arch64
  • release workflow like in communication - no more manual workflows

Meeting Minutes

v0.6.1 Release

• other modules have version "0.0.0", no version is unexpected and not handled currently -> merge manually and then update bazel registry scripts to handle no number AND zero version.
• discussion whether to do release or not -> v0.6.1 will be skipped

v0.7 Release

• Release process description #2671 - All the review comments should be applied before 19.03
• the decision record for what is needed and run in reference_integration repo -> check the process, organize separate meeting. @anmittag will organize the meeting. Target day is to have something already prepared for next meeting 19.03
• no more manual releases in modules - breakout session to discuss the scope of the checks and common reusable workflow. It needs previous point to be completed to start. @pawelrutkaq will take this topic further.
• in bugfix releases it is not possible to execute pull_request_target workflows as they use code from default branch instead of the target one.

[LittleHuba]

Statement from communication module:

v0.6.1 Release

Registry Release

bazel registry release blocked by the patcher not taking modules without version tag into account.
Bazel documentation clearly recommends to not put the version in a MODULE.bazel file outside of the registry.
See: https://bazel.build/external/faq#module-versioning-best-practices

Dev-Dependencies

Our dev_dependencies are purposefully set in exactly this way. Our public API of the module consists of production targets a user may use. Any development artifacts are not part of the public API. This aligns with common practice of other bazel modules in the bcr.
We are convinced that this is the correct approach and see no reason why S-CORE should diverge from the proven approach in the bcr.
Thus, we do not want to have this patched in our release in the bazel registry.

The reference integration should do integration tests and not run unit tests.
We run the unit tests as part of the release workflow. In our opinion, rerunning all these tests in the reference integration holds no benefit. It costs resources to rerun tests that are already a gate of creating the release.

We strive to make communication a SeOOC. From integration perspective we should be treated as blackbox and not whitebox.

Finally, making dev-dependencies official dependencies has several consequences:

1. Users always must pull these dependencies even when they do not use that infrastructure
2. Integrators must use in their project the exact same version of all non-dev_dependencies. Bazel forces that. Elevating some of our dependencies to normal dependencies would make it impossible for us to integrate communication in our internal project.

We are happy to discuss specific dependencies based on use case. But the basic requirement is that there is a production use case for that dependency.

v0.7 Release

Release Process Description

I'll take this description with me and discuss it with the maintainers of the module. We will directly review on the PR. For the moment I put a Change-Request to enforce the approval from our side.

What to run in reference_integration

We strive to make communication a SeOOC. This means that our internal tests must already assure that we fulfill our safety-relevant requirements based on our AoUs. To use our SeOOC the reference integration must adhere to these AoUs.
Running our internal tests again in the context of the reference integration will only give you the same results that we hand over as part of our safety artifacts anyway. In other words, the reference integration would duplicate the work we already do for our releases without additional benefits.

Thus, the reference integration should treat the modules as SeOOCs and focus on testing integration of them. Plus additionally what is necessary to make the reference integration itself a SeOOC.

For modules as communication or baselibs, we propose to put more focus on what the release workflow should check and support a motion towards a mandatory release workflow for all modules.

Please keep in mind that a mandatory release workflow does not mean that each module must use the exact same workflow.
It only means that each module must have one. We can discuss how we support modules in aligning on common strategies. Requirements, actions, automated checks are good tools to support in this direction. Over time modules will converge naturally. Forcing this convergence early on through a mandatory shared workflow will slow down innovation.

[RolandJentschETAS]

No, the component have to fulfill to feature requirements and not their own AoU. Otherwise we will not have a platform ...

[evinoth1206]

I agree with the dev dependency comment. Here we need to find an alternative way or apply this patch only in test workflow execution.
However, in reference integration, test re-execution is necessary since the toolchain versions, bazel dependencies, and compiler options may differ from the component release. Consequently, the SEooC approach cannot be justified in such cases.

[PiotrKorkus]

Meeting minutes - What to run in reference integration ( 17.03.2026 10 AM)

Participants

Record

• @antonkri : Run all UT and Quality checks in modules, in ref_int run FIT, showcases, collect all artefacts into ref_int
• @thilo-schmitt : When running quality checks in modules, we will have distributed reports that are hard to grasp. Finally, in favour of running all checks in ref_int once again to be on the safe side and have it all in one place.
• @LittleHuba : Running all in ref_int may be cause resource issues (runners + cache storage + timing). Finally, in favour of not running quality checks in ref_int and use ref_int as AoU provider for modules (ie. for toolchains, compilation flags etc)
• @4og : Same as @LittleHuba
• @anmittag Need to redicuss internally.

Decisions

• Decide in the TL meeting on the way forward - @pawelrutkaq and @PiotrKorkus will join to help with more context about ref_int
• Decision agreed that each module have it's own release cycle, cadence that does not need to be the same as S-CORE (ie. module can release 5 times in a single S-CORE release window). Still, they need to provide a viable release for the conducted S-CORE release.

FYI: If I am wrong somewhere, please comment and I will fix.

[PiotrKorkus]

Meeting minutes - 27.03.2026 14:00

Participants

• Alexander @AlexanderLanin
• Andreas @anmittag
• Anton @antonkri
• Lars @qor-lb
• Markus @masc2023
• Pawel @pawelrutkaq
• Piotr @PiotrKorkus
• Thilo @thilo-schmitt

Agenda

• Status update on what to build, test and how to integrate modules in reference_integration repository

Minutes

• @AlexanderLanin:

The topic is how test responsibility is split between modules and integration in S-CORE, viewed through a SEooC-like approach.
The core question is whether modules are treated as independently validated units (SEooCs) with defined assumptions and guarantees, or whether integration additionally re-verifies them in the concrete system context.
In a SEooC-oriented model, modules are developed and tested out of context and provide clear guarantees. Integration mainly ensures that the assumptions of each module are fulfilled in the system.
At the same time, integration can optionally re-run tests. This is not strictly required from a formal SEooC perspective, but it can significantly increase confidence that the modules behave as expected in the actual system setup. This is especially valuable when dealing with changes in hardware, compiler settings, or runtime environments, where subtle integration effects may not be fully covered by module-level validation.
In essence, modules provide SEooC-style guarantees, while integration can optionally re-verify them to strengthen confidence that those guarantees hold in the real system context.

• @antonkri:

- S-CORE provides a set of SEooCs. The reference integration shows that these SEooCs can be integrated to a consistent Safety Case of the platform.
- Dont use known_good.json - stick to MODULE files.
- Some base modules e.g. baselibs do not need definition of specific version in reference_integration. Bazel should take care of resolving and finding correct version itself.
- What modules do in their repositories is up to them. Reference_integration is a place where everything comes together and we need to verify that all tests are passing with resolved versions.

• We need to define a what is happening when a module does not want to follow defined process. Excluding a module is not a solution.
• SCORE as full stack - https://eclipse-score.github.io/score/main/design_decisions/DR-001-strat.html
• @masc2023: In reference_integration at least tests that were NOT executed by the module have to be executed. Other Meeting Participants agree that all tests should be re-executed in reference_integration.
• @qor-lb What is the point of being a part of SCORE for the Module if they don't want to follow the process agreed in SCORE.
  SCORE should start enforcing following processes defined.
• Modules can be independent but the minimum is to follow the baseline defined in SCORE.

Decision record to be prepared by @pawelrutkaq and @PiotrKorkus.

[PiotrKorkus]

Meeting minutes - 08.04.2026 11:00

Participants

• Alexander @AlexanderLanin
• Andrey @4og
• Andreas @anmittag
• Anton @antonkri
• Frank @FScholPer
• Lars @qor-lb
• Markus @masc2023
• Pawel @pawelrutkaq
• Piotr @PiotrKorkus
• Thilo @thilo-schmitt

Agenda

• Discuss Option#3 Decision record - reference_integration scope #2747 (review)

Minutes

Discussed details of Option #3.

Dependencies checks and collecting artifacts will not be possible for CI on main branch of ref_int using hashes.
Module Owners need to deliver artifacts in the common form for aggregation in ref_int.
Bazel mod will enable dependency analysis to confirm release of the Module was created with correct version of tools etc.
Ref_int will run Feature Integration Tests and examples from the Modules.

@PiotrKorkus to prepare update of DCR

[PiotrKorkus]

Meeting minutes - 16.04.2026 11:00

Participants

• Alexander @AlexanderLanin
• Andreas @anmittag
• Anton @antonkri
• Ante @antres1
• Dan @dcalavrezo-qorix
• Frank @FScholPer
• Lars @qor-lb
• Markus @masc2023
• Pawel @pawelrutkaq
• Piotr @PiotrKorkus

Agenda

• Regular meetings established on Tuesdays 10:00 CET
• Release v0.7 checklist Release v0.7 #2791

Minutes

• Join link for regular reference_integration meetings: https://eclipse.zoom.us/j/82705116449?pwd=69bbzVqu9mrdEQdMmqE0RvmUbITWjf.1
• Keep FEO out of release v0.7
• Checklist has been updated
• The release will follow similar approach to v0.6 - Modules do a codefreeze on Monday 20.04 - if they want to continue merging features to main branch, release branch needs to be created. Module owners need to create a release with the tooling version defined in the checklist.
• @PiotrKorkus will create a release candidate in reference_integration once all Modules prepare their releases
• General release notes will be moved to reference_integration repository. We will prepare highlights as part of release_candidates, there will be links to full-release notes directly in each Modules' repo

[PiotrKorkus]

Meeting minutes - 21.04.2026 10:00

Participants

• Anton @antonkri
• Max @MaximilianSoerenPollak
• Piotr @PiotrKorkus

Agenda

• Release v0.7 checklist Release v0.7 #2791
• dev_dependency - what deps should be dev, do we still need to upgrade if its dev?
• score_platform release
• DR008 Decision record - reference_integration scope #2747

Minutes

• @MaximilianSoerenPollak docs-as-code cant be really a dev_depenendency as we build docs in ref_int
  e.g. IDE integration can be dev_dependency as it is not used outside of the Module.
  @antonkri to clarify internally why dev_dependencies in communication are not relevant to be upgraded. -> We wont execute UTs, wont be able to build documentation

• score_platform release to be clarified on Thursday Tech Lead call

• Initial scope for v0.8 - bazel upgrade to at least 8.6.0 and lockfiles usage for bazel commands

[PiotrKorkus]

Meeting minutes - 28.04.2026 10:00

Participants

@FScholPer
@AlexanderLanin
@LittleHuba
@nradakovic
@S-MOHAMD
@pawelrutkaq
@RacheleSetto
@masc2023
@odra

Agenda

• Release v0.7 checklist Release v0.7 #2791
• logging requesting releases from baselibs and communication

Minutes

Release v0.7

• Baselibs 0.2.6 - integrated in ref_int
• Baselibs_rust 0.1.2 - integrated in ref_int
• Communication v0.2.0 - integrated in ref_int, new release possible as requested by logging
• Persistency - Qorix will support for release preparation
• Kyron - integrated in ref_int with hash, release pending
• Orchestration - integrated in ref_int with hash, release pending
• Lifecycle - was failing integration, PR with fix dependencies and bump was merged
• Logging - was failing integration, CW17 export pending, check integration after its merged CW_17 export logging#100

Decision record

Eclipse has no tools for voting on multiple options.
Idea from Alexander: Only Tech Leads should decide witch options should be chosen. They should take input from other committers.
Frank proposed to do a single vote per company. Each company has to decide internally which option they choose.
If there is no agreement among single company, we would need to conduct voting involving all committers.
@PiotrKorkus will update PR with technical comments after v0.7 and enable companies to use it as basis for their internal discussion.

Kind reminder: Companies should decide what is the best for SCORE, not for just them.

[PiotrKorkus]

Meeting minutes - 21.07.2026 10:00

Participants

@PiotrKorkus
@antonkri
@masc2023
@AlexanderLanin
@RacheleSetto
@anmittag
@evinoth1206
@4og

Agenda

DR8 implementation

• implementation status
• which jobs to run in ref_int

SCORE v0.8 - retro

• how far were we from filling v0.8 goals?
• when v0.8 gaps will be closed?
• how confident are we to fulfill v0.9 + v0.8 overhead?

Minutes

DR8 implementation

• ref_int - dependency resolve, overwrite and execute as in root module are currently drafted as PRs in ref_int repo
• modules should use common configurations, either use .bazelrc file from ref_int or MODULE TEMPLATE repo should provide common files feat: shared bazelrc config? infrastructure#16
• communication coverage tooling will be extracted to common place after baselibs and pers will finalize checks on their side

SCORE v0.8 - retro

• score_baselibs
  not everything from v0.8 was closed
  arch and req inspection unfinished, should be finished till end of the year
  new code is being added which delays reqs and arch
  testlinks will be added to requirements

• score_communication
  not joined

• score_persistency
  not joined

• score_orchestrator
  not joined

• score_kyron
  not joined

• score_lifecycle_health
  not joined

• score_logging
  not joined

• score_time
  not joined

Misc

• https://github.com/eclipse-score/module_template/blob/main/docs/verification_report/module_verification_report.rst will be updated
  to be discussed next week

[PiotrKorkus]

Meeting minutes - 28.07.2026 10:00

Participants

@PiotrKorkus
@antonkri
@OliverHeilwagen
@AlexanderLanin
@masc2023
@RacheleSetto
@evinoth1206
@FScholPer
@olivembo
@4og

Agenda

Module verification report update

• https://github.com/eclipse-score/module_template/blob/main/docs/verification_report/module_verification_report.rst

Code coverage evaluation

• https://github.com/orgs/eclipse-score/discussions/2390?sort=new#discussioncomment-17733192

DR8 checks

Review fixes ongoing

Integrate newest version of modules

Every module bump in ref_int repo at least every 2 weeks with git hashes to the newest version.

Minutes

Module verification report update

No update in place yet. Process community requested to split into 2. PRs are under review.

What about traceability report? We should have a way to display dashboards in sphinx-needs for feature, component requirements.
Docs build executes python script that generates traceability metrics, can be extended e.g. with per variant statistics.
https://github.com/eclipse-score/docs-as-code/blob/main/scripts_bazel/traceability_metrics_schema.json
Example filled metrics.json -> https://github.com/eclipse-score/persistency/blob/gh-pages/main/metrics.json
Docs build relies on test execution, so bazel-testlogs directory needs to be present during docs build in order to establish traceability.

Goal for v0.9 - to have in modules statistics with tracebility within github pages

DR8 checks

Second round of review pending
eclipse-score/reference_integration#278
eclipse-score/reference_integration#280

Code coverage evaluation

Rust implementation ongoing in communication. eclipse-score/communication#772
C++ has some issues with line coverage with templates - reported by baselibs. It is not a show stopper for now, we could keep the solution and do the fix in llvm upstream.
LLVM should be located in central place to be used by all modules.

Slack discussion: https://sdvworkinggroup.slack.com/archives/C08C0JATADP/p1784805528757259

Integrate newest version of modules

Every module bump in ref_int repo at least every 2 weeks with git hashes to the newest version.
@PiotrKorkus will create a single PR in ref_int to bump all modules on Friday 31.07

[PiotrKorkus]

Meeting minutes - 04.08.2026 10:00

Participants

@PiotrKorkus
@RacheleSetto
@LittleHuba
@FScholPer

Agenda

Module verification report update

Modules bump

Minutes

Module verification report update

• https://github.com/eclipse-score/module_template/blob/main/docs/verification_report/module_verification_report.rst

One of the PRs is merged, new to DaC was added with templates and inspections which is not yet merged.

Integrate newest version of modules

CW31 modules bump: eclipse-score/reference_integration#302

DR8 workflows needs to be finalized ASAP and brought to main of ref_int, then we can schedule regular bumps of the modules.

[PiotrKorkus]

Meeting minutes - 11.08.2026 10:00

Participants

@PiotrKorkus
@OliverHeilwagen
@evinoth1206
@kgraeper
@opajonk
@chheis
@4og
@AlexanderLanin
@FScholPer

Agenda

dev_dependency handling in integration workflow

Minutes

dev_dependency handling in integration workflow

"Important" dev dependencies such as GTest that artifacts are collected from should be defined as single version in ref_int and then this version should be used for all executions in downstream repos. Not relevant dependencies can be omitted - ones that we dont collect artifacts from e.g. Hedron compile commands.

DaC v7

Process changes, very release is breaking due to process changes.
Introduced warnings are not errors mode. Will be introduced in ref_int repo. Errors from warning can be disabled in conf.py
Split documentation across directories. Can be created next to implementation.
Docs_combo old command is gone, is replaced in place - every repo can do it now.

SBOM for ref_int

Covers tools usage with the result in json file. Work in progress - eclipse-score/reference_integration#304
https://github.com/eclipse-score/dash-license-scan/tree/dev
For now uv can be treated as not critical dependency, to be checked again later.

MISRA scanning

CodeQL scan with MISRA rules is working in ref_int repo. Next step would be to raise awareness with dashboard and set the goals to fix discovered issues.
Warnings can be added to repo overview dashboard. Based on sarif file artifact.

[PiotrKorkus]

Meeting minutes - 18.08.2026 10:00

Participants

@PiotrKorkus
@antonkri
@anmittag
@opajonk
@masc2023
@odra
@kgraeper
@RacheleSetto
@4og

Agenda

DR8 workflow

eclipse-score/reference_integration#280
https://github.com/Subramanian-K812/reference_integration-ci-verify/actions/runs/32011971817

DaC v7

eclipse-score/reference_integration#306

v0.9 status

#3186

Minutes

v0.9 status

Last modules bump - 04.08
Gaps of release v0.8 - where are we currently with 0.9 incoming?
Module verification report - currently is not automated, Modules should deliver it for v0.9. We should focus on baselibs and persistency.
Baselibs - testlinks will take time as need manual verification. In v0.9 we aim to have it in for first component.

DR8 workflow

• finish unit test execution
• generate common documentation in ref_int with artifacts collected from all the modules
• next step - Module Verification Report could be probably generated in this step
• any additional review of PR DR-008 Option 4: two-stage test-execution workflow (PR 2 of 2) reference_integration#280 is welcome

[PiotrKorkus]

Meeting minutes - 25.08.2026 10:00

Participants

@PiotrKorkus
@odra
@antonkri
@kgraeper
@LittleHuba

Agenda

v0.9 status

#3186

Module verification report

Minutes

v0.9 status

Release candidate branch: https://github.com/eclipse-score/reference_integration/tree/release_candidate_09
Module Owners to upgrade versions of their modules to the hashes / versions expected to be a part of Release v0.9 on release candidate branch. @PiotrKorkus will create a PR from release candidate to release branch.
Please do not use force push.

DR8 workflow will be running in parallel to the old one. We will use following 2 weeks to test that it works as expected, fix issues and then fully switch to the new one.

Module verification report

@antonkri prepares update - eclipse-score/baselibs#491
Every component gets its own traceability statistics, architectural elements listing, verification and checklists.
Communication has lobster verification report which should be equivalent.
https://eclipse-score.github.io/communication/v0.4.0/docs/sphinx/mw_com_index/traceability_report/index.html

[PiotrKorkus]

Meeting minutes - 25.08.2026 10:00

Participants

@PiotrKorkus
@odra
@antonkri
@kgraeper
@nradakovic
Eswaran
@evinoth1206
@opajonk

Agenda

v0.9 integration status

#3186

DR8 worfklow

eclipse-score/reference_integration#280

CPP toolchain in known_good

Minutes

CPP toolchain in known_good

CPP toolchains v0.5.4 will be used for SCORE v0.9 release.
In ref_int builds the minimal set of warning is defined in the toolchain itself. It is up to module owners to define any extra set of warnings. e.g communication - https://github.com/eclipse-score/communication/blob/5c22c564320afa3d37a1129b827f79c93367edbd/MODULE.bazel#L96

Kai will create PR with pulling cpp toolchains into known_good.json into main branch.

v0.9 integration status

PR: eclipse-score/reference_integration#320

• baselibs
• communication
• persistency
• orchestrator - needs to be deleted
• kyron
• lifecycle_health - PR to bump to 0.6 in place
• logging - release to be created
• time - to be updated in known_good with new release
• config - if it is causing problems will be removed from SCORE v0.9 otherwise newest main will be integrated and new release created

Test workflow was failing on release candidate branch - Piotr to check for the root causes.

Module verification report was created for persistency - Anton will create a PR.

DR8 workflow

Rust parts are failing during the integration step.
Piotr will check the rust failures.

DR8 workflow needs to be polished before merging to not introduce too much chaos.

SCORE release v0.9 will be created next week with the old integration workflow and DR8 will be integrated to main once all issues are fixed.

[PiotrKorkus]

Meeting minutes - 08.09.2026 10:00

Participants

@PiotrKorkus
@odra
@kgraeper
@LittleHuba
@RacheleSetto

Agenda

SCORE v0.9 release

Patches overview

Minutes

SCORE v0.9 release

SCORE v0.9 has been created
https://github.com/eclipse-score/reference_integration/releases/tag/v0.9.0
https://eclipse-score.github.io/reference_integration/v0.9.0/index.html

Main branch has been updated with the v0.9 versions (as hashes) - eclipse-score/reference_integration#336

Patches overview

baselibs
8 patches - https://github.com/eclipse-score/reference_integration/tree/main/patches/baselibs

communication
@LittleHuba will check examples visibility (currently located in tutorial doc pages)
dev_dependency - was agreed to not change, it should stay as it is in comm repo.

config_management
1 patch - https://github.com/eclipse-score/reference_integration/tree/main/patches/config_management

kyron
1 patch - https://github.com/eclipse-score/reference_integration/tree/main/patches/kyron

lifecycle
4 patches - https://github.com/eclipse-score/reference_integration/tree/main/patches/lifecycle
@kgraeper to forward and check

persistency
6 patches - https://github.com/eclipse-score/reference_integration/tree/main/patches/persistency

platform
1 patch - https://github.com/eclipse-score/reference_integration/tree/main/patches/platform
@PiotrKorkus will check

tooling
1 patch - https://github.com/eclipse-score/reference_integration/tree/main/patches/tooling
@PiotrKorkus will check

Examples

Each module should have an example in reference_integration.
If existing examples in the repository are not exposing the real use case of the feature itself, it is ok to create a separate example directly in ref_int repo and skip the linking of examples from module repo.

[PiotrKorkus]

Meeting minutes - 15.09.2026 10:00

Participants

@PiotrKorkus
@odra
@antonkri
@nradakovic
@AlexanderLanin
@masc2023
@Lukasz-Juranek
@kgraeper

Agenda

• SCORE v0.9 lessons learned
• Patches from v0.9
• Increase integration frequency
• Output and purpose for reference_integration

Minutes

SCORE v0.9 lessons learned

Session will take place next week (22.09), please forward information. @PiotrKorkus will post also in slack channel.

Patches from v0.9

Baselibs, communication, config_management still to be checked

Output and purpose for reference_integration

Clarify what is dev_dependency and what should be not. @AlexanderLanin created initial list - to be extended, contributions are welcome. https://github.com/eclipse-score/tools/blob/main/repo_policy_sync/policies/dev-dependency-alignment/policy.yml
Bazel registry is currently a mirror of github releases of all the modules.
Split macros from dev_dependencies and regular ones between separate BUILD files, so ref_int can reference the targets without encountering issues from dev_dependecies ( e.g. building docs in ref_int might collide with copyright check in root BUILD file).

@antonkri will use baselibs to draft a PoC if we can separate deps and check if that solves the problems.

Module verification report - could be created in module repo, as long as it has the same dependencies as in reference integration.

Increase integration frequency

Module owner should create a PR in ref_int with bumping their module version (via hash, no need for a release). This should happen at least once in 2 weeks. To be further discussed in tech alignment call on Monday and lessons learned next week.
GH stacked PRs can be also considered if multiple modules need to be updated at once: https://docs.github.com/en/pull-requests/how-tos/stacked-pull-requests , example: eclipse-score/docs-as-code#825

SBOM

Currently integrated workflow in reference_integration - eclipse-score/reference_integration#304

Platform verification report should have a link to SBOM file.
Modules should create also SBOM in their workflows and place it in Module verification report. - @Lukasz-Juranek will discuss the idea further in the security meeting.

[PiotrKorkus]

Meeting minutes - 22.09.2026 10:00

Participants

@PiotrKorkus
@antonkri
@odra
@kgraeper
@pahmann
@evinoth1206
@RacheleSetto
@AlexanderLanin
@4og
@thilo-schmitt
@OliverHeilwagen
@FScholPer

Agenda

• SCORE v0.9 lessons learned
• Feature Integration Test location - not discussed
• Public APIs in terms of Modules - what should be provided for integrator - not discussed
• Speedup CICD times in ref_int - introduce merge queue, use bazel cache in repo properly - not discussed

Minutes

SCORE v0.9 lessons learned

1. Integration of the modules takes a lot of efforts - each module should integrate to ref_int at least once every two weeks. No release is needed, Module owners can use hash from their main branch.
   During Monday's Tech Alignment call or this Release meeting we go through integration dashboard and review status.
   Dashboards: https://eclipse-score.github.io/.github/#versions and https://eclipse-score.github.io/reference_integration/main/status_dashboard.html

Idea: On integration dashboard show also how many tagged releases are behind - one commit can be more impactful that 100 others.

e.g.
Baselibs currently creates automatically PR in Module that have it as dependency.

Communication could create a release that doesnt work in ref_int, they would need to fix issues and create a next release. Using hash prevents creating releases that do not work in ref_int.

We need step-by-step approach to bump all modules once a week in single PR. @kgraeper has already prepared a script that fetches newest HEAD. Kai will update on newest main branch.

The automation will go module by module and check integration

DaC has breaking changes - 3 modules already updated, other did not. At this point commit bump is red.

How Modules should flag breaking changes without release? - solution to be found.

---

This week approach: Module owners create PRs in ref_int bumping their Modules to newest main until Wednesday EOB. All PRs should be merged until end of week - this is a combined effort of Module Owners to fix cross-dependency issues. We will use next week Tech Alignment call and this Release meeting to review process and propose the automation.

[PiotrKorkus]

Meeting minutes - 29.09.2026 10:00

Participants

@PiotrKorkus
@antonkri
@odra
@kgraeper
@4og
@anmittag
@AlexanderLanin
@RacheleSetto
@LittleHuba
@pahmann

Agenda

• Modules bump
• DR8 status of implementation
• last weeks topics

Minutes

Modules bump & deprecated APIs

• baselibs - required a lot of patches because depraced APIs were removed, and modules did not update to new ones.
• communication Bump communication module reference_integration#363
• config_management
• kyron
• lifecycle Bump score_lifecycle pin and fix simple_lifecycle mw::com config reference_integration#350
• logging
• persistency chore(deps): bump score_persistency pin, drop obsolete patches reference_integration#365
• time

Deprecation warnings are mostly ignored by Modules, now when the API is removed / migrated, the consumer Modules are failing integration. We need to improve the process of adapting to deprecation changes. Renovate does not highlight deprecation warnings.

Communication, config_management, lifecycle, logging, persistency - please update to newest baselibs API in your Modules then bump in ref_int and remove patches.

Idea from @LittleHuba - use C++ warnings that will be raised during bazel build and let user opt in for compiler flag that will raise them as errors giving clear indication what APIs are being deprecated and when. User should need to suppress on purpose the usage for the time until they upgrade - surprising is only for testing the API of the Module. Same mechanizm should be used for Rust - https://doc.rust-lang.org/reference/attributes/diagnostics.html#the-deprecated-attribute . To be checked if bazel is supporting such mechanizm.

When the Module is doing a bump in ref_int that requires to patch other Modules they should create an issue and/or PR to inform that Module about required changes. Then dependent Module in next bump in ref_int should remove those patches.

DR8 status of implementation

PR with updated workflow was exposing issues in the module integration, blocking the merge to main branch. Currently there are also conflicts.

Speedup CICD times in ref_int (last week)

@antonkri introduces cache improvements for testing, which sped up a little workflow. Current workflow tests modules as externals which are not included in bazel cache saved to repository.
Extract the first docs build into paralel job that will allow to expose issues early but wont extend the test workflow too much. test_and_docs will still build docs after tests and do the deployment. - @PiotrKorkus to implement that

Public dependencies of Modules - what should be provided for integrator (last week)

We need an agreement what should be public API and what should not. @AlexanderLanin started with a list of Modules that need to be public and cannot be dev_dependency https://github.com/eclipse-score/tools/blob/main/repo_policy_sync/policies/dev-dependency-alignment/policy.yml . Policy tool can accept exceptions or scan only if the dependecy is in the module, it wont add the dep if the module doesnt have it defined.

example case: you want to use docs() from DaC in your BUILD file, so docs_as_code cannot be a dev_dependency

Current source of truth is Module Verification Report - it can be created with DaC, communication will create it on their own and it will be integrated into ref_int combined docs build.

[PiotrKorkus]

Meeting minutes - 06.10.2026 10:00

Participants

@PiotrKorkus
@anmittag
@AlexanderLanin
@OliverHeilwagen
@antonkri
@masc2023
@evinoth1206
@4og

Agenda

• Module verification content
• Integration PR - dev deps

Minutes

dev dependecy update

• score_itf is framework for running integration tests, so ITF cannot be a dev_dependency (same for its dependencies e.g. rules_oci)
• some Modules use score_qnx_unit_test framework also for integration tests - this also should be non dev_dependency
  feat(repo-sync): add non dev dependencies tools#56
• changing dev_dependency will influence DR8

Actual users of SCORE might not want to use ITF, so we should not leak our dev_dependecies used for verification.

Module verification content

• executing UTs in ref_int currently doesnt take a lot of time due to cache usage
• modules in DR8 workflow are parallelized so they also are not blocking the execution time

Define list of public targets:

• one public target in each module per all libraries collection, binaries, unit test suite, integration test suite
• we need commitment from the Modules if we proceed with DR8

@PiotrKorkus will check which modules are currently failing the DR8 workflow integration and discuss next Monday meeting the updates needed.

[PiotrKorkus]

Meeting minutes - 13.10.2026 10:00

Participants

@PiotrKorkus
@antonkri
@RacheleSetto
@chheis
@OliverHeilwagen
@evinoth1206
@AlexanderLanin
@FScholPer
@MaximilianSoerenPollak

Agenda

• DR8 workflow

Minutes

DR8 workflow

Demo PR: PiotrKorkus/reference_integration#5

Failing:

• communication
• lifecycle
• config management

@PiotrKorkus will prepare a PR in reference_integration. Module owners to prepare fixes / requests for workarounds and we can switch to new workflow. As test_and_docs is triggered on pull_request_target we need to do a demo on private fork to show working changes in workflow itself. -> eclipse-score/reference_integration#398

AutoSD failures

AutoSD is failing for some time already on main branch - Piotr to contact Leonardo about it e.g. https://github.com/eclipse-score/reference_integration/actions/runs/37788755373/job/113350220326

Dashboards

We have duplicated data across different dashboards.

https://eclipse-score.github.io/.github/#versions
https://eclipse-score.github.io/reference_integration/main/status_dashboard.html

Proposals to track versions used in modules and ref_int.
We will keep the dashboards splitted, as reference_integration one is linked to the PR / release changes from ref_int.
Cleanup - score dashboard data from ref_int will be extracted and moved to ref_int.

Create an entry point for all dashboards in central repo.
SCORE webpage should also get links to the dashboards.

The combined documentation from reference_integration should be also packed as zip and added to release assets, so it can be downloaded separately. @chheis said it is also possible to use CLI to do the backup in eclipse:

das gleiche könnt ihr als Ankaios committer machen.
[10:09 AM]
scp rpi4-image.iso <[eclipseUser>@projects-storage.eclipse.org](mailto:eclipseUserchheis@projects-storage.eclipse.org):/home/data/httpd/download.eclipse.org/ankaios/
[10:10 AM]
Löschen geht auch:
ssh <eclipseUser>@projects-storage.eclipse.org rm /home/data/httpd/download.eclipse.org/ankaios/deineDatei.iso
[10:10 AM]
das taucht dann hier auf: https://download.eclipse.org/ankaios/

https://eclipse.dev/cbi/best-practices/github-actions/upload-to-downloads.eclipse.org/

[PiotrKorkus]

Meeting minutes - 20.10.2026 10:00

Participants

@PiotrKorkus
@OliverHeilwagen
@odra
@RacheleSetto
@antonkri

Agenda

• DR8 workflow
• image artifact in ref_int
• dashboards update

Minutes

DR8 workflow

Failing:

• communication
• config management

@antonkri will contact the teams

image artifact in ref_int

eclipse-score/reference_integration#403

Rolling release created nightly if there are changes merged to main and mandatory image on release attached to the assets.

dashboards update

eclipse-score/.github#127

Multiple views that help identify different versions of dependencies across repositories and reference integration.

warnings as errors

Will not be enabled until SCORE v1.0, Modules need to fix the warning in their repos first, then once we have stable builds this option can be enabled in ref_int.

[PiotrKorkus]

Meeting minutes - 27.10.2026 10:00

Participants

@PiotrKorkus
@odra
@AlexanderLanin
@masc2023
@RacheleSetto
@OliverHeilwagen
@FScholPer
@evinoth1206

Agenda

• dev_dep overview with DR8
• examples - location, implementation, usage in ref_int
• SCORE v0.10 release
• Image releasing in reference_integration
• Dashboards

Minutes

dev_dependency

Current status of dependencies after DR8 merge:

Must stay NON dev_dependency:

• score_sbom
• score_tools & pip
• score_itf
• OCI
• score_rules_imagefs

Can go back to dev:

• GTest
• score_rules_imagefs
• rules_build_error
• json_schema_validator

Proposal to have a separate directory with MODULE file that would allow to do the testing with context of external module. To be checked - if traceability can be established within the main repo, how to sync dependencies.
We should try to make a list of non dev-dep as minimal as possible - only what we need + DaC, tooling.
Can reference_integration be showing how tools can be used and keep non-dev (e.g. ITF) only there.

What are our public interfaces is it only implementation or also process and requirements?
Briefly talk on Monday tech alignment, decide who we need to continue discussion in separate session.
https://gist.github.com/AlexanderLanin/d413158883f08e7847672c2c12b0859d

Examples

https://eclipse-score.github.io/score/main/contribute/general/folder.html
https://github.com/eclipse-score/module_template

Both show different place of implementation - this needs to be clarified which one is correct. Also how the examples should be implemented - public targets, separate MODULE etc?

Image releasing in reference_integration

PR: eclipse-score/reference_integration#413

Create image for release candidate branch and nightly on main if there were changes merged.

SCORE v0.10 release

Release candidate branch will be created today and posted on slack channel.

Dashboards

Not discussed