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

Hi Quentin,

Thanks for the suggestions, I'll prepare a v2.

Otherwise I'll answer to what I know the answer to.

On Fri Jun 6, 2025 at 11:25 AM CEST, Quentin Schulz wrote:
> 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?

I took a note of that, thanks

>> +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...?

Sure, I can briefly mention that, it can help people locating their "under-test"
patches.

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

I did not want to display the email adresses of the people there without their
consent, although it would be nice to include, for sure. I guess I can mention
that layer READMEs should contain more information, including the email address.

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

Indeed this was a mistake, thanks!

>> +   * - `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`?

Yes, this builder is testing package types from 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

Antonin

Hi Antonin,

On 6/10/25 1:38 PM, Antonin Godard wrote:
> Hi Quentin,
> 
> Thanks for the suggestions, I'll prepare a v2.
> 
> Otherwise I'll answer to what I know the answer to.
> 
> On Fri Jun 6, 2025 at 11:25 AM CEST, Quentin Schulz wrote:
>> Hi Antonin,
>>
>> On 6/6/25 9:37 AM, Antonin Godard via lists.yoctoproject.org wrote:
[...]
>>> +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?
> 
> I did not want to display the email adresses of the people there without their
> consent, although it would be nice to include, for sure. I guess I can mention
> that layer READMEs should contain more information, including the email address.
> 

Fair enough, especially considering that the mail addresses may change 
over time.

Not sure the layer's README will contain information about machines' or 
some autobuilder builders' maintainers though?

I'm mostly perplexed about what is the purpose for such a column in the 
table.

@Richard - or anyone else :) - what is/was intended here?

Cheers,
Quentin

On Tue, 2025-06-10 at 15:21 +0200, Quentin Schulz wrote:
> On 6/10/25 1:38 PM, Antonin Godard wrote:
> > Thanks for the suggestions, I'll prepare a v2.
> > 
> > Otherwise I'll answer to what I know the answer to.
> > 
> > On Fri Jun 6, 2025 at 11:25 AM CEST, Quentin Schulz wrote:
> > > Hi Antonin,
> > > 
> > > On 6/6/25 9:37 AM, Antonin Godard via lists.yoctoproject.org wrote:
> [...]
> > > > +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?
> > 
> > I did not want to display the email adresses of the people there without their
> > consent, although it would be nice to include, for sure. I guess I can mention
> > that layer READMEs should contain more information, including the email address.
> > 
> 
> Fair enough, especially considering that the mail addresses may change 
> over time.
> 
> Not sure the layer's README will contain information about machines' or 
> some autobuilder builders' maintainers though?
> 
> I'm mostly perplexed about what is the purpose for such a column in the 
> table.
> 
> @Richard - or anyone else :) - what is/was intended here?

We have a few challenges. Is these things are going to get tested and
maintained to some level, we really need to show how you can contact
the people responsible for maintaining them. There are project
processes such as the autobuilder failure triage that do need to know
who to email.

Ideally, we'd teach the autobuilder how to do that. In practise, it is
hard to know what is a real failure and what is not, so automation is
no where near as easy as people think.

Ideally we'd just put a list of email addresses here. There are privacy
concerns some would raise, spam concerns and so on. Some would say
these can change too frequently and should be maintained on the wiki
(which we have plans to deprecate) or somewhere else. Equally forcing
triage people to look up addresses in layer readmes every time seems
suboptimal too.

So really, we do need to have this information somewhere and we do need
to hold actual individuals accountable for some of this. But we also
can't identify anyone.

Cheers,

Richard

Hi Richard, hi Antonin, hi TSC

Thank you very much for this patch.

