Base Libs FT Meeting Minutes 2026

[4og]

All regular meetings of the Base Libs Feature Team will be documented in this thread. If you subscribe here, you'll get summaries of the meetings you missed.

[4og]

Weekly 2026-01-07

Participants

@4og
@LucaFgr
@Erikhu1
@aschemmel-tech
@rtrippel-dfine
@paulquiring
@halnasri
@rahulthakre29
@Priyanka-Patil18
@ssingh2099

Agenda & Meeting Minutes

1. S-CORE 0.5 Beta release. https://eclipse-score.github.io/score/main/score_releases/score_releases/score_v0_5_beta.html
   • todo: bring changes from the release branch to main.
2. vajson change request will be discussed at the Architecture Community meeting next week. https://github.com/orgs/eclipse-score/discussions/472#discussioncomment-15414444
3. Current state of TSF for JSON
   • Should it go to the 0.5 final release?
     • https://github.com/eclipse-score/score/issues/1993 is a prerequisite
     • reference integration should have nlohmann json as a dependency, and the docs should be added to https://eclipse-score.github.io/reference_integration/main/
     • open question: is it ok to have inc_ repo in the bazel registry? @4og to bring this to the S-CORE FT leads & communities alignment meeting.
4. PRs up for review:
   • Define AoU requirements for filesystem lib #2360

[4og]

Regarding the open point: I updated https://github.com/eclipse-score/score/issues/1993 based on the outcome of the alignment meeting. The inc_ can be removed from the name.

[4og]

Weekly 2026-01-14

Participants

@4og
@FelixMoelders
@halnasri
@paulquiring
@OliverHeilwagen
@LucaFgr
@Erikhu1
@linnealinnea
@Priyanka-Patil18
@ssingh2099

Agenda & Meeting Minutes

1. S-CORE 0.5 Final release is shifted to end of February. The cadence of future releases is planed to be changed.
   • The changes made in the baselibs release branch for 0.5 beta release have been moved to main.
2. Change request to introduce vajson library:
   • Discussed in the Architecture Community meeting: https://github.com/orgs/eclipse-score/discussions/472#discussioncomment-15414444
   • Next steps:
     • Finalize docs: Adding requirements and a component change request for vajson #2358 - @linnealinnea
     • Dump the code to https://github.com/eclipse-score/inc_json - this will be started in about two weeks.
     • Make the code compliable
     • Dump safety documentation
     • Convert documentation to the S-CORE format -> Support from the community will be needed.
3. TSF for nlohmann_json
   • https://github.com/eclipse-score/score/issues/1993 - Unblocked and can be worked on.
   • Persistent data storage like test reports - Suggestion is to store files in repository releases.
   • Code scanning alerts - some of them are already resolved, and some need to be dismissed. @4og can dismiss alerts.
4. Documentation migration for baselibs - on pause until process: add DR-001 for independent feature delivery #2346 is complete.
5. Handling of dynamic memory in S-CORE - currently there are not guidelines in S-CORE for it. It would be nice to add one.

[4og]

Weekly 2026-01-21

Participants

@4og
@FelixMoelders
@LucaFue
@halnasri
@OliverHeilwagen
@rahulthakre29
@Priyanka-Patil18
@arsibo
@ssingh2099
Thomas Clausnitzer
@paulquiring
@aschemmel-tech

Agenda & Meeting Minutes

1. New release strategy for S-CORE: https://github.com/orgs/eclipse-score/discussions/2383#discussion-9297512
2. Migrate to score_bazel_cpp_toolchains baselibs#70 - waiting for the https://github.com/eclipse-score/bazel_cpp_toolchains release. Strict warnings currently cannot be enabled due to many compilation errors.
3. Update on TSF
   • Internal review for Bug: Unresolved review comments in TA-ANALYSIS nlohmann_json#10, PR will be created soon. @aschemmel-tech will review it.
   • There will be proposal for dealing with C++ exceptions in nlohmann_json. To be presented next week.
   • Rename inc_nlohmann_json repo to nlohmann_json .eclipsefdn#127
4. ABI compatible data types
   • Current status is unknown. To be discussed next week.

[4og]

Weekly 2026-01-28

Participants

@4og
@aschemmel-tech
@halnasri
@linnealinnea
@FelixMoelders
Thomas Clausnitzer
@ShoroukRamzy
@rahulthakre29
Ingo Matheis
@NEOatNHNG
@rtrippel-dfine
@atarekra
@sankurm
@Rutik7

Agenda & Meeting Minutes

1. New workflows in baselibs repo
   • https://github.com/eclipse-score/baselibs/tree/main/.github/workflows
   • Known issues:
     • Bazel cache is not working well. Attempt to fix it: Improve Bazel cache behavior: restrict writes to pushes and add optional disk-cache input for QNX workflow cicd-workflows#56
     • Missing copyrights in a few files and duplicated copyrights. Bug: multipe copyrights baselibs#82
2. Proposal for dealing with C++ exceptions in nlohmann_json
   • it's possible to disable exceptions using a runtime parameter allow_exceptions. It's available in parse API.
   • The lib would still throw on API misuse cases. Thomas Clausnitzer will provide a link for that.
   • Thomas Clausnitzer will check if error message is captured on parse error.
   • Check if any changes in https://github.com/eclipse-score/baselibs/tree/main/score/json/internal/parser/nlohmann are needed.
3. Update on TSF
   • Meeting with Exida is planned on Friday.
   • Resolve TA-ANALYSIS Feedback and Adapt nlohmann pipeline to check s-core matrix specification nlohmann_json#16 - Special handling is needed. See "!! important information !!" section.
4. ABI compatible data types
   • https://eclipse-score.github.io/score/main/features/communication/abi_compatible_data_types/index.html
   • @4og and @pawelrutkaq will work on creating a roadmap for this component.
   • Some rust types have already been implemented in [Rust] Base containers baselibs_rust#6
   • There is some activity in communication FT regarding implementing a variant type. @sankurm will arrange github issues.
   • @NEOatNHNG also needs a variant/union type to exchange data between two C++ processes via mw::com.
   • IDL topic still needs alignment in Architecture community. This will be required at some point for the SOME/IP serialization/deserialization. It's also needed for Rust-C++ interoperability.

[TClausnitzer]

Hi, quick follow-up with the nlohmann/json exception reference, this is the link to the official docu.

As to more details on possible throws with API misuse:

• In the baselibs wrapper the nlohmann usage is limited to nlohmann::json::parse(...) with a parser callback (parse_event_t) and basic type checks/conversions in the callback path. For the most common error, malformed JSON text, the only relevant nlohmann parse error class is json.exception.parse_error.101. As we talked about in the call, this is the error that does not throw with the parameter parse(..., allow_exceptions=false).

• I suspected some possible other throws for API misuse, such as parse error 104 - 115 or error 2xx- 5xx. On a closer look, none of these errors can occur in the current wrapper code path, but only during use of other nlohmann functions such as at(), patch(), etc.

• Any remaining "throw/abort" scenarios would be general C++ runtime failures (e.g. OOM) or would require changes of the wrapper to use additional nlohmann APIs.

[4og]

Weekly 2026-02-04

Participants

@4og
@aschemmel-tech
@rtrippel-dfine
@TClausnitzer
@OliverHeilwagen
@FelixMoelders
VPeddina
@atarekra

Agenda & Meeting Minutes

1. S-CORE release milestones:
   • https://github.com/eclipse-score/score/milestones
2. Baselibs repo
   • New release: https://github.com/eclipse-score/baselibs/releases/tag/v0.2.3
   • Issue with new gcc toolchain: Analyze and resolve issues caused by strict_warnings toolchain feature from score_bazel_cpp_toolchains baselibs#97
   • Limited support for AArch64 Linux: Baselibs doesn't work on AArch64 Linux due to libacl dependency being x86_64 only baselibs#78
3. Update on TSF and nlohmann
   • https://github.com/eclipse-score/score/issues/1993 - in progress
   • Update on certification based on feedback from the assessors - We're on a good path! Once certification process started, it's expected to take ~3 months. Possibly, it will be funded by the Eclipse Foundation as it's a strategic topic that demonstrates usage of TSF. Certification process is expected to start around November 2026 according to the current plan. Follow-up meeting on the certification topic is planned on 13.02.2026.
   • Error handling
4. ABI compatible data types
   • Epics: ABI compatible data types - C++ baselibs#86 and [Rust] Base containers baselibs_rust#6

[TClausnitzer]

As promised in the call, here are the two slides I showed during our call conscerning the exception handling in nlohmann/json. As a short summary, we currently already have exception handling in our glue wrapper, which returns a message indicating a parsing error, but no detailed diagnostic message.

To obtain detailed diagnostics about the parsing errors, we would need to use sax_parse() using a custom SAX interface. As of yet, no final decision has been made on switching to sax_parse(), I will explore further what that would mean in terms of security concerns, performance and dynamic memory.

Exception Handling in nlohmann.pptx

[4og]

Weekly 2026-02-18

Participants

@4og
@rtrippel-dfine
@TClausnitzer
@ShoroukRamzy
@paulquiring
@Rutuja-Patil-Bosch
@aschemmel-tech
@FelixMoelders
Jonathan
@VamsiKrishna-max

Agenda & Meeting Minutes

1. S-CORE 0.6 release
2. Upcoming changes in project tracking BAS - Baselibs FT
   • Cleanup is ongoing
