OS tier levels + AutoSD as a community OS #2266

odra · 2025-12-01T12:35:23Z

Changes

adds a new Software Platform section to the OS Module
Includes AutoSD as a community platform to onboard the OS into S-CORE
Adds OS onboarding documents, including a template to be used as a starting point
Adds three folders regarding OS tier/levels: community, functional and certifiable

github-actions · 2025-12-01T12:35:34Z

⚠️ Docs-as-Code version mismatch detected
Please check the CI build logs for details and align the documentation version with the Bazel dependency.

github-actions · 2025-12-01T13:16:08Z

The created documentation from the pull request is available at: docu-html

opajonk

I checked the non-AutoSD-specific parts and I think this is a good starting point for adding OSs.

FScholPer · 2026-01-08T09:12:36Z

@odra whats the state with that pr?

odra · 2026-01-08T09:13:43Z

It's waiting for a review from the Arch. WG.

qor-lb

The PR is a good step towards making “supported OSs / software platforms” discoverable and positioning Red Hat AutoSD as the first documented target platform. The new entry point under the OS module is useful and the AutoSD page already contains actionable technical information (build/run/tooling pointers), which aligns well with the intention that users find practical integration guidance in one place.

That said, to fully achieve the goal that users can quickly answer:

What platforms are supported and at which level?
How are the levels defined?
How do I onboard / promote a new platform?

some restructuring and additional content would make the result significantly clearer and easier to maintain long-term imho.

docs/modules/os/sw_platforms/docs/index.rst

docs/modules/os/operating_systems/docs/index.rst

docs/modules/os/operating_systems/docs/community/autosd.rst

docs/modules/os/operating_systems/docs/index.rst

qor-lb · 2026-01-26T13:04:09Z

we should also update the codeowner file to reflect the necessary approvals for the different levels

qor-lb · 2026-01-26T13:37:15Z

resolves #1691 and #1740

aschemmel-tech

see inline comments

aschemmel-tech · 2026-01-27T12:30:00Z

docs/modules/os/sw_platforms/docs/community/index.rst

+   # SPDX-License-Identifier: Apache-2.0
+   # *******************************************************************************
+
+.. _comp_doc_os_sw_platforms_community:


Please rename this and the other occurrences to something different from "SW platform" because this is the name we use for the S-CORE SW platform - see discussion in #1740. I would rather call it plainly OS or Operating System. If you want to differentiate between different implementations maybe call it variant?

I just kept it as "os", so the name structure is "comp_doc_os_$level_$osname" (_comp_doc_os__community__autosd)

aschemmel-tech · 2026-01-27T12:33:14Z

docs/modules/os/sw_platforms/docs/community/index.rst

+Community
+#########
+
+These are the community-supported Software Platforms for Eclipse S-CORE.


Better: "These are the Operating Systems supported on a "community" level for Eclipse S-CORE."

aschemmel-tech · 2026-01-27T12:34:25Z

docs/modules/os/sw_platforms/docs/community/index.rst

+#########
+
+These are the community-supported Software Platforms for Eclipse S-CORE.
+See see :ref:`platform_assumptions` for the exact requirements for each Tier.


Better: "for the exact requirements for each level (Tier)" as we do not use the term Tier in the assumptions.

aschemmel-tech · 2026-01-27T12:36:47Z

docs/modules/os/sw_platforms/docs/index.rst

+
+.. _comp_doc_os_sw_platforms:
+
+Software Platforms


Also here please "Operating System" as a Component name. Or maybe "Operating System Platform" or "Operating System Environment" as proposed below in the text anyway.

I replace the term by "Operating System"

aschemmel-tech · 2026-01-27T12:45:52Z

docs/modules/os/sw_platforms/docs/community/index.rst

+
+.. _comp_doc_os_sw_platforms_community:
+
+Community


Please call this "Community Level"

aschemmel-tech · 2026-01-27T13:32:07Z

docs/modules/os/sw_platforms/docs/community/autosd.rst

+Integration Assistance
+~~~~~~~~~~~~~~~~~~~~~~
+
+.. aou_req:: integration assistance


