Yocto Point-Release Development Workflow: Difference between revisions

From Yocto Project
Jump to navigationJump to search
No edit summary
 
(12 intermediate revisions by the same user not shown)
Line 25: Line 25:
== Workflow ==
== Workflow ==


Scott will monitor the oe-core and poky/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).
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.
Please be aware that sgarman/denzil-next and especially sgarman/denzil-next-testing can be rebased at any time.


== Schedule ==
==== 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.


The goal is for a release candidate to be ready for 1.2.1 approximately 6-8 weeks after the release of 1.2.
Likewise, keep a single text file or some other reminder system to track the state of your branches and commits to watch for.


== 1.2.1 Bug Status Summary ==
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.


=== 1.2.1 Bugfixes, oe-core ===
== Testing ==


Note that all of these fixes are also applied to the [http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=sgarman/denzil-next poky-based sgarman/denzil-next branch].
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):


* [https://bugzilla.yoctoproject.org/show_bug.cgi?id=1858 1858]: Fixed with [http://git.openembedded.org/openembedded-core-contrib/commit/?h=sgarman/denzil-next&id=b1c28667592e736115ab5e603a12c2723b939cf2 b1c28667592e736115ab5e603a12c2723b939cf2]
* non-GPLv3 builds
* [https://bugzilla.yoctoproject.org/show_bug.cgi?id=1906 1906]: Fix was included in 1.2
* poky-tiny distro builds
* [https://bugzilla.yoctoproject.org/show_bug.cgi?id=2344 2344]: Resolved as NOTABUG
* ADT installer builds
* [https://bugzilla.yoctoproject.org/show_bug.cgi?id=2352 2352]: Fixed with [http://git.openembedded.org/openembedded-core-contrib/commit/?h=sgarman/denzil-next&id=6e2235a4d769b16ebf68d6bbed56d8bcc0e0c83f 6e2235a4d769b16ebf68d6bbed56d8bcc0e0c83f]
* meta-qt3
* [https://bugzilla.yoctoproject.org/show_bug.cgi?id=2362 2362]: Fix was included in 1.2
* [https://bugzilla.yoctoproject.org/show_bug.cgi?id=2368 2368]: Fixed with [http://git.openembedded.org/openembedded-core-contrib/commit/?h=sgarman/denzil-next&id=51a122a5593c62d7ffd07f860e54a2fb0327959c 51a122a5593c62d7ffd07f860e54a2fb0327959c]


=== 1.2.1 Bugfixes, poky ===
== Schedule ==


* [https://bugzilla.yoctoproject.org/show_bug.cgi?id=1892 1892]: Fix was included in 1.2
The goal is for a release candidate to be ready for 1.2.1 approximately 6-8 weeks after the release of 1.2.
* [https://bugzilla.yoctoproject.org/show_bug.cgi?id=1912 1912]: Fix was included in 1.2
* [https://bugzilla.yoctoproject.org/show_bug.cgi?id=2173 2173]: Fix was an external web site, no code commits needed
* [https://bugzilla.yoctoproject.org/show_bug.cgi?id=2219 2219]: Fixed with [http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=sgarman/denzil-next&id=43262f39cc6f493e33fadca0c67d8f421868e0ba 43262f39cc6f493e33fadca0c67d8f421868e0ba]
* [https://bugzilla.yoctoproject.org/show_bug.cgi?id=2330 2330]: Fixed with [http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=sgarman/denzil-next&id=166ab724c5c427f5a15fa7c5324aef71895bdfc2 166ab724c5c427f5a15fa7c5324aef71895bdfc2]
* [https://bugzilla.yoctoproject.org/show_bug.cgi?id=2337 2337]: Resolved as a duplicate
* [https://bugzilla.yoctoproject.org/show_bug.cgi?id=2366 2366]: Fixed with [http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=sgarman/denzil-next&id=5aa69ed4aaa617351f7277f922eb2b1b3f34aafc 5aa69ed4aaa617351f7277f922eb2b1b3f34aafc]
* [https://bugzilla.yoctoproject.org/show_bug.cgi?id=2371 2371]: Fixed with [http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=sgarman/denzil-next&id=2fc4b06a68beb2fa1eb923894ddf452bb899c35b 2fc4b06a68beb2fa1eb923894ddf452bb899c35b]

Latest revision as of 18:29, 22 June 2012

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:

https://bugzilla.yoctoproject.org/buglist.cgi?query_format=advanced&list_id=4572&bug_status=NEW&bug_status=ACCEPTED&bug_status=REOPENED&bug_status=NEEDINFO&bug_status=WaitForUpstream&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&target_milestone=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.