Stable branch maintenance

The Yocto Project maintains stable branches of Poky (OE-Core and BitBake)

Stable branch maintainers

Major version	Branch name	Maintainer
1.5	dora	Robert Yang <liezhi.yang@windriver.com>
1.4	dylan	Paul Eggleton <paul.eggleton@linux.intel.com>
1.3	danny	Ross Burton <ross.burton@intel.com>
1.2	denzil	Scott Garman <scott.a.garman@intel.com>

Policies

• Fixes must go into master first unless they are applicable only to the stable branch
• CVE (security) patches should be backported if at all possible
• No recipe upgrades unless:
  • The old version is completely broken
  • The new version contains a security patch or other critical bugfix that is too difficult to backport to the version already in the stable branch

As always, the stable branch maintainers' judgement is important when it comes to deciding which fixes are or are not appropriate. If there is doubt, feel free to consult with the overall project maintainer (Richard Purdie <richard.purdie@linuxfoundation.org>).

Procedures

Merge cycle

When there are enough changes (or a few critical ones), the stable branch maintainer should follow this procedure:

1. Look out for patches on the mailing list marked with the stable branch name
2. Look through recently merged patches in master
3. Collect patches together on a branch
   • If a submitted patch is a backport from master, rather than taking the patch as submitted, it is preferable to backport the patch from master so that the original commit message is preserved.
   • If you do the backporting from poky you will get the original commit ID in the commit message which is useful for reference.
   • It is beneficial to change the original commit ID line to say "OE-Core master rev" instead of "OE-Core rev" to distinguish it from the OE-Core branch revision that will be added when the commit is merged
4. Run a local build or two to pick up any obvious problems
5. Test the branch on the autobuilder (see How to start a build on the Autobuilder)
   • Make sure you check directly for the results of the build as these won't be reported to the yocto-builds mailing list.
6. Split out any bitbake changes and send them to the bitbake-devel mailing list (marking them with the appropriate stable version in the subject line e.g. [1.20])
7. Split out OE-Core changes and create an openembedded-core-contrib branch containing them; send the cover letter only (marking it as such in the subject) to the openembedded-core mailing list.
8. Split out any meta-yocto changes and create a poky-contrib branch containing them; send the cover letter only (marking it as such in the subject) to the poky mailing list.
9. When the patches are merged, mark any bugs specific to the stable branch as resolved as appropriate.

There will very likely be a number of these cycles during the lifetime of the stable branch.

Point release

Normally point releases are scheduled in advance as appropriate - contact Song Liu about scheduling point releases.

1. Send a patch to update the stable version in meta-yocto/conf/distro/poky.conf for the release
2. Once that is merged, ask Beth Flanagan to run the release candidate build
   • The stable branch maintainer should monitor the build and follow up on any failures
3. When the release candidate build completes successfully, Beth should notify the QA team to start the release QA process.
4. Gather together changes in the form needed for a release notes and send them to Beth Flanagan <elizabeth.flanagan@intel.com> so she can incorporate them in final release notes and to Song Liu <song.liu@intel.com> so he can have them in preparation for the release meeting.

Other

• It is useful to provide status updates on the Yocto Project technical call, particularly coming up to a stable release. If you're not able to be on the call, send the status update information to Song Liu <song.liu@intel.com> and he will present it.