Please do not duplicate the AoU documented in the "SW-platform Assumptions" section of S-CORE. What you want is to document the "fulfillment" of these "Non-Functional" AoU with a instruction/guideline how to use "Red Hat AutoSD". So please refer here to the AoU by stating for example "The following fulfills :need:aou_req__platform__integration_assistance ". Better would be to describe the instruction/guideline as a sphinx needs element like @qor-lb proposed (but not with the id "platform__...") with an attribute that links to the AoU. But this is maybe a seperate PR because it would need considering the best way to change the metamodel and modelling by docs-as-code team.

aschemmel-tech · 2026-01-27T13:32:35Z

docs/modules/os/sw_platforms/docs/community/autosd.rst

+Integration Manual
+~~~~~~~~~~~~~~~~~~
+
+.. aou_req:: integration manual


aschemmel-tech · 2026-01-27T13:32:58Z

docs/modules/os/sw_platforms/docs/community/autosd.rst

+Bug Interface
+~~~~~~~~~~~~~
+
+.. aou_req:: bug interface


odra · 2026-01-29T11:26:01Z

@qor-lb @aschemmel-tech I've updated my PR with the requested changes, could you please review it again?

opajonk

Details only

docs/modules/os/operating_systems/docs/onboarding/index.rst

docs/modules/os/operating_systems/docs/community/autosd.rst

docs/modules/os/operating_systems/docs/onboarding/index.rst

docs/modules/os/operating_systems/docs/onboarding/os_onboard_template.rst

masc2023 · 2026-01-30T15:18:38Z

docs/modules/os/operating_systems/docs/onboarding/os_onboard_template.rst

+OS Name
+=======
+
+.. os: <os_name>


Our metamodel does not define that need, you should follow that, and OS is more or less a component, so use please .. comp: as defined here https://github.com/eclipse-score/docs-as-code/blob/main/src/extensions/score_metamodel/metamodel.yaml (row 553), example https://eclipse-score.github.io/score/main/modules/communication/ipc_binding/docs/architecture/index.html#comp__com_ipc_binding

if the intention here is only to have an description, then please use document (raw 202)

this as the original proposed by @qor-lb:

.. platform:: <platform name> :id: platform__<platform name snake case> :level: <community/functinal/certifiable> :maintainer: <GitHub Handles>

I assumed it was comment metadata (at least for now) since there's no "platform::" directive (I got a compilation error when using it)

Also not part of metadata, as proposed, your content is mainly a document, so use ..document, the need ..platform is not intended to be implemented, as also discussed with @aschemmel-tech, S-CORE itself is defined as SW-Platform

I've changed it to use "comp_arc_sta" instead.

FScholPer

Looks good to me

masc2023 · 2026-02-03T10:22:59Z

docs/modules/os/operating_systems/docs/onboarding/os_onboard_template.rst

+OS Name
+=======
+
+.. comp_arc_sta:: os_name


Your PR has an very old version of doc-as-code, that's why you may not able to use comp, because does not exists yet, please update at least do bazel_dep(name = "score_docs_as_code", version = "2.3.3") or higerh and try again with comp

rebased and updated.

I've set the comp id as "comp__os_$osname".

RolandJentschETAS · 2026-02-03T11:11:09Z

docs/modules/os/operating_systems/docs/community/autosd.rst

+   # SPDX-License-Identifier: Apache-2.0
+   # *******************************************************************************
+
+.. comp:: Red Hat AutoSD


Please add the comp to the os module ... (see modules/os/docs/index)

RolandJentschETAS · 2026-02-03T11:13:15Z

docs/modules/os/operating_systems/docs/onboarding/os_onboard_template.rst

+=======
+
+.. comp:: os_name
+   :id: comp__os_osname


See above. Please add to the os module.

This is one is just a template for onboarding a new OS, does it need to be added to the module list?

No its fine then. I hope there is no issue with it. At least a free running component. Not sure if this make some trouble in the sphinx needs linking. If this is only an template (placeholder) and not a real component, then maybe it is better to not define an sphinx needs element.

Again, if it is a template, use the document need and add the comp need as note, as we do it also here https://eclipse-score.github.io/process_description//main/folder_templates/features/feature_name/architecture/index.html for example

It looks like I cannot use :implements: in with comps anymore, and using logic_arc_int does not work as well since it requires a feat_req.

Should the meta model file be updated with a proper platform/os type?

RolandJentschETAS · 2026-02-03T11:43:41Z

docs/modules/os/operating_systems/docs/community/autosd.rst

+Mixed Critical Orchestration
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Upstream documentation: https://sigs.centos.org/automotive/features-and-concepts/con_mixed-criticality/


