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

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

…platform-onboarding Added descriptive texts

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

qor-lb · 2026-01-26T12:43:25Z

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

We should describes the onboarding, maybe something like this (in separate file):

.. _platform-onboarding: Onboarding and Promotion of Platforms ===================================== This page describes how platforms are added and promoted. The process requirements are defined in :ref:`platform_assumptions`. Principle --------- Promotion has two phases: 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. Community level onboarding -------------------------- **What it means** In-tree best-effort integration. S-CORE provides no guarantees. **Eligibility requirements (Platform Maintainer / supplier requirements)** The OS maintainer must fulfil 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. Promotion to Functional ----------------------- **What it means** S-CORE provides functional guarantees for the accepted reference integration and maintains them across all increments. **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 Promotion to Certifiable ------------------------ **What it means** S-CORE provides certifiability-oriented guarantees for the accepted reference integration and maintains them across all increments. **Eligibility requirements (Platform Maintainer / supplier requirements)** The platform maintainer must fulfil the Certifiable level supplier requirements as defined in: :ref:`platform_assumptions`. **Additional acceptance requirements (S-CORE / system integrator requirements)** Certifiable level implies additional safety/security expectations and evidence handling. **Required approvals** Promotion to Certifiable requires explicit approval by: * OS module maintainers * Architecture WG * Infrastructure WG * Testing WG * Quality Management * Safety Manager * Security Manager Demotion -------- If the eligibility requirements or the S-CORE lifecycle guarantees of an accepted platform can no longer be maintained, the platform must be demoted to the highest level that can be sustained.

@odra this is still open

added as onboarding.rst

qor-lb · 2026-01-26T12:58:32Z

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

We should add a template that standardizes the information presented. I would also like the ability to filter for specific platform so making them as needs would be nice. Please include and link that in the onboarding page and apply it for autosd:

Platform Name ============= .. platform:: <platform name> :id: platform__<platform name snake case> :level: <community/functinal/certifiable> :maintainer: <GitHub Handles> Short overview of the platform and why it is relevant for S-CORE. Keep this to 3-6 lines. Mention what the OS is and the intended usage context. Target maintainers/integration assistance ----------------------------------------- GitHub Handles of the target maintainers. Integration assistance ---------------------- - Provide the names or mailing lists that users can contact for help with S‑CORE integration. - Use bullet points for multiple contacts. Integration manual ------------------ - Summarise how to obtain and use the integration manual for this platform. - Link to external documentation if it exists. Build instructions ------------------ Explain how to build an image of this platform and how to build S-CORE for it. .. code-block:: console # example commands to build an image curl -o /tmp/image-builder.sh https://example.com/image-builder.sh chmod +x /tmp/image-builder.sh sudo bash /tmp/image-builder.sh --distro <distro> --target <target> Provide any additional context, such as how to boot or run the image (e.g. with QEMU). Toolchain --------- - Explain how to set up Bazel toolchains for this platform. - Include a short example ``MODULE.bazel`` snippet. Bug interface ------------- - Explain how users can report bugs (mailing lists, issue trackers, Matrix/Slack channels etc.).

@odra this is still open. I would also link the template in the onboarding section above.

Added as "os_onboarding_template.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


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-01-29T11:26:01Z

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

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

opajonk

Details only

opajonk · 2026-01-30T14:00:38Z

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

+-------------------
+
+Use the :doc:`onboarding template document <os_onboard_template>` as the starting point to add a new operating system to
+one of the levels, as described in the previou sections of this document.


Suggested change

one of the levels, as described in the previou sections of this document.

one of the levels, as described in the previous sections of this document.

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

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

opajonk · 2026-01-30T14:09:41Z

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

+Short overview of the platform and why it is relevant for S-CORE.
+Keep this to 3-6 lines. Mention what the OS is and the intended usage context.
+
+Target maintainers/integration assistance


Again - title case or not? We should decide and then make it consistent.

Personally: Title Case +1, it looks more nice and is more common ;-)

Makes sense to me, I've changed all headers to use title case

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

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

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)

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 2 times, most recently from d602c54 to 629cafa Compare December 8, 2025 12:19

adding autosd

eb1535e

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

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

odra and others added 3 commits December 10, 2025 03:44

adding requirements link to top level sw_platforms page

2e60e99

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

Added descriptive text

f978949

Merge pull request #1 from elektrobit-contrib/proposed-modifications-…

b126d3f

…platform-onboarding Added descriptive texts

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 and others added 3 commits January 29, 2026 06:09

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

74b829b

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

refactor operating systems section

1f80559

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

add functional and certifiable levels

0a57a2c

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

odra added 4 commits January 29, 2026 13:06

add template and update autosd.rst accordingly

92fddfd

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

updated build instructions

b859503

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

add onboarding doc + template page

76f5b6f

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

fix hierarchy

34a6713

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

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

odra and others added 3 commits January 30, 2026 11:20

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

989fb30

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

e3ae59f

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

template header consistency

2706da3

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

masc2023 requested changes Jan 30, 2026

View reviewed changes

	one of the levels, as described in the previou sections of this document.
	one of the levels, as described in the previous sections of this document.

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!

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 Jan 29, 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!

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!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

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

odra Jan 29, 2026 •

edited

Loading

qor-lb commented Jan 26, 2026 •

edited

Loading