Meta-intel Release Process

meta-intel releases happen with the same cadence that poky releases happen, though the actual release may be staggered with respect to the associated poky release. We now attempt to co-release with poky, or at least have everything ready to co-release, but the actual release decision may dictate that we don't actually co-release. The meta-intel release may also be staggered simply because meta-intel needs the extra time to stabilize against the associated poky release.

This pages attempts to capture the meta-intel release process as it exists - it isn't meant to be an official or binding document.

Also, this process only addresses the BSPs built and released by the Yocto Autobuilder team, and tested by the Yocto QA team - it doesn't address the release process for any BSPs that are managed outside of that process, such as the ISG BSPs, which may be built using a separate autobuilder and tested by ISG, i.e. which have their own release process, though their metadata may exist within the meta-intel and linux-yocto repositories.

Branch and Tag Management

The autobuilder maintainers are the only ones who can create new branches and release tags in meta-intel, and will do so when necessary as required to generate the infrastructure needed for a release.

• Once a new branch is created for the release, the meta-intel maintainer(s) will add new commits to both master and the release branch up until the time of release (as appropriate - some patches may only be intended for master or the release)

Release Notes

Currently, the 'release notes' for a BSP consist of the information found on the web page for the BSP in the 'Downloads' section for the BSP, and essentially consists of the BSP's README along with a 'Layer-Specific Notes' section, which is tacked on to the end of the page.

• The Yocto documentation and website maintainers will be responsible for the content of the BSP pages and will ask the BSP maintainer(s) for any additional information needed for a particular BSP
• Normally the only thing needed from the BSP maintainer(s) are the 'Layer-Specific Notes' for a BSP, which the BSP maintainers should supply to the documentation and website maintainers unsolicited as part of the release process.
  • Any layer-specific notes that affect multiple or all BSPs should be attached to each BSP separately in the 'Layer-Specific Notes' section.
• The title used for the BSP on the website is retrieved by the documentation and website maintainers from the BSP's WEBTITLE field in the BSP's machine.conf, and should therefore reflect accurately how the BSP is identified on the website. This may be a string defined by marketing, and should at least be approved by marketing.

Testing

According to the Yocto Project compliance requirements, no meta-intel BSP can be released without testing data. The webpage for each BSP must contain a link to the testing data generated for every image contained in a released BSP. For the BSPs tested by Yocto QA, the QA test report should be the one linked to for those BSPs.

Image Verification

For every BSP image contained in a tarball released on the Yocto website, it must be verified that the image can be independently generated from scratch (including downloads) using the released metadata.

Customers must (and have, and will) be able to verify that the images contained in the release tarball can in fact be generated from the combination of the metadata contained in the BSP tarball and the set of packages downloaded by the build (from a scratch build) process to create those images.

In practice, this means that the autobuilder maintainer needs to supply the settings required to generate the BSP to the person verifiying the image. If the release tarball is generated by some other process, the BSP maintainer needs to supply that information.

• Note that all images released on the website must contain a time-limited kernel and this must be taken into account when verifying the image.