Please use rst links

masc2023

Fine for now.

opajonk

Read it once more completely. Nice job! Understandable, and clear what needs to be done for an OS.

I found only one actual typo and a few details.

docs/modules/os/operating_systems/docs/onboarding/index.rst

docs/modules/os/operating_systems/docs/index.rst

Co-authored-by: Oliver Pajonk <oliver@pjnk.de> Signed-off-by: Leonardo Rossetti <oss@lrossetti.com>

opajonk

odra · 2026-02-06T07:27:27Z

@masc2023 it needs a new approval due to some spelling errors

RolandJentschETAS · 2026-02-06T07:58:11Z

docs/modules/os/operating_systems/docs/community/autosd.rst

+.. comp:: AutoSD
+   :id: comp__os_autosd
+   :security: YES
+   :safety: QM


Looks from module cope now strange. QM inside ASIL module.

But it is correct and as intended, as AutoSD applies not for Certifiable level

My understanding of this would be: "If you integrate S-CORE on AutoSD, at the moment all you can expect is a QM system".

Disclaimer: same would be true for EB corbos Linux for Safety Application right now, until we successfully qualify for the highest integration level, as described in the PR. This is a step-by-step process, which is totally reasonable, and not how we start off.

This is understandable. Maybe we need an tag or something for this, within the the generated picture.

Or it is another module and dont fit into the OS.

As comment above, not a problem, it shows exactly the status and any safety engineer will easily see, that AutoSD can not used currently in safety-critical context

But it is against our process requirements, so maybe we have an process issue. See gd_req__arch_linkage_safety_trace. The module OS is defined as ASIL_B and is an architectural element (see gd_req__arch_build_blocks). Therefore linking an QM element will be against this requirement.

Your rules does not consider yet https://eclipse-score.github.io/score/pr-2266/requirements/platform_assumptions/index.html#aou_req__platform__integration_assistance, where it is allowed to deviate, if you want only to deliver on Community Level, so that is SCORE specific tailoring of the general process

Not sure, what "The supplier shall provide a contact point for integration assistance." have to do with this. But it might be another AOU. But nevertheless it would mean, that our docs as code which will implement the enforcement of this rule by sphinx-needs tests have to be modified or deactivated within S-CORE project scope. Right ?

I talked with the docs_as_code colleagues. They will implement the checks (leads to built errors) and there is currently no possibility implemented and anyhow foreseen to overrule that from the project. They follow currently only the process requirements.

qor-lb

@odra I added some minor consistency hints for renaming Platform to OS accordingly and the addition of the newly formed release team which is required from Functional level onwards to approve. Besides this the overall change looks good to me and we can continue with merging after this has been resolved.

docs/modules/os/operating_systems/docs/index.rst

docs/modules/os/operating_systems/docs/onboarding/index.rst

qor-lb · 2026-02-09T07:45:44Z

docs/modules/os/operating_systems/docs/onboarding/index.rst

+1. **Eligibility (Platform Maintainer)**:
+   The platform maintainer resolves the **supplier** requirements of the target level.
+   Only if these requirements are fulfilled, the OS can be considered for promotion.
+
+2. **Acceptance + Lifecycle Guarantees (S-CORE)**:
+   S-CORE reviews the promotion request.
+   If accepted at **Functional** or **Certifiable**, S-CORE commits to maintain the
+   guarantees of the accepted level across all increments.


Consistency: Platform -> OS

Suggested change

1. **Eligibility (Platform Maintainer)**:

The platform maintainer resolves the **supplier** requirements of the target level.

Only if these requirements are fulfilled, the OS can be considered for promotion.

2. **Acceptance + Lifecycle Guarantees (S-CORE)**:

S-CORE reviews the promotion request.

If accepted at **Functional** or **Certifiable**, S-CORE commits to maintain the

guarantees of the accepted level across all increments.

1. **Eligibility (OS Maintainer)**:

The OS maintainer resolves the **supplier** requirements of the target level.

Only if these requirements are fulfilled, the OS can be considered for promotion.

2. **Acceptance + Lifecycle Guarantees (S-CORE)**:

S-CORE reviews the promotion request.

If accepted at **Functional** or **Certifiable**, S-CORE commits to maintain the

guarantees of the accepted level across all increments.

qor-lb · 2026-02-09T07:46:29Z

