Base Libs FT Meeting Minutes 2025

[4og]

This is the archive of the Base Libs Feature Team meetings in 2025.

[4og]

Weekly 2025-06-18

Participants

@ramceb
Felix Moelders
@FScholPer
mishu-dev
@RAHUL2054
Alekhya Reddy
@4og

Agenda & Meeting Minutes

1. Introduction & work mode
   • Base libs FT scope. Repos: https://github.com/eclipse-score/baselibs (except for mw::log) and inc_json
   • Work mode
     • Team goal: To drive the development of Base Libraries in S-CORE while ensuring S-CORE processes are followed and providing support to other feature teams.
     • How to become a contributor: https://www.eclipse.org/projects/handbook/#contributing
   • Communication channels
     • See https://github.com/orgs/eclipse-score/discussions/1223
   • Meeting time. Is it ok for everyone?
     • We keep the current timeslot.
2. GitHub Project for the Base Libs: BAS - Baselibs FT
3. Roadmap for S-CORE 0.5
   • Focus on fulfilling the S-CORE process for the code in https://github.com/eclipse-score/baselibs and getting the json lib qualified.
4. Qualification of the JSON library. Summary of https://github.com/orgs/eclipse-score/discussions/1181 & https://github.com/orgs/eclipse-score/discussions/1225 and the next steps.
   • Practical example for TSF is needed. @mishu-dev to invite Paul and Daniel Krippner (can be found on Slack), @masc2023. The next Baselibs FT meeting is to be dedicated to applying TSF to nlohmann json.
   • "Daniel Krippner: Trustable Service Mesh via Eclipse uProtocol & Trustable Software Framework" https://www.youtube.com/watch?v=SBAqX7EyEDY&ab_channel=EclipseSoftwareDefinedVehicle
   • Component request for json parser: Feature Request: JSON Parser #822. The stakeholder requirement is to be converted to a feature requirement.

[4og]

Weekly 2025-06-25

Participants

@ramceb
@masc2023
@mishu-dev
@devcurmudgeon
@FelixMoelders
@alexandruiulian10
@Erikhu1
@lennartbecker-d
@NilsEb
@AnotherDaniel
@sankurm
@kalu-an
@FScholPer
@mishu-dev
@RAHUL2054

Agenda & Meeting Minutes

