Meeting Minutes - Tech Lead Sync

[johannes-esr]

General Discussion for all Meeting Minutes

[johannes-esr]

2025-02-26

Participants

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

Meeting Minutes

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

[johannes-esr]

2025-02-28

Participants

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

Meeting Minutes

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

[johannes-esr]

2025-03-06

Participants

@pahmann
@antonkri
@FScholPer
@johannes-esr

Agenda

• Breakdown of first to Milestones in Epics

Meeting Minutes

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

[antonkri]

2025-03-07

Participants

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

Agenda

• Breakdown further Milestones

Meeting Minutes

• Milestone: Reference Integration Linux

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

• Milestone: QNX Support

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

• Milestone: Reference integration QNX

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

[johannes-esr]

2025-03-14

Participants

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

Agenda

• How to do further planning?

Meeting Minutes

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

[johannes-esr]

2025-03-19

Participants

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

Meeting Minutes

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

[johannes-esr]

2025-03-21

Participants

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

Agenda

• Open points from last discussion

Meeting Minutes

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

[qor-lb]

2025-03-24

Participants

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

Agenda

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

Meeting Minutes

to 1.

• An agenda of SteerCo but not update yet

to 2.
Proposals to be prepared until friday:

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

misc:

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

[qor-lb]

2025-03-26

Participants

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

Agenda

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

Meeting Minutes

to 1.

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

to 2.

• accepted

misc:

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

[johannes-esr]

2025-03-28

Participants

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

Meeting Minutes

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

[FScholPer]

2025-03-31

Participants

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

Agenda

• Feedback for planning milestones

Meeting Minutes

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

[johannes-esr]

2025-04-02

Participants

@johannes-esr
@antonkri
@FScholPer

Agenda

• Review of Monday Meeting

Meeting Minutes

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

[TomFleischmann]

2025-04-07

Participants

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

Agenda

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

Meeting minutes

Review last weeks cross functional community meeting

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

Review roadmap for next meeting

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

Craft agenda for next meeting

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

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

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

[FScholPer]

2025-04-11

Participants

Agenda

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

Meeting minutes

[johannes-esr]

2025-04-11

Participants

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

Meeting Minutes

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

[johannes-esr]

2025-04-14

Participants

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

Agenda

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

Meeting Minutes

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

[FScholPer]

2025-07-28

Participants

@qor-lb
@markert-r
@FScholPer
Mohamed BJIJOU
Mina Hamdi
@devcurmudgeon
@chheis

Agenda & Meeting Minutes

• Start Feature Team Orchestration
  • Invite into Monday Meeting
  • Create Epics
• Task Force
  • Invite Leads to Moday 10 a clock Meeting. Timeslot about 10 min. each
  • Assign the Taskforce Leads to the epics
  • Milestones of Taskforces to be discussed
  • Check overlaps with Infrastructure
• @chheis mentioned the Dashboard from Eclipse: Dashboard
• Please Review Pull Request @1281 until next week
• Logo issue assign Memsud
• LOP work

[chheis]

adding Participations from: @devcurmudgeon and @chheis

[FScholPer]

2025-07-31

Participants

@FScholPer
@antonkri
@markert-r
@johannes-esr
@hth9fe
Leonardo Rossetti

Agenda & Meeting Minutes

• Agenda PL Sync
  • Announcement Leave of Rebecca and step in of Thomas (Election of Thomas as TL and Comitter...)
  • Announcement of Markus Schu as official Safety, Quality and Security Manager
  • Community Day Review of slides via mail
  • Frequency of the PL Circle and how to handle Summer vacation season.
    • Proposal / offer do a cadence change to biweekly.
    • Proposal / offer break until mid of September(restart 19th of September 25)
  • Wish to have a agenda point to inform about congress / conference etc.
  • Audit moved to January 26 (S-CORE internal audit in December)
• Preparation of Slides about Reference Integration & QNX Reference Image and Story success
• TL Syn Meetings keep CW 32,34,36 cancel CW33,35,37. Restart 15th of September 25)
• Update Federate
  • Contributions from Hal4SDV / Shift4SDV possible in next months
  • S-CORE contribution processes have be used
• Qorix additional capacity @nmohanan31
• @antonkri will do a proposal to restructure the discussions
• Coming Office hour -> Biweekly.
• AutoSD will become incubation repository to start developing inside S-CORE
• Discussion about doc-as-code: https://docs.google.com/spreadsheets/d/1R3RbLRmZnPfJWC-VOT0SSTzH7S0CxhICEu2y-gxbtHo/edit?gid=0#gid=0
• doc-as-code TL Circle requests proposal for decision
• MB announced that their will be a potential app framework contribution in the next architecture workshop
  • Proposal: onsite workshop
