Create yamllint.yml

.github/actions/gitlint/Dockerfile

@@ -0,0 +1 @@
+FROM jorisroovers/gitlint:0.19.1

.github/actions/gitlint/action.yml

@@ -23,15 +23,14 @@ inputs:
     required: false
 runs:
   using: "docker"
-  image: "jorisroovers/gitlint:0.19.1"
-  entrypoint: /bin/sh
+  image: "Dockerfile"
   args:
     - -c
     - |
       git config --global --add safe.directory /github/workspace && \
       git fetch origin +refs/heads/${{ inputs.base-branch }}:refs/remotes/origin/${{ inputs.base-branch }} && \
       git fetch origin +refs/pull/${{ inputs.pr-number }}/head && \
-      if ! gitlint --commits origin/${{ inputs.base-branch }}..HEAD; then \
+      if ! gitlint --commits origin/${{ inputs.base-branch }}..HEAD --target=/github/workspace; then \
         echo -e "\nWARNING: Your commit message does not follow the required format." && \
         echo "Formatting rules: https://eclipse-score.github.io/score/main/contribute/general/git.html" && \
         echo -e "To fix your commit message, run:\n" && \

.github/workflows/docs-cleanup.yml

@@ -67,7 +67,9 @@ jobs:
           done
 
           # Remove versions.json entries without corresponding folders
-          jq '[.[] | select((.version | IN($folders[])))]' --argjson folders "$(ls -1 | jq -R -s -c 'split("\n")[:-1]')" versions_tmp.json > versions_tmp_clean.json
+          jq '[.[] | select((.version | IN($folders[])))]' \
+            --argjson folders "$(find . -maxdepth 1 -mindepth 1 -type d -not -name '.*' -exec basename {} \; | jq -R -s -c 'split("\n")[:-1]')" \
+            versions_tmp.json > versions_tmp_clean.json
 
           # Ensure "main" is the first entry and others sorted alphabetically
           jq '[.[] | select(.version != "main")] | sort_by(.version) | [{"version": "main", "url": "https://eclipse-score.github.io/score/main/"}] + .' versions_tmp_clean.json > versions.json

.github/workflows/gitlint.yml

@@ -21,7 +21,7 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - name: Checkout code
-        uses: actions/checkout@v3
+        uses: actions/checkout@v4
         with:
           fetch-depth: 0
       - name: Run Gitlint Action

.github/workflows/lint_actions.yml

@@ -0,0 +1,28 @@
+# *******************************************************************************
+# Copyright (c) 2024 Contributors to the Eclipse Foundation
+#
+# See the NOTICE file(s) distributed with this work for additional
+# information regarding copyright ownership.
+#
+# This program and the accompanying materials are made available under the
+# terms of the Apache License Version 2.0 which is available at
+# https://www.apache.org/licenses/LICENSE-2.0
+#
+# SPDX-License-Identifier: Apache-2.0
+# *******************************************************************************
+
+name: YAML checks
+on:
+  pull_request:
+    types: [opened, synchronize, reopened]
+
+jobs:
+  lint:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+
+      - name: Check github actions
+        uses: docker://rhysd/actionlint:latest
+        with:
+          args: -color

docs/contribute/contribution_request/index.rst

@@ -78,7 +78,7 @@ Join Us in Building S-CORE
   Submit a contribution pitch for a specific feature request if you have a solution you'd like to share.
 
 - **Looking to Improve What's Already There?**
-  Contribute enhancements to existing implementations or get involved with one of our cross-functional teams (CFTs).
+  Contribute enhancements to existing implementations or get involved with one of our Feature Teams (FTs).
 
 We're excited to have you on board. Together, we can shape S-CORE into a platform that's not only innovative but also a joy to be a part of.
 

docs/contribute/index.rst

@@ -49,7 +49,7 @@ How is S-CORE organized
 
 Eclipse S-CORE is an open source project, so everyone is welcome to contribute. Since we are organized within the Eclipse Foundation, you must have an Eclipse Foundation account to participate - please see :ref:`contribution_attribution` for details.
 
-The project is structured into various :ref:`technical committees <pmp_pm_technical_committees>`, which include communities focused on specific domains and cross-functional teams responsible for defined work areas. Their meetings are public; feel free to join or review the minutes via our `GitHub Discussions <https://github.com/orgs/eclipse-score/discussions>`_.
+The project is structured into various :ref:`technical committees <pmp_pm_technical_committees>`, that include communities which focus on cross-cutting topics and feature teams responsible for the implementation of specific functionalities. Their meetings are public; feel free to join or review the minutes via our `GitHub Discussions <https://github.com/orgs/eclipse-score/discussions>`_.
 
 Additionally, two :ref:`steering committees <pmp_pm_steering_committees>`, the Technical Lead Circle and the Project Lead Circle, oversee the overall steering and planning of S-CORE.
 

docs/features/frameworks/feo/index.rst

@@ -184,8 +184,8 @@ Queuing of topics:
 * Queue enable and queue length are "runtime static" configuration settings
 
 
