Technical Lead Workshop 4th of September 2025

[FScholPer]

2025-09-04 09:30 am-16:30 pm CET hosted by Mercedes Benz Tech Innovation Location Ulm Germany

Open for remote listeners. We have a rough agenda
so if you have general questions our office hour is the best place.

https://teams.microsoft.com/l/meetup-join/19%3ameeting_YjM3MGYyNDYtM2I3Yy00YzAyLWFiYzMtYWQ3YjQ5ODhiN2Mz%40thread.v2/0?context=%7b%22Tid%22%3a%229652d7c2-1ccf-4940-8151-4a92bd474ed0%22%2c%22Oid%22%3a%22530e8654-9978-4117-a0d5-83bf8724cf1e%22%7d

Participants

@johannes-esr
@antonkri
@qor-lb
@FScholPer
@nmohanan31
@b-rei
@hth9fe -> unclear
@AlexanderLanin

Agenda

• Tooling doc-as-code
• Process repository creation
• PMP
• Review/Update of CODEOWNER File, Define CODEOWNER election process #1684
• https://github.com/orgs/eclipse-score/discussions/1692
• DR-002-Infra: Integration Testing in a Distributed Monolith #1689 DR02
• DR-001-Infra: Integration Strategy for External Development Tools #1687 DR01
• Call for Contributions next steps

Meeting Minutes

[nmohanan31]

Meeting minutes

@antonkri
@FScholPer
@ubmarco
@AlexanderLanin
@opajonk
@qor-lb
@nmohanan31
@johannes-esr
@pahmann

Tooling doc-as-code

• There seems to be no major functional difference between Sphinx needs and Lobster TRLC
• Sphinx needs has the documentation aspect to it which is an advantage
• If Requirements needs mark up support then sphinx needs
• If we need documentation with with traceability then sphinx needs is the choice
• Maintenance of the tools is a big factor and has to be seen which satisfies this criteria
• Competency is another factor that should be considered
• The reason we are questioning sphinx needs is because it did not meet certain BMW use cases?
  • Bound to the sphynx format and don't have the freedom to define your own format
  • Sphinx needs needs to have rust tooling to be qualified
  • Integration into another build system is not trivial
  • Integration into multi project environment is complicated
  • TLRC and Lobster is a light weight tool with qualification which will be open sourced
  • But it does not have the infrastructure around it like sphinx needs has
• In Mercedes sphinx needs is qualified but to get into production could take a lot of effort
• TLRC is only requirements and Lobster for traceability but for everything we need sphinx to build a documentation
• TLRC and lobster does not support folder structure
• Isolated traceability report can be done in Sphinx which will match the speed of Lobster
• Rust tooling is due to big projects with 1000s of pages of requirements
• Currently with documentation and traceability build it takes 10 sec in sphinx needs
• Sphinx needs can qualify only the traceability build part if required but they are trying to make a complete solution
• The effort to split the documentation and traceability is going to be few days
• The risk would be for a distributor that if we have to go for another OEM then going with TLRC/Lobster will become an issue for long term support. Use blocks are dedicated company for giving long term support so we could avoid this risk
• Traceability for plant uml files is currently not available in Sphinx but its feasible to be done

Trunk based development

• We probably will not be able to go for a mono repo option
• Reusing a library will be difficult in the case of mono repo
• An advantage would be to have freedom of for processes in individual repos. Then have a integration gate for tests to get into one reference integrated repo
• CI/CD pipeline green time will be better with split repos
• If we want to qualify the tools then we need to have a unified approach that comes with a mono repo
• We let things go as it is and go in the direction of a monolithic repo but keep the repos distributed for now and use integration gate for reference integration

Planning

• We have Integration Increment which would function as a rolling release
• We would also have one major release after X number of Integration Increment
• The 'Why' and 'what' should be evident in the top level entity in Github
• Then the Break down tickets should explain the 'how' and 'when'
• Planning should be done on the main repo
• Potential DCO to be signed by new joiners
• We should use templates for issue types
• We need to develop a workflow for how we will use our planning strategy
• Proposal of labeling strategy:
  • one label per feature
  • one label per community
  • We use issue type for issues
  • one label per project lead
  • one label per technical lead

Workflow to initiate work planning

• Call for contribution would start the process which we would have an issue template for the potential contributors would fill out
• The contributors would pitch the feature request to the architecture community
• Then the PL/TL will be responsible to make the decision.
• This decision will be done via voting
• Which ever pitch gets selected for the feature they also become the maintainer/Feature owner
• We will then define a selection criteria against which the architecture community will assess the feature pitches
• Then the recommendations will be discussed in the Tech lead circle where the decision would be made for which feature gets selected.
• The call for contribution could be:
  • a PoC
  • full fledged code base
  • or partially developed feature that needs further development
  • Or an open sourced project that some one is ready to integrate into S-core

Action Items

• We will take the decision on the Tech lead circle for Sphinx needs vs Lobster/TLRC next Monday via voting
• To add the planning process in a pull request and get it reviewed in a meeting
• To check if a bot can prevent creating of new tickets with out links
• To check automation for labelling strategy
• To create issue templates for issue types and come up with their names
• To figure out how the maintainer/Feature owner would also agree to maintain the quality of code for the feature
• Define the selection criteria of Features from the pitches
• Update the code owner process under the organization section of the process @FScholPer

[opajonk]

"CI/CD pipeline green time will be better with split repos" --> maybe that was a misunderstanding? I think both are uncorrelated if you build things to the same level of integration. Otherwise, you are comparing apples and oranges.