• MB announced that their is plan to contribute a dds rust implementation
• Orchestration feature team kickoff -> invitation will come
• Invitation for the TL onsite day 4th of September will come in the next days
• PMPs ML2

[johannes-esr]

2025-08-04

Participants

@johannes-esr
@markert-r
@FScholPer
@nmohanan31
@qor-lb
Leonardo Rossetti
Paul Sherwood
Max Pabinger
Marco Heinemann
@antonkri
Thomas Hahn

Meeting Minutes & Agenda

• Introduction Round because of joining of Naveen
• Agenda Eclipse S-CORE Office Hours: Monthly, Monday 1pm CET (e.g. today)
  • Discussion created at https://github.com/orgs/eclipse-score/discussions/1540
• Agenda FT & Community Meeting
  • Discussion created at https://github.com/orgs/eclipse-score/discussions/434#discussioncomment-13984826
• AutoSD & Reference Integration
  • @antonkri will create a kick-off meeting reg. reference integration
• ADR PR: https://github.com/eclipse-score/score/pull/1408/files
  • Please included proposed changes directly into PR until next Monday
• @antonkri to create documentation reg. creation of FT
• Establish the CODEOWNER file for score repo #1491 -> to be reviewed
• LOP: Technical Lead Circle LOP (view)

[FScholPer]

2025-08-07

Participants

@johannes-esr
@devcurmudgeon
@nmohanan31
@FScholPer
@hth9fe

Meeting Minutes & Agenda

• On-Site TL Workshop on 4th of September 2025 -> Invitation by @FScholPer

  • Agenda: PMP

• @antonkri to present planning approach

• Validas

  • Toolchain qualification possible
    • Classification they can do -> Deepdive next TL Circle

• Hal4SDV, Shift4SDV

• @AlexanderLanin requested a process for repository creation

• LOP: Technical Lead Circle LOP (view)

[johannes-esr]

2025-08-18

Participants

@johannes-esr
@markert-r
@qor-lb
@odra
@hth9fe
@slotosch
@DanielSteinkeSDV
Mohamed Bejijou
@nmohanan31
@ubmarco
@chheis

Agenda & Meeting Minutes

• Tool Qualification with Validas
  • Validas proposed to support in the tool classification & qualification
  • Will start with classification -> Will result in public available documentation which can be used for qualification
  • Check availability of Infrastructure Community to Kick-Off this
• Planning Proposal @hth9fe: rework the section of work item types and relationship of the same #1605
  • PR to be continued, further review by TLs
• Preparation TL & Community & FT Agenda
  • https://github.com/orgs/eclipse-score/discussions/434#discussioncomment-14137747
• Review Technical Lead Circle LOP (view)

[johannes-esr]

2025-08-21

Participants

@johannes-esr
@nmohanan31
@opajonk
@hth9fe

Agenda & Meeting Minutes

• @opajonk will present some Elektrobit Linux example in S-CORE office hour in S-CORE Office Hour Meeting at September 1st
• Review Feature Requests: Feature Requests / Modification (view)
  • abi compatible data types feature request #1375 -> merge conflicts
  • docs: lifecycle feature #1246 -> asked PR owners
  • time feature request #1099
  • Feature Request: AI Platform #1258 -> no review from anyone available
  • SOME/IP Gateway #1115 -> unclear if it's finally done

To be followed up tomorrow at 11:30 am

[johannes-esr]

2025-08-22

Participants

@johannes-esr
@nmohanan31
@opajonk
@hth9fe
@qor-lb

Meeting Minutes & Agenda

• Review FRs: Feature Requests / Modification (view)

[FScholPer]

2025-09-01

Participants

@johannes-esr
@qor-lb
@odra
@FScholPer
@opajonk
@antonkri
@nmohanan31
@DanielSteinkeSDV

Agenda

1. PMP Issue for the PL Election Process from Eclipse Project leads are nominated and elected by committers #1623
2. PMP Issue for the TL Election Process from Eclipse Committers review and approve contributions #1624
3. Call for Contribution
4. Agenda of TL Workshop on Thursday
5. Agenda for TL, FT, Community Sync Meeting
6. LOP
7. https://pad.codethink.co.uk/i9_IsuxqRPq7IqVZh90Uow?view

Meeting Minutes

1. see comment of ticket
2. discuss with Wayne B. in Project Lead Circle next Friday
3. • No Process for Call for Contribution defined
   • To be discussed in Workhop on Thursday incl. proposal

[FScholPer]