On Fri, 2025-06-06 at 09:37 +0200, 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
> +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
> +associated to an architecture or a feature to test. For example, the
> +``qemuarm64`` builder corresponds to testing the ARM 64-bit
> architecture.
> +
> +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
> +features are being run on a daily basis on the Yocto Project
> Autobuilder and
> +also tested with incoming changes before they merge.
> +
> +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)
> +     - Builder(s)
> +   * - :wikipedia:`ARM <ARM_architecture_family>`
> +     - ARM architecture testing
> +     - Collective effort
> +     - genericarm64,
> +       genericarm64-alt,
> +       meta-arm,
> +       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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fge
> rrit.automotivelinux.org%2Fgerrit%2FAGL%2Fmeta-
> agl&data=05%7C02%7Cadrian.freihofer%40siemens.com%7C192e739e38ea4f3a5
> b4b08dda4cd0eea%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C63884792
> 2809852994%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLj
> AuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%
> 7C&sdata=BK%2BFTlVyLukcWwITgW%2FDk7CWNi1QIGnVHYKbzrxhFHc%3D&reserved=
> 0>`__
> +     - meta-agl-core layer testing
> +     - Jan-Simon Möller
> +     - meta-agl-core
> +   * - `meta-arm
> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi
> t.yoctoproject.org%2Fmeta-
> arm&data=05%7C02%7Cadrian.freihofer%40siemens.com%7C192e739e38ea4f3a5
> b4b08dda4cd0eea%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C63884792
> 2809881187%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLj
> AuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%
> 7C&sdata=HqpnTQl5oy5jBwhyc6pyk18tnHYob61b6Yc9ijTBrFY%3D&reserved=0>`_
> _
> +     - meta-arm layer testing
> +     - Jon Mason,
> +       Ross Burton
> +     - meta-arm
> +   * - `meta-aws
> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi
> thub.com%2Faws4embeddedlinux%2Fmeta-
> aws&data=05%7C02%7Cadrian.freihofer%40siemens.com%7C192e739e38ea4f3a5
> b4b08dda4cd0eea%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C63884792
> 2809897969%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLj
> AuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%
> 7C&sdata=cyoSr7gk0ZY6od4mhWJWZ8QtgFWA5DZHPHnPEG1eotU%3D&reserved=0>`_
> _
> +     - meta-aws layer testing
> +     - Thomas Roos
> +     - meta-aws
> +   * - `meta-intel
> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi
> t.yoctoproject.org%2Fmeta-
> intel&data=05%7C02%7Cadrian.freihofer%40siemens.com%7C192e739e38ea4f3
> a5b4b08dda4cd0eea%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638847
> 922809913790%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIw
> LjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7
> C%7C&sdata=vBtpevMEH77vDWn0T2fZUCjo1l2pAwxsCM4Xv5D4b6o%3D&reserved=0>
> `__
> +     - meta-intel layer testing
> +     - Anuj Mittal
> +     - meta-intel
> +   * - `meta-virtualization
> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi
> t.yoctoproject.org%2Fmeta-
> virtualization%2F&data=05%7C02%7Cadrian.freihofer%40siemens.com%7C192
> e739e38ea4f3a5b4b08dda4cd0eea%7C38ae3bcd95794fd4addab42e1495d55a%7C1%
> 7C0%7C638847922809930582%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRy
> dWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D
> %3D%7C0%7C%7C%7C&sdata=xClequnHUG5%2FW8zCBuB%2Bdhuf7%2BIjOAvLtKjS6svr
> Ahs%3D&reserved=0>`__
> +     - 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>`)
> +     - 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.
> +
> +-  Test results can be submitted as part of the release process
> if desired.
> +
> +The Yocto Project :oe_wiki:`Technical Steering Committee (TSC)
> </TSC>` makes
> +decisions on features in this status and Autobuilder testing. Such
> support would
> +be dropped if the maintainers/testing were inactive.
> +
> +If you are interested in providing resources for improving testing
> please
> +contact the :oe_wiki:`Technical Steering Committee (TSC) </TSC>`.
> +
> +Below is a list of secondary tested features, their maintainer(s)
> and
> +builder(s):
> +
> +.. list-table::
> +   :widths: 20 20 20 40
> +   :header-rows: 1
> +
> +   * - Feature
> +     - Description
> +     - Maintainer(s)
> +     - Builder(s)
> +   * - :wikipedia:`PowerPC (32-bit) <PowerPC>`
> +     - PowerPC architecture testing (32-bit)
> +     - Adrian Freihofer

Would it be possible to add Peter Marko in addition to me?

> +     - qemuppc,
> +       qemuppc-alt,

Not sure how much effort we'll be able to dedicate to PPC-32 with
systemd. To be transparent, we might need to consider moving qemuppc-
alt to unsupported status until somebody would step up as a maintainer
for qemuppc-alt.

Regards,
Adrian