3. Dynamic memory in nlohmann/json
   • Two DOM trees exist: only when nlohmann json object is constructed and in json wrapper.
   • it's possibile to use SAX parser instead of json.parse().
   • It's unclear how the situation with the dynamic memory in vajson is.
   • Performance benchmarks of various json libs: https://github.com/miloyip/nativejson-benchmark#parsing-time (suggested to be put to documentation).
   • @TClausnitzer will check if it's possible to use polymorphic allocators with nlohmann/json.
4. TSF for nlohmann/json
   • Update save_historical_data branch to prepare PR #16 nlohmann_json#21 - needs workflow approval from a committer (already done).
   • @TClausnitzer: https://github.com/eclipse-score/score/issues/1460 needs update
5. Extra unit tests for filesystem and datetime_converter libs.
   • Feel free to propose a PR.
6. Baselibs for Rust
   • Use slack channel to discuss potential contributions.
7. Access management and crypto in Baselibs
   • See https://eclipse-score.github.io/score/main/features/security_crypto/index.html and [Contribution Request] Security & Cryptography #2054

[4og]

Weekly 2026-02-25

Participants

@linnealinnea
@TClausnitzer
@ShoroukRamzy
@aschemmel-tech
@VamsiKrishna-max
@sankurm
@lammjo
@atarekra

Agenda & Meeting Minutes