2025-09-08 doc-as-code Meeting

Participants

@johannes-esr
@qor-lb
@FScholPer
@antonkri
@nmohanan31
@ramceb
@AlexanderLanin
@ubmarco
@danwos
@ubmax
@sameer6989

Agenda & Meeting Minutes

• TLRC & Lobster Licensing
  • Currently GPL v3 is used -> concerns regarding usage in commercial products
  • Outcome: It has to be evaluated if a relicensing would be possible
• Decision about doc-as-code. The Options to vote are:
  1. Proceed with the Sphinx-Needs
  2. • switch to TRLC requirements management and Lobster for tracing
     • sphinx-needs only for documentation
  3. Baselibs & Communication Modules use 2. and the Rest stays at 1. until end of the year 2025 there will be a new Decision for either 1. or 2.
  4. Sphinx-needs as primary tool (for process and infrastructure support). All artifacts are available in the primary tool. We allow modules to additionally support the secondary toolchain of TLRC & Lobster for the evaluation until 0.5

Votes:

• @qor-lb -> Option 4
• @FScholPer -> Option 1
• @AlexanderLanin -> Option 1
• @johannes-esr -> Option 4
• @antonkri -> Option 3

-> Decision note made, new meeting needed for re-vote (tomorrow 9am)

[FScholPer]

2025-09-15

Participants

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

Agenda & Meeting Minutes

• https://github.com/orgs/eclipse-score/discussions/1692

[johannes-esr]

2025-09-09

Participants

@johannes-esr
@antonkri
@qor-lb
@AlexanderLanin
@ramceb
@FScholPer
@ubmarco
@MarkSchmitt
@ubmax
@sameer6989
@nmohanan31

Voting

Option 1: For modules in S-CORE itself, sphinx-needs is the only permitted solution for requirements management, tracing & documentation.

Option 2: For modules in S-CORE itself, we switch to TRLC for requirements management and Lobster for tracing. Sphinx-needs is only used for documentation

Option 3: Sphinx-needs as the common language - modules are allowed to deviate (on their own responsibility)

S-CORE's common language is Sphinx-Needs. Modules wishing to be part of S-CORE are required to produce Sphinx-Needs artifacts. The means how to achieve this lies within each module’s freedom. Ideally the module uses Sphinx-Needs directly, which is recommended by S-CORE. Modules are, however, also free to choose another format and translate it to Sphinx-Needs. If a translation mechanism is used, it is the module's responsibility and duty to maintain that solution and be able to produce Sphinx-Needs artifacts at any point in time. Furthermore S-CORE expects such solutions to be available as Open Source.
This decision will be piloted for release 0.5. We will conduct a critical review after the release 0.5 completed. Based on the review’s outcome we will decide to adjust or take the approach further.

Risks mentioned:

1. Having different tools will break our current integration concept, which will block every PR until reference_integration is green.
   Example: renaming a requirements attribute from safety to safety_classification would require elaborate changes in each repository, depending on how the metamodel is configured and how requirements are stored (.trlc, .rst).

   Even if modules are considered "100% responsible" for their own tooling, some overhead will always end up in the central infrastructure. Distributors will have to set up more tools internally, and safety qualification will have to cover more tools.

   Cross-repository work will become more difficult, since contributors must follow the "software development method" of each repository, e.g. “how do I add/review a requirement here?”

   To sum it up:
   As long as the goal is to develop modules for the reference_integration within eclipse-score, in my opinion they must follow the same process, methods, and tools.
   If this principle is to be changed, it requires a dedicated discussion with project leads – not just a debate of TRLC vs. sphinx-needs.

-> Decision needs to be delayed, new meeting

[devcurmudgeon]

Does this mean that any pre-existing open source module to be adopted will also require Sphinx-Needs artifacts?

[FScholPer]

No but at least a converter to convert existing artifacts to that format

[antonkri]

Vote:

• @antonkri for PL Holger Grandy -> option 3
• @FScholPer for PL Thilo Schmitt -> option 3
• @nmohanan31 for PL @HartmannNico -> option 3
• @AlexanderLanin for PL Sven Kappel -> option 1

[AlexanderLanin]

This refers to https://github.com/orgs/eclipse-score/discussions/516#discussioncomment-14348298

[chheis]

@antonkri , @FScholPer, @AlexanderLanin , @qor-lb, @nmohanan31 : as I recall this vote, you need to consider ALL committers, not "only" Project Leads! See the EDP Handbook => Project Leads has no special voting rights nor veto rights.
If consensus is not reached within the committers, the escalations path is to the PMC.
@waynebeaton FYI