> +       qemuppc-tc
> +   * - :oe_git:`meta-openembedded </meta-openembedded>`
> +     - meta-openembedded layer testing
> +     - Khem Raj
> +     - meta-oe
> +   * - `meta-mingw
> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi
> t.yoctoproject.org%2Fmeta-
> mingw&data=05%7C02%7Cadrian.freihofer%40siemens.com%7C192e739e38ea4f3
> a5b4b08dda4cd0eea%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638847
> 922809950438%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIw
> LjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7
> C%7C&sdata=GFT18vJeV3EkCduLBsSeufEsCdO1trqyyrarsekz9o0%3D&reserved=0>
> `__
> +     - mingw based SDKs testing
> +     - Joshua Watt
> +     - meta-mingw
> +   * - `meta-webosose
> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi
> thub.com%2Fwebosose%2Fmeta-
> webosose&data=05%7C02%7Cadrian.freihofer%40siemens.com%7C192e739e38ea
> 4f3a5b4b08dda4cd0eea%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638
> 847922809971163%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiO
> iIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7
> C%7C%7C&sdata=aDQzRy3tcJhNZLqRJIdGTMOuARX4kBZc8CuoLv%2F%2BWPg%3D&rese
> rved=0>`__
> +     - meta-webosose layer testing
> +     - Martin Jansa
> +     - meta-webosose
> +   * - :wikipedia:`RISC-V (32-bit) <RISC-V>`
> +     - RISC-V architecture testing (32-bit)
> +     - Collective effort
> +     - qemuriscv32,
> +       qemuriscv32,
> +       qemuriscv32-tc
> +
> +Untested
> +========
> +
> +"Untested" means that whilst the configurations are present in the
> project, we
> +don't currently run the tests on any regular basis and new changes
> are not
> +tested against them. We may take patches in these areas if they make
> sense but
> +it is on a best effort only basis.
> +
> +.. list-table::
> +   :widths: 20 20 20 40
> +   :header-rows: 1
> +
> +   * - Feature
> +     - Description
> +     - Maintainer(s)
> +     - Builder(s)
> +   * - `meta-exein
> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi
> thub.com%2Fexein-io%2Fmeta-
> exein&data=05%7C02%7Cadrian.freihofer%40siemens.com%7C192e739e38ea4f3
> a5b4b08dda4cd0eea%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638847
> 922809992529%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIw
> LjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7
> C%7C&sdata=cIY01vQNRO%2Br0%2FOFPKqlm%2Btqv45L1PCvxMDnrpQy%2FYU%3D&res
> erved=0>`__
> +     - meta-exein layer testing
> +     - Gianluigi Spagnuolo
> +     - meta-exein
> +   * - :wikipedia:`MIPS <MIPS_architecture>`
> +     - MIPS architecture testing
> +     - No maintainers
> +     - qemumips,
> +       qemumips64,
> +       qemumips-alt,
> +       qemumips-tc,
> +       qemumips64-tc
> +   * - :wikipedia:`PowerPC (64-bit) <PowerPC>`
> +     - PowerPC architecture testing (64-bit)
> +     - No maintainers
> +     - qemuppc64,
> +       qemuppc64-tc
> 
> ---
> base-commit: c4748f5079e5193f82afc1b754816edd40ce9254
> change-id: 20250516-supported-architectures-201201e73c95
> 
> Best regards,
> 
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#7011):
> https://lists.yoctoproject.org/g/docs/message/7011
> Mute This Topic: https://lists.yoctoproject.org/mt/113499660/3616858
> Group Owner: docs+owner@lists.yoctoproject.org
> Unsubscribe:
> https://lists.yoctoproject.org/g/docs/unsub [adrian.freihofer@siemens.com
> ]
> -=-=-=-=-=-=-=-=-=-=-=-
>

On Wed Jun 11, 2025 at 6:31 PM CEST, Adrian Freihofer wrote:
[...]
>> +Below is a list of secondary tested features, their maintainer(s)
>> and
>> +builder(s):
>> +
>> +.. list-table::
>> +   :widths: 20 20 20 40
>> +   :header-rows: 1
>> +
>> +   * - Feature
>> +     - Description
>> +     - Maintainer(s)
>> +     - Builder(s)
>> +   * - :wikipedia:`PowerPC (32-bit) <PowerPC>`
>> +     - PowerPC architecture testing (32-bit)
>> +     - Adrian Freihofer
>
> Would it be possible to add Peter Marko in addition to me?

Hi Adrian,

We decided it would be better if each maintainer modifies this document to add
themselves once it is merged on the master branch. The v2 of this patch contains
"TBD" values instead, which are to replace. I think you could modify that and
add Peter Marko as well.

>> +     - qemuppc,
>> +       qemuppc-alt,
>
> Not sure how much effort we'll be able to dedicate to PPC-32 with
> systemd. To be transparent, we might need to consider moving qemuppc-
> alt to unsupported status until somebody would step up as a maintainer
> for qemuppc-alt.

Thanks for letting me know, I will move that to the unsupported section.

Antonin