Add a document to list supported Yocto features

Add a "Yocto Project Supported Architectures And Features" document that
aims at:

- Defining the different levels of support for features
- Listing the maintainers for a feature
- Listing the existing builders on the Autobuilder for the feature

Co-developed-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: Yocto TSC <tsc@lists.yoctoproject.org>
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
---
 documentation/ref-manual/index.rst                 |   1 +
 .../yocto-project-supported-features.rst           | 264 +++++++++++++++++++++
 2 files changed, 265 insertions(+)


---
base-commit: c4748f5079e5193f82afc1b754816edd40ce9254
change-id: 20250516-supported-architectures-201201e73c95

Best regards,

Hi Antonin,

On 6/6/25 9:37 AM, Antonin Godard via lists.yoctoproject.org wrote:
> Add a "Yocto Project Supported Architectures And Features" document that
> aims at:
> 
> - Defining the different levels of support for features
> - Listing the maintainers for a feature
> - Listing the existing builders on the Autobuilder for the feature
> 
> Co-developed-by: Richard Purdie <richard.purdie@linuxfoundation.org>
> Cc: Yocto TSC <tsc@lists.yoctoproject.org>
> Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
> ---
>   documentation/ref-manual/index.rst                 |   1 +
>   .../yocto-project-supported-features.rst           | 264 +++++++++++++++++++++
>   2 files changed, 265 insertions(+)
> 
> diff --git a/documentation/ref-manual/index.rst b/documentation/ref-manual/index.rst
> index a746dde492..53fa98cc99 100644
> --- a/documentation/ref-manual/index.rst
> +++ b/documentation/ref-manual/index.rst
> @@ -11,6 +11,7 @@ Yocto Project Reference Manual
>      :numbered:
>   
>      system-requirements
> +   yocto-project-supported-features
>      terms
>      release-process
>      structure
> diff --git a/documentation/ref-manual/yocto-project-supported-features.rst b/documentation/ref-manual/yocto-project-supported-features.rst
> new file mode 100644
> index 0000000000..8776a1a7eb
> --- /dev/null
> +++ b/documentation/ref-manual/yocto-project-supported-features.rst
> @@ -0,0 +1,264 @@
> +.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
> +
> +**************************************************
> +Yocto Project Supported Architectures And Features
> +**************************************************
> +
> +The Yocto Project is putting continuous efforts into testing the changes made to
> +the :term:`OpenEmbedded-Core (OE-Core)` metadata and core tools. The details on
> +how this test environment functions is described in the
> +:doc:`/test-manual/index`.
> +
> +These tests are also run for stable and Long Term Support versions of the Yocto

Could point Long Term Support to the :term:`LTS` as well since we 
already have it :)

> +Project. See the :doc:`/ref-manual/release-process` section of the Yocto Project
> +Reference Manual for more information on these types of releases.
> +
> +The infrastructure behind the test environment is the Yocto Project Autobuilder.
> +For more information on the Yocto Project Autobuilder, see the
> +:ref:`test-manual/intro:Yocto Project Autobuilder Overview` section of the Yocto
> +Project Test Manual. The Autobuilder contains a set of Builders that are

I would squash the first and second sentence with a simple link

:ref:`Yocto Project Autobuilder<test-manual/intro:Yocto Project 
Autobuilder Overview>`

for example.

> +associated to an architecture or a feature to test. For example, the
> +``qemuarm64`` builder corresponds to testing the ARM 64-bit architecture.
> +

Wondering if this information should be part of 
documentation/test-manual/understand-autobuilder.rst as well/only?

> +Below is a comprehensive list of target architectures and features that are
> +supported, as well as their level of support. For each architecture or feature,
> +their corresponding builders are also listed.
> +
> +Primary Supported
> +=================
> +
> +The term "primary" means that dedicated builds for these architecture or

s/architecture/architectures/

> +features are being run on a daily basis on the Yocto Project Autobuilder and
> +also tested with incoming changes before they merge.
> +

Should we mention this is typically the -next branches? E.g. 
master-next, walnascar-next, etc...?

> +Below is a list of primary tested features, their maintainer(s) and builder(s):
> +
> +.. list-table::
> +   :widths: 20 20 20 40
> +   :header-rows: 1
> +
> +   * - Feature
> +     - Description
> +     - Maintainer(s)

What are we trying to achieve with this column?

What am I supposed to derive as information as a user of YP/OE/BB based 
on that?

Is this some kind of public recognition from the project of efforts from 
some people?

Are we supposed to be able to contact those people maybe? Should there 
be some mail address there or some pointers to some document on what to 
do if we want to contact them?

> +     - Builder(s)
> +   * - :wikipedia:`ARM <ARM_architecture_family>`
> +     - ARM architecture testing
> +     - Collective effort
> +     - genericarm64,
> +       genericarm64-alt,
> +       meta-arm,

This stood out compared to other entries in this column as I recognized 
most others as machines, but this is a layer.

So this then prompted me to look it up on the autobuilder and I see that 
we have tags for builders.

Some are "layers" like meta-arm, "qemu", "toolchain", "qemu-alt", "ltp", 
"ptest", etc.

I'm guessing they have a purpose and things are tested differently in 
the autobuilder based on this tag? Is this something we want to document?