-Process/Thread Mapping 
-======================
+Process/Thread/Activity Mapping
+===============================
 
 * An application consists of one or more processes
 * One of the processes is the primary process
@@ -208,6 +208,50 @@ Process/Thread Mapping
   achieve Freedom From Interference for safety relevant applications
 
 
+Static mapping of activities to threads
+'''''''''''''''''''''''''''''''''''''''
+
+As pointed out above, FEO activities are required to be mapped to threads in a static way.
+The rationale behind this requirement is:
+
+* Calling activity functions init(), step() and shutdown() from a single pre-defined thread
+  allows implementations to make use of thread-local optimizations such as thread-local variables.
+* Calling an activity's step() function from different threads in different iterations of the
+  task chain may cause execution time jitter e.g. from unpredictable cache misses or different
+  properties of the processor cores the respective threads may be assigned to.
+* Most importantly, a dynamic assignment of activities to threads may result in non-deterministic
+  variations of the task-chain execution time.
+
+To understand how a dynamic thread assignment can cause execution time variations, consider
+the following example (sub-) task chain.
+
+|example_task_chain|
+
+Here, activity 6 depends on, i.e. must be executed after activities 1 to 5. The length of the bars
+is intended to indicate the relative computation time needed by the respective activity on a
+single processor core. It is assumed that all of these activities will be executed in the same process.
+
+In a simple approach, each of the activities 1 to 5 could be assigned to its own thread and
+activity 6 could be executed subsequently in one of these threads as shown in the figure below.
+Each blue "lane" indicates one thread.
+
+|example_task_chain_5_threads|
+
+If each thread runs on a separate core and execution is not interrupted by other tasks, the length of
+the blue box is related to the total execution time of the task chain.
+
+Approximately the same total execution time can be achieved with only 3 threads (on three cores), if the
+tasks are assigned in an optimized way:
+
+|example_task_chain_3_threads_optimized|
+
+If, on the other hand,  activities are assigned to the same 3 threads in a dynamic way, the execution
+time may vary unpredictably, because of the possibly varying execution sequence of activities,
+as can be seen below.
+
+|example_task_chain_3_threads_dynamic|
+
+
 Lifecycle
 =========
 
@@ -383,3 +427,11 @@ timing of activities, supporting safety-critical applications
 in the automotive domain. In this domain the footprint of the framework is curcial especially
 w.r.t impact of computation load and latency.
 
+
+.. |example_task_chain| image:: _assets/example_task_chain.png
+
+.. |example_task_chain_5_threads| image:: _assets/example_task_chain_5_threads.png
+
+.. |example_task_chain_3_threads_optimized| image:: _assets/example_task_chain_3_threads_optimized.png
+
+.. |example_task_chain_3_threads_dynamic| image:: _assets/example_task_chain_3_threads_dynamic.png

docs/platform_management_plan/problem_resolution.rst

@@ -120,7 +120,7 @@ ISSUE using the Problem Template :ref:`prm_templates`.
 
 :need:`[[title]] <gd_req__problem__attr_stakeholder>` is defined in the description part of the
 ISSUE using the Problem Template :ref:`prm_templates`. For S-CORE stakeholder use pre-defined labels
-for Communities or Cross Functional Teams (Feature Owner) (under discussion, compare
+for Communities or Feature Teams (Feature Owner) (under discussion, compare
 https://github.com/eclipse-score/score/issues/870)
 
 :need:`[[title]] <gd_req__problem__attr_classification>` is defined in the description part of the

docs/platform_management_plan/project_management.rst

@@ -84,17 +84,15 @@ Technical committees
   in order to achieve milestones on time. All important architectural decisions
   should be reported to the project as *Feature Request* to get the final approvement from the *Technical lead circle*.
 
-* **Cross functional teams**
+* **Feature Teams**
 
-  *Cross functional teams* are responsible for some piece
-  of work from the beginning (e.g. definition of the architecture) till the end
-  (e.g. integration tests) and are usually assigned to the *S-CORE* main integration project or to one particular software module. *Cross-functional teams* work independently from each other on *GitHub Issues* in the assigned software module. *Cross-functional teams* consist of the contributors, who can specify requirements, define architecture, develop source code and implement tests afterwards. *Project Leads* and *Committers* are also *Contributors* and effectively work on processing of *GitHub Issues*.
+  *Feature Teams* have end-to-end responsibility for specific functionalities. This includes all aspects beginning with the architecture definition to the integration test. They are usually assigned to the *S-CORE* main integration project or to one particular software module. *Feature Teams* work independently of each other on *GitHub Issues* in the assigned software module. *Feature Teams* consist of the contributors, who can specify requirements, define architecture, develop source code and implement tests afterwards. *Project Leads* and *Committers* are also *Contributors* and effectively work on processing of *GitHub Issues*.
 
-  *Cross-functional team* usually consists of the following roles: Project Lead, Safety Manager, Quality Manager, Security Manager, Committers and Contributors. Every *cross-functional* team has at least one committer who can approve and merge the Pull Requests of the Contributors.
+  *Feature Team* usually consists of the following roles: Project Lead, Safety Manager, Quality Manager, Security Manager, Committers and Contributors. Every *Feature Team* has at least one committer who can approve and merge the Pull Requests of the Contributors.
 
-  In case *Cross-functional team* needs to request a new repository, this can be done be extending the `otterdog configuration file <https://github.com/eclipse-score/.eclipsefdn/blob/main/otterdog/eclipse-score.jsonnet>`_ and creating a new PR, that should be approved by the *Eclipse Project Security Team*.
+  In case a *Feature Team* needs to request a new repository, this can be done be extending the `otterdog configuration file <https://github.com/eclipse-score/.eclipsefdn/blob/main/otterdog/eclipse-score.jsonnet>`_ and creating a new PR, that has to be approved by the *Eclipse Project Security Team*.
 
-  The *GitHub Discussions* for cross-functional teams can be found in the `Cross-functional teams section <https://github.com/orgs/eclipse-score/discussions>`_ of the main *S-CORE* project.
+  The *GitHub Discussions* for feature teams can be found in the `Feature Teams section <https://github.com/orgs/eclipse-score/discussions>`_ of the main *S-CORE* project.
 
 Meeting Structure
 -----------------
@@ -364,7 +362,7 @@ and gets assigned to one of the *Communities* for refinement. The state of the s
     :alt: Planning workflow
     :align: center
 
-The members of the *Responsible Community* define or refine feature, process or tool requirements. They may also create feature architecture and high level component requirements for every involved software component. Depending on the feature scope, one of the cross-functional team can be requested to make a POC in the `incubation repository <https://eclipse-score.github.io/score/features/integration/index.html#incubation-repositories>`_. Finally, *Responsible Community* does the break down of the corresponding *saga* to the tickets that can be assigned to the individual software modules or *communities*.
+The members of the *Responsible Community* define or refine feature, process or tool requirements. They may also create feature architecture and high level component requirements for every involved software component. Depending on the feature scope, one of the feature team can be requested to make a POC in the `incubation repository <https://eclipse-score.github.io/score/features/integration/index.html#incubation-repositories>`_. Finally, *Responsible Community* does the break down of the corresponding *saga* to the tickets that can be assigned to the individual software modules or *communities*.
 As most of the software modules will have their own separate repository,
 then the detailed tracking of their work will also happen inside of that repository.
 However, the corresponding saga of the S-CORE repository will still have a sub-issue of type epic,

docs/process/process_areas/release_management/guidance/release_guideline.rst

@@ -38,7 +38,7 @@ Software Module Release
 
 3. **Development and Testing**:
 
-   * According process, cross functional teams implement and test.
+   * According process, feature teams implement and test.
    * Check the :need:`wp__verification__module_ver_report` to ensure that all tests pass before proceeding to the release.
    * In case of failed test, evaluate and possibly justify their failure.
 

docs/process/roles/index.rst

@@ -119,7 +119,7 @@ S-CORE development roles
    units. In this way the testing community takes a supportive role for unit testing
 
 
-S-CORE cross functional teams
+S-CORE feature teams
 -----------------------------
 
 .. role:: Platform Team

docs/score_releases/index.rst

@@ -53,28 +53,28 @@ SW Module List
      - Q4
      - _
      - `inc_mw_com <https://github.com/eclipse-score/inc_mw_com>`_
-     - `Communication CTF <https://github.com/orgs/eclipse-score/discussions/categories/communication-cft>`_
+     - `Communication CTF <https://github.com/orgs/eclipse-score/discussions/categories/communication-ft>`_
    * - Fixed Execution Order Framework (incl. Orchestrator)
      - Holger Grandy, Gerd Schäfer, Nico Hartmann, Sven Kappel, Thilo Schmitt
      - v0.5
      - Q4
      - _
      - `inc_feo <https://github.com/eclipse-score/inc_feo>`_
-     - `FEO CTF <https://github.com/orgs/eclipse-score/discussions/categories/feo-cft>`_
+     - `FEO CTF <https://github.com/orgs/eclipse-score/discussions/categories/feo-ft>`_
    * - Logging
      - Holger Grandy, Gerd Schäfer, Nico Hartmann
      - v0.5
      - Q4
      - _
      - `inc_mw_log <https://github.com/eclipse-score/inc_mw_log>`_
-     - `Logging CTF <https://github.com/orgs/eclipse-score/discussions/categories/logging-cft>`_
+     - `Logging CTF <https://github.com/orgs/eclipse-score/discussions/categories/logging-ft>`_
    * - Persistency
      - Gerd Schäfer, Nico Hartmann, Sven Kappel
      - v0.5
      - Q4
      - _
      - `inc_mw_per <https://github.com/eclipse-score/inc_mw_per>`_
-     - `Persistency CTF <https://github.com/orgs/eclipse-score/discussions/categories/persistency-cft>`_
+     - `Persistency CTF <https://github.com/orgs/eclipse-score/discussions/categories/persistency-ft>`_
    * - Integration Testing Framework
      - Holger Grandy
      - v0.5