Yocto Point-Release Development Workflow
Yocto 1.2, "denzil" was released on April 30, 2012. Work is now happening in parallel for 1.3 as well as the 1.2.1 point-release. This page describes some of the workflow/guidelines of what will go into the 1.2.1 release.
Scott Garman is the maintainer of the 1.2.1 release. His email is scott.a.garman@intel.com and he can be found on Freenode IRC as zenlinux in the #yocto, #poky, and #oe channels.
Git Branches
Scott is maintaining two git branches, one based on oe-core, and one based on poky:
http://git.openembedded.org/openembedded-core-contrib/log/?h=sgarman/denzil-next
http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=sgarman/denzil-next
Focus and Scope
The primary focus for getting patches into 1.2.1 is bugfixing, security updates, and making sure that recently released Ubuntu, Fedora, and OpenSUSE distros work with this release. All other kinds of patches (e.g, performance improvements) will have a very 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 off the table.
Please mention in your pull requests if you wish to have your commits included in the 1.2.1 release.
The intention is to include bugfixes for these bugs in the eventual release of 1.2.1:
This list is not set in stone and may change at any time.
Workflow
Scott will monitor the oe-core, poky, and yocto mailing lists for commits that are relevant for the 1.2.1 release (again, mentioning in a pull request that you want the pull's contents in 1.2.1 makes things much easier for him). After the commits get merged into oe-core master and/or poky master, Scott will add these commits to an sgarman/denzil-next-testing branch to run some basic build tests on. If the build tests pass, Scott will merge the commits to the corresponding sgarman/denzil-next branch(es).
Please be aware that sgarman/denzil-next and especially sgarman/denzil-next-testing can be rebased at any time.
Tips for Future Maintainers
This is a list of some things I found it helpful to do when preparing the 1.2.1 release that I recommend to future stable release maintainers:
Use only one working area to manage your git trees.
I started off by bouncing between my laptop and desktop system when merging commits, and this was a disaster - it was too difficult to keep track of which branches on which system were up to date vs. the remote git repos. After switching to one work area, I managed to get this under control.
Likewise, keep a single text file or some other reminder system to track the state of your branches and commits to watch for.
I had to regularly comb through the commits in oe-core and poky master to make sure I wasn't missing potentially important commits. I kept a text file with the shortlog of the last commit I had researched to help make sure I wasn't missing any commits or re-reviewing the same ones. This text file also kept track of commit titles that came in to the mailing lists that were intended for 1.2.1 that were not yet in master, as a reminder of what I could expect to merge soon. Finally, this text file included a Release Notes section for me to make notes of things I would need to eventually include in the final Release Notes for 1.2.1.
Testing
Building our reference images (core-image-minimal and core-image-sato) for all five of our QEMU architectures is the most basic testing that needs to be done on an ongoing basis (ideally, nightly) with the sgarman/denzil-next branches. Additionally, the following use cases also need to be exercised on a regular basis (i.e, weekly):
- non-GPLv3 builds
- poky-tiny distro builds
- ADT installer builds
- meta-qt3
Schedule
The goal is for a release candidate to be ready for 1.2.1 approximately 6-8 weeks after the release of 1.2.