1. Deep-dive Trustable framework for nlohmann json
2. Intro to the approach from d-fine @lennartbecker-d
   • see https://score-json.github.io/inc_json/pr-12/
   • [test coverage for nlohmann](json https://coveralls.io/github/nlohmann/json)
   • link calibration training for SME
3. Open topics:
   • Requirements elicitation for the safe json library
   • Collect AoUs.
   • Linkage to the existing tests.
   • Rationale for all items https://score-json.github.io/inc_json/pr-12/trustable/report.html

[4og]

Weekly 2025-07-02

Participants

@4og
@FScholPer
@kalu-an
Alekhya Reddy
@lennartbecker-d
@LuNieb
@mishu-dev
@FelixMoelders
@RAHUL2054
@arsibo

Agenda & Meeting Minutes

1. Open topics from the last meeting w.r.t. JSON lib qualification.
   • @mishu-dev will check with Communication FT and other FTs if any extra reqs for JSON are needed? E.g. w.r.t restriction to RFC. The new requirements are to be added the component request Feature Request: JSON Parser #822.
   • Do we have platform requirements? This will be discussed on 7.7.2025 in a special Tech Lead WS.
   • TSF is iterative, so new requirements can be incorporated on demand. Drastic changes in requirements (e.g. changing the JSON standard) will result in rework.
   • Logging lib should fulfill FFI. The safety decomposition needs to be done for the entire system to know the impact on the JSON lib.
2. Currently the entire Logging system is in baselibs repo. The long-term plan is to refactor it such way that only the interface is kept in the baselibs repo, and the rest moved to a separate module. The Logging FT will take care of refactoring.
3. It's still not clear how to bring the original nlohmann code to S-CORE with keeping the history and with a possibility to make changes. Is forking nlohmann_json repo to eclipse-score org an option? @mishu-dev will approach the Operation Community.
4. Anything to bring to the Architecture Community F2F Workshop next week? https://github.com/orgs/eclipse-score/discussions/1247
   • The Base libs FT meeting next week will be canceled due to the workshop

[FelixMoelders]

Please find attached the Application Example of TSF as pdf and the assertion to test mapping in the excel file:

• TrustableSoftwareFramework_JSON_library.pdf
• test_mapping.xlsx

[mishu-dev]

[heart] Haraga, Mihai reacted to your message:

…

________________________________ From: Felix Mölders ***@***.***> Sent: Thursday, July 3, 2025 6:17:35 AM To: eclipse-score/score ***@***.***> Cc: Haraga, Mihai ***@***.***>; Mention ***@***.***> Subject: Re: [eclipse-score/score] Base Libs FT Meeting Minutes (Discussion #1239) CAUTION: This is an external email. Do not click or open any attachments unless you recognize the sender and know that the content is safe. (http://links.conti.de/mailcheck) Please find attached the Application Example of TSF as pdf and the assertion to test mapping in the excel file: * TrustableSoftwareFramework_JSON_library.pdf<https://github.com/user-attachments/files/21030782/TrustableSoftwareFramework_JSON_library.pdf> * test_mapping.xlsx<https://github.com/user-attachments/files/21030786/test_mapping.xlsx> — Reply to this email directly, view it on GitHub<#1239 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/BQSAKRKOZPLPSIS5GK66VO33GTDH7AVCNFSM6AAAAAB7PUMJN2VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTGNRUHAZDENA>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[4og]

Weekly 2025-07-16

Participants

@4og
@arsibo
@FelixMoelders
@mishu-dev
@alexandruiulian10
@NilsEb
@chheis
Ankur Satle
Rahul Singh
Richard Trippel
Alekhya Reddy
@aschemmel-tech

Agenda & Meeting Minutes

1. Update from the Architecture Community F2F Workshop: https://github.com/orgs/eclipse-score/discussions/1247
   • Kickoff for defining assumed Platform AoU: https://github.com/orgs/eclipse-score/discussions/472?sort=new#discussioncomment-13751269
   • We will need to figure out where to place base libraries written in Rust. This will probably be a separate repository (= bazel module)
   • The scope of Baselibs FT is to take care of qualifying other third-party libraries.
2. The https://github.com/qnx-ports includes several JSON libs, but not nlohmann_json
   • Reason why nlohmann_json is chosen: @mishu-dev will provide a link where it was decided to use it.
3. Current status of JSON lib qualification.
   • Progress on applying TSF: setting up the trustable graph & assertions
   • Location of the fork/mirror: It will be a fork in eclipse-score github org pointing to the latest nlohmann_json release. TSF artefacts will be added to the fork. CI pipelines will be taken over from the upstream repo.
   • Feature Request: JSON Parser #822: is ready to be merged.
     - Introduce two components: for API (lib/json in baselibs repo) and the nlohmann_json .
     - Requirements need to be split to lib/json in baselibs and nlohmann_json fork.
     - Common reqs: e.g. the RFC8259: this one should be in the set of reqs of the fork.
4. Next steps for Feature Request: JSON Parser #822:
   • @arsibo will try to move the Modules structure from Com to Modules tab and inform about it in score-baselibs Slack channel.
   • Component requirements for JSON are to be relocated to Modules. Eventually, the structure should be similar to https://eclipse-score.github.io/process_description/main/folder_templates/modules/module_name/component_name/docs/index.html
   • Merge the PR to establish the basis.
   • Address changes in follow-up PRs (e.g. split to multiple components)

[lennartbecker-d]

Regarding 2:
I created some impressions on the motives to choose the nlohmann/json instead to other existing libraries here.

[4og]

Weekly 2025-07-23

Participants

@4og
@Jonas-Kirchhoff
@NilsEb
@aschemmel-tech
Alekhya Reddy
@mishu-dev
Rahul Singh
@FelixMoelders
Ankur Satle
Rutik Akolkar
Rahul Thakre
@kalu-an

Agenda & Meeting Minutes

1. TSF Framework will be presented in the Process Community meeting next week. @FelixMoelders
   • Direct nlohmann_json fork will be created with Create Nlohmann JSON FORK .eclipsefdn#58
2. Status of Feature Request: JSON Parser #822
   • Should S-CORE have a generic error-handling guideline? Ankur will raise a github issue
   • The communictaion+feo: move modules to the rigth folder #1438 is still not merged. After it is merged, the JSON Component Requests and the Requirements should be relocated to the next structure in the Modules tab.
3. Board BAS - Baselibs FT (view)
   • When adding new issues, always add ft:baselibs label
4. C++ Exceptions
   • https://github.com/orgs/eclipse-score/discussions/301 @mishu-dev, please leave a comment there to revive the discussion.
   • Helper in baselibs: https://github.com/eclipse-score/baselibs/tree/main/score/language/safecpp/aborts_upon_exception
   • From the safety perspective, it's ok to replace throws with abort.

[AlekhyaBendhi]

Weekly 2025-07-29

Participants

@aschemmel-tech
@Jonas-Kirchhoff
@alexandruiulian10
@FelixMoelders
@sankurm
@NilsEb
@richard Trippel
@RSingh1511

Agenda & Meeting Minutes

1. As agreed in the TL & Communities & CFTs Epic JSON library qualification using TSF (C++) #1460 will be part of 2025-10-01 Process Execution Audit Completed milestone to be delivered in January .
2. For ABI Compatible data types the concept is being discussed and will be part of SCORE V 1.0 ABI Data Types
3. Status of PR : Feature Request: JSON Parser #822 - to be closed and pushed it to Eclipse Score after approval @aschemmel-tech.
4. TSF Documentation and trudag tool is for TSF reports is being Demo'ed and once done they will be a PR raise for SCore. @FelixMoelders

[AlekhyaBendhi]

Weekly 2025-08-06

Participants

@aschemmel-tech
@Jonas-Kirchhoff
@alexandruiulian10
@FelixMoelders
@NilsEb
@erik
@mihai
@kalu-an

Agenda & Meeting Minutes

1. Generic comments on JSON:
   The PR:
   Comment 1: Feature Request: JSON Parser #822 (comment)
   higher level issue created: Improvement: Add an API implementation guideline #1533
   Comment 2: Feature Request: JSON Parser #822 (comment)
   Looks like this section was added: https://eclipse-score.github.io/score/pr-822/modules/baselibs/json/docs/index.html#future-extensions
2. Status of PR : Feature Request: JSON Parser #822 - to be closed and pushed it to Eclipse Score after approval @aschemmel-tech.
3. Open discussions for general topics can be found at Discussions
4. Trudag tool - continue with tool for alpha version, discussion on having versioning system is ongoing.
5. Clarification on comment for Comment to be done with @sankrum
6. Handling of C++ Exceptions as discussed in meeting with reference to nlohmann JSON - Abort is acceptable in context of nlohmann json library but not acceptable in context of eclipse score json wrapper

[aschemmel-tech]

Weekly 2025-08-13

Participants
@aschemmel-tech
@sankurm
@Jonas-Kirchhoff
@alexandruiulian10
@FelixMoelders
@Erikhu1
@mishu-dev
@RSingh1511
@arsibo

Agenda & Meeting Minutes

• @aschemmel-tech as a stand-in for @AlekhyaBendhi for this meeting
• Committers of the project are documented here: https://projects.eclipse.org/projects/automotive.score/who but additionally the CODEOWNERS files define which Committer needs to approve: see e.g. https://github.com/eclipse-score/score/blob/main/.github/CODEOWNERS
• PR Feature Request: JSON Parser #822 - finally merged
• Baselibs architecture: @arsibo asked if he can extend the baselibs module architecture according to 0.5 architecture as in https://github.com/orgs/eclipse-score/discussions/1247, at least for the components needed by logging module like "Filesystem" and "OSAL" - agreed, @arsibo will provide PR for review.
• C++ exception topic: see https://eclipse-score.github.io/score/main/contribute/development/api_guideline.html and PR Update api_guideline.rst #1610
• Discussion on Comment for Feature Request: JSON Parser #822 (comment) : @sankurm will provide example of possible solution as a comment to this MoM
  Note: C++20 is maybe possible in the future: see https://eclipse-score.github.io/score/main/contribute/development/cpp/coding_guidelines.html
  Writing C++ Code — S-CORE 0.1 documentation
• Reminder to @aschemmel-tech to provide branch for testing (by Nils over Slack)

[mishu-dev]

Weekly 2025-08-20

Participants:
@FelixMoelders
@Jonas-Kirchhoff
@alexandruiulian10
@Erikhu1
@sankurm
@RSingh1511

Agenda & Meeting Minutes:

• Discussion on Comment for Feature Request: JSON Parser #822 (comment) : @sankrum will provide example of possible solution as a comment to this MoM - preparation still in progress from @sankurm
• branch created but is mirroring the wrong repository , this should be fixed when @aschemmel-tech is back
• Update api_guideline.rst #1610 - our understanding is that allowing abort in exceptional use cases is enabled with this PR
• Decision based for nlohmann json selection for eclipse s-core - https://github.com/orgs/eclipse-score/discussions/1239#discussioncomment-13794352
• slack architecture community score-architecture-community - Markus Schu can help with process vs architecture questions

[4og]

Weekly 2025-09-03

Participants

@4og
@sankurm
@Jonas-Kirchhoff
@FScholPer
@Erikhu1
@FelixMoelders
@rtrippel-dfine
@aschemmel-tech
@AlekhyaBendhi
@RSingh1511

Agenda & Meeting Minutes

1. Review of open points from the last meeting
   • Update api_guideline.rst #1610 should be raised in Arch Community as a request for review. @qor-lb please add it to the agenda.
2. Status of TSF in S-CORE
   • D-fine is working on TSF documentation
   • It's not clear yet how the fork is updated from the upstream (issue: Define the process how the nlohmann fork is updated #1700).
   • Trudag tool is to be used in S-CORE as a pilot (agreed in the Process community). The tool generates a trustable report for a release. The safety arguments to the code, and if the code changes, the tool detects it and invalidate the affected arguments.
   • Safety qualification of TSF and its tooling is in scope of the Process community. The auditors are aware of S-CORE using TSF.
   • @Jonas-Kirchhoff will share the current state of applying TSF for nlohmann for @aschemmel-tech to review. @FelixMoelders will schedule an appointment with @aschemmel-tech this Friday.
   • Library-agnostic data types in S-CORE.
     • It's part of the JSON wrapper in baselibs repo.
   • Should we have separate repos?
     • Currently the json_test_data is a branch in https://github.com/eclipse-score/inc_nlohmann_json/tree/json_test_data_version_3_1_0_mirror
     • for documentation, nlohmann_json fork, and the test data (fork of https://github.com/nlohmann/json_test_data).
     • according to TSF, all dependencies must be mirrored.
     • It's probably ok to have 2 repos: nlohmann_json fork with added documentation and the json_test_data fork. @FScholPer will discuss this with @AlexanderLanin.
     • The https://github.com/eclipse-score/inc_json can be deleted. @FScholPer will discuss this with @AlexanderLanin.
3. Current work on align the code in Baselibs with S-CORE process
   • Feature architecture for Baselibs: Committing Base Libs Architecture Document  #1656 please review.
   • Component description, architecture, and requirements are WIP at BMW.
4. For the next week meeting: have a demo of the current state of TSF (if it's ready).

[4og]

Weekly 2025-09-10

Participants

@4og
@Jonas-Kirchhoff
@FelixMoelders
@Erikhu1
@mishu-dev
@FScholPer
@RSingh1511

Agenda & Meeting Minutes

1. Reviews
   • Update api_guideline.rst #1610
   • Committing Base Libs Architecture Document  #1656
2. Outcome of the meeting last week regarding the current state of applying TSF for nlohmann json.
   • @aschemmel-tech and @masc2023 provided a review on the current state of the TSF documentation: TSF documentation findings score-json/json#73
   • The https://github.com/score-json reflects the current state of the TSF documentation. Later the documentation is going to be migrated of eclipse-score org.
3. Demo of the current state of TSF.
   • See https://score-json.github.io/json/main/report.html
   • Feedback is welcome.
4. Conclusion on the repository discussion.
   • Keep the https://github.com/eclipse-score/inc_nlohmann_json repository and three branches (mirror of upstream develop branch, mirror of the test data, and a pinned release that is subject for qualification).
   • Keep the https://github.com/eclipse-score/inc_json for now.
   • This decision will be revisited after S-CORE 0.5 release.
5. Rust library for manipulating JSON files
   • Currently not in scope for Baselibs FT (for S-CORE 0.5).
6. QNX platform for use in the reference integration is not ready. It means that we won't be able to provide any evidence in the trustable report yet.
   • See also https://github.com/orgs/eclipse-score/discussions/1692
7. AoUs in TSF
   • They are part of the report. See example: https://score-json.github.io/json/main/generated/trustable_report_for_Software.html#compliance-for-aou
   • How are platform AoU handled in TSF? @masc2023

[FelixMoelders]

Weekly 2025-09-17

Participants

@sankurm
@Jonas-Kirchhoff
@Erikhu1
@pawelrutkaq
@arsibo
@rtrippel-dfine
@FelixMoelders
@aschemmel-tech

Agenda & Meeting Minutes

• State of the TSF and Incorporation of Feedback from @aschemmel-tech and Markus Schu
  • The feedback was addressed (TSF documentation findings score-json/json#73)
  • A review session should be scheduled (22. september at 14:00-16:00) - https://teams.microsoft.com/meet/385685795586?p=SJESgh2ypazH5tkQkp
• Doc as code integration of trudag features
  • Alexander Lanin suggests that the documentation is executed in rst files and transformed into md for consumption of the trudag tool.
  • Arvid Sievert points out that the "implemented by" could be used to support the approach of not changing the source code.
  • Alexander Lanin points out that versioning/hashing is currently not supported (core feature of trudag) but is in development (estimated october).
  • Erik Hu will check the "implemented by" feature of doc as code for mapping of the argumentation to the code.
• Write Feature
  • Can be tsf-documented in the same way as the read functionality. Effort estimate is 5-15 PD.
  • Write functionality is already in use, so should be qualified too for v0.5 of score.

[AlexanderLanin]

Versioning in docs-as-code is currently estimated to mid October.
Concept discussion at useblocks/sphinx-needs#1481
But, at least in early versions, it will probably not cover hashing.

[4og]

Weekly 2025-09-24

Participants

@4og
@mishu-dev
@FelixMoelders
@aschemmel-tech
@Jonas-Kirchhoff
@rtrippel-dfine
@sankurm

Agenda & Meeting Minutes

1. Reviews
   • Define component requirements for Utils library #1717
   • Define component requirements for Containers library #1718
   • Define component requirements for bitmanipulation library #1719
2. State of TSF and integration of trudag
   • Proposal for S-CORE 0.5:
     • Keep trudag out of doc-as-code until the project agrees that TSF is the right approach for SW module qualification.
     • The docs-as-code is still used to generate the final TSF report. The trudag output is the input for the doc-as-code.
     • The repos in https://github.com/score-json will be relocated to eclipse-score organization.
     • The safety assessors will use the generated TSF report along with other S-CORE documentation.
     • @AlexanderLanin, do you agree with this approach?
3. Write functionality in JSON lib
   • Write functionality is implemented directly in JSON lib: https://github.com/eclipse-score/baselibs/blob/main/score/json/json_writer.h, so nlohmann_json is not used.
   • For S-CORE 0.5 we don't apply TSF for writing.
   • There should be evidence that writing with nlohmann_json is not executed.
   • Should we split the requirements into two components, the wrapper and the backend (i.e. nlohmann_json) to differentiate between responsibilities of each component? Split JSON component requirements into two sets #1432 @aschemmel-tech, please propose a decent split between the component requirements.

[4og]

Weekly 2025-10-01

Participants

@4og
@Jonas-Kirchhoff
@rtrippel-dfine
@alexandruiulian10
@mishu-dev
@arsibo
@aschemmel-tech

Agenda & Meeting Minutes

1. Baselibs is a pilot module for I-Gate in S-CORE
2. State of TSF
   • When are we going to set scores?
     • The precondition to calculate resulting scores is to perform a review of evidences. Proposal: @aschemmel-tech and @masc2023 will perform the review.
     • Subject matter experts are setting initial scores. Currently the scores are already set by d-fine based on best effort. Info about scores: https://codethinklabs.gitlab.io/trustable/trustable/trudag/scoring-impl.html
   • Repository migration: When to migrate https://github.com/score-json to eclipse-score organization. @Jonas-Kirchhoff will investigate what needs to be done.
3. Splitting JSON requirements: Split JSON component requirements into two sets #1432

[4og]

Weekly 2025-10-08

Participants

@4og
@rtrippel-dfine
@alexandruiulian10
@Jonas-Kirchhoff
@FelixMoelders
@Erikhu1
@aschemmel-tech
Paul Quiring
@arsibo
@mishu-dev

Agenda & Meeting Minutes

1. Component requirements
   • Split JSON component requirements into two sets #1432
     - @aschemmel-tech prepared a PR: Split JSON-Library in two components #1846
     - Is requirement https://eclipse-score.github.io/score/pr-1846/modules/baselibs/json/docs/requirements/index.html#comp_req__json__validation needed? @mishu-dev will check if this requirement is needed.
   • Ready for review after addressing review comments:
     - Define component requirements for Containers library #1729
     - Define component requirements for bitmanipulation library #1727
     - Define component requirements for Utils library #1723
2. State of TSF
   • Review of evidences. @aschemmel-tech is on it. Related PR: Review round 2 score-json/json#92
     • The report generation tooling is being simplified. Currently it is not possible to generate the report locally. @Erikhu1 will inform @aschemmel-tech via Slack once it's fixed.
   • Repository migration to eclipse-score org.
     • Blocker 1: nobody in D-fine has committer rights in S-CORE to setup the branch protection & security rules. Configuration has to be done via https://github.com/eclipse-score/.eclipsefdn. Infrastructure community can assist.
     • Blocker 2: After migration, only the committers would have rights to approve & merge. It maybe hard to get committer right for d-fine. Possible solution: Eclipse S-CORE takes over the content of https://github.com/score-json and the contributions there are provided as evidence in the committer election process. @rtrippel-dfine and @4og join the [sdv-wg-SCORE] Alignment Tech Leads, Community Leads & Feature Team Leads or "[sdv-wg] Eclipse S-Core Project Office Hours" on Monday to ask how to proceed.

[mishu-dev]

Hello
@arsibo
@vbogdanb
@crimson11
@LittleHuba

FYI:
@4og
@aschemmel-tech
@Erikhu1
@Jonas-Kirchhoff
@alexandruiulian10

Related to the following requirement.
https://eclipse-score.github.io/score/pr-1846/modules/baselibs/json/docs/requirements/index.html#comp_req__json__validation

Is it enough if the checks are done only internally by the json library during the processing or do you also need this as an additional public interface explicit function for your client functionalities (ex: communication, persistence, logging etc).

The requirement proposal origin:
#822 (comment)

requirement in discussion: The JSON-Library shall provide a service to check the well-formedness of JSON data.

Thank you!

[mishu-dev]

Communication:

• Feedback from @LittleHuba and @crimson11 on 13.10.2025 Communication CFT meeting
  • json should be validated during the image build
  • no runtime requirement needed at the moment
• link: https://github.com/orgs/eclipse-score/discussions/1893

[vbogdanb]

Feedback from Persistence CFT :

• json should be validated at runtime as json files will also be written at runtime
• another use case would be in case the json files get corrupted during runtime

[4og]

Weekly 2025-10-15

Participants

@4og
@Erikhu1
@Jonas-Kirchhoff
@rtrippel-dfine
@aschemmel-tech
@mishu-dev
Paul Quiring
Kai Hudalla

Agenda & Meeting Minutes

1. Baselibs QNX build for I-Gate:
   • First release: https://github.com/eclipse-score/baselibs/releases/tag/v0.1.0
   • Release verification workflow: https://github.com/eclipse-score/baselibs/blob/main/.github/workflows/release_verification.yml
   • There are still various issues: Baselibs doesn't compile with bl-x86_64-qnx configuration baselibs#28, QNX build fails on inotify (undefined references); repo conditionally links libfsnotify only for //bazel/platforms/qnx_version:qnx8 baselibs#26
2. Component requirements
   • Split JSON component requirements into two sets #1432
     - Split JSON-Library in two components #1846
     - Reformulate the comp_req__json__validation.
     - Remove the "Check" logical operation.
   • New component requirements:
     - Define component requirements for Containers library #1729
     - Define component requirements for bitmanipulation library #1727
     - Define component requirements for Utils library #1723
3. State of TSF
   • Committer rights after repo migration: After attending "[sdv-wg] Eclipse S-Core Project Office Hours", looks like the committer rights won't be granted right away.
   • Proposal (Migrate the TSF documentation of nlohmann_json to eclipse-score org #1905):
     1. migrate to eclipse-score org. Repo: https://github.com/eclipse-score/inc_nlohmann_json
     2. have a shared fork where multiple contributors work together (e.g. in https://github.com/score-json/)
     3. Periodically upstream via PR (e.g. once a week).
     4. The PR is reviewed by a Committer (e.g. @4og or @aschemmel-tech).

Next meeting: @4og is not available on 22 October to moderate the meeting. Whoever feels responsible, feel free to moderate the meeting.

[mishu-dev]

Weekly 2025-10-22

Participants

@arsibo
@rtrippel-dfine
Paul Quiring
@Jonas-Kirchhoff
@pawelrutkaq
@mishu-dev
@Erikhu1

Agenda & Meeting Minutes

• Logging CFT new pull request available for logging: import: import log crate as baseline baselibs#18
  • provide rust solution to the baselibs
  • copy log crate from rust to eclipse baselibs and connect it to c++
  • intermediate solution due to current eclipse limitations
  • communication , feo , baselibs needs the rust version of logging
  • goal to merge would be to merge the log crate till 24.10.2025 - @4og please also check this pull request
• ETAS Proposal to pitchup a new data feature request for baselibs for flat buffer functionality for configurations stored in binary blobs ( currently only JSON is available ) - much faster than json , there is an solution from ETAS that can be pitched
• @arsibo please check if this requirement is needed for logging and reply as a comment: https://github.com/orgs/eclipse-score/discussions/1239#discussioncomment-14636056
  • requirement in discussion: The JSON-Library shall provide a service to check the well-formedness of JSON data.
• TSF: new release should be tagged with semantic versioning which is no 100% compatible with TSF documentation
  • how releases should be named in context of semantic versioning:
    • proposal example: official_version_tag_version - not compatible because of the format (only a pair of major.minor.patch is allowed
    • how strict is the semantic versioning policy or can we diverge with documenting the versioning convention ???? - please contact Markus Schu
  • migrate to eclipse-score org. Repo: https://github.com/eclipse-score/inc_nlohmann_json in progress
  • Discussions with @aschemmel-tech related to the review process. When this is done the migration procedure can be done.

[4og]

Weekly 2025-10-29

Participants

@4og
@arsibo
@Erikhu1
@mishu-dev
@FelixMoelders
@OliverHeilwagen
@alexandruiulian10
@paulquiring
@JochenSatETAS

Agenda & Meeting Minutes

1. Change: add component binary config loader #1935 -> planned to be discussed in S-CORE arch workshop in Ulm.
2. New repo to store common libraries written in Rust: https://github.com/eclipse-score/baselibs_rust
3. Recent changes in https://github.com/eclipse-score/baselibs
   • Bazel version is updated to 8.3.1. This required update to gtest 1.17. @arsibo, check with the logging team.
   • Release branch to prepare S-CORE 0.5 alpha: https://github.com/eclipse-score/baselibs/tree/s_core_release_v0_5_0 it's created on the old state of the baselibs module, because the latest sate is not compatible with the communication module.
   • Releases https://github.com/eclipse-score/baselibs/releases/tag/v0.1.1 and https://github.com/eclipse-score/baselibs/releases/tag/v0.1.2 are done from this branch.
   • The releases are available in the bazel registry: https://github.com/eclipse-score/bazel_registry/tree/main/modules/score_baselibs
4. Component requirements
   • Split JSON component requirements into two sets #1432 - merged
   • New component requirements:
     - Define component requirements for filesystem library #1909
5. State of TSF for JSON lib
   • Repository migration: need to push master branch of the upstream nlohmann repo to https://github.com/eclipse-score/inc_nlohmann_json. @Erikhu1 and @4og will take care of it.
   • Regarding https://github.com/orgs/eclipse-score/discussions/1239#discussioncomment-14725824
     • Validation of JSON is done while reading: https://github.com/eclipse-score/score/pull/1846/files#diff-3021f19ca29852735e45e642dcf51c8d65871db748493f130c9aba33d8c14a43R35-R36
     • @mishu-dev will approach Persistency FT to discuss the need for JSON validation while writing.
6. Docs-as-code seems to be fixed, so the module docs https://eclipse-score.github.io/score/main/modules/index.html can be moved to the corresponding repos. BMW will start moving the docs to the baselibs repo,
7. Next meeting: @4og is not available on 5 November due to the S-CORE Architecture Workshop.
8. ABI compatible types are to be discussed in the Baselibs FT. To be pitched in the architecture workshop: https://github.com/orgs/eclipse-score/discussions/1922

[rtrippel-dfine]

Participants

@Erikhu1
@LucaFgr
@aschemmel-tech
@paulquiring
@rtrippel-dfine
hatem

Agenda & Meeting Minutes

• TSF/JSON:
  • obstacle regarding migration: main branch currently cannot be created. Bypass permission to user necessary, now approved.
  • TODO: Read over release checklist for v0.5 alpha
  • new review from @aschemmel-tech for: TT-CONFIDENCE (PR 118)
• @aschemmel-tech + @4og: Working on component requirement inspection, s. Piloting Comp Req Inspection #1947

[4og]

Weekly 2025-11-12

Participants

@4og
@mishu-dev
@Erikhu1
@paulquiring
@LucaFgr
@OliverHeilwagen
@aschemmel-tech
@rtrippel-dfine
@halnasri
@arsibo

Agenda & Meeting Minutes

1. Baselibs module release to be used in S-CORE 0.5 Alpha: https://github.com/eclipse-score/baselibs/releases/tag/v0.1.3
   • S-CORE v0.5-alpha release notes #1987
2. State of TSF for JSON lib
   • Repository migration Migrate the TSF documentation of nlohmann_json to eclipse-score org #1905
   • From now on, https://github.com/eclipse-score/inc_nlohmann_json is the mirror of the upstream repo.
     • We need to add inc_nlohmann_json into score bazel registry.
     • And we need to adapt the baselibs module to depend on inc_nlohmann_json from the registry.
     • Ticket: Add nlohmann_json to bazel registry and update dependency in baselibs module #1993
   • CI workflows don't work properly from forks -> address in score-infrastructure community. Ideally, we should enable possibility to everyone to contribute from their forks. @Erikhu1
   • @aschemmel-tech did more review of TSF stuff: https://github.com/score-json/json/pulls The comments could be discussed in the regular TSF meeting (see Eclipse SDV Calendar).
3. Outcome of the S-CORE Architecture workshop last week.
   • Features affecting Baselibs FT
     • [Contribution Request] ABI compatible datatypes #1763
     • Change: add component binary config loader #1935 -> bring to the architecture community meeting for the decision in ~2 weeks. @arsibo and @OliverHeilwagen will prepare an announcement with a request to feature teams to participate in the decision-making. Since we strive for a single solution for a single problem, every module should either switch to the flatbuffer approach or keep sticking to the json for dealing with the static configuration.

[4og]

Weekly 2025-11-19

Participants

@4og
@a-zw
@OliverHeilwagen
@LucaFgr
@Erikhu1
@aschemmel-tech
@halnasri
@FelixMoelders
@rahulthakre29
@mishu-dev
@arsibo
@AlekhyaBendhi

Agenda & Meeting Minutes

1. Module safety plan for Baselibs:
   • Create Baselibs Module Safety Plan #2055
     • discussion about flatbuffers: they will also require tool qualification. See https://eclipse-score.github.io/score/main/score_tools/index.html
   • Piloting Comp Req Inspection #1947 - Requirements inspection
     • How requirement inspection is updated in case of requirement change: currently we plan to do inspections for each qualifiable release, later we may have a CI automation to help out.
     • REQ_08_01 checklist element: BMW will try to fill out this row.
2. Migrating module documentation to https://github.com/eclipse-score/baselibs
   • Add docs-as-code dependency baselibs#41 - todo for @rahulthakre29
   • Add docs-as-code documentation generation to github actions baselibs#42 - todo for @a-zw
   • Migrate module documentation to eclipse-score/baselibs baselibs#43 - it causes a cyclic dependency between score and baselibs repos
     • The issue is that feature architecture references elements from module architecture that requires score to depend on baselibs.
3. State of TSF for JSON lib
   • Add nlohmann_json to bazel registry and update dependency in baselibs module #1993
   • CI workflows works from forks

[4og]

Weekly 2025-11-26

Participants

@4og
@Erikhu1
@rtrippel-dfine
@OliverHeilwagen
@rahulthakre29
@LucaFgr
@alexandruiulian10
@aschemmel-tech
@halnasri
@sankurm
@mishu-dev

Agenda & Meeting Minutes

1. TSF for JSON
   • Resolve TT-CHANGES feedback nlohmann_json#7 is merged
   • next steps: @aschemmel-tech is going to provide SME scores for TT-CHANGES.
2. Documentation migration
   • Add docs-as-code documentation generation to github actions baselibs#42
   • Migrate module documentation to eclipse-score/baselibs baselibs#43
     • Formulate the concrete proposal and present in the process community on 4th December. @4og, @aschemmel-tech, @OliverHeilwagen, @a-zw.
     • Put your ideas into this discussion: https://github.com/orgs/eclipse-score/discussions/2250
     • Currently we have three options:
       1. Pull needs.json from GH pages of module to retain the feature architecture view as we have currently
       2. Do nothing. Feature architecture and logical interfaces will render empty in score repo. The ref integration will show them however.
       3. Change the process to avoid feature architecture to depend on modules content. E.g. draw only the modules and their dependencies.
3. Dependency on logging in baselibs
   • There is a logging frontend in baselibs repo only because some base libraries need to log something.
   • @sankurm to summarize the cases of using logging in the baselibs in a github issue with a proposal to remove the dependency.

Next meeting (2025-12-03):

• Potential open-sourcing of vajson.

[FScholPer]

Weekly 2025-12-10

Participants

@4og
@awillenbuecher-xq-tec
@Erikhu1
@LucaFgr
@rahulthakre29
@aschemmel-tech
@linnealinnea
Anja Unnasch
@halnasri

Agenda & Meeting Minutes

1. Alignment with module template: Add missing formatter and checks from template baselibs#55 -> postponed to the next meeting
2. Scope for S-CORE 0.5 Beta release (scheduled on 18 Dec)
   • release form main branch
   • most of issues with QNX are resolved in eclipse-score/baselibs@b3fbed3
   • more safety artifacts compared to alpha
3. Documentation migration
   • Pause work on Migrate module documentation to eclipse-score/baselibs baselibs#43 until the S-CORE metamodel changes are clarified (scheduled on 2025-12-11 in the process community meeting)
4. TSF for JSON lib
   • Add nlohmann_json to bazel registry and update dependency in baselibs module #1993
   • Adapt nlohmann pipeline to check s-core matrix specification #1520
   • Adding scores for TT-Changes nlohmann_json#8 is approved and should be merged before Update 4 trustable tenets nlohmann_json#9
5. Component request: (JSON parsing) VaJson in S-CORE #2310
   • Change the issue to a PR following the https://eclipse-score.github.io/process_description/main/folder_templates/modules/module_name/component_name/docs/index.html# template
   • Repo for code: https://github.com/eclipse-score/inc_json
   • @aschemmel-tech will check if agreement with PLs is needed
   • Disclaimer: Effort of adapting the module to comply with s-score qualification process? - this action is not planned from Vector side, but open for anyone to take the task.
6. ABI compatible data types
   • Should we put rust container types to baselibs_rust repo and C++ types to baselibs repo?
     • No, let's put everything into baselibs_rust repo to simplify testing and assure compatibility in memory layout.
     • Long term goal is to migrate all code from baselibs_rust into baselibs.
7. Naming convention for needs in baselibs and baselibs_rust modules -> postponed to the next meeting
8. Next meeting: 7 January 2026