|
|
| (11 intermediate revisions by 2 users not shown) |
| Line 1: |
Line 1: |
| == Yocto Linux Release Engineering Procedures == | | == Yocto Project Release Engineering == |
|
| |
|
| This document describes release engineering procedures for the Yocto Linux project.
| | Welcome to Yocto Project Release Engineering. |
|
| |
|
| While this is intended to be a living document, this process is becoming more stable now that we're entering M3. Further changes will be considered if they are accompanied with strong reasoning and evidence of improvement.
| | === Processes === |
|
| |
|
| == Naming Conventions ==
| | * [[Yocto Project Release Process]] |
| | * [[Yocto Project Release Checklist]] |
| | * [[Uninative Release Process]] |
| | * [[Third_Party_BSP_Release_Process | Third Party BSP Release Guidelines]] |
|
| |
|
| Official/public releases will use the following scheme: '''M.m.p'''
| | === Conventions === |
|
| |
|
| * M = major release number | | * [[Yocto Project Tagging Conventions]] |
| * m = minor release number | | * [[Yocto Project Branch Conventions]] |
| * p = minor rev release number
| |
|
| |
|
| Major release number changes imply compatibility changes with previous releases. Minor release number changes imply significant changes up to, but not including compatibility changes. Minor rev number changes are for minor issues such as simple bugfixes, security updates, etc.
| | === Resources === |
|
| |
|
| Nightly releases will be named using the following scheme: '''image-name-M.m.p-date-buildnum.extension''', where M.m.p is the release number, where date is the datestamp of the build, e.g, 20100715, and buildnum is a build counter, e.g, 1, 2, 3, in case more than one build is generated the same day.
| | * [[The Yocto Autobuilder]] |
| | * [[Frequently Asked Release Engineering Questions]] |
| | * [[Frequently Asked Yocto Autobuilder Questions]] |
|
| |
|
| Milestone releases will be named using the following scheme: '''image-name-M.m.p-date-milestonenum-buildnum.extension''', where the field definitions are the same as above with the addition of milestonenum, e.g. M3.
| | === Best Known Methods === |
|
| |
|
| Our first public release was 0.9.0 in October 2010. Our second public release will be the 1.0.0 release in Spring 2011.
| | * [[BKM: Packaging a BSP for Release]] |
| | * [[BKM: Releasing a source archive]] |
|
| |
|
| == Types of Releases == | | === Release Engineering Team === |
|
| |
|
| ==== Internal/Nightly Releases ====
| | The Yocto Project's Release Engineering Team is comprised of Chee Yang Lee and Michael Halstead. |
| | |
| Nightly releases can be considered a "base class" of the release system. Weekly releases are generated directly from them, and otherwise the nightly release build status serves as a fundamental health status of the builds. Nightly releases are built directly from poky master and '''failures should be immediately addressed or the offending changes reverted'''.
| |
| | |
| ==== Internal/QA Weekly Releases ====
| |
| | |
| These releases are the basic unit of internal progress for the Yocto project.
| |
| | |
| Every Wednesday (mid-day US Pacific time), the nightly build will generate a release which gets submitted to QA that evening (the start of China's Thursday).
| |
| | |
| If this weekly release passes initial testing from QA, the QA team will continue on to run their full weekly test suite.
| |
| | |
| If the weekly release does ''not'' pass initial testing from QA, the QA team will report this to the distro team and the distro team will focus on addressing these issues the next day. If the distro team lead believes these changes will resolve the reported issues, he/she will submit the nightly build for that day to QA again.
| |
| | |
| Weekly releases will be made available to the QA team via a web-accessible directory on the autobuilder. Within this directory, a tarball of all of the above components will be available to make downloading the release more convenient.
| |
| | |
| ==== Milestone Releases ====
| |
| | |
| These releases are performed at the end of a milestone period and are used to measure our progress in delivering new features to Yocto Linux.
| |
| | |
| To generate a milestone release, a snapshot of poky/meta-intel/eclipse-poky/meta-qt3 master is taken and pushed to a milestone branch. This branch then serves as a stabilization branch, allowing poky master to continue feature development. builds/milestone can then be improved by pulling in fixes via cherry-picking from poky master.
| |
| | |
| After each release candidate is generated, the branch is tagged (M.m_M1.rcX). Once stabilization has occurred, the branch is then tagged as M.m_M1.final and git tar archives are generated. No images are released for milestone builds.
| |
| | |
| ==== Point releases/Major Releases ====
| |
| | |
| These are the final, QA-tested, manager-approved releases of Yocto Linux which will '''WOW''' our customers and change the future of embedded Linux devices. Words can barely describe the awesomeness of these SDK and filesystem images!
| |
| | |
| == Release Components ==
| |
| | |
| Yocto Linux includes a number of software components to be included in each release. These include:
| |
| | |
| ==== Distro Components ====
| |
| | |
| * Bootable QEMU images of minimal and sato for the following architectures: qemux86, qemux86-64, qemuarm, qemumips, qemuppc
| |
| ** A bootable QEMU image consists of a kernel file, a kernel modules tarball, and root filesystem tarball
| |
| * Non-emulated machine targets (e.g, netbook, emenlow) will include appropriate images (e.g, live images) of minimal and sato.
| |
| | |
| ==== SDK Components ====
| |
| | |
| * meta-toolchain tarballs for the following host/target combinations: i586/[arm|i586|mips|ppc|x86_64], x86_64/[arm|i586|mips|ppc|x86_64]
| |
| * Bootable SDK images for the following architectures: qemux86, qemux86-64, qemuarm, qemumips, qemuppc
| |
| * SDK plugins for the following IDEs: Anjuta, Eclipse
| |
| | |
| Currently the SDK plugins are not being generated with the remaining build output. Jessica and Scott will need to define a process for this that makes sense before public release. There are issues to be take into consideration such as how the plugins are distributed (Anjuta and Eclipse have their own plugin repositories, for example).
| |
| | |
| ==== Other components ====
| |
| | |
| * gitinfo - a file which includes information about which commit the images were built from
| |
| * Changelog - a file which includes git log information between the last released version and the newly built version
| |
| * Bugfixes - a list of bugs, extracted from the Changelog, that were fixed between the last released version and the newly built version
| |
| | |
| == Major/Point Release Procedures ==
| |
| | |
| === Release Readiness Review ===
| |
| | |
| The Release Readiness Review is a sign-off process for official/public Yocto releases. This process reviews feature completeness, status of open defects, testing status, and verifies the status of documentation. From the release readiness review a decision is made on the status of launching an official release.
| |
| | |
| === Technical Release Procedures ===
| |
| | |
| 24 hours before the release is made public, the release images would be mirrored to external locations and allow time for the blog and mailing list announcements to be written. The final steps in releasing would be ready to be performed in a matter of seconds:
| |
| | |
| * Move the release directory from a staging area into the public web server area
| |
| * Push the web site update including new release information
| |
| * Post the pre-written release announcement on the blog and mailing lists
| |
| | |
| ==== Steps to building a release for Yocto ====
| |
| | |
| Prior to release build:
| |
| * If the build is a point release, use the appropriate release branch (edison, bernard, etc). If not, create a milestone release branch in the following repositories. The milestone branch follows <Major>.<minor>_M<milestone_number> where Major and minor are Yocto release Major and minor release numbers:
| |
| - poky
| |
| - meta-qt3
| |
| - meta-intel
| |
| - eclipse-plugin
| |
| - meta-x32
| |
| * Set DISTRO and DISTRO_VERSION in meta/conf/poky.conf
| |
| * Update handbook references to stable release (introduction.xml, master branch needs this too)
| |
| * Update version reference and updated date in handbook (poky-handbook.xml)
| |
| * Run the nightly build using the release branch from the autobuilder. This will create images at http://autobuilder.yoctoproject.org/pub/nightly/<datestamp>/.
| |
| * If the build is "good", and adequate for delivery to QA, git tag/sign/commit the above repo's release branch HEADs as <Major>.<minor>_M<milestone_number>.rc<release_candidate_number>
| |
| * Update MIRRORS to use the autobuilders source dir
| |
| | |
| ===== Checklist =====
| |
| * Are docs within the release branch current and correct?
| |
| * Is the tarball location within the release branch correct?
| |
| * Has DISTRO and DISTRO_VERSION and SDK_VERSION been flipped?
| |
| * Have we branched/tagged poky/meta-intel/meta-qt3 etc?
| |
| * Do the mirrors work?
| |
| | |
| ==== Steps to release Yocto ====
| |
| | |
| Once a release candidate has been validated as a GO:
| |
| * git branch the milestone branches as <Yocto name> eg "edison", "bernard" etc.
| |
| * git tag/sign/commit the above repo's release branch HEADs as <Yocto_name>-<M>.<m>.<p> where M.m.p is the Poky version.
| |
| * Copy http://autobuilder.yoctoproject.org/pub/nightly/<datestamp> to http://downloads.yoctoproject.org/releases/yocto/yocto-<M>.<m>. Set to non-world readable
| |
| * Remove all timestamp images from machines/*
| |
| * For final release, copy DL_DIR to yocto_M.m/sources
| |
| * Modify the yocto tarball so that it extracts to poky-<Yocto-name>-<M>.<m> where M.m is the Poky version.
| |
| * Create the ADT repo using the ipk directory
| |
| * Extract the eclipse-plugin archive to http://downloads.yoctoproject.org/releases/eclipse-plugin/<M>.<m> where M.m is the Yocto version
| |
| * create the md5sum table in http://downloads.yoctoproject.org/releases/yocto/yocto-<M>.<m>
| |
| * gpg sign the md5sum table
| |
| * create release notes
| |
| * verify new handbook as been published
| |
| * Set release directory to world readable. Verify release access.
| |
| * Post release announcement on Blog
| |
| * Post release announcement on mailing list
| |
| | |
| On master branch:
| |
| * Set DISTRO_VERSION in poky.conf to new version
| |
| * Update version reference and updated date in handbook (poky-handbook.xml)
| |
| * cd handbook
| |
| * make
| |
| * scp -r poky-handbook.tgz poky-handbook.html poky-handbook.pdf *.png *.xml *.css *.svg <server>:<path>/releases/purple-3.2/doc/
| |
| * scp -r poky-handbook.tgz poky-handbook.html *.png *.xml *.css *.svg <server>:<path>/releases/doc/
| |
| (or copy across by hand when remotely connected to machine?)
| |
| * Edit web pages (website is controlled from a git repo)
| |
| **support/index.php
| |
| **getit/index.php
| |
| **index.php
| |
| **poky-wp-theme/common-funcs.inc
| |
| **poky-wp-theme/front-page.php
| |