docs/modules/os/operating_systems/docs/onboarding/index.rst

+**Eligibility requirements (Platform Maintainer / supplier requirements)**
+  The OS maintainer must fulfill the Community level supplier requirements as defined in:
+  :ref:`platform_assumptions`.
+
+**Review and acceptance (S-CORE)**
+  S-CORE reviews the documentation entry for completeness and consistency.
+  Acceptance only means the platform is listed in-tree.
+  No infrastructure or lifecycle support is implied.


Consistency

Suggested change

**Eligibility requirements (Platform Maintainer / supplier requirements)**

The OS maintainer must fulfill the Community level supplier requirements as defined in:

:ref:`platform_assumptions`.

**Review and acceptance (S-CORE)**

S-CORE reviews the documentation entry for completeness and consistency.

Acceptance only means the platform is listed in-tree.

No infrastructure or lifecycle support is implied.

**Eligibility requirements (OS Maintainer / supplier requirements)**

The OS maintainer must fulfill the Community level supplier requirements as defined in:

:ref:`platform_assumptions`.

**Review and acceptance (S-CORE)**

S-CORE reviews the documentation entry for completeness and consistency.

Acceptance only means the OS is listed in-tree.

No infrastructure or lifecycle support is implied.

qor-lb · 2026-02-09T07:50:37Z

docs/modules/os/operating_systems/docs/onboarding/index.rst

+**Eligibility requirements (Platform Maintainer / supplier requirements)**
+  The platform maintainer must fulfil the Functional level supplier requirements as defined in:
+  :ref:`platform_assumptions`.
+
+**Additional acceptance requirements (S-CORE / system integrator requirements)**
+  From Functional level onwards, S-CORE must be able to continuously validate the platform.
+  This requires infrastructure and test integration.
+
+**Required approvals**
+  Promotion to Functional requires explicit approval by:
+
+  * Platform maintainers
+  * Architecture WG
+  * Infrastructure WG (CI / build & test environment support)
+  * Testing WG
+  * Quality Management


Consitency + We need review from the release team as they need need to maintain this guarantee in following releases

Suggested change

**Eligibility requirements (Platform Maintainer / supplier requirements)**

The platform maintainer must fulfil the Functional level supplier requirements as defined in:

:ref:`platform_assumptions`.

**Additional acceptance requirements (S-CORE / system integrator requirements)**

From Functional level onwards, S-CORE must be able to continuously validate the platform.

This requires infrastructure and test integration.

**Required approvals**

Promotion to Functional requires explicit approval by:

* Platform maintainers

* Architecture WG

* Infrastructure WG (CI / build & test environment support)

* Testing WG

* Quality Management

**Eligibility requirements (OS Maintainer / supplier requirements)**

The OS maintainer must fulfill the Functional level supplier requirements as defined in:

:ref:`platform_assumptions`.

**Additional acceptance requirements (S-CORE / system integrator requirements)**

From Functional level onwards, S-CORE must be able to continuously validate the OS integration.

This requires infrastructure, test and release integration.

**Required approvals**

Promotion to Functional requires explicit approval by:

* OS maintainers

* Architecture WG

* Infrastructure WG (CI / build & test environment support)

* Testing WG

* Release Team

* Quality Management

qor-lb · 2026-02-09T07:56:25Z

docs/modules/os/operating_systems/docs/onboarding/os_onboard_template.rst

+- Summarise how to obtain and use the integration manual for this platform.
+- Link to external documentation if it exists.


consistency

Suggested change

- Summarise how to obtain and use the integration manual for this platform.

- Link to external documentation if it exists.

- Summarise how to obtain and use the integration manual for this OS.

- Link to external documentation if it exists.

qor-lb · 2026-02-09T07:56:51Z

docs/modules/os/operating_systems/docs/onboarding/os_onboard_template.rst

+Build Instructions
+------------------
+
+Explain how to build an image of this platform and how to build Eclipse S-CORE for it.


Consistency

Suggested change

Explain how to build an image of this platform and how to build Eclipse S-CORE for it.

Explain how to build an image of this OS and how to build Eclipse S-CORE for it.

docs/modules/os/operating_systems/docs/onboarding/os_onboard_template.rst

docs/modules/os/operating_systems/docs/community/autosd.rst

qor-lb · 2026-02-09T08:05:21Z