1. vajson update (https://github.com/eclipse-score/score/issues/2602) by @linnealinnea - vajson code is provided current work on removing dependencies from Vector libraries, update in staffing from next week onwards, dynamic memory use similar to nlohman (how to deal with this could be to make the amount of dynamic memory usage configurable in the future), performance compared to RapidJSON is about 3 times slower
2. TSF for nlohmann/json - merged Resolve TA-ANALYSIS Feedback and Adapt nlohmann pipeline to check s-core matrix specification nlohmann_json#16 and Update save_historical_data branch to prepare PR #16 nlohmann_json#21, next PR in progress, expected to be finished end of the week, final contribution for the Tenents
3. polymorphic allocators usable in nlohmann/json? - seems not possible to use a singe memory pool. @TClausnitzer to add detailed explanation as a comment.
4. Review for const correctness for public interfaces in MemoryManagedResource baselibs#110 remove unnecessary lock in SharedMemoryResource::do_deallocate baselibs#108 - please check these

[TClausnitzer]

More on the polymorphic allocators for nlohmann/json here:

So for implementation of polymorphic allocators (std::pmr) we would need to use type-level allocators (std::pmr::polymorphic_allocator) and a runtime memory pool (std::pmr::memory_resource, e.g. monotonic_buffer_resource):

• With basic_json we can swap out types via template parameters (so we can quite easily pick pmr-enabled container/string types): see here.
• The problem is the runtime memory pool: during parsing we can’t reliably inject/propagate a single memory_resource instance through the whole parse, that was simply not in the design scope of nlohmann/json, and forcing it in the code can lead to allocator mismatch: see here
• So basically, just adding the type level allocators with a custom basic_json interface would add some complexity, but not offer full allocator propagation

[4og]

Weekly 2026-03-04

Participants

@4og
@JuriSchroeder
@paulquiring
@rahulthakre29
@ShoroukRamzy
@Rutuja-Patil-Bosch
@TClausnitzer
@masc2023
@ssingh2099
@aschemmel-tech
@sankurm
@Rutik7
Ahmed TAREK-RAMADAN

Agenda & Meeting Minutes

1. @JuriSchroeder is taking over the vajson open-sourcing topic. Welcome to the S-CORE project!
   • The cleanup work for vajson is currently done in the internal repo, and it will be published as a PR in https://github.com/eclipse-score/inc_json as soon as the work is complete.
2. TSF for nlohmann/json: Discussion about Risk Analysis findings (risk_analysis.md file in Update trustable tenet TT-EXPECTATIONS nlohmann_json#22)
   • STPA diagram contains elements that are not SW components, but process descriptions (workmodes, guidelines). The proposal is to remove them.
   • Term "untrusted" is unclear. It used in different contexts in the risk_analysis.md. And it somewhat contradicts with AoUs for nlohmann/json. It would be nice to have some clarification in the text (e.g. untrusted input JSON means corrupted JSON, etc.)
   • Feels like HARA/TARA style of analysis.
   • Tailoring of the process is needed. Currently it feels too complicated for a header-only library. @masc2023 and @aschemmel-tech will investigate and give feedback.
   • @aschemmel-tech will also discuss this with the accessors.
   • TA behaviours checklist and context have different content, and it's unclear what is used in the generated report currently. Context needs to be used. @TClausnitzer will check this and make sure that other TAs are correctly handled.

[4og]

Weekly 2026-03-11

Participants

@4og
@JuriSchroeder
@aschemmel-tech
@rahulthakre29
@TClausnitzer
@ssingh2099
@ShoroukRamzy
@atarekra
@LucaFue
@anmittag

Agenda & Meeting Minutes

1. Requirement inspection of the bitmanipulation lib requirements:
   • Done according to the https://eclipse-score.github.io/process_description/main/general_concepts/score_review_concept.html#inspection-conduct
   • See Comp Req inspection - Bitmanipulation #2480 @Rutik7 is going to address the findings in Improvement: Correct bit manipulation requirements based on inspection findings #2669.
2. TSF for nlohmann/json: outcome of the meeting with the assessors: some hints were given to improve the risk analysis in Update trustable tenet TT-EXPECTATIONS nlohmann_json#22. The rework is ongoing.
3. The https://github.com/eclipse-score/inc_json is archived, but will be unarchived. Currently, @JuriSchroeder is working on a fork of the https://github.com/eclipse-score/baselibs with vajson placed in the score/json folder.
4. All bugs here BAS - Baselibs FT (view) are still relevant.

[4og]

Weekly 2026-03-25

Participants

@4og
@OliverHeilwagen
@rahulthakre29
@atarekra
@Priyanka-Patil18
@TClausnitzer
@paulquiring
@JuriSchroeder
@ShoroukRamzy
@aschemmel-tech

Agenda & Meeting Minutes

1. TSF for nlohmann/json
   • https://github.com/eclipse-score/score/issues/1993. To get it published in the registry, a release at https://github.com/eclipse-score/nlohmann_json/releases needs to be created. @4og will assist.
   • The risk analysis PRs got merged. The last one was Add tailored STPA risk analysis nlohmann_json#25
2. Component request for flatbuffers: https://github.com/eclipse-score/score/issues/1935 and the general approach for pulling flatbuffer as dependency.
   • Component request will be updated
   • flatbuffers upstream (https://github.com/google/flatbuffers) will need to be forked in case it needs to be qualified using the TSF process (similar to https://github.com/eclipse-score/nlohmann_json). The exact qualification process for flatbuffers needs to be discussed and agreed in the process community. Maybe TSF is not needed. flatc - is the tool for codegen. It can be tool-qualified (after tool evaluation). The headers used by the user code can be qualified using the S-CORE process.
   • Baselibs repo will be used for the header wrapper and extra starlark rules. Any new issues should be linked to the https://github.com/eclipse-score/score/issues/2608
3. Workflow for merging changes in Baselibs.
   • Context: remove unnecessary lock in SharedMemoryResource::do_deallocate baselibs#108 & const correctness for public interfaces in MemoryManagedResource baselibs#110
   • The changes are first merged into an internal repo, and then exported to https://github.com/eclipse-score/baselibs

[4og]

Weekly 2026-04-01

Participants

@4og
@JuriSchroeder
@aschemmel-tech
@ThomasClausnitzer
@OliverHeilwagen
@atarekra
@Rutuja-Patil-Bosch

Agenda & Meeting Minutes

1. Module documentation migration to eclipse-score/baselibs
   • Migrate module documentation to eclipse-score/baselibs baselibs#43
   • Overview of the documentation structure in S-CORE: https://eclipse-score.github.io/score/main/design_decisions/DR-001-proc.html
2. TSF for nlohmann/json
   • Update bazel dependencies to recent versions nlohmann_json#28
   • nlohman_json repository is shown as uncategorized in https://github.com/eclipse-score#uncategorized. @4og will check that
3. Ongoing work to run unit tests in QNX VM on GitHub Actions
   • Enable QNX UT for x86-64 baselibs#134
4. Review for Add round-trip and leap-year coverage tests for DateTimeConverter (pre/post 1970) baselibs#135 is requested.
5. The Migrate module documentation to eclipse-score/baselibs baselibs#43 may take some time, so the Add flatbuffers component #2720 can be reviewed and merged to score repo and then migrated to the baselibs repo along with the other components.
6. vajson can be brought directly to the baselibs repo instead of inc_json.
7. Filled out https://eclipse-score.github.io/score/main/modules/baselibs/docs/verification/module_verification_report.html is planned for S-CORE 1.0.

[4og]

Weekly 2026-04-08

Participants

@4og
@OliverHeilwagen
@JuriSchroeder
@ThomasClausnitzer
@atarekra
@paulquiring
@aschemmel-tech

Agenda & Meeting Minutes

1. Scope of S-CORE 0.7
   • Release is currently expected to happen at the end of April. See discsussion https://sdvworkinggroup.slack.com/archives/C085F44D2CS/p1775556559664299
   • baselibs repo release will be created either today or tomorrow.
2. TSF for nlohmann/json
   • Update bazel dependencies to recent versions nlohmann_json#28
   • Can it be made to s-core 0.7 release including the dependency change in baselibs? Change nlohmann_json dependency to point to s-core bazel registry baselibs#103 This will require an additional baselibs release.
3. @aschemmel-tech will moderate the meeting on 15 and 22 April.

[4og]

Weekly 2026-04-15

Participants

@OliverHeilwagen
@JuriSchroeder
@paulquiring
@aschemmel-tech
@anmittag
@ShoroukRamzy
@atarekra

Agenda & Meeting Minutes

1. Execute unit tests on QNX using the score_qnx_unit_tests baselibs#142
2. Baselibs - S-CORE Release v0.7 #2687 - new release
3. Question on Baselibs OS abstraction layer, which contains interfaces with different ASIL: this is not a common practice in Baselibs, it is coming from the QNX use of this component: QNX has a subset of the interfaces it provides qualified - so Baselibs groups these together for better discrimination. See also Add OS library component requirements in baselibs #2743 for requirements and https://github.com/eclipse-score/baselibs/blob/main/score/os/README.md for architecture
4. For contributions in S-CORE you need to join Eclipse and also sign the ECA (see https://www.eclipse.org/contribute/) - otherwise the check for this fails and your contribution cannot be merged.

[aschemmel-tech]

Weekly 2026-04-22

Participants

@TClausnitzer
@OliverHeilwagen
@JuriSchroeder
@aschemmel-tech
@rtrippel-dfine
@MichaelSteffens17

Agenda & Meeting Minutes

1. Ongoing safety analysis for baselibs: Feature FMEA/DFA for baselibs #2777, Baselibs component DFA #2820 and more to come
2. Further requirements inspections: Feat Req inspection - Baselibs #2812
3. What are next steps in https://eclipse-score.github.io/nlohmann_json/main/report.html? - d-fine team is working on adding scores and validate the links, @aschemmel-tech should be contacted via slack if there are new PRs to review.
4. For technical reviews on PR please trigger Katancevic Mihajlo and Baeuerle Florian
5. @MichaelSteffens17 asked how to contribute new component "no-throw containers in shared mem" PoC: https://github.com/MichaelSteffens17/baselibs/tree/main/score/nothrow - please do similar to Component request for Base Libraries: Configuration loading using FlatBuffers baselibs#164 and using the template in https://eclipse-score.github.io/process_description/main/folder_templates/modules/module_name/component_name/docs/index.html#doc__component_name

[4og]

Weekly 2026-04-29

Participants

@4og
@OliverHeilwagen
@paulquiring
@JuriSchroeder
@fscr
@rahulthakre29
@ssingh2099
@rtrippel-dfine
@ThomasClausnitzer
@aschemmel-tech

Agenda & Meeting Minutes

1. JSON lib in baselibs
   • Next steps after the Add vajson to score baselibs baselibs#139 is merged:
     • Open-source the vajson test suite.
     • The quality KPIs for code coverage (only for info, no need to comply for the upcoming releases until the code coverage tooling is well established): https://eclipse-score.github.io/score/main/platform_management_plan/software_verification.html#quality-criteria
     • @JuriSchroeder will take over docs: Adding requirements and a component change request for vajson #2358
     • vajson safety artifacts (requirements, architecture, detailed design, safety analysis, AoUs) - @JuriSchroeder will provide a PR in baselibs repo, ideally in the format defined in https://eclipse-score.github.io/process_description/main/process_areas/index.html. @ThomasClausnitzer (and d-fine in general) can support with the documentation.
     • What backend to make default will be discussed in the next meetings.
2. Direct PR merges in https://github.com/eclipse-score/baselibs
   • We plan to enable direct PR merges next week.
   • Some folders will remain closed for direct merges for now. PRs touching these areas will still need to be merged into the internal codebase first.
   • We plan to gradually reduce the number of restricted folders over the coming weeks.
   • End goal: fully eliminate internal-only merges.

[4og]

Weekly 2026-07-15

Participants

@4og
@OliverHeilwagen
@paulquiring
@aschemmel-tech
@Priyanka-Patil18
@anmittag
@Rutuja-Patil-Bosch

Agenda & Meeting Minutes

1. Relocate score/memory to eclipse-score/communication and clean up remaining baselibs dependencies baselibs#371
   • This will be a breaking change for baselibs users. Adaptation to include paths, bazel targets, and namespaces would be needed.
   • The scope of the braking changes and how to migrate will be explained the release notes.
2. Update baselibs feature requirements per inspection findings #3071
   • After removing feat_req__baselibs__safety it became unclear how to promote component requirements to ASIL B when a corresponding feature requirement is QM. @4og will raise a PR with adapting baselibs to the latest score_platform to see how it looks like.
3. Toolchain usage in examples: Add score_bazel_cpp_toolchains support to example module baselibs#363
4. Code and UT update for epoch time calculation within DateTimeConverter  baselibs#230 - needs a review from @gierer

[4og]

Weekly 2026-07-22

Participants

@4og
@anmittag
@OliverHeilwagen
@Rutik7
@FScholPer
@JuriSchroeder
@aschemmel-tech
@Priyanka-Patil18
@sankurm

Agenda & Meeting Minutes

1. Relocate score/memory to eclipse-score/communication and clean up remaining baselibs dependencies baselibs#371
   • The original strategy has changed. The Migrate atomic indirector and string manipulation baselibs#396 provides a migration path for users
   • Follow up: Further preparation for moving score/memory/shared baselibs#400
2. vajson Library: Initial contribution & integration into S‑CORE baselibs#149 - status updated
3. New baselibs module release - planed for Monday, 27.07 or Tuesday 28.07
4. Add component FlatBuffers Library to Base Libraries baselibs#147 - all remaining work is merged - the epic is closed
5. Two backends for JSON lib: a decision is needed if we still would like to have two.
6. vajson writer is not open-sourced yet. Still in internal discussion.
7. Code coverage Evaluate llvm-cov coverage solution in baselibs baselibs#289 Unclear if llvm-cov is the right approach as line coverage computation there is incorrect. Follow-up in break-out session with all parties involved. Discuss it in "SCORE - reference integration weekly"

[4og]

Weekly 2026-07-29

Participants

@4og
@odra
@aschemmel-tech
@paulquiring
@MichaelSteffens17
@Rutik7
@JuriSchroeder
@sankurm
@eclipse-impl
@Priyanka-Patil18

Agenda & Meeting Minutes

1. New baselibs release: https://github.com/eclipse-score/baselibs/releases/tag/v0.2.10
2. Removal of deprecated functionality
   • Option 1: Pin removal to the next S-CORE release.
   • Option 2: Pin removal to a Baselibs release.
   • Idea: Write the release number in the release notes when deprecated functionality is to be removed.
   • Bring it to the S-CORE alignment meeting - @4og
3. Issue templates in eclipse-score github organization and in baselibs repository
   • The issue is that organization-wide templates are ignored by github if at least one template is present in a repo.
   • Try to bring the https://github.com/eclipse-score/baselibs/blob/main/.github/ISSUE_TEMPLATE/fusa_component_req_inspection.yml to https://github.com/eclipse-score/.github/tree/main - 4og to create an issue.
4. Announce Nothrow: Substitutes for standard C++ containers and memory resources, with pluggable pointer storage policies baselibs#167 in the Architecture Community Slack - @4og

[4og]

Weekly 2026-08-05

Participants

@odra
@paulquiring
@OliverHeilwagen
@4og

Agenda & Meeting Minutes

1. Flatbuffers: current state and the roadmap till the end of the year.
   Topics still to do (provided by @OliverHeilwagen):

• tool classification flatc (binary serialization)
• tool qualification flatc
  • generic (via end to end integration test)
  • module specific (via end to end integration test)
• finish flatbuffer header unit tests unit tests (flatbufferscpp target)
• SCA for flatbuffer header (flatbufferscpp target)
• generated header unit test (coverage & sca handling)
  • demonstrate in baselibs
  • replicate in modules
• architecture documentation
• component / feature integration tests (if not already covered by above points)
• Other supporting documents e.g. FMEA

These are to be put to the github issues under an epic or multiple epics
Later attached to a product increment (@anmittag)

[OliverHeilwagen]

As discussed in the meeting, this is only the broad pending topics overview not what is planned to be finished till end of this year.
We currently expect to be finished by some time in 2027.

[4og]

Weekly 2026-08-12

Participants

@4og
@odra
@aschemmel-tech
@OliverHeilwagen
@JuriSchroeder
@anmittag
@Rutik7
@Priyanka-Patil18
Aryan (LTTS)

Agenda & Meeting Minutes

1. User manual for libraries
   • It's possible to link source code to sphinx-needs elements (meant to be used for requirement linking). Example: https://github.com/etas-contrib/score_baselibs/blob/79594b3abbfe2595191195281b66f6c0f022898b/score/flatbuffers/load_buffer.hpp#L32
   • Each component must have a docs folder
   • Some components have detailed design pages in markdown format. It's still open if we link them in sphinx-needs docs or not.
   • It's beneficial that every component folder has a readme in markdown format as it's easier to explore the code base such way.
   • The content of https://github.com/eclipse-score/baselibs/tree/main/examples needs documentation and it should be linked on github pages front page. @4og to create an issue.
   • See also https://eclipse-score.github.io/score/main/contribute/general/folder.html
2. When using agents for requirement engineering: https://github.com/eclipse-score/baselibs/tree/main/.agents/skills/requirements-management-skill
3. Usage of mw/log in baselibs
   • Safety collaterals such as requirements, detailed design and architecture will be documented in the baselibs repo for the mw/log frontend. One exception: the safety manual is to be placed in the score_logging including the parts belonging to the mw/log frontend.
4. baselibs docs must be accessible from reference Integration docs, but it doesn't seem to be the case now. Action: ask the reference integration team why it's missing - @anmittag

[4og]

Weekly 2026-08-19

Participants

@JuriSchroeder
@OliverHeilwagen
@Priyanka-Patil18
@aschemmel-tech
@sankurm

Agenda & Meeting Minutes

1. New baselibs release: https://github.com/eclipse-score/baselibs/releases/tag/v0.2.11 - main change is the removal (transfer) of memory/shared to communication repository. Documentation of this removal still to do (e.g. in feature architecture, component requirements, ...) - @4og to create tickets for this.
2. Open-sourcing vajson serializer - Vector agreed to provide the serializer in S-CORE. Question is how to deal with the already existing "json writer" implementation. Proposal is to have the Vector json serializer sorce code first in S-CORE baselibs and then to compare the feature sets of the two implementations and merge (delete duplicated functions) if necessary. The alternaive suggested by Vector is to provide a PR which already removes surplus code with the addition of the Vector json serializer. @JuriSchroeder to follow the second approach.
3. Folder and file structure for tests - FT opinion is to better make the folder structure as recommended. @aschemmel-tech prepared Add DR about module folder structure #3194 which would follow this opinion.

[4og]

The documentation of the score/memory will be cleaned up in epic eclipse-score/baselibs#522 The removal of the moved-out content is in eclipse-score/baselibs#586

[4og]

Weekly 2026-08-26

Participants

@4og
@JuriSchroeder
@anmittag
@MichaelSteffens17
@sankurm

Agenda & Meeting Minutes

1. New baselibs release for S-CORE 0.9
   • will be released today
2. Rename the ABI Compatible Data Types component baselibs#516
   • More proposals are welcome
3. Overview of reporting
   • the verification report contains test-requirement traceability: https://eclipse-score.github.io/baselibs/main/verification_report/requirements_statistics.html
   • The code coverage report is available in the github actions artifacts and in the release artifacts.
4. vajson serializer open-sourcing:
   • Current implementation does pretty-printing whereas vajson produces a long one-line output.
   • Ideally we need a runtime parameter to choose pretty printing or not
   • For now. place the code in https://github.com/eclipse-score/baselibs/tree/main/score/json/internal/writer next to the current implementation with a bazel config. The end goal is to have only one implementation. Performance is one of the factors to decide.

[4og]

Weekly 2026-09-02

Participants

@4og
@paulquiring
@JuriSchroeder

Agenda & Meeting Minutes

1. bazel: switch to score_cpp_policies for clang-tidy baselibs#514
   Next steps:
   • Upload scanning results to Github Code Scanning
   • Unify clippy, ruff, and clang-tidy because all of them are based on the aspect_rules_lint.
   • The infrastructure for clang-tidy in score_cpp_policies has a lot of drawbacks especially the misleading documentation. Will we clean this up.
2. Cancel next week Baselibs weekly (2026-09-09)? Both @4og and @aschemmel-tech are not available next week.

[4og]

Weekly 2026-09-09

No meeting this week.

[4og]

Weekly 2026-09-16

Participants

@JuriSchroeder
@MichaelSteffens17
@sankurm
@aschemmel-tech
@OliverHeilwagen
@Priyanka-Patil18

Agenda & Meeting Minutes

1. Flatbuffers: Add issues for the remaining work as discussed in https://github.com/orgs/eclipse-score/discussions/2390?sort=new#discussioncomment-17882485
2. JSON schema validator (tool that is executed during the bazel build). There is validation tooling in communication, but it's also needed for flatbuffers and probably other components such as logging. @OliverHeilwagen will talk to @arsibo about bringing this up in the Architecture community.
3. Linters in baselibs.
   • All clippy, ruff, and clang-tidy can be run with --config=lint
4. JSON lib: Add vajson as second serializer backend baselibs#520
   • Several findings are confirmed as bugs. @JuriSchroeder is in touch with the vajson developers and will give feedback in the PR.

[OliverHeilwagen]

As briefly discussed in weekly meeting 2026-09-23, the JSON schema validator was discussed with @arsibo plan is to propose a starlark wrapper rule in baselibs later this year.

[4og]

Weekly 2026-09-23

Participants

@4og
@paulquiring
@aschemmel-tech
@OliverHeilwagen
@JuriSchroeder
@Priyanka-Patil18

Agenda & Meeting Minutes

1. Deprecation clean-up: Epic: Retire deprecated Baselibs APIs and Bazel targets baselibs#595
   • Corresponding bump in ref_intergation revealted that several S-CORE modules still use deprecated targets. @4og will bring this up on Monday in S-CORE alighnment sync to discuss who is in charge of removing usages of deprecatated functionality.
2. Automatically generated verification report: https://eclipse-score.github.io/baselibs/main/verification_report/module_verification_report.html
   • For to set a requirement as fully verified one needs to set testcovered: YES. It is currently not reflected in the verification report. In general it'd be better to have a more reliable mechanism to claim a requirement as fully verified based on a group of passed unit tests. @aschemmel-tech and @OliverHeilwagen (via @RolandJentschETAS) will bring it to the process community.
3. Planning for the flatbuffers qualification activity: FlatBuffers: Extend quality artifacts (C++) baselibs#257
   • A break out session could be needed to discuss specific details.
4. Add vajson as second serializer backend baselibs#520
   • Ready to be reviewed and merged
   • @JuriSchroeder is planning to raise a PR with pretty-printing support for JSON
   • @mihajlo-k and @Nikhil2206 will lead the topic of JSON lib refactoring.

[aschemmel-tech]

Weekly 2026-09-30

Participants

@4og
@aschemmel-tech
@OliverHeilwagen
@JuriSchroeder
@fscr
@anmittag

Agenda & Meeting Minutes

1. https://github.com/orgs/eclipse-score/discussions/3283 - one interesting question for baselibs would be: "What kind of component is "abi_compatible_data_types" if it has no code / bazel target to it?"
   • Currently only Rust types are implemented. C++ types are still pending.
   • See https://github.com/eclipse-score/baselibs/issues?q=state%3Aopen%20label%3A%22comp-abi-types%22
2. Gaps for safety qualification
   • https://eclipse-score.github.io/reference_integration/main/verification_report/platform_verification_report.html#baselibs - There are valid feature requirements but no feature integration tests
   • How to provide feature integration tests for Baselibs?
     • ITF is useful for testing non-functional requirements and when actual executables involved.
     • For most of base libraries the unit tests (that also run in qemu QNX) are enough. - It should be decided for each component individually.
       • Proposal: make it part of feature requirement inspection. For example, for bitmanipulation we can formulate that the existing unit tests linked to component requirement are sufficient to claim no need in a feature intergation tests
       • The automatic verification report would still show missing test coverage. @aschemmel-tech will bring it to the Process Community to find a solution.
     • For generic libs (e.g. containers): add AoU that the user is obliged to test it with their types.
3. Since there is no much time left till S-CORE 1.0 release, we should focus on a few components for which we are confident to complete the safety process.
   • Candidates in baselibs: bitmanipulation, result, string_manipulation, scope_exit, containers
4. Follow up on the discussion in Weekly 2026-09-23 about the partial verification: https://github.com/orgs/eclipse-score/discussions/3292

[4og]

Weekly 2026-10-07

Participants

@4og
@OliverHeilwagen
@JuriSchroeder
@MichaelSteffens17
@mihajlo-k

Agenda & Meeting Minutes

1. nlohmann_json backend removal: Component Modification : json parser : remove parser backend selection and the nlohmann parser baselibs#632
   • Update the issue to follow the 1b_ComponentenRequest.yml template. Also mention the fork https://github.com/eclipse-score/nlohmann_json in the issue. We'll need to come to the decision if this repository should be kept or archived.
   • Check with the process community regarding the TSF for json lib - @aschemmel-tech
2. OpenSSL in S-CORE. Check how this can be used in baselibs.
   • See https://github.com/Valeo-S-CORE-Organization/inc_security_crypto_valeo_pitch/tree/test-openssl/third_party/score_openssl
   • https://github.com/eclipse-score/openssl - Since the hash lib is using openssl, baselibs should be involved in reviewing and adopting this version.
   • The goal is to switch to score_openssl (until the hash lib is migrated to security/crypto). In total 3 users of the score_openssl are expected: inc_secutiry_crypto, score_crates, and score_baselibs.
   • Migration of a part of hash lib: Migration of hashing from Baselibs to Crypto repo inc_security_crypto#125

[4og]

Weekly 2026-10-14

Participants

@OliverHeilwagen
@aschemmel-tech
@JuriSchroeder
@fscr
@sankurm

Agenda & Meeting Minutes

1. New baselibs release: https://github.com/eclipse-score/baselibs/releases/tag/v0.2.15
   • Issue with devcontainer is discussed in https://sdvworkinggroup.slack.com/archives/C0894QGRZDM/p1791883526115759
2. What can be achieved till the safety audit (in 3 weeks)?
   • Baselibs feature architecture inspection fixes: Perform Architecture Inspection Baselibs baselibs#188
   • The non-functional requirements are shown as not covered in the verification report. Example: https://eclipse-score.github.io/baselibs/main/baselibs/components/bitmanipulation/requirements/index.html#comp_req__bitmanipulation__header_only In this particular case maybe we don't need such requirement at all, but we leave it for now to serve as an example for non-functional requirement verification process. S-CORE Process community nominated @pahmann to have a look. Verification coverage of non-functional requirements process_description#813
3. Task assignment in baselibs
   • @4og to add @fscr to S-CORE Contributors
   • Open tasks can be discussed with @4og on Slack

[4og]

Weekly 2026-10-21

No meeting this week.