You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There's no "one size fits all" way of validating BSP layers, so we need to document what exactly we want to support and how we are validating that using the CI. On top of that we have external requirements for things like the "Yocto Compatible designation".
For validation this layer should support all of the following scenarios in its CI workflow:
Use the DISTRO from meta-qcom-distro to have the CI build and validate the most complete experience we can offer, including optional, specific changes to enable Qualcomm tooling that has no upstream equivalent yet, like training AI models.
Use, and this is important, an unmodified Poky to gain the "Yocto Compatible" designation. This will not be a complete experience, but a good experience for users.
Use 'nodistro' with the tooling (currently KAS) showing which changes are needed to get close to the complete experience.
Users who include more than one BSP layer tend to have less leeway to make changes to their DISTRO, so the 'nodistro' workflow above should clearly show and document the steps it takes to make copy/pasting less dangerous.
Ideally this layer won't need invasive configuration changes, so improving upstream OE-core to get the defaults more in line with what the MACHINEs in meta-qcom-hwe require, would directly benefit both Poky and nodistro workflows.
What we mean with 'complete' and 'good' in the text above needs to get clearly defined as well!
The text was updated successfully, but these errors were encountered:
There's no "one size fits all" way of validating BSP layers, so we need to document what exactly we want to support and how we are validating that using the CI. On top of that we have external requirements for things like the "Yocto Compatible designation".
Related to the discussion in qualcomm-linux/meta-qcom-hwe#116, here's the initial proposal:
For validation this layer should support all of the following scenarios in its CI workflow:
Users who include more than one BSP layer tend to have less leeway to make changes to their DISTRO, so the 'nodistro' workflow above should clearly show and document the steps it takes to make copy/pasting less dangerous.
Ideally this layer won't need invasive configuration changes, so improving upstream OE-core to get the defaults more in line with what the MACHINEs in meta-qcom-hwe require, would directly benefit both Poky and nodistro workflows.
What we mean with 'complete' and 'good' in the text above needs to get clearly defined as well!
The text was updated successfully, but these errors were encountered: