Meeting Minutes #236

AlexanderLanin · 2025-01-28T09:04:29Z

AlexanderLanin
Jan 28, 2025
Collaborator

All official meetings will be documented in this thread. So if you subscribe here, you'll get summaries of the meetings you missed.

Landing page for our team: #107

AlexanderLanin · 2025-01-28T09:05:59Z

AlexanderLanin
Jan 28, 2025
Collaborator Author

0 replies

AlexanderLanin · 2025-01-28T09:07:51Z

AlexanderLanin
Jan 28, 2025
Collaborator Author

Daily

2025-01-28

Agenda

Alignment on currently worked upon issues. Specifically identification of dependences and collaboration.

Participants

Meeting Minutes

Contribute to Issues via comment or via pull request. You'll need to fork the repository.
Operational Backlog
"Kick-Off": a few more people in our existing community
Meeting Infrastructure: Meetings stay as they are for now. We'll switch to open eclipse infrastructure mid February: google calender & zoom meetings.
Chat:
- Chat-Access
- Chat
Let's make issues smaller, so they are estimatable and closed
Let's create "milestones" what we aim to achieve e.g. end of january / february

OSS deep dive
split OSS (#82, #126) to sub-issues, e.g.:

setup dash for python on PR (non blocking) -> dash: Integrate DASH tool in Bazel build #155
- rename "license check" to something like "license dry run"
automation: print problems as comment to pull request, see also bug: pr-preview comment #211
create private key for automatic clearance
extend automaton with automatic clearance
add rust dependencies to dash (via bazel)
add C++ dependencies to dash (via bazel)
bazel modules
change automation (daily / blocking / etc)

0 replies

AlexanderLanin · 2025-01-28T21:26:26Z

AlexanderLanin
Jan 28, 2025
Collaborator Author

Daily

2025-01-29

Agenda / Minutes

Collect current member status (see below)
Yet another issue organization attempt: Infrastructure
Collect what needs to be documented: document current setup #245
Daily time -> 1 hour earlier? @nradakovic ok?
Hint: good first issues
esbonio setup broken? -> @MaximilianSoerenPollak

Participants

Current member status

who	score-member (GitHub)	chat (Slack)
Alexander Lanin @AlexanderLanin	✔️	✔️
Nikola Radakovic @nradakovic	✔️	✔️
Maximillian Sören Pollak, @MaximilianSoerenPollak	✔️	✔️
Dan Calavrezo @dcalavrezo-qorix	✔️	✔️
Nicolae Dicu @nicu1989	✔️	✔️
Sameer Srivastava @sameer6989	❌	✔️
Aymen Soussi	requested ❓	✔️
Tomas Pereira	❌ (blocked by legal)	❌ (blocked by legal)
Daniel Woste @danwos	✔️	✔️
Philip Partsch @PhilipPartsch	✔️	✔️
Michael Mueller	❌	❌

0 replies

AlexanderLanin · 2025-01-31T08:29:57Z

AlexanderLanin
Jan 31, 2025
Collaborator Author

0 replies

MaximilianSoerenPollak · 2025-02-03T10:02:13Z

MaximilianSoerenPollak
Feb 3, 2025
Collaborator

0 replies

AlexanderLanin · 2025-02-05T09:20:44Z

AlexanderLanin
Feb 5, 2025
Collaborator Author

0 replies

AlexanderLanin · 2025-02-07T09:33:21Z

AlexanderLanin
Feb 7, 2025
Collaborator Author

0 replies

AlexanderLanin · 2025-02-07T11:33:36Z

AlexanderLanin
Feb 7, 2025
Collaborator Author

0 replies

AlexanderLanin · 2025-02-10T09:21:54Z

AlexanderLanin
Feb 10, 2025
Collaborator Author

0 replies

AlexanderLanin · 2025-02-12T14:07:32Z

AlexanderLanin
Feb 12, 2025
Collaborator Author

0 replies

AlexanderLanin · 2025-02-12T15:38:35Z

AlexanderLanin
Feb 12, 2025
Collaborator Author

Python tooling in bazel deep dive

2025-02-14
To join the meeting, get in contact via Chat-Access + Chat

Agenda / Minutes

Sharing experience on how to best integrate python tools into bazel
Sandbox Approach
Dependency Management in Bazel
Running Black as Bazel Aspect

Participants

0 replies

hoe-jo · 2025-02-14T14:57:35Z

hoe-jo
Feb 14, 2025
Collaborator

Python tooling in bazel deep dive follow up

2025-02-21
To join the meeting, get in contact via Chat-Access + Chat

Agenda / Minutes

Continue on exchanging experiences with bazel IDE integration and linter support

Participants

0 replies

AlexanderLanin · 2025-02-17T09:00:06Z

AlexanderLanin
Feb 17, 2025
Collaborator Author

0 replies

AlexanderLanin · 2025-02-17T10:01:42Z

AlexanderLanin
Feb 17, 2025
Collaborator Author

How to reuse tools across repositories?

2025-02-17
To join the meeting, get in contact via Chat-Access + Chat

Agenda / Minutes

How to reuse tools across repositories?
We can use bazel (see https://eclipse-score.github.io/score/main/features/infrastructure/bazel_registry.html) to pull tools via bazel
One repository per tool is too much
One repository can hold multiple bazel modules
one bazel module = one tool, or we group them:
=> start with one group and split as needed
Example:
- Setup: score-tooling with cr_checker
- Scenario: bug in cr_checker
  - fix in score-tooling
  - release new score-tooling-group
  - update bazel-registry
  - update all users (e.g. Dependabot, Renovatebot?)
Separate repo or keep in score?
- For now we can use the score repository with modules as described above
- Note: bazel_registry is even optional. Direct usage is also possible.
Proposal: use both approaches
- Move one tool (e.g. cr_checker) to a separate repository (tooling repo in https://github.com/eclipse-score/) -> POC by @nradakovic
- Keep the rest in score for now. Depending on timeline, we wait for tooling POC.
How to synchronize python versions across repositories / modules?
- root repository sets the python version. tooling sets a minimal supported version.

Participants

0 replies

AlexanderLanin · 2025-02-17T19:26:24Z

AlexanderLanin
Feb 17, 2025
Collaborator Author

0 replies

dcalavrezo-qorix · 2025-11-24T14:03:35Z

dcalavrezo-qorix
Nov 24, 2025
Collaborator

Weekly

2025-11-24
To join the meeting see calendar in #107

Participants

Agenda / Minutes

unified toolchain repository structure ( for CPP code)
docs-as-code - integrate into modules - DR (https://eclipse-score.github.io/score/pr-2089/design_decisions/DR-005-infra.html)
baselibs cross-compilation for EBCL issues
toolchains_qnx PR qnx: do not rely on /proc/self toolchains_qnx#35 from @pawelrutkaq
- PoC how to remove /proc/self paths so build works in cases where you don't invoke CC from bazel sandbox root
- @nradakovic solution is not really reliable/ durable - looking for a better option, we can approve it with some caveats
@opajonk devcontainer updates: arm64/amd64 builders + gdb and gh command client => we should release it as 1.0.0
we should conduct some cleaning up of our repos ( for 0.5 release there were many "temporary" solutions) considering that we need a more consolidated approach for release 1.0 ( @AlexanderLanin we should define a set of immediate actions in this direction).

0 replies

darkwisebear · 2025-11-26T13:15:31Z

darkwisebear
Nov 26, 2025
Collaborator

Weekly

14:00-15:00 CET

Participants

@PLeVasseur
@FScholPer
@dcalavrezo-qorix
@darkwisebear
@pawelrutkaq

Agenda

Update on safety qualification efforts
Introducing Iceoryx dependencies

Minutes

Safety qualification efforts

@pawelrutkaq libcorecertification: Opened PR rust: add libcore to certification doc #2249: Describing the gap
@pawelrutkaq scanned the code for libcore usage. Ferrocene has a compiler switch to do that automated.
@FScholPer will find documentation about the terms of usage for Ferrocene
Misra will soon start to talk about Rust
Request: Have a look at https://coding-guidelines.arewesafetycriticalyet.org/, https://github.com/rustfoundation/safety-critical-rust-coding-guidelines/blob/main/CONTRIBUTING.md
Todo: Check whether rules_rust need to be adapted to Ferrocene. @pawelrutkaq will add a ticket to the board if needed
Idea: have a tailoring guideline in the SCRC to help people to apply the SCRC CGs to their project

Introducing Iceoryx dependencies

deps: Add orchestrator deps score-crates#16 will be merged. As soon as methods and "signal" support is in score/com, we migrate away from Iceoryx.

0 replies

dcalavrezo-qorix · 2025-12-03T13:20:34Z

dcalavrezo-qorix
Dec 3, 2025
Collaborator

Weekly RUST 03-12-2025

14:00-15:00 CET

Participants

@PLeVasseur
@FScholPer
@dcalavrezo-qorix
@pawelrutkaq
@odra
@rafael - ETAS
@darkwisebear
@sophokles73

Agenda

go over our Board https://github.com/orgs/eclipse-score/discussions/236

Minutes

static code analysis using clippy
- set of rules will come from the safety consortium ( based on that we will decide whether clippy suffices or we need to create an extension or even rely on 3rd party tools)
- add the clippy checks to all Rust based repos from the alfa 0.5 release (@dcalavrezo-qorix )
- https://github.com/rustfoundation/safety-critical-rust-coding-guidelines ( end of March - some degree of completeness )
QNX 8 support on Rust ( pthread signature issue - Allow Neutrino QNX SDK dependent values for PTHREAD_MUTEX_INITIALIZER rust-lang/libc#4192)
groom the old RUST tickets Tooling: Enable rust development #80 and close what is relevant ( or at least comment) @pawelrutkaq
- Epic: (Initial) Coding Guidelines Rust #592

Safety qualification efforts

1 reply

PLeVasseur Dec 7, 2025
Collaborator

Hey there, this is @PLeVasseur 👋 following up on steps to move nto-qnx from Tier 3 to Tier 2.

I reached out to the target maintainers, two of whom I know somewhat, on the Rust Zulip to hear their thoughts on challenges / concerns.

I read the Tier 2 target policy. Seems most of these should be okay, but the target maintainers will know better.

I also reached out to an Rust Project Infrastructure Team member I know to ask for next steps which were: draft a post and post it publicly in the right spot (#t-infra). I've drafted the post, but am waiting to hear back from the target maintainers before proceeding.

AlexanderLanin · 2025-12-08T10:25:42Z

AlexanderLanin
Dec 8, 2025
Collaborator Author

Weekly

2025-12-08
To join the meeting see calendar in #107
(Zoom meeting broken, switched to Teams via slack channel)

Participants

@AlexanderLanin
@opajonk
@a-zw
@dcalavrezo-qorix
@nicu1989
@ubmarco
@evinoth1206
@AyJebri

Agenda / Minutes

Info: interesting topics in progress:
- common c++ toolchain
- new bazel_registry rewrite automation/scripts bazel_registry#190, e.g. version info can be removed from MODULE.bazel files
- on_pr workflow for modules to trigger reference_integration via prepare script for integration feedback on PR #1852
- monorepo view (gita) onto score via reference_integration
- rust SCA
- os_images stuck due to old QNX --> keep going and call it "community supported" !?
Info: Release "0.5 beta" on 18th December.
Request: Can someone review github secrets from forks #1983?
docs: For full docu build we need an score_platform release -> @AlexanderLanin & @dcalavrezo-qorix
docs: versioned links in concept phase, in discussion with process_description experts. Links via docs: Add versioned links docs-as-code#314, Versioned links for tracking suspicious links useblocks/sphinx-needs#1352, Tech concept for edge properties useblocks/sphinx-needs#1481
docs: sphinx-needs-6 metamodel validation as automatic translation from current metamodel.yml (for now anyway) in progress.

1 reply

AlexanderLanin Dec 8, 2025
Collaborator Author

Forgot to mentioned another in progress topic:

dash-license-scan as POC to replace calling tools via bazel. See poc for entire flow dash-license-scan#3

dcalavrezo-qorix · 2025-12-10T13:15:13Z

dcalavrezo-qorix
Dec 10, 2025
Collaborator

Weekly RUST 10-12-2025

14:00-15:00 CET

Participants

@PLeVasseur
@dcalavrezo-qorix
@darkwisebear
@FScholPer
@chulhee Lee
@pawelrutkaq

Agenda

go over our Board https://github.com/orgs/eclipse-score/discussions/236

Minutes

clippy was added to persistency and refrence_integration (PR) - the rest to follow ( hopefully together with rustfmt)
update from @PLeVasseur https://github.com/orgs/eclipse-score/discussions/236#discussioncomment-15188240
PRs from rules_rust won't be merged any time soon
Find out what tooling can be used for branch coverage #2013 (comment)
- https://public-docs.ferrocene.dev/main/coverage/index.html
consider switching to the ferrocene compiler within a POC repo using bazel toolchains - let's go with persistency ( @infra team)
agreement on proposal from Find out what tooling can be used for branch coverage #2013 (blanket)
review needed: formatting: score configuration score_rust_policies#4

0 replies

AlexanderLanin · 2025-12-15T10:47:38Z

AlexanderLanin
Dec 15, 2025
Collaborator Author

Weekly

2025-12-15
To join the meeting see calendar in #107

Participants

@dcalavrezo-qorix
@nicu1989
@ubmarco
@nradakovic
@odra
@jgetas
@MayurMysoreNagaraja

Agenda / Minutes

QNX license issue?
- escalation needed - some PRs are opened for more than 10 days
Limit workflows to forks? (Collect idea, schedule follow up?) -> https://sdvworkinggroup.slack.com/archives/C0894QGRZDM/p1765795691165719
Update from last weeks topics:
- common c++ toolchain
  - via https://github.com/eclipse-score/bazel_cpp_toolchains
- new bazel_registry rewrite automation/scripts bazel_registry#190, e.g. version info can be removed from MODULE.bazel files
  - via rewrite scripts bazel_registry#188
- on_pr workflow for modules to trigger reference_integration via prepare script for integration feedback on PR #1852
  - delayed
- monorepo view (gita) onto score via reference_integration
  - progress?
- rust SCA
  - progress?
- os_images stuck due to old QNX --> keep going and call it "community supported" !?
  - progress?
  - AP: reping QNX folks
- dash-license-scan as POC to replace calling tools via bazel. See poc for entire flow dash-license-scan#3
  - blocked due to .eclipsefdn still stuck
Info: Release "0.5 beta" on 18th December.
On QORIX side, we have consciously decided not to continue the project unchanged under the current setup. Given the market and budget conditions, this would neither be strategically sound nor economically responsible. Instead of tying up resources and creating expectations we cannot reliably meet, we are executing a controlled ramp-down. This decision is not an exit from the topics and not a reflection of the quality. It is a deliberate focus to create the conditions to rebuild with clear priorities, a stable setup and reliable commitment
AP: evaluate the integration of the AutoSD toolchain into our common / aggregated toolchain

0 replies

dcalavrezo-qorix · 2025-12-17T13:06:19Z

dcalavrezo-qorix
Dec 17, 2025
Collaborator

Weekly RUST 17-12-2025

14:00-15:00 CET

Participants

@dcalavrezo-qorix
@darkwisebear
@bharatGoswami8
@pawelrutkaq

Agenda

clippy: added clippy support communication#117 - was rejected
ferrocene builder
QNX builds in S-Core

Minutes

we shall clarify the rules_rust vs Aspect till the end of the week and proceed with the agreed approach
ferrocene builder not working atm in CI
QNX 8 SDP available in S-CORE is outdated ( virtio packages are also missing - no QEMU support for aarch64, no mkifs support for real hw targets)
update on the safety rust guidelines: https://github.com/rustfoundation/safety-critical-rust-coding-guidelines/milestone/1

0 replies

anmittag · 2025-12-29T16:41:10Z

anmittag
Dec 29, 2025
Collaborator

2026-01-??

Please review your open issues. Close them, adapt the description or delete them https://github.com/eclipse-score/score/issues?q=is%3Aissue%20state%3Aopen%20label%3Acommunity%3Ainfrastructure

0 replies

AlexanderLanin · 2026-01-12T13:28:43Z

AlexanderLanin
Jan 12, 2026
Collaborator Author

Weekly

2025-01-12
To join the meeting see calendar in #107

Participants

@dcalavrezo-qorix
@nradakovic
@AlexanderLanin
@odra
@a-zw
@kgraeper
@FScholPer
J. Zimmermann
@MaximilianSoerenPollak
N. Trifunovic
C. Swamy
@nradakovic
@jgetas
@nick-hildebrant-etas
aresetar

Agenda / Minutes

bazel_registry no longer requires version & compatibility_level set in MODULE.bazel.
- version & compatibility_level will be patched automatically based on git tag (compatibility_level is semver.major).
- locally it should be module(score_mymodule, version='0.0.0')
- We'll add a warning somewhere when the version is not 0.0.0 in your MODULE.bazel
- modules can be set as "periodic-pull": true, in metadata.json no more separate modules.json file
- other modules can be updated by triggering workflows/check_new_releases.yml
Presentation of bazel_cpp_toolchains by @nradakovic
- @odra, @kgraeper will try it out "today"
- this will deprecate toolchains_cpp and toolchains_qnx
new image file systems repo, it will be used by os_images repo. No decision record required, as there are no good alternatives. To be created by @nradakovic
- Note: one os_images qnx branch by @jgetas is blocked at the moment as we need qnx 8.0.3 + Virtualization Drivers

Not discussed today (out of time):

branching strategy
c++ formatting

0 replies

dcalavrezo-qorix · 2026-01-14T09:31:49Z

dcalavrezo-qorix
Jan 14, 2026
Collaborator

Weekly RUST 14-01-2026

14:00-15:00 CET

Participants

@dcalavrezo-qorix
@darkwisebear
@bharatGoswami8
@pawelrutkaq

Agenda

Rebuilt the Ferrocene toolchain using the official Ubuntu 20.04 CI image to match the older baseline ( still building)
Enabled profiling support and rebuilt the toolchain accordingly.
Hit QNX build failures when profiling is on; prepared a patch but it still needs to be submitted/integrated, so QNX profiling is deferred.
Prepared the coverage tooling workflow (blanket + symbol-report) with a runnable example in examples/coverage-demo/
Upgrading rust version in s-core toolchain

Minutes

AP: discuss in the next Infra weekly about hermetic approaches for our builds ( Bazel, containerized, etc)
commercial offer will arrive by the end of the week
S-CORE & QNX mtg regarding RUST certification ( details tba)
clarify clippy execution scenario (rules_rust vs Aspect)
https://hackmd.io/@plevasseur/r199Y_lS-l
Constraints for ABI bazelbuild/platforms#38
Extend QNX support by adding all currently supported variants bazelbuild/rules_rust#3723
AP: we need to fork our own rules_rust and publish a release with our changes in our S-CORE BCR

5 replies

dcalavrezo-qorix Jan 15, 2026
Collaborator

Reminder : request from @MaximilianSoerenPollak for next week's Minutes:

Can you take the topic of 'Testing' into the Rust meeting next week?
Specifically the discussion what test framework to use.
As it came up again that the current one does not support properties in XML.

If the frameworks that exist that support that are too much (or too hard to verify / secure etc.) then we might need to find another way to parse rust tests inside docs-as-code.

pawelrutkaq Jan 15, 2026
Collaborator

So I hope @PLeVasseur or @darkwisebear or others have a better approach but since I don't really know any solution that could let us connect test with req-id out of box, I would tend to say that using syn::parse_file and adding a small macro like

...
#[tracable_test="req-id"]
fn test_somethig_nicely() {
}

should allow to write simple Rust tool that extracts locations, and ids for doc-as-code.

tracable_test - simply expand to #test

MaximilianSoerenPollak Jan 15, 2026
Collaborator

The tests are different than the source code link. They work via xml properties.
Though it can also work through source code parsing.

darkwisebear Jan 22, 2026
Collaborator

I would strongly encourage to put the links to the source where possible. Either as attributes or as rustdoc somehow. I also spoke to a maintainer of rustdoc last year and they were open to extensions if we give reason why this is necessary. But no, I don't have a better idea than these...

MaximilianSoerenPollak Jan 22, 2026
Collaborator

I would strongly encourage to put the links to the source where possible. Either as attributes or as rustdoc somehow. I also spoke to a maintainer of rustdoc last year and they were open to extensions if we give reason why this is necessary. But no, I don't have a better idea than these...

Pure links to source code are different than the testing linkage.
As the testlinkage will parse things from the XML and also create testcase needs that can be used in statistics etc.
Yes it will also link to the source code itself (in the testlink attribute) so that is the same. But via the XML there is more too it than just that.
Simple links (without any additional information) already work right now regardless of language.

AlexanderLanin · 2026-01-19T13:24:23Z

AlexanderLanin
Jan 19, 2026
Collaborator Author

Weekly

2025-01-19
To join the meeting see calendar in #107

Participants

@dcalavrezo-qorix
@nradakovic
@AlexanderLanin
@kgraeper
@MaximilianSoerenPollak
@nradakovic
@jgetas
@nick-hildebrant-etas
D Kenjic
@guejan
@kgraeper
@odra
@ubmarco
@opajonk

Agenda / Minutes

bazel_registry no longer requires version & compatibility_level set in MODULE.bazel -> approach as discussed last time is now documented. @AlexanderLanin
new action more-disk-space, can be used @AlexanderLanin
integration status by @kgraeper:
- "pull request feedback from integration" as a reusable workflow is now available. Volunteer for testing? baselibs via @nradakovic? - in case baselibs is using pull requests now.
- next: auto update of known good manifest on main branch
fix: Test linking via Pytest decorator now also works with class based tests. It will name the link '__' if both are available, or just if it's not a class based test. Test linking can be used now! by @MaximilianSoerenPollak docs, example
architecture of tooling, score-tools

I want(ed) to do a score-tools pipx approach for tooling. And I still believe it's one of the best appraches I've seen so far. But:
let's be realistic. I have not touched that repo for 3 months now.
if people have the chance to call ruff instead of score-ruff, they will. So basically this is fighting the same problems as a bazel integration. No IDE support. As soon as the command is non standard, you are screwed.
So I'm now proposing a different solution.
We put a central ruff.toml, pyrightconfig.json, clang-format, etc file somewhere in cicd-workflows / module-template, and push it from there to all the other repos. We'll need to figure out some way to merge that with local stuff, and I have no idea how at the moment. But that's only one pain point, compared to the many if we use pipx-approach or bazel-approac

proposal for tools that do not benefit from bazlification (fast enough, no cache required, bazel does not provide inputs):
- provide tool versioning centrally, via devcontainer
- provide tool config from one central place, automatically copied to all the repositories (daily)
- @AlexanderLanin writes a "mini DR", building on top of DR-001, for this decision.

request: present analyzed GitHub-caching options by ETAS
general problem: AppArmor in Ubunut 24 + GitHub Runners (without admin access) + Docker + Bazel is a bad combination for bazel process sandbox (used by communication tests). Tracked in Enable linux-sandbox also for Ubuntu 24.04 devcontainer#40. Was solved just TODAY?! See eclipse-score/communication@108d1f8

copybara usage experience: Is anyone using it? ETAS (@nick-hildebrant-etas, @AlexanderLanin etc) have tried using it, but so far the conclusion is to abandon it. Feedback @dcalavrezo-qorix: similar experience, and it stores a state - which is bad for CI, abandoned as well after some attempts -> using native git instead. We can collect feedback async from @nradakovic.

0 replies

AlexanderLanin · 2026-01-19T15:47:55Z

AlexanderLanin
Jan 19, 2026
Collaborator Author

Weekly

2025-01-26
To join the meeting see calendar in #107

Participants (to be updated)

@dcalavrezo-qorix
@AlexanderLanin
@MaximilianSoerenPollak
@kgraeper
@jgetas
@nick-hildebrant-etas
@kgraeper
@odra
@ubmarco
@a-zw
A. Resetar
@MTomBosch
@tbreckle
@arnoox

Agenda / Minutes

Testing table format for topics :-)

Topic	Who	Discussion	Conclusion
caching options analysis presentation	@MTomBosch	pptx will be attached later	-
module -> module dependencies, see image, release frequency: in order to not spam releases we should allow usage of `git_override` for daily work. However module releases must refer to other modules via release, otherwise their local testing becomes meaningless	@AlexanderLanin	..	1b
remove feo from ref_int? main is not maintained since 3month and module name is still feo instead of score_feo on main	@kgraeper	Feedback Tech Leads: Will be discussed tomorrow. FEO is still maintained. Make sure an issue exists.	eclipse-score/feo#33
add lifecycle to ref_int	@kgraeper	Feedback Tech Leads: feel free to try out, but it is still very volatile.	..
latest logging does not work with latest communication	@kgraeper		Create ticket in logging that in order to be integrated, they must be compatible to latest communication -> eclipse-score/logging#41

0 replies

dcalavrezo-qorix · 2026-01-21T12:59:05Z

dcalavrezo-qorix
Jan 21, 2026
Collaborator

Weekly RUST 21-01-2026

14:00-15:00 CET

Participants

@dcalavrezo-qorix
@bharatGoswami8
@pawelrutkaq
@odra
@arvindr19
@MaximilianSoerenPollak
@haritha

Agenda

integrated clippy into communication using rules_lint
prepared DR for clippy clippy: added decision record on how to integrate clippy #2466
prepared S-CORE execution contract draft execution contract #2475
still opened: - AP: we need to fork our own rules_rust and publish a release with our changes in our S-CORE BCR
issue from @MaximilianSoerenPollak https://github.com/orgs/eclipse-score/discussions/236#discussioncomment-15505810

Minutes

the AP still remains valid - forking our own rules_rust @dcalavrezo-qorix
AP: perform an analysis whether we actually need a custom tool/framework - if not go ahead with vanilla
commercial offer from Ferrocene <100k for certification

1 reply

MaximilianSoerenPollak Jan 22, 2026
Collaborator

Here is a small write-up I made regarding the Testing Framework Discussion:

Rust Testing Framework Suggestions

A couple of suggestions for the community to consider.
These frameworks would supply at least somewhat the things needed to make the docs-as-code solution via XML work.
If none of these are viable options determined by the community then a custom solution might be the only way, as traceability is a must have.

Frameworks

1. Cargo-Nextest

A very powerful testing framework that does a lot, and in addition with quick-junit it also allows for properties inside the XML as far as I can tell.

The main issue here is that it has over 100 dependencies, and that might be an issue once it gets to porting the tests etc. to other architectures.

2. Cargo Test (Vanilla) + cargo2junit

This allows for the output to be in XML, though we would be missing the properties here as far as I know. That means we would have to find another way to add properties & attributes to the XML in order to enable this

3. Cargo Test (Vanilla) + Custom solution

Also possible that we can just make a custom solution that enables properties to tests and parses the output from cargo tests. We theoretically could even skip the XML creation and go straight to generating the JSON that will be outputed but that might be more confusing especially if we change how the source code linker behaves.
There already is a prototype of this that could be looked at / build upon, made by @PiotrKorkus a while back.

Conclusion

I'm not qualified to say which is the best way to go about this, I merely gathered some possible paths the rust community could take.
If there is need of example XML's (what the source_code_linker would expect) or any questions on how it works, I'm more than happy to answer those.

AlexanderLanin · 2026-01-26T15:00:44Z

AlexanderLanin
Jan 26, 2026
Collaborator Author

Weekly

2025-02-02
To join the meeting see calendar in #107

Participants (to be updated)

Agenda / Minutes

Topic	Who	Discussion	Conclusion
PR reviews	@nick-hildebrant-etas @AlexanderLanin	the review requests chat is not the best option ever to facilitate reviews. Any other ideas?	-
dash-licensce-scan	@AlexanderLanin	new tool / action for scanning dependencies	-
docs-as-code source links API change	@a-zw	change in API	-
overview of actions/tools we have	@AlexanderLanin	I assume most people do not know that we have actions like apt-install and more-disk-space. We need to spread that info	-
bug in score_platform due merge of old PR branch	@AlexanderLanin	Require up to date PRs? Activate merge queue?	-

7 replies

nick-hildebrant-etas Jan 27, 2026
Collaborator

@AlexanderLanin no I don't have other examples, but i don't really want to go at this as a special case. I would just generally like to know if this is the agreement. I think CODEOWNERS is in play here. If i make a contribution which is fully approved, it's still possible I can't actually push the merge button right? it needs to be someone on the list, so I am just asking do we agree that it's done by the code owner by default?

AlexanderLanin Jan 27, 2026
Collaborator Author

Yeah we do. But lets address it. Devcontainer is a special case at the moment since CODEOWNER != maintainer.

FScholPer Jan 27, 2026
Collaborator

I would say devcontainer is special as it is used by everyone. There should be no owner

opajonk Jan 27, 2026
Collaborator

Agreed, this is certainly a tool for everyone. However, you still need some kind of maintainer which keeps the lights on (update tools etc. regularly) and keeps and eye on the "architecture"... just like for the rest of the infrastructure...

odra Jan 28, 2026
Collaborator

I would like to present about how autosd will be included in the os_images repository, together with some autosd image builder updates (bootc) and how that integrates in a Bazel workflow.

dcalavrezo-qorix · 2026-01-28T12:55:09Z

dcalavrezo-qorix
Jan 28, 2026
Collaborator

Weekly RUST 28-01-2026

14:00-15:00 CET

Participants

@dcalavrezo-qorix
@bharatGoswami8
@pawelrutkaq
@PLeVasseur

Agenda

prepared DR for clippy clippy: added decision record on how to integrate clippy #2466
prepared S-CORE execution contract draft execution contract #2475
still opened: - AP: we need to fork our own rules_rust and publish a release with our changes in our S-CORE BCR
issue from @MaximilianSoerenPollak https://github.com/orgs/eclipse-score/discussions/236#discussioncomment-15505810
- release new score_toolchain_rust with blanket and symbol-report incorporated
updated score_tooling to 1.1.0, incorporating bazel rules to easily produce RUST coverage
at this point we have a Demo coverage workflow set-up for persistency ferrocene: build with compiler persistency#201
- it will be switched to a reusable workflow
- the job fails if the configured coverage is not met - the gate is per test target/ component, not an overall one
- the line coverage for the RUST within the repo is 93%

---
Fully Tested: 131
Partially tested: 11
Fully untested: 6
Fully ignored: 24
Total: 172
---
Generated coverage report at /home/runner/.bazel/execroot/_main/bazel-out/k8-fastbuild/bin/coverage/rust-tests/__src_rust_rust_kvs_tests/blanket/index.html
Line coverage for //src/rust/rust_kvs:tests: 93.16% (913/980 lines)
Report for //src/rust/rust_kvs:tests: /home/runner/.bazel/execroot/_main/bazel-out/k8-fastbuild/bin/coverage/rust-tests/__src_rust_rust_kvs_tests/blanket/index.html
---
Overall line coverage: 93.16% (913/980 lines across 1 targets)

 -  you can download the artifacts/reports from here

https://github.com/eclipse-score/persistency/actions/runs/21402500267/artifacts/5273959839

Minutes

AP: identify how to consolidate coverage reports for mixed situations ( repos with both C++/ RUST code)

1 reply

PLeVasseur Jan 28, 2026
Collaborator

https://github.com/rustfoundation/safety-critical-rust-coding-guidelines

Eclipse S-CORE

Meeting Minutes #236

Uh oh!

Uh oh!

AlexanderLanin Jan 28, 2025 Collaborator

Replies: 92 comments · 24 replies

Uh oh!

Uh oh!

AlexanderLanin Jan 28, 2025 Collaborator Author

Kick-Off

Uh oh!

Uh oh!

AlexanderLanin Jan 28, 2025 Collaborator Author

Daily

Uh oh!

Uh oh!

AlexanderLanin Jan 28, 2025 Collaborator Author

Daily

Uh oh!

Uh oh!

AlexanderLanin Jan 31, 2025 Collaborator Author

Daily

Uh oh!

MaximilianSoerenPollak Feb 3, 2025 Collaborator

Daily

Uh oh!

Uh oh!

AlexanderLanin Feb 5, 2025 Collaborator Author

Daily

Uh oh!

Uh oh!

AlexanderLanin Feb 7, 2025 Collaborator Author

Daily

Uh oh!

Uh oh!

AlexanderLanin Feb 7, 2025 Collaborator Author

Daily

Uh oh!

Uh oh!

AlexanderLanin Feb 10, 2025 Collaborator Author

Daily

Uh oh!

Uh oh!

AlexanderLanin Feb 12, 2025 Collaborator Author

Daily

Uh oh!

Uh oh!

AlexanderLanin Feb 12, 2025 Collaborator Author

Python tooling in bazel deep dive

Uh oh!

hoe-jo Feb 14, 2025 Collaborator

Python tooling in bazel deep dive follow up

Uh oh!

Uh oh!

AlexanderLanin Feb 17, 2025 Collaborator Author

Daily

Uh oh!

Uh oh!

AlexanderLanin Feb 17, 2025 Collaborator Author

How to reuse tools across repositories?

Uh oh!

Uh oh!

AlexanderLanin Feb 17, 2025 Collaborator Author

Daily

Uh oh!

Uh oh!

AlexanderLanin
Jan 28, 2025
Collaborator

Replies: 92 comments 24 replies

AlexanderLanin
Jan 28, 2025
Collaborator Author

AlexanderLanin
Jan 28, 2025
Collaborator Author

AlexanderLanin
Jan 28, 2025
Collaborator Author

AlexanderLanin
Jan 31, 2025
Collaborator Author

MaximilianSoerenPollak
Feb 3, 2025
Collaborator

AlexanderLanin
Feb 5, 2025
Collaborator Author

AlexanderLanin
Feb 7, 2025
Collaborator Author

AlexanderLanin
Feb 7, 2025
Collaborator Author

AlexanderLanin
Feb 10, 2025
Collaborator Author

AlexanderLanin
Feb 12, 2025
Collaborator Author

AlexanderLanin
Feb 12, 2025
Collaborator Author

hoe-jo
Feb 14, 2025
Collaborator

AlexanderLanin
Feb 17, 2025
Collaborator Author

AlexanderLanin
Feb 17, 2025
Collaborator Author

AlexanderLanin
Feb 17, 2025
Collaborator Author