OS tier levels + AutoSD as a community OS by odra · Pull Request #2266 · eclipse-score/score

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

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

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

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

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

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

Please check documentation for final review

masc2023 · 2026-02-05T15:44:22Z

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

+   :implements: aou_req__platform__integration_assistance, aou_req__platform__os_integration_manual, aou_req__platform__bug_interface
+
+AutoSD
+######


@odra there seems some documentation issue in this file, otherwise for me it looks now fine

it's showing a warning (future error) for :implements: aou_req__platform__integration_assistance, aou_req__platform__os_integration_manual, aou_req__platform__bug_interface - it seems it's not allowed anymore as I said in this previous comment: #2266 (comment)

Not sure the error is "/home/runner/work/score/score/docs/modules/os/operating_systems/docs/community/autosd.rst:23: WARNING: Duplicate explicit target name: "upstream documentation". [docutils]"
@RolandJentschETAS , any idea on that?

@masc2023 ok, I fixed it

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

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.

@odra this is still open

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.

@odra this is still open

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

@odra this is still open

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

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

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

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

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.

qor-lb

@odra I added some small proposed changes for the supported architecture and there are still some open comments that were not yet addressed

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

qor-lb · 2026-02-13T10:46:43Z

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.


@odra this is still open

qor-lb · 2026-02-13T10:46:53Z

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.


@odra this is still open

qor-lb · 2026-02-13T10:47:01Z

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


@odra this is still open

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

qor-lb · 2026-02-13T10:50:40Z

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

+
+Build Instructions
+------------------
+
+---------------+--------------------------------+
+| Target Arch   | Comments                       |
+---------------+--------------------------------+
+| <target_arch> | <Native Only, Cross Compile>   |
+---------------+--------------------------------+


@odra I don't like that the target arch table is currently duplicated in the build instructions and in the toolchains.

How about creating an additional section before the build instructions to list this down:

Suggested change

Build Instructions

------------------

+---------------+--------------------------------+

| Target Arch | Comments |

+---------------+--------------------------------+

| <target_arch> | <Native Only, Cross Compile> |

+---------------+--------------------------------+

Supported Architectures

--------------------------------

+---------------+--------------------------------+

| TArchitecture | Comments |

+---------------+--------------------------------+

| <target_arch> | <Native Only, Cross Compile> |

+---------------+--------------------------------+

Build Instructions

------------------

An then also add the description within the build instructions and toolchain that they should reference the target architecture and explain if there are any differences when approaching the supported architectures.

all the previous changes have already been address, I will push and update regarding the arch. table.

aschemmel-tech

my comments taken into account

Co-authored-by: Lars Bauhofer <lars.bauhofer@qorix.ai> Co-authored-by: Oliver Pajonk <oliver@pjnk.de> Co-authored-by: Frank Scholter Peres(MBTI) <145544737+FScholPer@users.noreply.github.com> Signed-off-by: Leonardo Rossetti <lrossett@redhat.com>

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

Closed

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

odra force-pushed the fix-2264_autosd-onboard branch from 5c2cf49 to 6324f53 Compare February 5, 2026 09:25

masc2023 reviewed Feb 5, 2026

View reviewed changes

masc2023 previously approved these changes Feb 6, 2026

View reviewed changes

opajonk suggested changes Feb 6, 2026

View reviewed changes

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

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

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

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 2 times, most recently from eada8ee to 7c59a7d Compare February 9, 2026 21:39

qor-lb requested changes Feb 13, 2026

View reviewed changes

odra force-pushed the fix-2264_autosd-onboard branch 3 times, most recently from 1437db3 to 9f86b83 Compare February 16, 2026 13:49

aschemmel-tech previously approved these changes Feb 16, 2026

View reviewed changes

Adds AutoSD and OS onboarding template

e1a6f6a

Co-authored-by: Lars Bauhofer <lars.bauhofer@qorix.ai> Co-authored-by: Oliver Pajonk <oliver@pjnk.de> Co-authored-by: Frank Scholter Peres(MBTI) <145544737+FScholPer@users.noreply.github.com> Signed-off-by: Leonardo Rossetti <lrossett@redhat.com>

odra dismissed aschemmel-tech’s stale review via e1a6f6a February 16, 2026 14:38

odra force-pushed the fix-2264_autosd-onboard branch from 9f86b83 to e1a6f6a Compare February 16, 2026 14:38

	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.

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!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

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.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

RolandJentschETAS Feb 3, 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!

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 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