> +       musl-qemuarm64,
> +       qemuarm,
> +       qemuarm-alt,
> +       qemuarm-oecore,
> +       qemuarm-tc,
> +       qemuarm64,
> +       qemuarm64-alt,
> +       qemuarm64-armhost,
> +       qemuarm64-ltp,
> +       qemuarm64-ptest,
> +       qemuarm64-tc,
> +       qemuarmv5
> +   * - :yocto_git:`Beaglebone </poky/tree/meta-yocto-bsp/conf/machine/beaglebone-yocto.conf>`
> +     - Beaglebone image and SDK build testing
> +     - Collective effort
> +     - beaglebone,
> +       beaglebone-alt
> +   * - :doc:`Reproducible </test-manual/reproducible-builds>`
> +     - reproducibility testing
> +     - Collective effort
> +     - reproducible
> +   * - :term:`Buildtools`
> +     - Buildtools generation
> +     - Collective effort
> +     - buildtools
> +   * - `meta-agl-core <https://gerrit.automotivelinux.org/gerrit/AGL/meta-agl>`__
> +     - meta-agl-core layer testing
> +     - Jan-Simon Möller
> +     - meta-agl-core
> +   * - `meta-arm <https://git.yoctoproject.org/meta-arm>`__
> +     - meta-arm layer testing
> +     - Jon Mason,
> +       Ross Burton
> +     - meta-arm

Ahah, should meta-arm be removed from the first row?

> +   * - `meta-aws <https://github.com/aws4embeddedlinux/meta-aws>`__
> +     - meta-aws layer testing
> +     - Thomas Roos
> +     - meta-aws
> +   * - `meta-intel <https://git.yoctoproject.org/meta-intel>`__
> +     - meta-intel layer testing
> +     - Anuj Mittal
> +     - meta-intel
> +   * - `meta-virtualization <https://git.yoctoproject.org/meta-virtualization/>`__
> +     - meta-virtualization layer testing
> +     - Bruce Ashfield
> +     - meta-virt
> +   * - :ref:`Multilib <dev-manual/libraries:Combining Multiple Versions of Library Files into One Image>`
> +     - Multilib feature testing
> +     - Collective effort
> +     - multilib
> +   * - :term:`OpenEmbedded-Core selftest<OpenEmbedded-Core (OE-Core)>`
> +     - OpenEmbedded-Core layers selftests
> +     - Collective effort
> +     - oe-selftest-fedora,
> +       oe-selftest-debian,
> +       oe-selftest-armhost
> +   * - Package managers> +     - Package managers (RPM, DEB and IPK formats) testing in the
> +       :term:`OpenEmbedded Build System` (different from the
> +       ``package-management`` :term:`image feature <IMAGE_FEATURES>`)

Would that then be :term:`PACKAGE_CLASSES`?

We can keep the disambiguation though.

> +     - Collective effort
> +     - pkgman-non-rpm (other builders use RPM by default)
> +   * - :ref:`Patchtest <contributor-guide/submit-changes:Validating Patches with Patchtest>`
> +     - Patchtest tool selftests
> +     - Trevor Gamblin
> +     - patchtest-selftest
> +   * - :wikipedia:`RISC-V (64-bit) <RISC-V>`
> +     - RISC-V architecture testing (64-bit)
> +     - Collective effort
> +     - qemuriscv64,
> +       qemuriscv64-ptest,
> +       qemuriscv64-tc
> +   * - :wikipedia:`systemd <Systemd>`
> +     - Systemd init manager testing
> +     - Collective effort
> +     - no-x11, qa-extras2
> +   * - :term:`Toaster`
> +     - Toaster web interface testing
> +     - Collective effort
> +     - toaster
> +   * - :ref:`Wic <dev-manual/wic:creating partitioned images using wic>`
> +     - WIC image creation testing
> +     - Collective effort
> +     - wic
> +   * - :wikipedia:`X86 <X86>`
> +     - X86 architecture testing
> +     - Collective effort
> +     - genericx86,
> +       genericx86-64,
> +       genericx86-64-alt,
> +       genericx86-alt,
> +       musl-qemux86,
> +       musl-qemux86-64,
> +       qemux86,
> +       qemux86-64,
> +       qemux86-64-alt,
> +       qemux86-64-ltp,
> +       qemux86-64-ptest,
> +       qemux86-64-tc,
> +       qemux86-64-x32,
> +       qemux86-alt,
> +       qemux86-tc,
> +       qemux86-world,
> +       qemux86-world-alt
> +
> +Secondary Supported
> +===================
> +
> +The term "secondary" means that in some cases there is code/feature/support
> +which is desired by people using the project and is in the project's interests
> +to support, however there isn't wide enough interest and support to justify
> +testing all incoming changes on it. There are however project member
> +organisations and maintainers willing to run tests and review fixes.
> +
> +This category may be applicable as support/usage in an area develops and grows,
> +or as support/usage fades but we continue to have tests. It can also apply where
> +resourcing isn't available for full primary support but there is
> +member/maintainer support for running tests.
> +
> +We therefore have the following criteria and policies for such items:
> +
> +-  It can be clearly isolated and defined by specific configuration.
> +
> +-  There is a clear documented group of maintainers agreeing to maintain it.
> +
> +-  Those maintainers are active and responsive.
> +
> +-  It is being actively and publicly tested (potentially using
> +   the :ref:`Autobuilder <test-manual/intro:Yocto Project Autobuilder Overview>`
> +   by agreement, or otherwise).
> +
> +-  Testing would not be part of standard incoming change testing and regressions
> +   would not block incoming patches.
> +
> +-  The :yocto_wiki:`SWAT </Yocto_Build_Failure_Swat_Team>` team would not handle
> +   any test builds on the autobuilder.
> +

Autobuilder has always been capitalized in this patch until here, so...

s/autobuilder/Autobuilder/

?

> +-  Test results can be submitted as part of the release process if desired.
> +

Submitted where? Can we see the test results somewhere?

Cheers,
Quentin