|
|
| (30 intermediate revisions by 4 users not shown) |
| Line 1: |
Line 1: |
| The Yocto Project maintains stable branches of Poky (OE-Core and BitBake). Typically, alongside the latest release the previous two releases are also maintained.
| | Page deleted. All information found on [[Releases]]. |
| | |
| == Stable branch maintainers ==
| |
| | |
| {| class="wikitable"
| |
| ! 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>
| |
| |-style="color: slategray;"
| |
| | 2.5
| |
| | 2.5.3
| |
| | sumo
| |
| | 1.38
| |
| | Armin Kuster <akuster808@gmail.com>
| |
| |- style="color: slategray;"
| |
| | 2.4
| |
| | 2.4.4
| |
| | rocko
| |
| | 1.36
| |
| | Armin Kuster <akuster808@gmail.com>
| |
| |- style="color: slategray;"
| |
| |2.3
| |
| |2.3.4
| |
| |pyro
| |
| |1.34
| |
| |Armin Kuster <akuster808@gmail.com>
| |
| |- style="color: slategray;"
| |
| |2.2
| |
| |2.2.4
| |
| |morty
| |
| |1.32
| |
| |Armin Kuster <akuster808@gmail.com>
| |
| |- style="color: slategray;"
| |
| |2.1
| |
| |2.1.3
| |
| |krogoth
| |
| |1.30
| |
| |Armin Kuster <akuster808@gmail.com>
| |
| |- style="color: slategray;"
| |
| |2.0
| |
| |2.0.3
| |
| |jethro
| |
| |1.28
| |
| |Robert Yang <liezhi.yang@windriver.com>
| |
| |- style="color: slategray;"
| |
| |1.8
| |
| |1.8.2
| |
| |fido
| |
| |1.26
| |
| |Joshua Lock <joshua.g.lock@intel.com>
| |
| |- style="color: slategray;"
| |
| |1.7
| |
| |1.7.3
| |
| |dizzy
| |
| |1.24
| |
| |Armin Kuster <akuster808@gmail.com>
| |
| |- style="color: slategray;"
| |
| |1.6
| |
| |1.6.3
| |
| |daisy
| |
| |1.22
| |
| |Saul Wold <sgw@linux.intel.com>
| |
| |- style="color: slategray;"
| |
| |1.5
| |
| |1.5.4
| |
| |dora
| |
| |1.20
| |
| |Robert Yang <liezhi.yang@windriver.com>
| |
| |- style="color: slategray;"
| |
| |1.4
| |
| |1.4.3[http://lists.yoctoproject.org/pipermail/yocto/2014-July/020699.html *]
| |
| |dylan
| |
| |1.18
| |
| |Paul Eggleton <paul.eggleton@linux.intel.com>
| |
| |- style="color: slategray;"
| |
| |1.3
| |
| |1.3.2
| |
| |danny
| |
| |1.16
| |
| |Ross Burton <ross.burton@intel.com>
| |
| |- style="color: slategray;"
| |
| |}
| |
| | |
| (Versions in <font color="slategray">grey</font> above are no longer actively maintained, but well-tested patches may still be accepted for them.)
| |
| | |
| == Policies ==
| |
| | |
| == 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 <tt>[branchname]</tt> 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 [http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/README 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:
| |
| | |
| # 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.
| |
| | |
| === Kernel LTS ===
| |
| [https://wiki.yoctoproject.org/wiki/Linux_Yocto#Release_Cadence, Kernel cadence]
| |
| | |
| === Yocto LTS ===
| |
| [https://wiki.yoctoproject.org/wiki/LTS_Background, Yocto LTS]
| |
