Stable branch maintenance
From Yocto Project
Jump to navigationJump to search
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 |
|---|---|---|---|---|
| 3.2 | Dreaming | Gatesgarth | 1.48 | Richard Purdie <richard.purdie@linuxfoundation.org> |
| 3.1 | Dev | Dunfell | 1.46 | Richard Purdie <richard.purdie@linuxfoundation.org> |
| 3.0 | 3.0.0 | Zeus | 1.44 | Anju/Armin |
| 2.7 | 2.7.2 | Warrior | 1.42 | Armin Kuster <akuster808@gmail.com> |
| 2.6 | 2.6.4 | Thud | 1.40 | Armin Kuster <akuster808@gmail.com> |
| 2.5 | 2.5.3 | sumo | 1.38 | Armin Kuster <akuster808@gmail.com> |
| 2.4 | 2.4.4 | rocko | 1.36 | Armin Kuster <akuster808@gmail.com> |
| 2.3 | 2.3.4 | pyro | 1.34 | Armin Kuster <akuster808@gmail.com> |
| 2.2 | 2.2.4 | 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
Maintainer Procedures
Merge cycle
When there are enough changes (or a few critical ones), the stable branch maintainer should follow this procedure:
- Look out for patches on the mailing list marked with the stable branch name in the subject
- Look through recently merged patches in master that are suitable for backporting
- 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
- Run a local build or two to pick up any obvious problems
- 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.
- 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])
- 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.
- 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.
- 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 <sjolley.yp.pm@gmail.com> and CC: Ricard Purdie <richard.purdie@linuxfoundation.org> about scheduling point releases.
- Send a patch to update the stable version in meta-yocto/conf/distro/poky.conf for the release
- Once that is merged, ask Richard to run the release candidate build
- The stable branch maintainer should monitor the build and follow up on any failures
- When the release candidate build completes successfully, Branch Maintainer should notify the QA team to start the release QA process.
- Gather together changes in the form needed for a release notes and send them Yocto Project TSC to so she can incorporate them in final release notes and to Stephen Jolley <sjolley.yp.pm@gmail.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.
