Meta-intel Release Process

From Yocto Project
Jump to navigationJump to search

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.

Overall Responsibilities

The meta-intel repository consists of a set of BSPs and some common metadata. Because those BSPs each have separate owners, we can't make a blanket assertion that all those BSPs will be released as part of a meta-intel release. It would be nice to be able to do so, but in reality, different groups of maintainers may decide to do separate releases. As such. this section only describes the perceived responsibilities of the maintainers for the set of BSPs controlled by the Yocto team.

The Yocto Project Program Manager has the ultimate responsibility for coordinating the various BSP owners and managing the overall meta-intel release.

  • Basically the BSP maintainer(s) are responsible for tracking the release milestones and making sure the BSPs are up-to-date and releasable with respect to the poky release. This includes all recipe upgrades and bugfixes intended to go into the release.
  • At each release candidate, the autobuilder team generates the images passes them on to QA for testing.
  • QA tests and provides feedback on how the BSPs meet the release criteria.
  • The BSP maintainer(s) fix any problems found by QA, and the cycle repeats itself in the next RC cycle, until all BSPs can be released.

Once the BSPs are ready to be released from the BSP maintainer's and QA team standpoint, the autobuilder team generates release tarballs for each BSP and makes them available to the Yocto website maintainers for availability as downloads on the Yocto website.

  • The yocto website maintainers make the tarballs available from pages containing the release notes for each BSP, along with test reports and image verification status for each (see sections below for details).
  • Any problems not fixed by the BSP maintainers need to be noted by the maintainer and sent to the website maintainer and Yocto documentation maintainer as 'Layer-specific Notes' to be appended to each affected BSP's release notes (see below).

Basic Process

Even though exceptions may occur for some BSPs, this is the basic process we use to release all meta-intel BSPs:

  • All meta-intel BSPs will be build along with each Yocto Project milestone release candidates. Then QA will follow and results will be integrated with the full pass QA report.
  • Bugs will be fixed/handled by maintainers or others.
  • Within the first week after Yocto Project major release, RC1 for meta-intel BSPs will be built and tested.
  • Within the second week after Yocto Project major release, RC2 for meta-intel BSPs will be built and tested.
  • meta-intel BSPs will be released by the end of the third week after Yocto Project major release.

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.
Retrieved from "https://wiki.yoctoproject.org/wiki/index.php?title=Meta-intel_Release_Process&oldid=10304"