docs/modules/os/operating_systems/docs/index.rst

Please update the codeowners file to include the TLs as intermediate reviewers until all the different representatives from the communities that need to approve have been defined:

https://github.com/eclipse-score/score/blob/main/.github/CODEOWNERS#L34C1-L34C81

# TLs are intermediate until representatives have been finalized /docs/modules/os/operating_systems @antonkri @FScholPer @qor-lb @johannes-esr

qor-lb · 2026-02-09T08:15:23Z

@pawelrutkaq / @FScholPer can you please also review this in the context of the newly formed release team?

@PiotrKorkus , @AlexanderLanin can you please take a look at this from testing/infra perspective?

qor-lb · 2026-02-09T08:22:00Z

@odra on second sight, I think we have missed the definition of the target archtiecture. Could you make a proposal where we can define the target triplets for this in AutoSD and a place in the template? This would be important for the release team as they need to maintain the exact target triplets and I think this is also the required integration point for the toolchains.

masc2023 · 2026-02-09T08:24:51Z

@pawelrutkaq / @FScholPer can you please also review this in the context of the newly formed release team?

@PiotrKorkus , @AlexanderLanin can you please take a look at this from testing/infra perspective?

Please keep in mind, changing teams, roles needs to be reflected also in the process, please create issues, if there something needs to be changed see
https://eclipse-score.github.io/process_description//main/process_areas/release_management/release_workflow.html
https://eclipse-score.github.io/process_description//main/process_areas/quality_management/quality_workflow.html#wf__vy_ap_pltrelease

Co-authored-by: Lars Bauhofer <lars.bauhofer@qorix.ai> Signed-off-by: Frank Scholter Peres(MBTI) <145544737+FScholPer@users.noreply.github.com>

FScholPer · 2026-02-09T09:00:52Z

@odra looks good to me. Can you please add the suggestions from @qor-lb

Co-authored-by: Lars Bauhofer <lars.bauhofer@qorix.ai> Signed-off-by: Leonardo Rossetti <oss@lrossetti.com>

Signed-off-by: Leonardo Rossetti <lrossett@redhat.com>

odra · 2026-02-09T22:13:45Z

@qor-lb I added an "architecture table" to both files, I am not sure if this is the best format. It sounds like it should be a platform requirement card, eventually.

Also, I think we need to discuss how to describe toolchains within the project as well, the same way we are doing with operating systems.

odra requested a review from a team as a code owner December 1, 2025 12:35

odra force-pushed the fix-2264_autosd-onboard branch 2 times, most recently from 2cb329f to 24804bd Compare December 1, 2025 13:16

odra force-pushed the fix-2264_autosd-onboard branch 3 times, most recently from 629cafa to eb1535e Compare December 8, 2025 12:52

opajonk approved these changes Dec 10, 2025

View reviewed changes

anmittag assigned odra Dec 17, 2025

odra mentioned this pull request Jan 23, 2026

Add support for AutoSD upstream GCC version eclipse-score/bazel_cpp_toolchains#7

Open

odra changed the title ~~[WIP] adding autosd~~ adding autosd Jan 23, 2026

qor-lb requested changes Jan 26, 2026

View reviewed changes

aschemmel-tech requested changes Jan 27, 2026

View reviewed changes

odra changed the title ~~adding autosd~~ OS tier levels + AutoSD as a community OS Jan 29, 2026

opajonk reviewed Jan 30, 2026

View reviewed changes

masc2023 requested changes Jan 30, 2026

View reviewed changes

opajonk approved these changes Feb 3, 2026

View reviewed changes

FScholPer previously approved these changes Feb 3, 2026

View reviewed changes

masc2023 reviewed Feb 3, 2026

View reviewed changes

odra dismissed FScholPer’s stale review via 57c7757 February 3, 2026 10:52

odra force-pushed the fix-2264_autosd-onboard branch from 5b569e8 to 57c7757 Compare February 3, 2026 10:52

RolandJentschETAS reviewed Feb 3, 2026

View reviewed changes

masc2023 previously approved these changes Feb 6, 2026

View reviewed changes

opajonk suggested changes Feb 6, 2026

View reviewed changes

Update docs/modules/os/operating_systems/docs/onboarding/index.rst

8eb58cd

Co-authored-by: Oliver Pajonk <oliver@pjnk.de> Signed-off-by: Leonardo Rossetti <oss@lrossetti.com>

