Stable branch maintenance

The Yocto Project maintains stable branches of Poky (OE-Core and BitBake). Typically, alongside the latest release the previous two releases are also maintained.

Stable branch maintainers

Major version	Current Version	Branch name	BitBake version	Maintainer
2.4	2.4	Rocko	1.36	Richard Purdie
2.3	2.3.1	pyro	1.34	Armin Kuster <akuster808@gmail.com>
2.2	2.2.1	morty	1.32	Armin Kuster <akuster808@gmail.com>
2.1	2.1.3	krogoth	1.30	Armin Kuster <akuster808@gmail.com>
2.0	2.0.3	jethro	1.28	Robert Yang <liezhi.yang@windriver.com>
1.8	1.8.2	fido	1.26	Joshua Lock <joshua.g.lock@intel.com>
1.7	1.7.3	dizzy	1.24	Armin Kuster <akuster808@gmail.com>
1.6	1.6.3	daisy	1.22	Saul Wold <sgw@linux.intel.com>
1.5	1.5.4	dora	1.20	Robert Yang <liezhi.yang@windriver.com>
1.4	1.4.3*	dylan	1.18	Paul Eggleton <paul.eggleton@linux.intel.com>
1.3	1.3.2	danny	1.16	Ross Burton <ross.burton@intel.com>

(Versions in grey above are no longer actively maintained, but well-tested patches may still be accepted for them.)

Policies

The primary focus for stable branches is bugfixing, security updates, and making sure that builds on recently released Ubuntu, Fedora, and OpenSUSE distros work. All other kinds of patches (e.g, performance improvements) have a high bar to reach for them to be accepted - i.e, it will have to be very clear they pose little risk to introducing more bugs or stability issues. Anything that breaks APIs or compatibility is not appropriate.

General policies:

• Fixes must go into master first unless they are applicable only to the stable branch; if back-porting to an older stable branch, the fix should first be applied to the newer stable branches before being back-ported to the older branch.
  • In order to help make it clear when this policy has been followed cover letters for stable pull requests must include information for each patch detailing whether it's a backport, which other branches require the fix and (equally as importantly) when appropriate why the patch isn't required in other maintained branches.
• All CVE (security) patches should be back-ported if at all possible, if a CVE fix is only appropriate to a stable branch the patch submission should detail why this is the case.
• 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>).

Requesting a fix in a stable branch

With reference to the above policies, if you would like to request a backport of a commit in a newer release, you can either (a) do the backport yourself and send the patch marked with [branchname] to the appropriate mailing list; or alternatively (b) you can send a simple request giving commit hashes / URLs that you would like to be backported. In both cases it helps to CC the maintainer - refer to the table above.

For information on which mailing list you should send these to see the README file in the Poky repository.

Maintainer 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 in the subject
2. Look through recently merged patches in master that are suitable for backporting
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 Stephen Jolley <stephen.k.jolley@intel.com> 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 Stephen Jolley <stephen.k.jolley@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 Stephen Jolley <stephen.k.jolley@intel.com> and he will present it.