[FScholPer]

@chheis Just for understanding you told us that we need to vote every decision in the project with all committers?

[chheis]

No, just if the committers are not mainly on the same page (establish a conses)

[FScholPer]

2025-09-15

Participants

@johannes-esr
@qor-lb
C.A.Bryan (TSI)
@antonkri
Mohamed Bejijou (Valeo)
@hth9fe
@odra
@devcurmudgeon
@ubmarco
@FScholPer
Eduard Metzker

Agenda & Meeting Minutes

1. Agenda for TL, FT, Community Sync Meeting
   • https://github.com/orgs/eclipse-score/discussions/434#discussioncomment-14400445
2. Meta Feature Request: Platform request #1691
   • General approach okay -> @qor-lb to move this forward to incorperate it in the documentation
3. Timeline Call for Contribution
   • Timeline: Architecture Workshop beginning of November 4 - 6
   • Possible pitches: Code (OSS or internal) OR Concepts (Architecture, Design, API, ...)
   • @qor-lb to present this to the Architecture Community next Monday
4. Virtual Webinar Series at 04th November 2025 15:00 pm. 1-1,5h slot can be used to present S-CORE topics. Request from marketing team if there is interest and people to do so.
   • To be raised in MarCom community
5. Role of TL in Contrast of the Eclipse handbook e.g. Decision making process in the future. Also see https://www.eclipse.org/projects/handbook/#roles-other
   • Proposal to be prepared by Thilo
   • Meeting with Eclipe Foundation requested for next week
6. Technical Lead Circle LOP (view)

[ubmarco]

Let me lay out some thoughts I had throughout the last days of voting meetings and discussions.

In short
In terms of as-code requirements management, tracing and documentation, I see a rising risk for high complexity, maintenance and qualification efforts with the current discussion & decision approach.

The current discussion is driven around tools (tool X vs tool Y), not requirements and intentions.
Allowing to support all wanted module specific requirements management and documentation solutions
is a hell to maintain and understand. Whole concepts differ in peoples minds.

This is the current list of stakeholder requirements. We have 2 of them.
@AlexanderLanin asked for this over a longer period: let us collect requirements that the Engineering-as-Code approach should fulfill, just like we do for target ECU code. Then we do not have to discuss the details using Powerpoint slides. Just on stakeholder level, so there is something we can agree upon. We can also have multiple requirement levels (must / may), because no solution will tick all boxes.

I collected some requirements that I derived from the existing usage and that are coming in from the tool discussions. I would also like to add those with a PR.

• Some support for markup. Already written requirements in S-CORE contain
  • bullet lists (nested)
  • numbered lists
  • admonitions
  • code markup
  • links to other requirements
  • links to glossary entries
  • links to external documents
• Isolated source code analyzer with links to GitHub
  • File + line based tracing to existing requirements without creating new 'implementation' items
• Declarative schema definition
• Build system
  • Must work with Bazel as it's the default build system in S-CORE
  • Must work with build system xyz (for integrators of S-CORE)
• Must support build system cache for tracing sources
• Multi-project support (technical exchange format to import into other projects)
• Traceability and docs structure
  • Project based traceability (as it is now)
  • Project based documentation, integrated with traceability (as it is now)
  • Keep projects, but split traceability from docs (also means no requirements in docs)
  • File based traceability
  • Component based traceability (multiple files)
  • The build system decides what to integrate.
    Consider impact on IDE support that cannot know what files are part of the traceability/docs anymore.
  • Above requirements are obviously contradicting - allow multiple use cases?
• Performance baseline for x requirement items and y docs pages for:
  1. Traceability checks only
  2. Traceability html report
  3. Integration with docs
• Some sort of UML modeling
• Local dev build for integrated docs
• Reports
  • One page traceability report
  • Traceability analysis report
  • Coverage report

The list is far from complete, but I want to lay out the bare minimum for discussion.
Currently we let tool decision drive the stakeholder requirements and also integration requirements.
If every repo can choose their own tool, it also means the rest of the system needs to care for the missing pieces and will carry integration load.

I'm not against allowing other solutions, but the whole solution landscape is bigger than "decide for tool x vs tool y" or "allow any tool".
I also think we can change the way of working with the existing Sphinx-Needs solution so most of the requirements will be met.
Collecting the requirements will allow us to find any gaps.

Advantages:

• All modules will benefit from this
• Requirements driven
• A single integrated solution
• Less maintenance
• Less risk for 0.5 and going forward

[antonkri]

2025-09-12

Participants

@FScholPer
@antonkri

Agenda

1. S-Core Planning clean-up

Meeting Minutes