odra dismissed masc2023’s stale review via 8eb58cd February 6, 2026 07:12

odra and others added 3 commits February 6, 2026 04:12

Update docs/modules/os/operating_systems/docs/index.rst

c18c43d

Co-authored-by: Oliver Pajonk <oliver@pjnk.de> Signed-off-by: Leonardo Rossetti <oss@lrossetti.com>

Update docs/modules/os/operating_systems/docs/onboarding/index.rst

9013e3e

Co-authored-by: Oliver Pajonk <oliver@pjnk.de> Signed-off-by: Leonardo Rossetti <oss@lrossetti.com>

Update docs/modules/os/operating_systems/docs/onboarding/index.rst

bbf1304

Co-authored-by: Oliver Pajonk <oliver@pjnk.de> Signed-off-by: Leonardo Rossetti <oss@lrossetti.com>

opajonk approved these changes Feb 6, 2026

View reviewed changes

masc2023 previously approved these changes Feb 6, 2026

View reviewed changes

odra requested review from aschemmel-tech and qor-lb February 6, 2026 07:40

RolandJentschETAS reviewed Feb 6, 2026

View reviewed changes

qor-lb requested changes Feb 9, 2026

View reviewed changes

Apply suggestion from @qor-lb

39cd0f7

Co-authored-by: Lars Bauhofer <lars.bauhofer@qorix.ai> Signed-off-by: Frank Scholter Peres(MBTI) <145544737+FScholPer@users.noreply.github.com>

FScholPer dismissed masc2023’s stale review via 39cd0f7 February 9, 2026 08:41

Update docs/modules/os/operating_systems/docs/index.rst

3268632

Co-authored-by: Lars Bauhofer <lars.bauhofer@qorix.ai> Signed-off-by: Leonardo Rossetti <oss@lrossetti.com>

odra requested review from antonkri and johannes-esr as code owners February 9, 2026 21:14

odra force-pushed the fix-2264_autosd-onboard branch from 4ea76a0 to eada8ee Compare February 9, 2026 21:31

odra and others added 3 commits February 9, 2026 18:38

Update os/onboarding/os_onboard_template.rst

179b2ec

Co-authored-by: Lars Bauhofer <lars.bauhofer@qorix.ai> Signed-off-by: Leonardo Rossetti <oss@lrossetti.com>

Update os/operating_systems/docs/community/autosd.rst

6c99582

Co-authored-by: Lars Bauhofer <lars.bauhofer@qorix.ai> Signed-off-by: Leonardo Rossetti <oss@lrossetti.com>

set temporary codeowners for modules/os

7c59a7d

Signed-off-by: Leonardo Rossetti <lrossett@redhat.com>

odra force-pushed the fix-2264_autosd-onboard branch from eada8ee to 7c59a7d Compare February 9, 2026 21:39

arch. table

5795dd9

Signed-off-by: Leonardo Rossetti <lrossett@redhat.com>

		- Summarise how to obtain and use the integration manual for this platform.
		- Link to external documentation if it exists.

	Explain how to build an image of this platform and how to build Eclipse S-CORE for it.
	Explain how to build an image of this OS and how to build Eclipse S-CORE for it.

OS tier levels + AutoSD as a community OS #2266

Are you sure you want to change the base?

OS tier levels + AutoSD as a community OS #2266

Conversation

odra commented Dec 1, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Changes

Uh oh!

github-actions bot commented Dec 1, 2025

Uh oh!

github-actions bot commented Dec 1, 2025

Uh oh!

opajonk left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

FScholPer commented Jan 8, 2026

Uh oh!

odra commented Jan 8, 2026

Uh oh!

qor-lb left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

qor-lb commented Jan 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

qor-lb commented Jan 26, 2026

Uh oh!

aschemmel-tech left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

odra commented Jan 29, 2026

Uh oh!

opajonk left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

masc2023 Feb 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

FScholPer left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

odra Feb 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

odra commented Dec 1, 2025 •

edited

Loading

opajonk left a comment •

edited

Loading

qor-lb commented Jan 26, 2026 •

edited

Loading

masc2023 Feb 1, 2026 •

edited

Loading

odra Feb 3, 2026 •

edited

Loading

RolandJentschETAS Feb 3, 2026 •

edited

Loading

odra Feb 5, 2026 •

edited

Loading