Yocto Project - User contributions [en]

How do I

2012-04-19T19:18:15Z

Scottrifw: /* Q: How do I tweak my build system and BitBake configuration for optimal build time as well as provide some guidance on how to collect build metrics and identify bottlenecks. ? */

== Q: How do get the package manager binaries on my target rootfs? ==

'''A:''' Make sure your image has IMAGE_FEATURES += "package-management" included.

== Q: How do I create my own source download mirror ? ==

'''A:'''
Make a complete build with these variables set in your local.conf.

SOURCE_MIRROR_URL ?= "file://source_mirror/sources/"

INHERIT += "own-mirrors"

BB_GENERATE_MIRROR_TARBALLS = "1"

After a complete build, copy all _files_(not symlinks) in your download directory to the desired source mirror directory
Test by setting variables below in local.conf
SOURCE_MIRROR_URL ?= "file://source_mirror/sources/"

INHERIT += "own-mirrors"

BB_GENERATE_MIRROR_TARBALLS = "1"

BB_NO_NETWORK = "1"

== Q: How do I put Yocto on a hard drive? ==

'''A:''' bitbake core-image-sato or core-image-sato-sdk

# have a suitable partition on the disk - say partition #3
# this partition will show up as sde3 on my host machine and sda3 on the atom
# mkfs.ext3 /dev/sde3
# mount /dev/sde3 /mnt/target
# mount -o loop tmp/deploy/images/core-image-sato-sdk.ext3 /mnt/target-ext3
# cp -a /mnt/target-ext3/* /mnt/target
# grub-install --recheck --root-directory=/mnt/target /dev/sde

If grub install passed, copy the following to /mnt/target/boot/grub/grub.cfg

set default="0"
set timeout="30"

menuentry 'Yocto SDK' {
insmod part_msdos
insmod ext2
set root='(hd0,msdos3)'
linux /boot/bzImage root=/dev/sda3
}

Thats it - this should boot.

== Q: How do I put my recipe into Yocto? ==

'''A:''' Let's use the Hello World example from Section 3.1.2 of the Yocto Project Reference Manual and expand on it.

* In this example, I'll start with a new meta layer named "meta-jfa" in the Yocto Project files directory, which is named "poky". Then, I will add the new recipe and build the image, which is named "core-image-minimal". I will build it using the autotooled package option. Once built, the image will have the “hello” application.

;Step One
:Create the following directory structure in the ~/poky directory. I'll use my initials to denote the layer and recipe name:

mkdir meta-jfa
mkdir meta-jfa/conf
mkdir meta-jfa/recipes-jfa
mkdir meta-jfa/recipes-jfa/hello

;Step Two
:Next, to make sure the recipe gets searched and located, I'll create the layer.conf file in the meta-jfa/conf directory as follows:

# We have a conf and classes directory, add to BBPATH
BBPATH := "${BBPATH}:${LAYERDIR}"
# We have a packages directory, add to BBFILES
BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \
${LAYERDIR}/recipes-*/*/*.bbappend"
BBFILE_COLLECTIONS += "jfa"
BBFILE_PATTERN_jfa := "^${LAYERDIR}/"
BBFILE_PRIORITY_jfa = "5

;Step Three
:Now I need to put the recipe (.bb) file into the right directory. So, I will put the file hello_2.7.bb into the meta-jfa/recipes-jfa/hello directory. I picked version 2.7 of the hello program by going to the gnu site for the application (ftp://ftp.gnu.org/gnu/hello/) and downloading it to checkout the version I wanted to include. hello-2.7.tar.gz is the most current. I downloaded it locally and expanded it to look at the license information. The hello_2.7.bb file contains the following:

DESCRIPTION = "GNU Helloworld application"
SECTION = "examples"
LICENSE = "GPLv3+"
LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504"
PR = "r0"
SRC_URI = "${GNU_MIRROR}/hello/hello-${PV}.tar.gz"
inherit autotools gettext
:Here is some explanation for a few of the recipe statements:
:* LIC_FILES_CHKSUM = is required and, using file location defaults, points to the COPYING file that is part of the tarball that is downloaded from the SRC_URI address. The md5= part of the statement is generated by running “md5sum COPYING” against the COPYING file I downloaded to examine.
:* ${PV} in the SRC_URI statement is picked up from the part of the recipe file name after the “_”. In this case PV =2.7.

;Step Four
:The recipe is built, so now I can run it:

cd ~/poky
source oe-init-build-env build-hello.

;Step Five
:Before I can use BitBake I need to edit two files. Sourcing the oe-init-build-env file above leaves me in the build-hello directory. Before issuing the bitbake command I need to edit the files conf/local.conf and conf/bblayers.conf in that build-hello directory. The bblayers.conf needs to have the one line added to include the layer you created.

# LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf
# changes incompatibly
LCONF_VERSION = "4"
BBFILES ?= ""
BBLAYERS = " \
/home/jim/poky/meta \
/home/jim/poky/meta-yocto \
/home/jim/poky/meta-jfa \
"

;Step Six
:The conf/local.conf file needs to have the parallel processing lines edited to speed up the baking on multicore systems. I can do that by uncommenting the BB_NUMBER_THREADS and PARALLEL_MAKE variables. Generally, I would set them equal to twice the number of cores used by my host machine. By default, the MACHINE variable is set to qemux86 and for this example is fine. I need to add a line to include the hello package I am building into the image by adding the following line:

POKY_EXTRA_INSTALL += "hello"

;Step Seven
:Now I can bake it with this command:
bitbake core-image-minimal
;Step Eight
:Once the image is built, I can test it by starting the QEMU emulator:

runqemu qemux86

;Step Nine
:Once the emulator comes up, login as root with no password. Then, at the prompt, enter "hello" to run your application.

==Q: How do I setup Intel® Atom™ Processor E6xx based system for media playback? ==

'''A:''' To playback media files on an Atom E6xx processor, you need to have the EMGD GFX driver installed. There is a README on this installation in the meta-crownbay directory. However, the official support for EMGD with accelerated 3D and media decode is scheduled for release 1.2, but is in the git repository now, so you need to start with branch, "master" of both the poky and meta-intel repository. And you will need the Intel Crownbay reference platform for the Atom E6xx processor or similar hardware.

; Step 1
Follow the Appendix A example in the Yocto Project Development Manual, but instead of editing out the crownbay references and using the crownbay-noemgd, you do the opposite.

One edit you need to add to the Appendix A instructions is for the file ~/poky/meta-intel/meta-mymachine/conf/mymachine.conf. You need to add the following statement to include audio features needed for the audio part of the videos:
MACHINE_FEATURES += "alsa"

; Step 2
In the Appendix A example a couple of changes are needed to the conf/local.conf and conf/bblayers.conf file edits from the standard example. The bblayers.conf file BBLAYERS statement should look like below, except correct the absolute path to match your system:
BBLAYERS ?= " \
/home/jim/poky/meta \
/home/jim/poky/meta-yocto \
/home/jim/poky/meta-intel \
/home/jim/poky/meta-intel/meta-mymachine \
"
The local.conf file should have some statements in addition to what the Appendix A used:
LICENSE_FLAGS_WHITELIST = "license_emgd-driver-bin_1.10"

# The 2 statements below allow the playing of MP3 files.
# Not specific to videos, but usually included on media use systems.
LICENSE_FLAGS_WHITELIST += "commercial"
POKY_EXTRA_INSTALL += "gst-fluendo-mp3"

# add debug development tweaks and test applications, which include amixer, aplay, arecord, etc.
EXTRA_IMAGE_FEATURES = "debug-tweaks tools-testapps"
; Step 3
After bitbaking the core-image-sato image, I put the .ext3 image on a hard drive per the above How Do I. I also added some h.264, mp4, m4a, and mp3 files to play with before moving the hard drive to the target hardware system.

I used both the Sato GUI Music and Video players to play the files.

That's all there is to it.

==Q: How do I tweak my build system and BitBake configuration for optimal build time as well as provide some guidance on how to collect build metrics and identify bottlenecks. ? ==

'''A:''' You should read the [https://wiki.yoctoproject.org/wiki/Build_Performance Build Performance] wiki page. It provides general tips, a description of the bb-matrix script used for collecting relevant build metrics, a description of how to enable buildstats to generate build performance log data, and a description of how best to apply parallelism to the build.

How do I

2012-04-19T19:17:48Z

Scottrifw: /* Q: How do I tweak my build system and BitBake configuration for optimal build time as well as provide some guidance on how to collect build metrics and identify bottlenecks. ? */

== Q: How do get the package manager binaries on my target rootfs? ==

'''A:''' Make sure your image has IMAGE_FEATURES += "package-management" included.

== Q: How do I create my own source download mirror ? ==

'''A:'''
Make a complete build with these variables set in your local.conf.

SOURCE_MIRROR_URL ?= "file://source_mirror/sources/"

INHERIT += "own-mirrors"

BB_GENERATE_MIRROR_TARBALLS = "1"

After a complete build, copy all _files_(not symlinks) in your download directory to the desired source mirror directory
Test by setting variables below in local.conf
SOURCE_MIRROR_URL ?= "file://source_mirror/sources/"

INHERIT += "own-mirrors"

BB_GENERATE_MIRROR_TARBALLS = "1"

BB_NO_NETWORK = "1"

== Q: How do I put Yocto on a hard drive? ==

'''A:''' bitbake core-image-sato or core-image-sato-sdk

# have a suitable partition on the disk - say partition #3
# this partition will show up as sde3 on my host machine and sda3 on the atom
# mkfs.ext3 /dev/sde3
# mount /dev/sde3 /mnt/target
# mount -o loop tmp/deploy/images/core-image-sato-sdk.ext3 /mnt/target-ext3
# cp -a /mnt/target-ext3/* /mnt/target
# grub-install --recheck --root-directory=/mnt/target /dev/sde

If grub install passed, copy the following to /mnt/target/boot/grub/grub.cfg

set default="0"
set timeout="30"

menuentry 'Yocto SDK' {
insmod part_msdos
insmod ext2
set root='(hd0,msdos3)'
linux /boot/bzImage root=/dev/sda3
}

Thats it - this should boot.

== Q: How do I put my recipe into Yocto? ==

'''A:''' Let's use the Hello World example from Section 3.1.2 of the Yocto Project Reference Manual and expand on it.

* In this example, I'll start with a new meta layer named "meta-jfa" in the Yocto Project files directory, which is named "poky". Then, I will add the new recipe and build the image, which is named "core-image-minimal". I will build it using the autotooled package option. Once built, the image will have the “hello” application.

;Step One
:Create the following directory structure in the ~/poky directory. I'll use my initials to denote the layer and recipe name:

mkdir meta-jfa
mkdir meta-jfa/conf
mkdir meta-jfa/recipes-jfa
mkdir meta-jfa/recipes-jfa/hello

;Step Two
:Next, to make sure the recipe gets searched and located, I'll create the layer.conf file in the meta-jfa/conf directory as follows:

# We have a conf and classes directory, add to BBPATH
BBPATH := "${BBPATH}:${LAYERDIR}"
# We have a packages directory, add to BBFILES
BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \
${LAYERDIR}/recipes-*/*/*.bbappend"
BBFILE_COLLECTIONS += "jfa"
BBFILE_PATTERN_jfa := "^${LAYERDIR}/"
BBFILE_PRIORITY_jfa = "5

;Step Three
:Now I need to put the recipe (.bb) file into the right directory. So, I will put the file hello_2.7.bb into the meta-jfa/recipes-jfa/hello directory. I picked version 2.7 of the hello program by going to the gnu site for the application (ftp://ftp.gnu.org/gnu/hello/) and downloading it to checkout the version I wanted to include. hello-2.7.tar.gz is the most current. I downloaded it locally and expanded it to look at the license information. The hello_2.7.bb file contains the following:

DESCRIPTION = "GNU Helloworld application"
SECTION = "examples"
LICENSE = "GPLv3+"
LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504"
PR = "r0"
SRC_URI = "${GNU_MIRROR}/hello/hello-${PV}.tar.gz"
inherit autotools gettext
:Here is some explanation for a few of the recipe statements:
:* LIC_FILES_CHKSUM = is required and, using file location defaults, points to the COPYING file that is part of the tarball that is downloaded from the SRC_URI address. The md5= part of the statement is generated by running “md5sum COPYING” against the COPYING file I downloaded to examine.
:* ${PV} in the SRC_URI statement is picked up from the part of the recipe file name after the “_”. In this case PV =2.7.

;Step Four
:The recipe is built, so now I can run it:

cd ~/poky
source oe-init-build-env build-hello.

;Step Five
:Before I can use BitBake I need to edit two files. Sourcing the oe-init-build-env file above leaves me in the build-hello directory. Before issuing the bitbake command I need to edit the files conf/local.conf and conf/bblayers.conf in that build-hello directory. The bblayers.conf needs to have the one line added to include the layer you created.

# LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf
# changes incompatibly
LCONF_VERSION = "4"
BBFILES ?= ""
BBLAYERS = " \
/home/jim/poky/meta \
/home/jim/poky/meta-yocto \
/home/jim/poky/meta-jfa \
"

;Step Six
:The conf/local.conf file needs to have the parallel processing lines edited to speed up the baking on multicore systems. I can do that by uncommenting the BB_NUMBER_THREADS and PARALLEL_MAKE variables. Generally, I would set them equal to twice the number of cores used by my host machine. By default, the MACHINE variable is set to qemux86 and for this example is fine. I need to add a line to include the hello package I am building into the image by adding the following line:

POKY_EXTRA_INSTALL += "hello"

;Step Seven
:Now I can bake it with this command:
bitbake core-image-minimal
;Step Eight
:Once the image is built, I can test it by starting the QEMU emulator:

runqemu qemux86

;Step Nine
:Once the emulator comes up, login as root with no password. Then, at the prompt, enter "hello" to run your application.

==Q: How do I setup Intel® Atom™ Processor E6xx based system for media playback? ==

'''A:''' To playback media files on an Atom E6xx processor, you need to have the EMGD GFX driver installed. There is a README on this installation in the meta-crownbay directory. However, the official support for EMGD with accelerated 3D and media decode is scheduled for release 1.2, but is in the git repository now, so you need to start with branch, "master" of both the poky and meta-intel repository. And you will need the Intel Crownbay reference platform for the Atom E6xx processor or similar hardware.

; Step 1
Follow the Appendix A example in the Yocto Project Development Manual, but instead of editing out the crownbay references and using the crownbay-noemgd, you do the opposite.

One edit you need to add to the Appendix A instructions is for the file ~/poky/meta-intel/meta-mymachine/conf/mymachine.conf. You need to add the following statement to include audio features needed for the audio part of the videos:
MACHINE_FEATURES += "alsa"

; Step 2
In the Appendix A example a couple of changes are needed to the conf/local.conf and conf/bblayers.conf file edits from the standard example. The bblayers.conf file BBLAYERS statement should look like below, except correct the absolute path to match your system:
BBLAYERS ?= " \
/home/jim/poky/meta \
/home/jim/poky/meta-yocto \
/home/jim/poky/meta-intel \
/home/jim/poky/meta-intel/meta-mymachine \
"
The local.conf file should have some statements in addition to what the Appendix A used:
LICENSE_FLAGS_WHITELIST = "license_emgd-driver-bin_1.10"

# The 2 statements below allow the playing of MP3 files.
# Not specific to videos, but usually included on media use systems.
LICENSE_FLAGS_WHITELIST += "commercial"
POKY_EXTRA_INSTALL += "gst-fluendo-mp3"

# add debug development tweaks and test applications, which include amixer, aplay, arecord, etc.
EXTRA_IMAGE_FEATURES = "debug-tweaks tools-testapps"
; Step 3
After bitbaking the core-image-sato image, I put the .ext3 image on a hard drive per the above How Do I. I also added some h.264, mp4, m4a, and mp3 files to play with before moving the hard drive to the target hardware system.

I used both the Sato GUI Music and Video players to play the files.

That's all there is to it.

==Q: How do I tweak my build system and BitBake configuration for optimal build time as well as provide some guidance on how to collect build metrics and identify bottlenecks. ? ==

'''A:''' You should read the [https://wiki.yoctoproject.org/wiki/Build_Performance] wiki page. It provides general tips, a description of the bb-matrix script used for collecting relevant build metrics, a description of how to enable buildstats to generate build performance log data, and a description of how best to apply parallelism to the build.

How do I

2012-04-19T19:13:47Z

Scottrifw:

== Q: How do get the package manager binaries on my target rootfs? ==

'''A:''' Make sure your image has IMAGE_FEATURES += "package-management" included.

== Q: How do I create my own source download mirror ? ==

'''A:'''
Make a complete build with these variables set in your local.conf.

SOURCE_MIRROR_URL ?= "file://source_mirror/sources/"

INHERIT += "own-mirrors"

BB_GENERATE_MIRROR_TARBALLS = "1"

After a complete build, copy all _files_(not symlinks) in your download directory to the desired source mirror directory
Test by setting variables below in local.conf
SOURCE_MIRROR_URL ?= "file://source_mirror/sources/"

INHERIT += "own-mirrors"

BB_GENERATE_MIRROR_TARBALLS = "1"

BB_NO_NETWORK = "1"

== Q: How do I put Yocto on a hard drive? ==

'''A:''' bitbake core-image-sato or core-image-sato-sdk

# have a suitable partition on the disk - say partition #3
# this partition will show up as sde3 on my host machine and sda3 on the atom
# mkfs.ext3 /dev/sde3
# mount /dev/sde3 /mnt/target
# mount -o loop tmp/deploy/images/core-image-sato-sdk.ext3 /mnt/target-ext3
# cp -a /mnt/target-ext3/* /mnt/target
# grub-install --recheck --root-directory=/mnt/target /dev/sde

If grub install passed, copy the following to /mnt/target/boot/grub/grub.cfg

set default="0"
set timeout="30"

menuentry 'Yocto SDK' {
insmod part_msdos
insmod ext2
set root='(hd0,msdos3)'
linux /boot/bzImage root=/dev/sda3
}

Thats it - this should boot.

== Q: How do I put my recipe into Yocto? ==

'''A:''' Let's use the Hello World example from Section 3.1.2 of the Yocto Project Reference Manual and expand on it.

* In this example, I'll start with a new meta layer named "meta-jfa" in the Yocto Project files directory, which is named "poky". Then, I will add the new recipe and build the image, which is named "core-image-minimal". I will build it using the autotooled package option. Once built, the image will have the “hello” application.

;Step One
:Create the following directory structure in the ~/poky directory. I'll use my initials to denote the layer and recipe name:

mkdir meta-jfa
mkdir meta-jfa/conf
mkdir meta-jfa/recipes-jfa
mkdir meta-jfa/recipes-jfa/hello

;Step Two
:Next, to make sure the recipe gets searched and located, I'll create the layer.conf file in the meta-jfa/conf directory as follows:

# We have a conf and classes directory, add to BBPATH
BBPATH := "${BBPATH}:${LAYERDIR}"
# We have a packages directory, add to BBFILES
BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \
${LAYERDIR}/recipes-*/*/*.bbappend"
BBFILE_COLLECTIONS += "jfa"
BBFILE_PATTERN_jfa := "^${LAYERDIR}/"
BBFILE_PRIORITY_jfa = "5

;Step Three
:Now I need to put the recipe (.bb) file into the right directory. So, I will put the file hello_2.7.bb into the meta-jfa/recipes-jfa/hello directory. I picked version 2.7 of the hello program by going to the gnu site for the application (ftp://ftp.gnu.org/gnu/hello/) and downloading it to checkout the version I wanted to include. hello-2.7.tar.gz is the most current. I downloaded it locally and expanded it to look at the license information. The hello_2.7.bb file contains the following:

DESCRIPTION = "GNU Helloworld application"
SECTION = "examples"
LICENSE = "GPLv3+"
LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504"
PR = "r0"
SRC_URI = "${GNU_MIRROR}/hello/hello-${PV}.tar.gz"
inherit autotools gettext
:Here is some explanation for a few of the recipe statements:
:* LIC_FILES_CHKSUM = is required and, using file location defaults, points to the COPYING file that is part of the tarball that is downloaded from the SRC_URI address. The md5= part of the statement is generated by running “md5sum COPYING” against the COPYING file I downloaded to examine.
:* ${PV} in the SRC_URI statement is picked up from the part of the recipe file name after the “_”. In this case PV =2.7.

;Step Four
:The recipe is built, so now I can run it:

cd ~/poky
source oe-init-build-env build-hello.

;Step Five
:Before I can use BitBake I need to edit two files. Sourcing the oe-init-build-env file above leaves me in the build-hello directory. Before issuing the bitbake command I need to edit the files conf/local.conf and conf/bblayers.conf in that build-hello directory. The bblayers.conf needs to have the one line added to include the layer you created.

# LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf
# changes incompatibly
LCONF_VERSION = "4"
BBFILES ?= ""
BBLAYERS = " \
/home/jim/poky/meta \
/home/jim/poky/meta-yocto \
/home/jim/poky/meta-jfa \
"

;Step Six
:The conf/local.conf file needs to have the parallel processing lines edited to speed up the baking on multicore systems. I can do that by uncommenting the BB_NUMBER_THREADS and PARALLEL_MAKE variables. Generally, I would set them equal to twice the number of cores used by my host machine. By default, the MACHINE variable is set to qemux86 and for this example is fine. I need to add a line to include the hello package I am building into the image by adding the following line:

POKY_EXTRA_INSTALL += "hello"

;Step Seven
:Now I can bake it with this command:
bitbake core-image-minimal
;Step Eight
:Once the image is built, I can test it by starting the QEMU emulator:

runqemu qemux86

;Step Nine
:Once the emulator comes up, login as root with no password. Then, at the prompt, enter "hello" to run your application.

==Q: How do I setup Intel® Atom™ Processor E6xx based system for media playback? ==

'''A:''' To playback media files on an Atom E6xx processor, you need to have the EMGD GFX driver installed. There is a README on this installation in the meta-crownbay directory. However, the official support for EMGD with accelerated 3D and media decode is scheduled for release 1.2, but is in the git repository now, so you need to start with branch, "master" of both the poky and meta-intel repository. And you will need the Intel Crownbay reference platform for the Atom E6xx processor or similar hardware.

; Step 1
Follow the Appendix A example in the Yocto Project Development Manual, but instead of editing out the crownbay references and using the crownbay-noemgd, you do the opposite.

One edit you need to add to the Appendix A instructions is for the file ~/poky/meta-intel/meta-mymachine/conf/mymachine.conf. You need to add the following statement to include audio features needed for the audio part of the videos:
MACHINE_FEATURES += "alsa"

; Step 2
In the Appendix A example a couple of changes are needed to the conf/local.conf and conf/bblayers.conf file edits from the standard example. The bblayers.conf file BBLAYERS statement should look like below, except correct the absolute path to match your system:
BBLAYERS ?= " \
/home/jim/poky/meta \
/home/jim/poky/meta-yocto \
/home/jim/poky/meta-intel \
/home/jim/poky/meta-intel/meta-mymachine \
"
The local.conf file should have some statements in addition to what the Appendix A used:
LICENSE_FLAGS_WHITELIST = "license_emgd-driver-bin_1.10"

# The 2 statements below allow the playing of MP3 files.
# Not specific to videos, but usually included on media use systems.
LICENSE_FLAGS_WHITELIST += "commercial"
POKY_EXTRA_INSTALL += "gst-fluendo-mp3"

# add debug development tweaks and test applications, which include amixer, aplay, arecord, etc.
EXTRA_IMAGE_FEATURES = "debug-tweaks tools-testapps"
; Step 3
After bitbaking the core-image-sato image, I put the .ext3 image on a hard drive per the above How Do I. I also added some h.264, mp4, m4a, and mp3 files to play with before moving the hard drive to the target hardware system.

I used both the Sato GUI Music and Video players to play the files.

That's all there is to it.

==Q: How do I tweak my build system and BitBake configuration for optimal build time as well as provide some guidance on how to collect build metrics and identify bottlenecks. ? ==

'''A:''' You should read the [Build Performance][https://wiki.yoctoproject.org/wiki/Build_Performance] wiki page. It provides general tips, a description of the bb-matrix script used for collecting relevant build metrics, a description of how to enable buildstats to generate build performance log data, and a description of how best to apply parallelism to the build.

How do I

2012-01-27T17:39:12Z

Scottrifw:

'''Q: How do I put yocto on a hard drive?'''

'''A:''' bitbake core-image-sato or core-image-sato-sdk

# have a suitable partition on the disk - say partition #3
# this partition will show up as sde3 on my host machine and sda3 on the atom
# mkfs.ext3 /dev/sde3
# mount /dev/sde3 /mnt/target
# mount -o loop tmp/deploy/images/core-image-sato-sdk.ext3 /mnt/target-ext3
# cp -a /mnt/target-ext3/* /mnt/target
# grub-install --recheck --root-directory=/mnt/target /dev/sde

If grub install passed, copy the following to /mnt/target/boot/grub/grub.cfg

set default="0"
set timeout="30"

menuentry 'Yocto SDK' {
insmod part_msdos
insmod ext2
set root='(hd0,msdos3)'
linux /boot/bzImage root=/dev/sda3
}

Thats it - this should boot.

'''Q: How do I put my recipe into Yocto? '''

'''A:''' Let's use the Hello World example from Section 3.1.2 of the Yocto Project Reference Manual and expand on it.

* In this example, I'll start with a new meta layer named "meta-jfa" in the Yocto Project files directory, which is named "poky". Then, I will add the new recipe and build the image, which is named "core-image-minimal". I will build it using the autotooled package option. Once built, the image will have the “hello” application.

;Step One
:Create the following directory structure in the ~/poky directory. I'll use my initials to denote the layer and recipe name:

mkdir meta-jfa
mkdir meta-jfa/conf
mkdir meta-jfa/recipes-jfa
mkdir meta-jfa/recipes-jfa/hello

;Step Two
:Next, to make sure the recipe gets searched and located, I'll create the layer.conf file in the meta-jfa/conf directory as follows:

# We have a conf and classes directory, add to BBPATH
BBPATH := "${BBPATH}:${LAYERDIR}"
# We have a packages directory, add to BBFILES
BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \
${LAYERDIR}/recipes-*/*/*.bbappend"
BBFILE_COLLECTIONS += "jfa"
BBFILE_PATTERN_jfa := "^${LAYERDIR}/"
BBFILE_PRIORITY_jfa = "5

;Step Three
:Now I need to put the recipe (.bb) file into the right directory. So, I will put the file hello_2.7.bb into the meta-jfa/recipes-jfa/hello directory. I picked version 2.7 of the hello program by going to the gnu site for the application (ftp://ftp.gnu.org/gnu/hello/) and downloading it to checkout the version I wanted to include. hello-2.7.tar.gz is the most current. I downloaded it locally and expanded it to look at the license information. The hello_2.7.bb file contains the following:

DESCRIPTION = "GNU Helloworld application"
SECTION = "examples"
LICENSE = "GPLv3+"
LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504"
PR = "r0"
SRC_URI = "${GNU_MIRROR}/hello/hello-${PV}.tar.gz"
inherit autotools gettext
:Here is some explanation for a few of the recipe statements:
:* LIC_FILES_CHKSUM = is required and, using file location defaults, points to the COPYING file that is part of the tarball that is downloaded from the SRC_URI address. The md5= part of the statement is generated by running “md5sum COPYING” against the COPYING file I downloaded to examine.
:* ${PV} in the SRC_URI statement is picked up from the part of the recipe file name after the “_”. In this case PV =2.7.

;Step Four
:The recipe is built, so now I can run it:

cd ~/poky
source oe-init-build-env build-hello.

;Step Five
:Before I can use BitBake I need to edit two files. Sourcing the oe-init-build-env file above leaves me in the build-hello directory. Before issuing the bitbake command I need to edit the files conf/local.conf and conf/bblayers.conf in that build-hello directory. The bblayers.conf needs to have the one line added to include the layer you created.

# LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf
# changes incompatibly
LCONF_VERSION = "4"
BBFILES ?= ""
BBLAYERS = " \
/home/jim/poky/meta \
/home/jim/poky/meta-yocto \
/home/jim/poky/meta-jfa \
"

;Step Six
:The conf/local.conf file needs to have the parallel processing lines edited to speed up the baking on multicore systems. I can do that by uncommenting the BB_NUMBER_THREADS and PARALLEL_MAKE variables. Generally, I would set them equal to twice the number of cores used by my host machine. By default, the MACHINE variable is set to qemux86 and for this example is fine. I need to add a line to include the hello package I am building into the image by adding the following line:

POKY_EXTRA_INSTALL += "hello"

;Step Seven
:Now I can bake it with this command:
bitbake core-image-minimal
;Step Eight
:Once the image is built, I can test it by starting the QEMU emulator:

runqemu qemux86

;Step Nine
:Once the emulator comes up, login as root with no password. Then, at the prompt, enter "hello" to run your application.

How do I

2012-01-27T17:34:49Z

Scottrifw:

'''Q: How do I put yocto on a hard drive?'''

'''A:''' bitbake core-image-sato or core-image-sato-sdk

# have a suitable partition on the disk - say partition #3
# this partition will show up as sde3 on my host machine and sda3 on the atom
# mkfs.ext3 /dev/sde3
# mount /dev/sde3 /mnt/target
# mount -o loop tmp/deploy/images/core-image-sato-sdk.ext3 /mnt/target-ext3
# cp -a /mnt/target-ext3/* /mnt/target
# grub-install --recheck --root-directory=/mnt/target /dev/sde

If grub install passed, copy the following to /mnt/target/boot/grub/grub.cfg

set default="0"
set timeout="30"

menuentry 'Yocto SDK' {
insmod part_msdos
insmod ext2
set root='(hd0,msdos3)'
linux /boot/bzImage root=/dev/sda3
}

Thats it - this should boot.

'''Q: How do I put my recipe into Yocto? '''

'''A:''' Let's use the Hello World example from Section 3.1.2 of the Yocto Project Reference Manual and expand on it.

* In this example, I'll start with a new meta layer named "meta-jfa" in the Yocto Project files directory, which is named "poky". Then, I will add the new recipe and build the image, which is named "core-image-minimal". I will build it using the autotooled package option. Once built, the image will have the “hello” application.

;Step One
:Create the following directory structure in the ~/poky directory. I'll use my initials to denote the layer and recipe name:

mkdir meta-jfa
mkdir meta-jfa/conf
mkdir meta-jfa/recipes-jfa
mkdir meta-jfa/recipes-jfa/hello

;Step Two
:Next, to make sure the recipe gets searched and located, I'll create the layer.conf file in the meta-jfa/conf directory as follows:

# We have a conf and classes directory, add to BBPATH
BBPATH := "${BBPATH}:${LAYERDIR}"
# We have a packages directory, add to BBFILES
BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \
${LAYERDIR}/recipes-*/*/*.bbappend"
BBFILE_COLLECTIONS += "jfa"
BBFILE_PATTERN_jfa := "^${LAYERDIR}/"
BBFILE_PRIORITY_jfa = "5

# Now I need to put the recipe (.bb) file into the right directory. So, I will put the file hello_2.7.bb into the meta-jfa/recipes-jfa/hello directory. I picked version 2.7 of the hello program by going to the gnu site for the application (ftp://ftp.gnu.org/gnu/hello/) and downloading it to checkout the version I wanted to include. hello-2.7.tar.gz is the most current. I downloaded it locally and expanded it to look at the license information. The hello_2.7.bb file contains the following:

DESCRIPTION = "GNU Helloworld application"
SECTION = "examples"
LICENSE = "GPLv3+"
LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504"
PR = "r0"
SRC_URI = "${GNU_MIRROR}/hello/hello-${PV}.tar.gz"
inherit autotools gettext
* Here is some explanation for a few of the recipe statements:
** LIC_FILES_CHKSUM = is required and, using file location defaults, points to the COPYING file that is part of the tarball that is downloaded from the SRC_URI address. The md5= part of the statement is generated by running “md5sum COPYING” against the COPYING file I downloaded to examine.
** ${PV} in the SRC_URI statement is picked up from the part of the recipe file name after the “_”. In this case PV =2.7.

# The recipe is built, so now I can run it:

cd ~/poky
source oe-init-build-env build-hello.

# Before I can use BitBake I need to edit two files. Sourcing the oe-init-build-env file above leaves me in the build-hello directory. Before issuing the bitbake command I need to edit the files conf/local.conf and conf/bblayers.conf in that build-hello directory. The bblayers.conf needs to have the one line added to include the layer you created.

# LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf
# changes incompatibly
LCONF_VERSION = "4"
BBFILES ?= ""
BBLAYERS = " \
/home/jim/poky/meta \
/home/jim/poky/meta-yocto \
/home/jim/poky/meta-jfa \
"

# The conf/local.conf file needs to have the parallel processing lines edited to speed up the baking on multicore systems. I can do that by uncommenting the BB_NUMBER_THREADS and PARALLEL_MAKE variables. Generally, I would set them equal to twice the number of cores used by my host machine. By default, the MACHINE variable is set to qemux86 and for this example is fine. I need to add a line to include the hello package I am building into the image by adding the following line:

POKY_EXTRA_INSTALL += "hello"

# Now I can bake it with this command:
bitbake core-image-minimal
# Once the image is built, I can test it by starting the QEMU emulator:

runqemu qemux86

# Once the emulator comes up, login as root with no password. Then, at the prompt, enter "hello" to run your application.

How do I

2012-01-27T17:28:12Z

Scottrifw:

'''Q: How do I put yocto on a hard drive?'''

'''A:''' bitbake core-image-sato or core-image-sato-sdk

# have a suitable partition on the disk - say partition #3
# this partition will show up as sde3 on my host machine and sda3 on the atom
# mkfs.ext3 /dev/sde3
# mount /dev/sde3 /mnt/target
# mount -o loop tmp/deploy/images/core-image-sato-sdk.ext3 /mnt/target-ext3
# cp -a /mnt/target-ext3/* /mnt/target
# grub-install --recheck --root-directory=/mnt/target /dev/sde

If grub install passed, copy the following to /mnt/target/boot/grub/grub.cfg

set default="0"
set timeout="30"

menuentry 'Yocto SDK' {
insmod part_msdos
insmod ext2
set root='(hd0,msdos3)'
linux /boot/bzImage root=/dev/sda3
}

Thats it - this should boot.

'''Q: How do I put my recipe into Yocto? '''

'''A:''' Let's use the Hello World example from Section 3.1.2 of the Yocto Project Reference Manual and expand on it.

* In this example, I'll start with a new meta layer named "meta-jfa" in the Yocto Project files directory, which is named "poky". Then, I will add the new recipe and build the image, which is named "core-image-minimal". I will build it using the autotooled package option. Once built, the image will have the “hello” application.

# Create the following directory structure in the ~/poky directory. I'll use my initials to denote the layer and recipe name:

mkdir meta-jfa
mkdir meta-jfa/conf
mkdir meta-jfa/recipes-jfa
mkdir meta-jfa/recipes-jfa/hello

# Next, to make sure the recipe gets searched and located, I'll create the layer.conf file in the meta-jfa/conf directory as follows:

# We have a conf and classes directory, add to BBPATH
BBPATH := "${BBPATH}:${LAYERDIR}"
# We have a packages directory, add to BBFILES
BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \
${LAYERDIR}/recipes-*/*/*.bbappend"
BBFILE_COLLECTIONS += "jfa"
BBFILE_PATTERN_jfa := "^${LAYERDIR}/"
BBFILE_PRIORITY_jfa = "5

# Now I need to put the recipe (.bb) file into the right directory. So, I will put the file hello_2.7.bb into the meta-jfa/recipes-jfa/hello directory. I picked version 2.7 of the hello program by going to the gnu site for the application (ftp://ftp.gnu.org/gnu/hello/) and downloading it to checkout the version I wanted to include. hello-2.7.tar.gz is the most current. I downloaded it locally and expanded it to look at the license information. The hello_2.7.bb file contains the following:

DESCRIPTION = "GNU Helloworld application"
SECTION = "examples"
LICENSE = "GPLv3+"
LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504"
PR = "r0"
SRC_URI = "${GNU_MIRROR}/hello/hello-${PV}.tar.gz"
inherit autotools gettext
* Here is some explanation for a few of the recipe statements:
** LIC_FILES_CHKSUM = is required and, using file location defaults, points to the COPYING file that is part of the tarball that is downloaded from the SRC_URI address. The md5= part of the statement is generated by running “md5sum COPYING” against the COPYING file I downloaded to examine.
** ${PV} in the SRC_URI statement is picked up from the part of the recipe file name after the “_”. In this case PV =2.7.

# The recipe is built, so now I can run it:

cd ~/poky
source oe-init-build-env build-hello.

# Before I can use BitBake I need to edit two files. Sourcing the oe-init-build-env file above leaves me in the build-hello directory. Before issuing the bitbake command I need to edit the files conf/local.conf and conf/bblayers.conf in that build-hello directory. The bblayers.conf needs to have the one line added to include the layer you created.

# LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf
# changes incompatibly
LCONF_VERSION = "4"
BBFILES ?= ""
BBLAYERS = " \
/home/jim/poky/meta \
/home/jim/poky/meta-yocto \
/home/jim/poky/meta-jfa \
"

# The conf/local.conf file needs to have the parallel processing lines edited to speed up the baking on multicore systems. I can do that by uncommenting the BB_NUMBER_THREADS and PARALLEL_MAKE variables. Generally, I would set them equal to twice the number of cores used by my host machine. By default, the MACHINE variable is set to qemux86 and for this example is fine. I need to add a line to include the hello package I am building into the image by adding the following line:

POKY_EXTRA_INSTALL += "hello"

# Now I can bake it with this command:
bitbake core-image-minimal
# Once the image is built, I can test it by starting the QEMU emulator:

runqemu qemux86

# Once the emulator comes up, login as root with no password. Then, at the prompt, enter "hello" to run your application.

How do I

2012-01-27T15:39:15Z

Scottrifw:

'''Q: How do I put yocto on a hard drive?'''

'''A:''' bitbake core-image-sato or core-image-sato-sdk

# have a suitable partition on the disk - say partition #3
# this partition will show up as sde3 on my host machine and sda3 on the atom
# mkfs.ext3 /dev/sde3
# mount /dev/sde3 /mnt/target
# mount -o loop tmp/deploy/images/core-image-sato-sdk.ext3 /mnt/target-ext3
# cp -a /mnt/target-ext3/* /mnt/target
# grub-install --recheck --root-directory=/mnt/target /dev/sde

If grub install passed, copy the following to /mnt/target/boot/grub/grub.cfg

set default="0"
set timeout="30"

menuentry 'Yocto SDK' {
insmod part_msdos
insmod ext2
set root='(hd0,msdos3)'
linux /boot/bzImage root=/dev/sda3
}

Thats it - this should boot.

'''Q: How do I put my recipe into Yocto? '''

'''A:''' Let's use the Hello World example from Section 3.1.2 of the Yocto Project Reference Manual and expand on it.

* In this example, I'll start with a new meta layer named "meta-jfa" in the Yocto Project files directory, which is named "poky". Then, I will add the new recipe and build the image, which is named "core-image-minimal". I will build it using the autotooled package option. Once built, the image will have the “hello” application.

1. Create the following directory structure in the ~/poky directory. I'll use my initials to denote the layer and recipe name:

mkdir meta-jfa
mkdir meta-jfa/conf
mkdir meta-jfa/recipes-jfa
mkdir meta-jfa/recipes-jfa/hello

2. Next, to make sure the recipe gets searched and located, I'll create the layer.conf file in the meta-jfa/conf directory as follows:

# We have a conf and classes directory, add to BBPATH
BBPATH := "${BBPATH}:${LAYERDIR}"
# We have a packages directory, add to BBFILES
BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \
${LAYERDIR}/recipes-*/*/*.bbappend"
BBFILE_COLLECTIONS += "jfa"
BBFILE_PATTERN_jfa := "^${LAYERDIR}/"
BBFILE_PRIORITY_jfa = "5

3. Now I need to put the recipe (.bb) file into the right directory. So, I will put the file hello_2.7.bb into the meta-jfa/recipes-jfa/hello directory. I picked version 2.7 of the hello program by going to the gnu site for the application (ftp://ftp.gnu.org/gnu/hello/) and downloading it to checkout the version I wanted to include. hello-2.7.tar.gz is the most current. I downloaded it locally and expanded it to look at the license information. The hello_2.7.bb file contains the following:

DESCRIPTION = "GNU Helloworld application"
SECTION = "examples"
LICENSE = "GPLv3+"
LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504"
PR = "r0"
SRC_URI = "${GNU_MIRROR}/hello/hello-${PV}.tar.gz"
inherit autotools gettext
* Here is some explanation for a few of the recipe statements:
** LIC_FILES_CHKSUM = is required and, using file location defaults, points to the COPYING file that is part of the tarball that is downloaded from the SRC_URI address. The md5= part of the statement is generated by running “md5sum COPYING” against the COPYING file I downloaded to examine.
** ${PV} in the SRC_URI statement is picked up from the part of the recipe file name after the “_”. In this case PV =2.7.

4. The recipe is built, so now I can run it:

cd ~/poky
source oe-init-build-env build-hello.

5. Before I can use BitBake I need to edit two files. Sourcing the oe-init-build-env file above leaves me in the build-hello directory. Before issuing the bitbake command I need to edit the files conf/local.conf and conf/bblayers.conf in that build-hello directory. The bblayers.conf needs to have the one line added to include the layer you created.

# LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf
# changes incompatibly
LCONF_VERSION = "4"
BBFILES ?= ""
BBLAYERS = " \
/home/jim/poky/meta \
/home/jim/poky/meta-yocto \
/home/jim/poky/meta-jfa \
"

6. The conf/local.conf file needs to have the parallel processing lines edited to speed up the baking on multicore systems. I can do that by uncommenting the BB_NUMBER_THREADS and PARALLEL_MAKE variables. Generally, I would set them equal to twice the number of cores used by my host machine. By default, the MACHINE variable is set to qemux86 and for this example is fine. I need to add a line to include the hello package I am building into the image by adding the following line:

POKY_EXTRA_INSTALL += "hello"

7. Now I can bake it with this command:
bitbake core-image-minimal
8. Once the image is built, I can test it by starting the QEMU emulator:

runqemu qemux86

9. Once the emulator comes up, login as root with no password. Then, at the prompt, enter "hello" to run your application.

Bugzilla Configuration and Bug Tracking

2011-11-22T21:44:51Z

Scottrifw: /* Importance */

Yocto Project Bug Process version

{|border="1"
|Version|| Modifier || Comments
|-
| 0.3 || Yongkang You || Initial Version
|-
| 0.5 || Yongkang You || Apply comments from Richard, Dave and Susie. Add Feature Request Process and Add a new Priority "FEAT" for it.
|-
| 0.8 || Yongkang You || Internal review and agree bug life cycle and bug Triage process.
|-
| 0.85 || Saul Wold || Add Bug Status / Sub-Status Definitions.
|-
| 0.9 || davest || Cleanup for 0.9 release.
|}

You should also read our [[Community Guidelines]] before submitting bugs.

------
== Defect Management ==
Yocto uses '''[http://www.bugzilla.org/ Bugzilla]''' as its defect tracking tool.

=== Home Address ===
http://bugzilla.yoctoproject.org

=== Get an Account ===
Anyone working on the Yocto project can query existing bugs in Bugzilla. You must have an account to submit a bug, edit a bug, or take action on a bug.

To set up an account, go to the '''[http://www.bugzilla.yoctoproject.org/ Yocto Bugzilla]''' home page and click on "New Account" in the footer area. Follow the directions there to set up your account.

=== Classification, Product and Components ===
Yocto Bugzilla uses these Classifications, Products and Components. Configurations change over time and should be defined by module owners:

<pre>
+=======================+======================+======================+
| Classification | Product | Components |
|=====================================================================|
| Yocto Projects | Anjuta Plug-in | General |
| +----------------------+----------------------|
| | BSPs | General |
| +----------------------+----------------------|
| | Cross-prelink | General |
| | +----------------------|
| | | Poky Integration |
| +----------------------+----------------------|
| | Documentation | Handbook |
| | +----------------------|
| | | Other |
| | +----------------------|
| | | PRD |
| | +----------------------|
| | | SDK |
| +----------------------+----------------------|
| | Eclipse Plug-in | General |
| +----------------------+----------------------|
| | Kernel | Build |
| | +----------------------|
| | | Configuration |
| | +----------------------|
| | | General |
| | +----------------------|
| | | Runtime |
| +----------------------+----------------------|
| | Pseudo | General |
| | +----------------------|
| | | Poky Configuration |
| +----------------------+----------------------|
| | Runtime Distribution | Installation |
| | +----------------------|
| | | System Startup |
| +----------------------+----------------------|
| | SDK Tools | General |
| +----------------------+----------------------|
| | Swabber | General |
| | +----------------------|
| | | Poky Integration |
| +----------------------+----------------------|
| | Yocto Test Suite | General |
|-----------------------+----------------------+----------------------|
| Infrastructure | AutoBuilder | General |
| +----------------------+----------------------|
| | Bugzilla | General |
| +----------------------+----------------------|
| | Website | General |
|-----------------------+----------------------+----------------------|
| Poky | ADT | General |
| +----------------------+----------------------|
| | Build System | BitBake |
| | +----------------------|
| | | Configuration |
| | +----------------------|
| | | General |
| | +----------------------|
| | | Hob |
| | +----------------------|
| | | Image Creator |
| | +----------------------|
| | | Layers |
| +----------------------+----------------------|
| | Security | General |
|-----------------------+----------------------+----------------------|
| Yocto Metadata Layers | Layers | dlna |
| | +----------------------|
| | | extra |
| | +----------------------|
| | | general |
| | +----------------------|
| | | intel |
| | +----------------------|
| | | linaro |
| | +----------------------|
| | | xilinx |
| |----------------------+----------------------|
| | Meta Recipes | connectivity |
| | +----------------------|
| | | core |
| | +----------------------|
| | | demoapps |
| | +----------------------|
| | | devtools / toolchain |
| | +----------------------|
| | | general |
| | +----------------------|
| | | graphics |
| | +----------------------|
| | | kernel |
| | +----------------------|
| | | multimedia |
| |----------------------+----------------------|
| | Sato | General |
| | +----------------------|
| | | gtk-engine |
| | +----------------------|
| | | Icon |
| | +----------------------|
| | | Matchbox |
|-----------------------+----------------------+----------------------+
</pre>

=== Platform ===
This field represents the platform and architecture for which the bug applies. The Platform consists of a hardware component and an architecture component. For example, the Platform's hardware could be "PC" and the architecture could be "x86". Here is a list of the hardware choices:

* All
* PC
* Netbook
* e-Menlow
* Blacksand
* JasperForest
* TunnelCreek
* Macintosh
* Beagleboard
* mpc8315e-rdb
* Routerstationpro
* Other

Here is a list of the architecture choices:

* All
* arm
* mips
* ppc
* x86
* x86_64
* Other

=== Version ===
This field represents the version of the Yocto Project for which the bug applies. The list of versions can vary depending on the Classification, Component and Project. Here is a list of current selections:

* 0.9
* 1.0-beta
* 1.0
* 1.1-beta
* 1.1
* 1.2

=== Target Milestone ===
This field represents when the assignee of the bug estimates the bug will be fixed. The values are based on releases and Milestone numbers. For example, "1.2 M3" indicates the third milestone for the 1.2 release.

=== Importance ===
The Importance of the bug is defined by its Priority and Severity. The Priority classifies the bug's fixing order. In other words, how soon will it get fixed relative to other bugs? Priorities are set during the bug Triage meeting and cannot be changed by the user. The priority appears to the left of the Severity field. Here are the values that Priority can be set to during the Triage meeting:

* High -- Bug fixing is planned within 2 weeks, no later than the up-coming milestone, or immediately as a critical issue for an out-of-cycle release (e.g. highly reproducible crash issues in the system or related to key applications or components needed for delivery in an upcoming milestone). High priority issues cause major functional loss of a specific feature that is POR for the up-comping milestone. These issues are easily hit by the user and greatly impact the user experience or customer requirements. Finally, these issues could be urgent security fixes that need to be corrected in a prior release.
* Medium -- Bug fixing is planned before the milestone and must be fixed before the release is finalized.
* Low -- Bug fixing is not planned for the up-coming project release. Issues that are not a POR feature request, or are hard to reproduce fall into this category.
* Undecided -- These issues are newly reported and are '''undecided''' before Triage.
* FEAT -- Issues that are a feature request, which isn't approved for future release yet. This issue will be changed to have an actual Priority after the Change Control Board (CCB) approves it.

'''Note:''' High impact but Low Priority bugs can be documented in the release notes.

The Severity indicates how much the issue impacted the person reporting the bug. Severity can be categorized into five areas.
* Critical -- Crashes, hang, loss of data, negative impact to other components, memory leak etc.
* Major -- Major loss of functionality of POR.
* Normal -- Regular issue, some loss of functionality under certain circumstance. This is the '''default''' Severity.
* Minor -- Minor loss of functionality, or issues with easy workaround available.
* Enhancement -- Request for enhancement work.

=== Bug Status ===
* Open -- A new reported bug with default assignee.
* ACCEPTED-- The assigned developer has reviewed and accept the bug.
* Resolved -- bug is fixed or closed by other resolved method.
** Fixed -- This is fixed and in the master branch will be set automatically during build
** NotABug -- This is verified as not a bug
** WontFix -- We will not fix this bug, possibly because a newer package fixes it
** Duplicate -- Duplicate of another bug, possibly different failure mode
** Invalid -- The bug is invalid, sometimes this is used when the author of the bug does not provide accurate information, these will be reviewed by Triage team, and could be changed to '''NeedInfo'''
** Obsolete -- The bug is obsolete, old bug that is no longer appropriate, or a package that is depercated.
** WorksForMe -- The bug does not appear when tested by engineer, more appropriately, this may be '''NeedInfo'''
* Verified -- bug is double checked and agreed with the resolved method by original reporter.
* Reopen: bug can be reopened, if it is in Resolved, Verified or Close stage.
* NeedInfo: bug needs be set to NeedInfo, if there is important information missing to understand or reproduce bug.
* WaitForUpstream: The owner does bug analysis and finds this bug comes from upstream. Owner can post a new bug in upstream bugzilla, change status to '''WaitForUpstream''' and add the upstream bugzilla URL in comment area. When upstream bug is fixed, put the bug fixing into Yocto repository. After the patch is built into weekly build, change its status to Resolved/FIXED.
* '''Close''' stage is not used in normal bug life. When reported two same bugs by wrongly click button twice, the 2nd one can be closed. Generally it(close stage) is just for keeping wrong bug out of scrub cycle and statistic.

=== Bug Life Cycle ===
A normal Bug's life is started from '''Open''' and ended by '''Verified'''. Triage team will select "verified: Program Management", after confirm the verification.

[[Image:Yocto_Bug_Life_Cycle.jpg|frame|none|Bug Life Cycle]]

Bug should be marked as Resolved/Fixed, after its fixing patch is built into formal build (weekly build or milestone build). There is an automation method to update bugs to "RESOVLED/FIXED" status by following steps.
# Developer fixed bug and check in patch to his ''contrib'' branch with special words in commit description: '''[BUGFIX #4321]'''
# Developer asked tree gatekeeper to pull patch.
# Release Engineer do formal build. The build script will read new commit description and find out bug ID.
# Build script will notify bugzilla and update bugs status to "RESOLVE/FIXED"

If a weekly build includes a new commit, which reverts another patch, there should be a tool to judge whether the reverted patch summary include any bug fixing ID. If the reverted patch does include any bug fixing, the bug should be reopen.

[[Image:Yocto_Bug_Fix_Process.PNG|frame|none|Bug Fixing Process]]

=== Defect Submission ===
Defects may be entered by anyone working on the Yocto. Bug submission should include severity, thorough environment information, proper and clear reproduce steps and logs.

=== Bug Group ===
Bug group is used to control bug visibility. Couple of groups will be set up. When reporting or updating bugs, group check box could be edit.

* '''Security''' -- Bugs can only be viewed by Security group user. Bugs will be in Security Group, when it is reported to security component.
* No_Group_Check_Box_Selection-- Bugs are public. (Be careful)''' '''
* TBD

=== Bug Reporter ===
* Provide clear and simple bug subject. It is recommended to put a '''Fault Component Name''' with brackets at the beginning of subject as a keyword, e.g. [Poky].
* Validate all fields are correct. If fields are not filled out correctly, the bug might be sent back to the submitter.
* Judge the right Severity.
* Adds any additional information from the bug scrub.
* Assigns the bug to the correct person to disposition the bug.
* If a bug is too vague to make a determination then the Resolution Field of the bug will be set to need more information and sent back the bug submitter.
* '''Bug Priority can't be set when report a bug. It will be set when doing bug Triage'''

=== Bug Owner ===
* Review bugs to check if there are enough information. If not, set the bug to NeedInfo. Try to reproduce bug, if there are clear steps.
* Based on bug Priority and Severity to fix bugs in time. For example, High Priority bugs usually should be fixed in 2 weeks. High/critical bugs should be fixed as soon as possible, which has impaction to whole system.
* Update bugs in time with comments. Set the bug to Fixed and provide the tree/commit info, after bug fixing. '''Bug should not be marked as "fix", if patch is not checked into repository. '''

== Bug Tracking ==
Yocto is a cross many Geo project. Single bug scrub meeting is not easy to maintain. Considering Embedded Linux will be a big project, it brings a concept named ''Triage'' to effectively track bug. Triage is mainly for setting new bug priority. Triage virtual team will based on bug's severity, features and schedule to suggest bug fixing priority. Developer teams will receive triage email in time. If reach agreement, bugs will be followed up based on priority. Team manager should be responsible for monitoring the bug fixing schedule to align with related priority. This process is to make the high priority bug be fixed in time and reduce the schedule risk. There are still separated bug review or discussion meeting, which is held through Jabber.

=== Triage Management Team ===
* Program Manager
* Architect
* Engineering Manager
* QA leader

=== Triage Process ===
The triage process will be held frequently to make sure new coming bugs are set with correct priority in time. Triage chairman scrubs new bugs and set priority everyday. PDT meeting will review past week's overall triage result once per week.

The Bugzilla system will send emails to component owner and related engineers about creating or changing of bugs. Before Triage, new bugs could be discussed and even fixed.

'''Bug Triage Process '''

[[Image:bug_triage_process.PNG|frame|none|bug traiage process]]

'''Triage email example'''
<pre>
To: Yocto OTC
Subject: [Yocto-bug-triage] Bug Triage Review - ww26.1

Manager: MGR_A
==================
Bug ID Sev Priority Assignee Summary
1 maj High dev_A [Poky] XYZ Build Failure

Manager: MGR_B
====================
Bug ID Sev Priority Assignee Summary
2 maj High dev_B [SDK] ABC button error
3 nor Medium dev_C [X] Can't start X
</pre>

=== Responsibility ===
* Triage Chairman
** Triage new bugs: set initial priority, correct bug component and owner and mark duplicated bugs.
** Monitor overall bug fix progress with indicators: find out aging bugs.
** Send out triage result email to yocto mailing list (or Triage management team member) for review.
** Escalate aging high priority open bugs.
* Triage Management Team
** Development/Distribution managers are mandatory to review triage result and commit to fix
* Development/Distribution Manager
** Ensure developer/distro ACCEPT bugs in bugzilla within 3 days
** Commit developer to fix high priority bugs
* Program Manager
** Coordinate and push bugs to be fixed in time
* Triage Decision Forum (PDT Meeting)
** Make decision on controversial bugs
** Review and Monitor previous decision
** Triage Chairman update bugzilla based on decision
** Discuss and approve bug whose priority needs to be downgraded

=== Triage Chairman ===
Triage chairman role will be rotated in distribution leaders, engineer manager, SDK leader and QA leader. Each chairman will own 1 milestone cycle. Triage chairman starts from Yocto 0.9 M2 cycle and rotate in following order.
# Saul Wold -- Distro leader
# Susie Li -- engineer manager
# Kevin Tian -- distro leader
# Jessica Zhang -- SDK leader
# QA Leader

=== Bug Data Reporting ===
Defect Data is tracked and presented to the PDT meeting on a weekly basis by QA team. Any escalation items should be discussed and resolved in the PDT meeting.

=== External Owned Bug Triage ===
There might be some bugs owned by external developers. These bugs' triage results will be sent to Yocto public mailing list weekly.

=== Re-Triage for Next Milestone and Release ===
After a new milestone, there will be a time to review all medium priority bugs and set new Priority for next coming milestone.
After a new release, there will be a time to review all low priority bugs and set new Priority for next coming release.

== Feature Request Process ==
New feature request should be applied through Bugzilla as a bug. User could select corresponding Severity to indicate how important the feature is. User needs to follow Feature Request template to submit new request. Triage chairman will mark new feature request bug priority to '''FEAT'''.

There will be two important feature request review time per year in Aug. and Jan. (2 months before current release). In the review period, there will be 2~4 times review meetings by CCB. CCB will decide new features which will be included in next release, that will be released 8 months later. If feature request missed the review period, in theory it will be missed in next release. Any approved new feature will be reset Priority value and Target Version value. Non approved feature will keep "FEAT" priority.

=== Change Control Board ===
Following people should join CCB to review new feature request.
PME(Product Marketing Engineer), PM, Architect, Managers, Key developer and QA leader

=== Feature Request Bug Requirement ===
Feature request bug should be added specific Keywords in subject and Keywords field.

Following message should be added at the beginning of subject.
[FEAT_REQ Company Yocto_Target_Version]

For example: [FEAT_REQ xxx 1.0] Add Connman for network connection.

Following words should be added in Keywords field.
FEATURE_REQUEST

=== Feature Request Bug Template ===
<pre>
1. Feature Description:

2. Feature Present Code Status(including location and version):

3. Code License (e.g. GPLv2):

4. Business Impaction:

5. Other Justification:

</pre>

Bugzilla Configuration and Bug Tracking

2011-11-22T21:42:52Z

Scottrifw:

Yocto Project Bug Process version

{|border="1"
|Version|| Modifier || Comments
|-
| 0.3 || Yongkang You || Initial Version
|-
| 0.5 || Yongkang You || Apply comments from Richard, Dave and Susie. Add Feature Request Process and Add a new Priority "FEAT" for it.
|-
| 0.8 || Yongkang You || Internal review and agree bug life cycle and bug Triage process.
|-
| 0.85 || Saul Wold || Add Bug Status / Sub-Status Definitions.
|-
| 0.9 || davest || Cleanup for 0.9 release.
|}

You should also read our [[Community Guidelines]] before submitting bugs.

------
== Defect Management ==
Yocto uses '''[http://www.bugzilla.org/ Bugzilla]''' as its defect tracking tool.

=== Home Address ===
http://bugzilla.yoctoproject.org

=== Get an Account ===
Anyone working on the Yocto project can query existing bugs in Bugzilla. You must have an account to submit a bug, edit a bug, or take action on a bug.

To set up an account, go to the '''[http://www.bugzilla.yoctoproject.org/ Yocto Bugzilla]''' home page and click on "New Account" in the footer area. Follow the directions there to set up your account.

=== Classification, Product and Components ===
Yocto Bugzilla uses these Classifications, Products and Components. Configurations change over time and should be defined by module owners:

<pre>
+=======================+======================+======================+
| Classification | Product | Components |
|=====================================================================|
| Yocto Projects | Anjuta Plug-in | General |
| +----------------------+----------------------|
| | BSPs | General |
| +----------------------+----------------------|
| | Cross-prelink | General |
| | +----------------------|
| | | Poky Integration |
| +----------------------+----------------------|
| | Documentation | Handbook |
| | +----------------------|
| | | Other |
| | +----------------------|
| | | PRD |
| | +----------------------|
| | | SDK |
| +----------------------+----------------------|
| | Eclipse Plug-in | General |
| +----------------------+----------------------|
| | Kernel | Build |
| | +----------------------|
| | | Configuration |
| | +----------------------|
| | | General |
| | +----------------------|
| | | Runtime |
| +----------------------+----------------------|
| | Pseudo | General |
| | +----------------------|
| | | Poky Configuration |
| +----------------------+----------------------|
| | Runtime Distribution | Installation |
| | +----------------------|
| | | System Startup |
| +----------------------+----------------------|
| | SDK Tools | General |
| +----------------------+----------------------|
| | Swabber | General |
| | +----------------------|
| | | Poky Integration |
| +----------------------+----------------------|
| | Yocto Test Suite | General |
|-----------------------+----------------------+----------------------|
| Infrastructure | AutoBuilder | General |
| +----------------------+----------------------|
| | Bugzilla | General |
| +----------------------+----------------------|
| | Website | General |
|-----------------------+----------------------+----------------------|
| Poky | ADT | General |
| +----------------------+----------------------|
| | Build System | BitBake |
| | +----------------------|
| | | Configuration |
| | +----------------------|
| | | General |
| | +----------------------|
| | | Hob |
| | +----------------------|
| | | Image Creator |
| | +----------------------|
| | | Layers |
| +----------------------+----------------------|
| | Security | General |
|-----------------------+----------------------+----------------------|
| Yocto Metadata Layers | Layers | dlna |
| | +----------------------|
| | | extra |
| | +----------------------|
| | | general |
| | +----------------------|
| | | intel |
| | +----------------------|
| | | linaro |
| | +----------------------|
| | | xilinx |
| |----------------------+----------------------|
| | Meta Recipes | connectivity |
| | +----------------------|
| | | core |
| | +----------------------|
| | | demoapps |
| | +----------------------|
| | | devtools / toolchain |
| | +----------------------|
| | | general |
| | +----------------------|
| | | graphics |
| | +----------------------|
| | | kernel |
| | +----------------------|
| | | multimedia |
| |----------------------+----------------------|
| | Sato | General |
| | +----------------------|
| | | gtk-engine |
| | +----------------------|
| | | Icon |
| | +----------------------|
| | | Matchbox |
|-----------------------+----------------------+----------------------+
</pre>

=== Platform ===
This field represents the platform and architecture for which the bug applies. The Platform consists of a hardware component and an architecture component. For example, the Platform's hardware could be "PC" and the architecture could be "x86". Here is a list of the hardware choices:

* All
* PC
* Netbook
* e-Menlow
* Blacksand
* JasperForest
* TunnelCreek
* Macintosh
* Beagleboard
* mpc8315e-rdb
* Routerstationpro
* Other

Here is a list of the architecture choices:

* All
* arm
* mips
* ppc
* x86
* x86_64
* Other

=== Version ===
This field represents the version of the Yocto Project for which the bug applies. The list of versions can vary depending on the Classification, Component and Project. Here is a list of current selections:

* 0.9
* 1.0-beta
* 1.0
* 1.1-beta
* 1.1
* 1.2

=== Target Milestone ===
This field represents when the assignee of the bug estimates the bug will be fixed. The values are based on releases and Milestone numbers. For example, "1.2 M3" indicates the third milestone for the 1.2 release.

=== Importance ===
The Importance of the bug is defined by its Priority and Severity. The Priority classifies the bug's fixing order. In other words, how soon will it get fixed relative to other bugs? Priorities are set during the bug Triage meeting and cannot be changed by the user. The priority appears to the left of the Severity field. Here are the values that Priority can be set to during the Triage meeting:

* High -- Bug fixing is planned within 2 weeks, no later than the up-coming milestone, or immediately as a critical issue for an out-of-cycle release (e.g. highly reproducible crash issues in the system or related to key applications or components needed for delivery in an upcoming milestone). High priority issues cause major functional loss of a specific feature that is POR for the up-comping milestone. These issues are easily hit by the user and greatly impact the user experience or customer requirements. Finally, these issues could be urgent security fixes that need to be corrected in a prior release.
* Medium -- Bug fixing is planned before the milestone and must be fixed before the release is finalized.
* Low -- Bug fixing is not planned for the up-coming project release. Issues that are not a POR feature request, or are hard to reproduce fall into this category.
* Undecided -- These issues are newly reported and are '''undecided''' before Triage.
* FEAT -- Issues that are a feature request, which isn't approved for future release yet. This issue will be changed to have an actual Priority after the Change Control Board (CCB) approves it.

** Note: High impact but Low Priority bugs can be documented in the release notes.

The Severity indicates how much the issue impacted the person reporting the bug. Severity can be categorized into five areas with '''default''' being '''Normal'''.
* Critical -- Crashes, hang, loss of data, negative impact to other components, memory leak etc.
* Major -- Major loss of functionality of POR.
* Normal -- Regular issue, some loss of functionality under certain circumstance.
* Minor -- Minor loss of functionality, or issues with easy workaround available.
* Enhancement -- Request for enhancement work.

=== Bug Status ===
* Open -- A new reported bug with default assignee.
* ACCEPTED-- The assigned developer has reviewed and accept the bug.
* Resolved -- bug is fixed or closed by other resolved method.
** Fixed -- This is fixed and in the master branch will be set automatically during build
** NotABug -- This is verified as not a bug
** WontFix -- We will not fix this bug, possibly because a newer package fixes it
** Duplicate -- Duplicate of another bug, possibly different failure mode
** Invalid -- The bug is invalid, sometimes this is used when the author of the bug does not provide accurate information, these will be reviewed by Triage team, and could be changed to '''NeedInfo'''
** Obsolete -- The bug is obsolete, old bug that is no longer appropriate, or a package that is depercated.
** WorksForMe -- The bug does not appear when tested by engineer, more appropriately, this may be '''NeedInfo'''
* Verified -- bug is double checked and agreed with the resolved method by original reporter.
* Reopen: bug can be reopened, if it is in Resolved, Verified or Close stage.
* NeedInfo: bug needs be set to NeedInfo, if there is important information missing to understand or reproduce bug.
* WaitForUpstream: The owner does bug analysis and finds this bug comes from upstream. Owner can post a new bug in upstream bugzilla, change status to '''WaitForUpstream''' and add the upstream bugzilla URL in comment area. When upstream bug is fixed, put the bug fixing into Yocto repository. After the patch is built into weekly build, change its status to Resolved/FIXED.
* '''Close''' stage is not used in normal bug life. When reported two same bugs by wrongly click button twice, the 2nd one can be closed. Generally it(close stage) is just for keeping wrong bug out of scrub cycle and statistic.

=== Bug Life Cycle ===
A normal Bug's life is started from '''Open''' and ended by '''Verified'''. Triage team will select "verified: Program Management", after confirm the verification.

[[Image:Yocto_Bug_Life_Cycle.jpg|frame|none|Bug Life Cycle]]

Bug should be marked as Resolved/Fixed, after its fixing patch is built into formal build (weekly build or milestone build). There is an automation method to update bugs to "RESOVLED/FIXED" status by following steps.
# Developer fixed bug and check in patch to his ''contrib'' branch with special words in commit description: '''[BUGFIX #4321]'''
# Developer asked tree gatekeeper to pull patch.
# Release Engineer do formal build. The build script will read new commit description and find out bug ID.
# Build script will notify bugzilla and update bugs status to "RESOLVE/FIXED"

If a weekly build includes a new commit, which reverts another patch, there should be a tool to judge whether the reverted patch summary include any bug fixing ID. If the reverted patch does include any bug fixing, the bug should be reopen.

[[Image:Yocto_Bug_Fix_Process.PNG|frame|none|Bug Fixing Process]]

=== Defect Submission ===
Defects may be entered by anyone working on the Yocto. Bug submission should include severity, thorough environment information, proper and clear reproduce steps and logs.

=== Bug Group ===
Bug group is used to control bug visibility. Couple of groups will be set up. When reporting or updating bugs, group check box could be edit.

* '''Security''' -- Bugs can only be viewed by Security group user. Bugs will be in Security Group, when it is reported to security component.
* No_Group_Check_Box_Selection-- Bugs are public. (Be careful)''' '''
* TBD

=== Bug Reporter ===
* Provide clear and simple bug subject. It is recommended to put a '''Fault Component Name''' with brackets at the beginning of subject as a keyword, e.g. [Poky].
* Validate all fields are correct. If fields are not filled out correctly, the bug might be sent back to the submitter.
* Judge the right Severity.
* Adds any additional information from the bug scrub.
* Assigns the bug to the correct person to disposition the bug.
* If a bug is too vague to make a determination then the Resolution Field of the bug will be set to need more information and sent back the bug submitter.
* '''Bug Priority can't be set when report a bug. It will be set when doing bug Triage'''

=== Bug Owner ===
* Review bugs to check if there are enough information. If not, set the bug to NeedInfo. Try to reproduce bug, if there are clear steps.
* Based on bug Priority and Severity to fix bugs in time. For example, High Priority bugs usually should be fixed in 2 weeks. High/critical bugs should be fixed as soon as possible, which has impaction to whole system.
* Update bugs in time with comments. Set the bug to Fixed and provide the tree/commit info, after bug fixing. '''Bug should not be marked as "fix", if patch is not checked into repository. '''

== Bug Tracking ==
Yocto is a cross many Geo project. Single bug scrub meeting is not easy to maintain. Considering Embedded Linux will be a big project, it brings a concept named ''Triage'' to effectively track bug. Triage is mainly for setting new bug priority. Triage virtual team will based on bug's severity, features and schedule to suggest bug fixing priority. Developer teams will receive triage email in time. If reach agreement, bugs will be followed up based on priority. Team manager should be responsible for monitoring the bug fixing schedule to align with related priority. This process is to make the high priority bug be fixed in time and reduce the schedule risk. There are still separated bug review or discussion meeting, which is held through Jabber.

=== Triage Management Team ===
* Program Manager
* Architect
* Engineering Manager
* QA leader

=== Triage Process ===
The triage process will be held frequently to make sure new coming bugs are set with correct priority in time. Triage chairman scrubs new bugs and set priority everyday. PDT meeting will review past week's overall triage result once per week.

The Bugzilla system will send emails to component owner and related engineers about creating or changing of bugs. Before Triage, new bugs could be discussed and even fixed.

'''Bug Triage Process '''

[[Image:bug_triage_process.PNG|frame|none|bug traiage process]]

'''Triage email example'''
<pre>
To: Yocto OTC
Subject: [Yocto-bug-triage] Bug Triage Review - ww26.1

Manager: MGR_A
==================
Bug ID Sev Priority Assignee Summary
1 maj High dev_A [Poky] XYZ Build Failure

Manager: MGR_B
====================
Bug ID Sev Priority Assignee Summary
2 maj High dev_B [SDK] ABC button error
3 nor Medium dev_C [X] Can't start X
</pre>

=== Responsibility ===
* Triage Chairman
** Triage new bugs: set initial priority, correct bug component and owner and mark duplicated bugs.
** Monitor overall bug fix progress with indicators: find out aging bugs.
** Send out triage result email to yocto mailing list (or Triage management team member) for review.
** Escalate aging high priority open bugs.
* Triage Management Team
** Development/Distribution managers are mandatory to review triage result and commit to fix
* Development/Distribution Manager
** Ensure developer/distro ACCEPT bugs in bugzilla within 3 days
** Commit developer to fix high priority bugs
* Program Manager
** Coordinate and push bugs to be fixed in time
* Triage Decision Forum (PDT Meeting)
** Make decision on controversial bugs
** Review and Monitor previous decision
** Triage Chairman update bugzilla based on decision
** Discuss and approve bug whose priority needs to be downgraded

=== Triage Chairman ===
Triage chairman role will be rotated in distribution leaders, engineer manager, SDK leader and QA leader. Each chairman will own 1 milestone cycle. Triage chairman starts from Yocto 0.9 M2 cycle and rotate in following order.
# Saul Wold -- Distro leader
# Susie Li -- engineer manager
# Kevin Tian -- distro leader
# Jessica Zhang -- SDK leader
# QA Leader

=== Bug Data Reporting ===
Defect Data is tracked and presented to the PDT meeting on a weekly basis by QA team. Any escalation items should be discussed and resolved in the PDT meeting.

=== External Owned Bug Triage ===
There might be some bugs owned by external developers. These bugs' triage results will be sent to Yocto public mailing list weekly.

=== Re-Triage for Next Milestone and Release ===
After a new milestone, there will be a time to review all medium priority bugs and set new Priority for next coming milestone.
After a new release, there will be a time to review all low priority bugs and set new Priority for next coming release.

== Feature Request Process ==
New feature request should be applied through Bugzilla as a bug. User could select corresponding Severity to indicate how important the feature is. User needs to follow Feature Request template to submit new request. Triage chairman will mark new feature request bug priority to '''FEAT'''.

There will be two important feature request review time per year in Aug. and Jan. (2 months before current release). In the review period, there will be 2~4 times review meetings by CCB. CCB will decide new features which will be included in next release, that will be released 8 months later. If feature request missed the review period, in theory it will be missed in next release. Any approved new feature will be reset Priority value and Target Version value. Non approved feature will keep "FEAT" priority.

=== Change Control Board ===
Following people should join CCB to review new feature request.
PME(Product Marketing Engineer), PM, Architect, Managers, Key developer and QA leader

=== Feature Request Bug Requirement ===
Feature request bug should be added specific Keywords in subject and Keywords field.

Following message should be added at the beginning of subject.
[FEAT_REQ Company Yocto_Target_Version]

For example: [FEAT_REQ xxx 1.0] Add Connman for network connection.

Following words should be added in Keywords field.
FEATURE_REQUEST

=== Feature Request Bug Template ===
<pre>
1. Feature Description:

2. Feature Present Code Status(including location and version):

3. Code License (e.g. GPLv2):

4. Business Impaction:

5. Other Justification:

</pre>

Bugzilla Configuration and Bug Tracking

2011-11-22T20:56:43Z

Scottrifw: /* Classification Product and Components */

Yocto Project Bug Process version

{|border="1"
|Version|| Modifier || Comments
|-
| 0.3 || Yongkang You || Initial Version
|-
| 0.5 || Yongkang You || Apply comments from Richard, Dave and Susie. Add Feature Request Process and Add a new Priority "FEAT" for it.
|-
| 0.8 || Yongkang You || Internal review and agree bug life cycle and bug Triage process.
|-
| 0.85 || Saul Wold || Add Bug Status / Sub-Status Definitions.
|-
| 0.9 || davest || Cleanup for 0.9 release.
|}

You should also read our [[Community Guidelines]] before submitting bugs.

------
== Defect Management ==
Yocto uses '''[http://www.bugzilla.org/ Bugzilla]''' as its defect tracking tool.

=== Home Address ===
http://bugzilla.yoctoproject.org

=== Get an Account ===
Anyone working on the Yocto project can query existing bugs in Bugzilla. You must have an account to submit a bug, edit a bug, or take action on a bug.

To set up an account, go to the '''[http://www.bugzilla.yoctoproject.org/ Yocto Bugzilla]''' home page and click on "New Account" in the footer area. Follow the directions there to set up your account.

=== Classification, Product and Components ===
Yocto Bugzilla uses these Classifications, Products and Components. Configurations change over time and should be defined by module owners:

<pre>
+=======================+======================+======================+
| Classification | Product | Components |
|=====================================================================|
| Yocto Projects | Anjuta Plug-in | General |
| +----------------------+----------------------|
| | BSPs | General |
| +----------------------+----------------------|
| | Cross-prelink | General |
| | +----------------------|
| | | Poky Integration |
| +----------------------+----------------------|
| | Documentation | Handbook |
| | +----------------------|
| | | Other |
| | +----------------------|
| | | PRD |
| | +----------------------|
| | | SDK |
| +----------------------+----------------------|
| | Eclipse Plug-in | General |
| +----------------------+----------------------|
| | Kernel | Build |
| | +----------------------|
| | | Configuration |
| | +----------------------|
| | | General |
| | +----------------------|
| | | Runtime |
| +----------------------+----------------------|
| | Pseudo | General |
| | +----------------------|
| | | Poky Configuration |
| +----------------------+----------------------|
| | Runtime Distribution | Installation |
| | +----------------------|
| | | System Startup |
| +----------------------+----------------------|
| | SDK Tools | General |
| +----------------------+----------------------|
| | Swabber | General |
| | +----------------------|
| | | Poky Integration |
| +----------------------+----------------------|
| | Yocto Test Suite | General |
|-----------------------+----------------------+----------------------|
| Infrastructure | AutoBuilder | General |
| +----------------------+----------------------|
| | Bugzilla | General |
| +----------------------+----------------------|
| | Website | General |
|-----------------------+----------------------+----------------------|
| Poky | ADT | General |
| +----------------------+----------------------|
| | Build System | BitBake |
| | +----------------------|
| | | Configuration |
| | +----------------------|
| | | General |
| | +----------------------|
| | | Hob |
| | +----------------------|
| | | Image Creator |
| | +----------------------|
| | | Layers |
| +----------------------+----------------------|
| | Security | General |
|-----------------------+----------------------+----------------------|
| Yocto Metadata Layers | Layers | dlna |
| | +----------------------|
| | | extra |
| | +----------------------|
| | | general |
| | +----------------------|
| | | intel |
| | +----------------------|
| | | linaro |
| | +----------------------|
| | | xilinx |
| |----------------------+----------------------|
| | Meta Recipes | connectivity |
| | +----------------------|
| | | core |
| | +----------------------|
| | | demoapps |
| | +----------------------|
| | | devtools / toolchain |
| | +----------------------|
| | | general |
| | +----------------------|
| | | graphics |
| | +----------------------|
| | | kernel |
| | +----------------------|
| | | multimedia |
| |----------------------+----------------------|
| | Sato | General |
| | +----------------------|
| | | gtk-engine |
| | +----------------------|
| | | Icon |
| | +----------------------|
| | | Matchbox |
|-----------------------+----------------------+----------------------+
</pre>

=== Hardware ===

* All
* PC
* Netbook
* e-Menlow
* Blacksand
* JasperForest
* TunnelCreek
* Macintosh
* Beagleboard
* mpc8315e-rdb
* Routerstationpro
* Other

=== Version ===
The versions can vary depending on the Component and Project. Here is a list of current selections:

* 0.9
* 1.0-beta
* 1.0
* 1.1-beta
* 1.1
* 1.2

=== Priority and Severity ===
* The priority classifies bug fixing order. It can not be set when open a bug. It was set when doing Triage. The Priorities should be following 5 kinds.
** High -- Bug fixing is planned within 2 weeks, no later than the up-coming milestone, or critical issue for out of cycle release. e.g. highly reproducible crash issues (system or related to key apps/components need to deliver in the upcoming milestone); issues which cause major function loss of a specific feature which is POR of the up-comping milestone; issues which are easy to hit by user and greatly impact user experience or customer requirements; and urgent security issues which needs to be fixed in last release.
** Medium -- Bug fixing is planned before the milestone and must be fixed before the release is finalized.
** Low -- Bug fixing is not planned for the up-coming project release. Non POR feature request, hard to reproduce will fall into this category.
** Undecided -- New reported bug is '''undecided''', before Triage.
** FEAT -- A feature request bug, which isn't approved for future release yet. It will be changed to real priority after Change Control Board (CCB) approves it.
** Note: High impact but Low Priority bugs can be documented in the release notes.

* The Severity indicates bug's impacting level to reporter. It can be categorized to following 5 kinds. The '''default''' is '''Normal'''.
** Critical -- Crashes, hang, loss of data, negative impact to other components, memory leak etc.
** Major -- Major loss of functionality of POR
** Normal -- Regular issue, some loss of functionality under certain circumstance
** Minor -- Minor loss of functionality, or issues with easy workaround available
** Enhancement -- Request for enhancement work

=== Bug Status ===
* Open -- A new reported bug with default assignee.
* ACCEPTED-- The assigned developer has reviewed and accept the bug.
* Resolved -- bug is fixed or closed by other resolved method.
** Fixed -- This is fixed and in the master branch will be set automatically during build
** NotABug -- This is verified as not a bug
** WontFix -- We will not fix this bug, possibly because a newer package fixes it
** Duplicate -- Duplicate of another bug, possibly different failure mode
** Invalid -- The bug is invalid, sometimes this is used when the author of the bug does not provide accurate information, these will be reviewed by Triage team, and could be changed to '''NeedInfo'''
** Obsolete -- The bug is obsolete, old bug that is no longer appropriate, or a package that is depercated.
** WorksForMe -- The bug does not appear when tested by engineer, more appropriately, this may be '''NeedInfo'''
* Verified -- bug is double checked and agreed with the resolved method by original reporter.
* Reopen: bug can be reopened, if it is in Resolved, Verified or Close stage.
* NeedInfo: bug needs be set to NeedInfo, if there is important information missing to understand or reproduce bug.
* WaitForUpstream: The owner does bug analysis and finds this bug comes from upstream. Owner can post a new bug in upstream bugzilla, change status to '''WaitForUpstream''' and add the upstream bugzilla URL in comment area. When upstream bug is fixed, put the bug fixing into Yocto repository. After the patch is built into weekly build, change its status to Resolved/FIXED.
* '''Close''' stage is not used in normal bug life. When reported two same bugs by wrongly click button twice, the 2nd one can be closed. Generally it(close stage) is just for keeping wrong bug out of scrub cycle and statistic.

=== Bug Life Cycle ===
A normal Bug's life is started from '''Open''' and ended by '''Verified'''. Triage team will select "verified: Program Management", after confirm the verification.

[[Image:Yocto_Bug_Life_Cycle.jpg|frame|none|Bug Life Cycle]]

Bug should be marked as Resolved/Fixed, after its fixing patch is built into formal build (weekly build or milestone build). There is an automation method to update bugs to "RESOVLED/FIXED" status by following steps.
# Developer fixed bug and check in patch to his ''contrib'' branch with special words in commit description: '''[BUGFIX #4321]'''
# Developer asked tree gatekeeper to pull patch.
# Release Engineer do formal build. The build script will read new commit description and find out bug ID.
# Build script will notify bugzilla and update bugs status to "RESOLVE/FIXED"

If a weekly build includes a new commit, which reverts another patch, there should be a tool to judge whether the reverted patch summary include any bug fixing ID. If the reverted patch does include any bug fixing, the bug should be reopen.

[[Image:Yocto_Bug_Fix_Process.PNG|frame|none|Bug Fixing Process]]

=== Defect Submission ===
Defects may be entered by anyone working on the Yocto. Bug submission should include severity, thorough environment information, proper and clear reproduce steps and logs.

=== Bug Group ===
Bug group is used to control bug visibility. Couple of groups will be set up. When reporting or updating bugs, group check box could be edit.

* '''Security''' -- Bugs can only be viewed by Security group user. Bugs will be in Security Group, when it is reported to security component.
* No_Group_Check_Box_Selection-- Bugs are public. (Be careful)''' '''
* TBD

=== Bug Reporter ===
* Provide clear and simple bug subject. It is recommended to put a '''Fault Component Name''' with brackets at the beginning of subject as a keyword, e.g. [Poky].
* Validate all fields are correct. If fields are not filled out correctly, the bug might be sent back to the submitter.
* Judge the right Severity.
* Adds any additional information from the bug scrub.
* Assigns the bug to the correct person to disposition the bug.
* If a bug is too vague to make a determination then the Resolution Field of the bug will be set to need more information and sent back the bug submitter.
* '''Bug Priority can't be set when report a bug. It will be set when doing bug Triage'''

=== Bug Owner ===
* Review bugs to check if there are enough information. If not, set the bug to NeedInfo. Try to reproduce bug, if there are clear steps.
* Based on bug Priority and Severity to fix bugs in time. For example, High Priority bugs usually should be fixed in 2 weeks. High/critical bugs should be fixed as soon as possible, which has impaction to whole system.
* Update bugs in time with comments. Set the bug to Fixed and provide the tree/commit info, after bug fixing. '''Bug should not be marked as "fix", if patch is not checked into repository. '''

== Bug Tracking ==
Yocto is a cross many Geo project. Single bug scrub meeting is not easy to maintain. Considering Embedded Linux will be a big project, it brings a concept named ''Triage'' to effectively track bug. Triage is mainly for setting new bug priority. Triage virtual team will based on bug's severity, features and schedule to suggest bug fixing priority. Developer teams will receive triage email in time. If reach agreement, bugs will be followed up based on priority. Team manager should be responsible for monitoring the bug fixing schedule to align with related priority. This process is to make the high priority bug be fixed in time and reduce the schedule risk. There are still separated bug review or discussion meeting, which is held through Jabber.

=== Triage Management Team ===
* Program Manager
* Architect
* Engineering Manager
* QA leader

=== Triage Process ===
The triage process will be held frequently to make sure new coming bugs are set with correct priority in time. Triage chairman scrubs new bugs and set priority everyday. PDT meeting will review past week's overall triage result once per week.

The Bugzilla system will send emails to component owner and related engineers about creating or changing of bugs. Before Triage, new bugs could be discussed and even fixed.

'''Bug Triage Process '''

[[Image:bug_triage_process.PNG|frame|none|bug traiage process]]

'''Triage email example'''
<pre>
To: Yocto OTC
Subject: [Yocto-bug-triage] Bug Triage Review - ww26.1

Manager: MGR_A
==================
Bug ID Sev Priority Assignee Summary
1 maj High dev_A [Poky] XYZ Build Failure

Manager: MGR_B
====================
Bug ID Sev Priority Assignee Summary
2 maj High dev_B [SDK] ABC button error
3 nor Medium dev_C [X] Can't start X
</pre>

=== Responsibility ===
* Triage Chairman
** Triage new bugs: set initial priority, correct bug component and owner and mark duplicated bugs.
** Monitor overall bug fix progress with indicators: find out aging bugs.
** Send out triage result email to yocto mailing list (or Triage management team member) for review.
** Escalate aging high priority open bugs.
* Triage Management Team
** Development/Distribution managers are mandatory to review triage result and commit to fix
* Development/Distribution Manager
** Ensure developer/distro ACCEPT bugs in bugzilla within 3 days
** Commit developer to fix high priority bugs
* Program Manager
** Coordinate and push bugs to be fixed in time
* Triage Decision Forum (PDT Meeting)
** Make decision on controversial bugs
** Review and Monitor previous decision
** Triage Chairman update bugzilla based on decision
** Discuss and approve bug whose priority needs to be downgraded

=== Triage Chairman ===
Triage chairman role will be rotated in distribution leaders, engineer manager, SDK leader and QA leader. Each chairman will own 1 milestone cycle. Triage chairman starts from Yocto 0.9 M2 cycle and rotate in following order.
# Saul Wold -- Distro leader
# Susie Li -- engineer manager
# Kevin Tian -- distro leader
# Jessica Zhang -- SDK leader
# QA Leader

=== Bug Data Reporting ===
Defect Data is tracked and presented to the PDT meeting on a weekly basis by QA team. Any escalation items should be discussed and resolved in the PDT meeting.

=== External Owned Bug Triage ===
There might be some bugs owned by external developers. These bugs' triage results will be sent to Yocto public mailing list weekly.

=== Re-Triage for Next Milestone and Release ===
After a new milestone, there will be a time to review all medium priority bugs and set new Priority for next coming milestone.
After a new release, there will be a time to review all low priority bugs and set new Priority for next coming release.

== Feature Request Process ==
New feature request should be applied through Bugzilla as a bug. User could select corresponding Severity to indicate how important the feature is. User needs to follow Feature Request template to submit new request. Triage chairman will mark new feature request bug priority to '''FEAT'''.

There will be two important feature request review time per year in Aug. and Jan. (2 months before current release). In the review period, there will be 2~4 times review meetings by CCB. CCB will decide new features which will be included in next release, that will be released 8 months later. If feature request missed the review period, in theory it will be missed in next release. Any approved new feature will be reset Priority value and Target Version value. Non approved feature will keep "FEAT" priority.

=== Change Control Board ===
Following people should join CCB to review new feature request.
PME(Product Marketing Engineer), PM, Architect, Managers, Key developer and QA leader

=== Feature Request Bug Requirement ===
Feature request bug should be added specific Keywords in subject and Keywords field.

Following message should be added at the beginning of subject.
[FEAT_REQ Company Yocto_Target_Version]

For example: [FEAT_REQ xxx 1.0] Add Connman for network connection.

Following words should be added in Keywords field.
FEATURE_REQUEST

=== Feature Request Bug Template ===
<pre>
1. Feature Description:

2. Feature Present Code Status(including location and version):

3. Code License (e.g. GPLv2):

4. Business Impaction:

5. Other Justification:

</pre>

Bugzilla Configuration and Bug Tracking

2011-11-22T20:56:22Z

Scottrifw: /* Version */

Yocto Project Bug Process version

{|border="1"
|Version|| Modifier || Comments
|-
| 0.3 || Yongkang You || Initial Version
|-
| 0.5 || Yongkang You || Apply comments from Richard, Dave and Susie. Add Feature Request Process and Add a new Priority "FEAT" for it.
|-
| 0.8 || Yongkang You || Internal review and agree bug life cycle and bug Triage process.
|-
| 0.85 || Saul Wold || Add Bug Status / Sub-Status Definitions.
|-
| 0.9 || davest || Cleanup for 0.9 release.
|}

You should also read our [[Community Guidelines]] before submitting bugs.

------
== Defect Management ==
Yocto uses '''[http://www.bugzilla.org/ Bugzilla]''' as its defect tracking tool.

=== Home Address ===
http://bugzilla.yoctoproject.org

=== Get an Account ===
Anyone working on the Yocto project can query existing bugs in Bugzilla. You must have an account to submit a bug, edit a bug, or take action on a bug.

To set up an account, go to the '''[http://www.bugzilla.yoctoproject.org/ Yocto Bugzilla]''' home page and click on "New Account" in the footer area. Follow the directions there to set up your account.

=== Classification Product and Components ===
Yocto Bugzilla uses these Classifications, Products and Components. Configurations change over time and should be defined by module owners:

<pre>
+=======================+======================+======================+
| Classification | Product | Components |
|=====================================================================|
| Yocto Projects | Anjuta Plug-in | General |
| +----------------------+----------------------|
| | BSPs | General |
| +----------------------+----------------------|
| | Cross-prelink | General |
| | +----------------------|
| | | Poky Integration |
| +----------------------+----------------------|
| | Documentation | Handbook |
| | +----------------------|
| | | Other |
| | +----------------------|
| | | PRD |
| | +----------------------|
| | | SDK |
| +----------------------+----------------------|
| | Eclipse Plug-in | General |
| +----------------------+----------------------|
| | Kernel | Build |
| | +----------------------|
| | | Configuration |
| | +----------------------|
| | | General |
| | +----------------------|
| | | Runtime |
| +----------------------+----------------------|
| | Pseudo | General |
| | +----------------------|
| | | Poky Configuration |
| +----------------------+----------------------|
| | Runtime Distribution | Installation |
| | +----------------------|
| | | System Startup |
| +----------------------+----------------------|
| | SDK Tools | General |
| +----------------------+----------------------|
| | Swabber | General |
| | +----------------------|
| | | Poky Integration |
| +----------------------+----------------------|
| | Yocto Test Suite | General |
|-----------------------+----------------------+----------------------|
| Infrastructure | AutoBuilder | General |
| +----------------------+----------------------|
| | Bugzilla | General |
| +----------------------+----------------------|
| | Website | General |
|-----------------------+----------------------+----------------------|
| Poky | ADT | General |
| +----------------------+----------------------|
| | Build System | BitBake |
| | +----------------------|
| | | Configuration |
| | +----------------------|
| | | General |
| | +----------------------|
| | | Hob |
| | +----------------------|
| | | Image Creator |
| | +----------------------|
| | | Layers |
| +----------------------+----------------------|
| | Security | General |
|-----------------------+----------------------+----------------------|
| Yocto Metadata Layers | Layers | dlna |
| | +----------------------|
| | | extra |
| | +----------------------|
| | | general |
| | +----------------------|
| | | intel |
| | +----------------------|
| | | linaro |
| | +----------------------|
| | | xilinx |
| |----------------------+----------------------|
| | Meta Recipes | connectivity |
| | +----------------------|
| | | core |
| | +----------------------|
| | | demoapps |
| | +----------------------|
| | | devtools / toolchain |
| | +----------------------|
| | | general |
| | +----------------------|
| | | graphics |
| | +----------------------|
| | | kernel |
| | +----------------------|
| | | multimedia |
| |----------------------+----------------------|
| | Sato | General |
| | +----------------------|
| | | gtk-engine |
| | +----------------------|
| | | Icon |
| | +----------------------|
| | | Matchbox |
|-----------------------+----------------------+----------------------+
</pre>

=== Hardware ===

* All
* PC
* Netbook
* e-Menlow
* Blacksand
* JasperForest
* TunnelCreek
* Macintosh
* Beagleboard
* mpc8315e-rdb
* Routerstationpro
* Other

=== Version ===
The versions can vary depending on the Component and Project. Here is a list of current selections:

* 0.9
* 1.0-beta
* 1.0
* 1.1-beta
* 1.1
* 1.2

=== Priority and Severity ===
* The priority classifies bug fixing order. It can not be set when open a bug. It was set when doing Triage. The Priorities should be following 5 kinds.
** High -- Bug fixing is planned within 2 weeks, no later than the up-coming milestone, or critical issue for out of cycle release. e.g. highly reproducible crash issues (system or related to key apps/components need to deliver in the upcoming milestone); issues which cause major function loss of a specific feature which is POR of the up-comping milestone; issues which are easy to hit by user and greatly impact user experience or customer requirements; and urgent security issues which needs to be fixed in last release.
** Medium -- Bug fixing is planned before the milestone and must be fixed before the release is finalized.
** Low -- Bug fixing is not planned for the up-coming project release. Non POR feature request, hard to reproduce will fall into this category.
** Undecided -- New reported bug is '''undecided''', before Triage.
** FEAT -- A feature request bug, which isn't approved for future release yet. It will be changed to real priority after Change Control Board (CCB) approves it.
** Note: High impact but Low Priority bugs can be documented in the release notes.

* The Severity indicates bug's impacting level to reporter. It can be categorized to following 5 kinds. The '''default''' is '''Normal'''.
** Critical -- Crashes, hang, loss of data, negative impact to other components, memory leak etc.
** Major -- Major loss of functionality of POR
** Normal -- Regular issue, some loss of functionality under certain circumstance
** Minor -- Minor loss of functionality, or issues with easy workaround available
** Enhancement -- Request for enhancement work

=== Bug Status ===
* Open -- A new reported bug with default assignee.
* ACCEPTED-- The assigned developer has reviewed and accept the bug.
* Resolved -- bug is fixed or closed by other resolved method.
** Fixed -- This is fixed and in the master branch will be set automatically during build
** NotABug -- This is verified as not a bug
** WontFix -- We will not fix this bug, possibly because a newer package fixes it
** Duplicate -- Duplicate of another bug, possibly different failure mode
** Invalid -- The bug is invalid, sometimes this is used when the author of the bug does not provide accurate information, these will be reviewed by Triage team, and could be changed to '''NeedInfo'''
** Obsolete -- The bug is obsolete, old bug that is no longer appropriate, or a package that is depercated.
** WorksForMe -- The bug does not appear when tested by engineer, more appropriately, this may be '''NeedInfo'''
* Verified -- bug is double checked and agreed with the resolved method by original reporter.
* Reopen: bug can be reopened, if it is in Resolved, Verified or Close stage.
* NeedInfo: bug needs be set to NeedInfo, if there is important information missing to understand or reproduce bug.
* WaitForUpstream: The owner does bug analysis and finds this bug comes from upstream. Owner can post a new bug in upstream bugzilla, change status to '''WaitForUpstream''' and add the upstream bugzilla URL in comment area. When upstream bug is fixed, put the bug fixing into Yocto repository. After the patch is built into weekly build, change its status to Resolved/FIXED.
* '''Close''' stage is not used in normal bug life. When reported two same bugs by wrongly click button twice, the 2nd one can be closed. Generally it(close stage) is just for keeping wrong bug out of scrub cycle and statistic.

=== Bug Life Cycle ===
A normal Bug's life is started from '''Open''' and ended by '''Verified'''. Triage team will select "verified: Program Management", after confirm the verification.

[[Image:Yocto_Bug_Life_Cycle.jpg|frame|none|Bug Life Cycle]]

Bug should be marked as Resolved/Fixed, after its fixing patch is built into formal build (weekly build or milestone build). There is an automation method to update bugs to "RESOVLED/FIXED" status by following steps.
# Developer fixed bug and check in patch to his ''contrib'' branch with special words in commit description: '''[BUGFIX #4321]'''
# Developer asked tree gatekeeper to pull patch.
# Release Engineer do formal build. The build script will read new commit description and find out bug ID.
# Build script will notify bugzilla and update bugs status to "RESOLVE/FIXED"

If a weekly build includes a new commit, which reverts another patch, there should be a tool to judge whether the reverted patch summary include any bug fixing ID. If the reverted patch does include any bug fixing, the bug should be reopen.

[[Image:Yocto_Bug_Fix_Process.PNG|frame|none|Bug Fixing Process]]

=== Defect Submission ===
Defects may be entered by anyone working on the Yocto. Bug submission should include severity, thorough environment information, proper and clear reproduce steps and logs.

=== Bug Group ===
Bug group is used to control bug visibility. Couple of groups will be set up. When reporting or updating bugs, group check box could be edit.

* '''Security''' -- Bugs can only be viewed by Security group user. Bugs will be in Security Group, when it is reported to security component.
* No_Group_Check_Box_Selection-- Bugs are public. (Be careful)''' '''
* TBD

=== Bug Reporter ===
* Provide clear and simple bug subject. It is recommended to put a '''Fault Component Name''' with brackets at the beginning of subject as a keyword, e.g. [Poky].
* Validate all fields are correct. If fields are not filled out correctly, the bug might be sent back to the submitter.
* Judge the right Severity.
* Adds any additional information from the bug scrub.
* Assigns the bug to the correct person to disposition the bug.
* If a bug is too vague to make a determination then the Resolution Field of the bug will be set to need more information and sent back the bug submitter.
* '''Bug Priority can't be set when report a bug. It will be set when doing bug Triage'''

=== Bug Owner ===
* Review bugs to check if there are enough information. If not, set the bug to NeedInfo. Try to reproduce bug, if there are clear steps.
* Based on bug Priority and Severity to fix bugs in time. For example, High Priority bugs usually should be fixed in 2 weeks. High/critical bugs should be fixed as soon as possible, which has impaction to whole system.
* Update bugs in time with comments. Set the bug to Fixed and provide the tree/commit info, after bug fixing. '''Bug should not be marked as "fix", if patch is not checked into repository. '''

== Bug Tracking ==
Yocto is a cross many Geo project. Single bug scrub meeting is not easy to maintain. Considering Embedded Linux will be a big project, it brings a concept named ''Triage'' to effectively track bug. Triage is mainly for setting new bug priority. Triage virtual team will based on bug's severity, features and schedule to suggest bug fixing priority. Developer teams will receive triage email in time. If reach agreement, bugs will be followed up based on priority. Team manager should be responsible for monitoring the bug fixing schedule to align with related priority. This process is to make the high priority bug be fixed in time and reduce the schedule risk. There are still separated bug review or discussion meeting, which is held through Jabber.

=== Triage Management Team ===
* Program Manager
* Architect
* Engineering Manager
* QA leader

=== Triage Process ===
The triage process will be held frequently to make sure new coming bugs are set with correct priority in time. Triage chairman scrubs new bugs and set priority everyday. PDT meeting will review past week's overall triage result once per week.

The Bugzilla system will send emails to component owner and related engineers about creating or changing of bugs. Before Triage, new bugs could be discussed and even fixed.

'''Bug Triage Process '''

[[Image:bug_triage_process.PNG|frame|none|bug traiage process]]

'''Triage email example'''
<pre>
To: Yocto OTC
Subject: [Yocto-bug-triage] Bug Triage Review - ww26.1

Manager: MGR_A
==================
Bug ID Sev Priority Assignee Summary
1 maj High dev_A [Poky] XYZ Build Failure

Manager: MGR_B
====================
Bug ID Sev Priority Assignee Summary
2 maj High dev_B [SDK] ABC button error
3 nor Medium dev_C [X] Can't start X
</pre>

=== Responsibility ===
* Triage Chairman
** Triage new bugs: set initial priority, correct bug component and owner and mark duplicated bugs.
** Monitor overall bug fix progress with indicators: find out aging bugs.
** Send out triage result email to yocto mailing list (or Triage management team member) for review.
** Escalate aging high priority open bugs.
* Triage Management Team
** Development/Distribution managers are mandatory to review triage result and commit to fix
* Development/Distribution Manager
** Ensure developer/distro ACCEPT bugs in bugzilla within 3 days
** Commit developer to fix high priority bugs
* Program Manager
** Coordinate and push bugs to be fixed in time
* Triage Decision Forum (PDT Meeting)
** Make decision on controversial bugs
** Review and Monitor previous decision
** Triage Chairman update bugzilla based on decision
** Discuss and approve bug whose priority needs to be downgraded

=== Triage Chairman ===
Triage chairman role will be rotated in distribution leaders, engineer manager, SDK leader and QA leader. Each chairman will own 1 milestone cycle. Triage chairman starts from Yocto 0.9 M2 cycle and rotate in following order.
# Saul Wold -- Distro leader
# Susie Li -- engineer manager
# Kevin Tian -- distro leader
# Jessica Zhang -- SDK leader
# QA Leader

=== Bug Data Reporting ===
Defect Data is tracked and presented to the PDT meeting on a weekly basis by QA team. Any escalation items should be discussed and resolved in the PDT meeting.

=== External Owned Bug Triage ===
There might be some bugs owned by external developers. These bugs' triage results will be sent to Yocto public mailing list weekly.

=== Re-Triage for Next Milestone and Release ===
After a new milestone, there will be a time to review all medium priority bugs and set new Priority for next coming milestone.
After a new release, there will be a time to review all low priority bugs and set new Priority for next coming release.

== Feature Request Process ==
New feature request should be applied through Bugzilla as a bug. User could select corresponding Severity to indicate how important the feature is. User needs to follow Feature Request template to submit new request. Triage chairman will mark new feature request bug priority to '''FEAT'''.

There will be two important feature request review time per year in Aug. and Jan. (2 months before current release). In the review period, there will be 2~4 times review meetings by CCB. CCB will decide new features which will be included in next release, that will be released 8 months later. If feature request missed the review period, in theory it will be missed in next release. Any approved new feature will be reset Priority value and Target Version value. Non approved feature will keep "FEAT" priority.

=== Change Control Board ===
Following people should join CCB to review new feature request.
PME(Product Marketing Engineer), PM, Architect, Managers, Key developer and QA leader

=== Feature Request Bug Requirement ===
Feature request bug should be added specific Keywords in subject and Keywords field.

Following message should be added at the beginning of subject.
[FEAT_REQ Company Yocto_Target_Version]

For example: [FEAT_REQ xxx 1.0] Add Connman for network connection.

Following words should be added in Keywords field.
FEATURE_REQUEST

=== Feature Request Bug Template ===
<pre>
1. Feature Description:

2. Feature Present Code Status(including location and version):

3. Code License (e.g. GPLv2):

4. Business Impaction:

5. Other Justification:

</pre>

Bugzilla Configuration and Bug Tracking

2011-11-22T20:52:49Z

Scottrifw: /* Version and Target */

Yocto Project Bug Process version

{|border="1"
|Version|| Modifier || Comments
|-
| 0.3 || Yongkang You || Initial Version
|-
| 0.5 || Yongkang You || Apply comments from Richard, Dave and Susie. Add Feature Request Process and Add a new Priority "FEAT" for it.
|-
| 0.8 || Yongkang You || Internal review and agree bug life cycle and bug Triage process.
|-
| 0.85 || Saul Wold || Add Bug Status / Sub-Status Definitions.
|-
| 0.9 || davest || Cleanup for 0.9 release.
|}

You should also read our [[Community Guidelines]] before submitting bugs.

------
== Defect Management ==
Yocto uses '''[http://www.bugzilla.org/ Bugzilla]''' as its defect tracking tool.

=== Home Address ===
http://bugzilla.yoctoproject.org

=== Get an Account ===
Anyone working on the Yocto project can query existing bugs in Bugzilla. You must have an account to submit a bug, edit a bug, or take action on a bug.

To set up an account, go to the '''[http://www.bugzilla.yoctoproject.org/ Yocto Bugzilla]''' home page and click on "New Account" in the footer area. Follow the directions there to set up your account.

=== Classification Product and Components ===
Yocto Bugzilla uses these Classifications, Products and Components. Configurations change over time and should be defined by module owners:

<pre>
+=======================+======================+======================+
| Classification | Product | Components |
|=====================================================================|
| Yocto Projects | Anjuta Plug-in | General |
| +----------------------+----------------------|
| | BSPs | General |
| +----------------------+----------------------|
| | Cross-prelink | General |
| | +----------------------|
| | | Poky Integration |
| +----------------------+----------------------|
| | Documentation | Handbook |
| | +----------------------|
| | | Other |
| | +----------------------|
| | | PRD |
| | +----------------------|
| | | SDK |
| +----------------------+----------------------|
| | Eclipse Plug-in | General |
| +----------------------+----------------------|
| | Kernel | Build |
| | +----------------------|
| | | Configuration |
| | +----------------------|
| | | General |
| | +----------------------|
| | | Runtime |
| +----------------------+----------------------|
| | Pseudo | General |
| | +----------------------|
| | | Poky Configuration |
| +----------------------+----------------------|
| | Runtime Distribution | Installation |
| | +----------------------|
| | | System Startup |
| +----------------------+----------------------|
| | SDK Tools | General |
| +----------------------+----------------------|
| | Swabber | General |
| | +----------------------|
| | | Poky Integration |
| +----------------------+----------------------|
| | Yocto Test Suite | General |
|-----------------------+----------------------+----------------------|
| Infrastructure | AutoBuilder | General |
| +----------------------+----------------------|
| | Bugzilla | General |
| +----------------------+----------------------|
| | Website | General |
|-----------------------+----------------------+----------------------|
| Poky | ADT | General |
| +----------------------+----------------------|
| | Build System | BitBake |
| | +----------------------|
| | | Configuration |
| | +----------------------|
| | | General |
| | +----------------------|
| | | Hob |
| | +----------------------|
| | | Image Creator |
| | +----------------------|
| | | Layers |
| +----------------------+----------------------|
| | Security | General |
|-----------------------+----------------------+----------------------|
| Yocto Metadata Layers | Layers | dlna |
| | +----------------------|
| | | extra |
| | +----------------------|
| | | general |
| | +----------------------|
| | | intel |
| | +----------------------|
| | | linaro |
| | +----------------------|
| | | xilinx |
| |----------------------+----------------------|
| | Meta Recipes | connectivity |
| | +----------------------|
| | | core |
| | +----------------------|
| | | demoapps |
| | +----------------------|
| | | devtools / toolchain |
| | +----------------------|
| | | general |
| | +----------------------|
| | | graphics |
| | +----------------------|
| | | kernel |
| | +----------------------|
| | | multimedia |
| |----------------------+----------------------|
| | Sato | General |
| | +----------------------|
| | | gtk-engine |
| | +----------------------|
| | | Icon |
| | +----------------------|
| | | Matchbox |
|-----------------------+----------------------+----------------------+
</pre>

=== Hardware ===

* All
* PC
* Netbook
* e-Menlow
* Blacksand
* JasperForest
* TunnelCreek
* Macintosh
* Beagleboard
* mpc8315e-rdb
* Routerstationpro
* Other

=== Version ===
The versions include the following:

* 0.9
* 1.0
* 1.1-beta
* 1.2

=== Priority and Severity ===
* The priority classifies bug fixing order. It can not be set when open a bug. It was set when doing Triage. The Priorities should be following 5 kinds.
** High -- Bug fixing is planned within 2 weeks, no later than the up-coming milestone, or critical issue for out of cycle release. e.g. highly reproducible crash issues (system or related to key apps/components need to deliver in the upcoming milestone); issues which cause major function loss of a specific feature which is POR of the up-comping milestone; issues which are easy to hit by user and greatly impact user experience or customer requirements; and urgent security issues which needs to be fixed in last release.
** Medium -- Bug fixing is planned before the milestone and must be fixed before the release is finalized.
** Low -- Bug fixing is not planned for the up-coming project release. Non POR feature request, hard to reproduce will fall into this category.
** Undecided -- New reported bug is '''undecided''', before Triage.
** FEAT -- A feature request bug, which isn't approved for future release yet. It will be changed to real priority after Change Control Board (CCB) approves it.
** Note: High impact but Low Priority bugs can be documented in the release notes.

* The Severity indicates bug's impacting level to reporter. It can be categorized to following 5 kinds. The '''default''' is '''Normal'''.
** Critical -- Crashes, hang, loss of data, negative impact to other components, memory leak etc.
** Major -- Major loss of functionality of POR
** Normal -- Regular issue, some loss of functionality under certain circumstance
** Minor -- Minor loss of functionality, or issues with easy workaround available
** Enhancement -- Request for enhancement work

=== Bug Status ===
* Open -- A new reported bug with default assignee.
* ACCEPTED-- The assigned developer has reviewed and accept the bug.
* Resolved -- bug is fixed or closed by other resolved method.
** Fixed -- This is fixed and in the master branch will be set automatically during build
** NotABug -- This is verified as not a bug
** WontFix -- We will not fix this bug, possibly because a newer package fixes it
** Duplicate -- Duplicate of another bug, possibly different failure mode
** Invalid -- The bug is invalid, sometimes this is used when the author of the bug does not provide accurate information, these will be reviewed by Triage team, and could be changed to '''NeedInfo'''
** Obsolete -- The bug is obsolete, old bug that is no longer appropriate, or a package that is depercated.
** WorksForMe -- The bug does not appear when tested by engineer, more appropriately, this may be '''NeedInfo'''
* Verified -- bug is double checked and agreed with the resolved method by original reporter.
* Reopen: bug can be reopened, if it is in Resolved, Verified or Close stage.
* NeedInfo: bug needs be set to NeedInfo, if there is important information missing to understand or reproduce bug.
* WaitForUpstream: The owner does bug analysis and finds this bug comes from upstream. Owner can post a new bug in upstream bugzilla, change status to '''WaitForUpstream''' and add the upstream bugzilla URL in comment area. When upstream bug is fixed, put the bug fixing into Yocto repository. After the patch is built into weekly build, change its status to Resolved/FIXED.
* '''Close''' stage is not used in normal bug life. When reported two same bugs by wrongly click button twice, the 2nd one can be closed. Generally it(close stage) is just for keeping wrong bug out of scrub cycle and statistic.

=== Bug Life Cycle ===
A normal Bug's life is started from '''Open''' and ended by '''Verified'''. Triage team will select "verified: Program Management", after confirm the verification.

[[Image:Yocto_Bug_Life_Cycle.jpg|frame|none|Bug Life Cycle]]

Bug should be marked as Resolved/Fixed, after its fixing patch is built into formal build (weekly build or milestone build). There is an automation method to update bugs to "RESOVLED/FIXED" status by following steps.
# Developer fixed bug and check in patch to his ''contrib'' branch with special words in commit description: '''[BUGFIX #4321]'''
# Developer asked tree gatekeeper to pull patch.
# Release Engineer do formal build. The build script will read new commit description and find out bug ID.
# Build script will notify bugzilla and update bugs status to "RESOLVE/FIXED"

If a weekly build includes a new commit, which reverts another patch, there should be a tool to judge whether the reverted patch summary include any bug fixing ID. If the reverted patch does include any bug fixing, the bug should be reopen.

[[Image:Yocto_Bug_Fix_Process.PNG|frame|none|Bug Fixing Process]]

=== Defect Submission ===
Defects may be entered by anyone working on the Yocto. Bug submission should include severity, thorough environment information, proper and clear reproduce steps and logs.

=== Bug Group ===
Bug group is used to control bug visibility. Couple of groups will be set up. When reporting or updating bugs, group check box could be edit.

* '''Security''' -- Bugs can only be viewed by Security group user. Bugs will be in Security Group, when it is reported to security component.
* No_Group_Check_Box_Selection-- Bugs are public. (Be careful)''' '''
* TBD

=== Bug Reporter ===
* Provide clear and simple bug subject. It is recommended to put a '''Fault Component Name''' with brackets at the beginning of subject as a keyword, e.g. [Poky].
* Validate all fields are correct. If fields are not filled out correctly, the bug might be sent back to the submitter.
* Judge the right Severity.
* Adds any additional information from the bug scrub.
* Assigns the bug to the correct person to disposition the bug.
* If a bug is too vague to make a determination then the Resolution Field of the bug will be set to need more information and sent back the bug submitter.
* '''Bug Priority can't be set when report a bug. It will be set when doing bug Triage'''

=== Bug Owner ===
* Review bugs to check if there are enough information. If not, set the bug to NeedInfo. Try to reproduce bug, if there are clear steps.
* Based on bug Priority and Severity to fix bugs in time. For example, High Priority bugs usually should be fixed in 2 weeks. High/critical bugs should be fixed as soon as possible, which has impaction to whole system.
* Update bugs in time with comments. Set the bug to Fixed and provide the tree/commit info, after bug fixing. '''Bug should not be marked as "fix", if patch is not checked into repository. '''

== Bug Tracking ==
Yocto is a cross many Geo project. Single bug scrub meeting is not easy to maintain. Considering Embedded Linux will be a big project, it brings a concept named ''Triage'' to effectively track bug. Triage is mainly for setting new bug priority. Triage virtual team will based on bug's severity, features and schedule to suggest bug fixing priority. Developer teams will receive triage email in time. If reach agreement, bugs will be followed up based on priority. Team manager should be responsible for monitoring the bug fixing schedule to align with related priority. This process is to make the high priority bug be fixed in time and reduce the schedule risk. There are still separated bug review or discussion meeting, which is held through Jabber.

=== Triage Management Team ===
* Program Manager
* Architect
* Engineering Manager
* QA leader

=== Triage Process ===
The triage process will be held frequently to make sure new coming bugs are set with correct priority in time. Triage chairman scrubs new bugs and set priority everyday. PDT meeting will review past week's overall triage result once per week.

The Bugzilla system will send emails to component owner and related engineers about creating or changing of bugs. Before Triage, new bugs could be discussed and even fixed.

'''Bug Triage Process '''

[[Image:bug_triage_process.PNG|frame|none|bug traiage process]]

'''Triage email example'''
<pre>
To: Yocto OTC
Subject: [Yocto-bug-triage] Bug Triage Review - ww26.1

Manager: MGR_A
==================
Bug ID Sev Priority Assignee Summary
1 maj High dev_A [Poky] XYZ Build Failure

Manager: MGR_B
====================
Bug ID Sev Priority Assignee Summary
2 maj High dev_B [SDK] ABC button error
3 nor Medium dev_C [X] Can't start X
</pre>

=== Responsibility ===
* Triage Chairman
** Triage new bugs: set initial priority, correct bug component and owner and mark duplicated bugs.
** Monitor overall bug fix progress with indicators: find out aging bugs.
** Send out triage result email to yocto mailing list (or Triage management team member) for review.
** Escalate aging high priority open bugs.
* Triage Management Team
** Development/Distribution managers are mandatory to review triage result and commit to fix
* Development/Distribution Manager
** Ensure developer/distro ACCEPT bugs in bugzilla within 3 days
** Commit developer to fix high priority bugs
* Program Manager
** Coordinate and push bugs to be fixed in time
* Triage Decision Forum (PDT Meeting)
** Make decision on controversial bugs
** Review and Monitor previous decision
** Triage Chairman update bugzilla based on decision
** Discuss and approve bug whose priority needs to be downgraded

=== Triage Chairman ===
Triage chairman role will be rotated in distribution leaders, engineer manager, SDK leader and QA leader. Each chairman will own 1 milestone cycle. Triage chairman starts from Yocto 0.9 M2 cycle and rotate in following order.
# Saul Wold -- Distro leader
# Susie Li -- engineer manager
# Kevin Tian -- distro leader
# Jessica Zhang -- SDK leader
# QA Leader

=== Bug Data Reporting ===
Defect Data is tracked and presented to the PDT meeting on a weekly basis by QA team. Any escalation items should be discussed and resolved in the PDT meeting.

=== External Owned Bug Triage ===
There might be some bugs owned by external developers. These bugs' triage results will be sent to Yocto public mailing list weekly.

=== Re-Triage for Next Milestone and Release ===
After a new milestone, there will be a time to review all medium priority bugs and set new Priority for next coming milestone.
After a new release, there will be a time to review all low priority bugs and set new Priority for next coming release.

== Feature Request Process ==
New feature request should be applied through Bugzilla as a bug. User could select corresponding Severity to indicate how important the feature is. User needs to follow Feature Request template to submit new request. Triage chairman will mark new feature request bug priority to '''FEAT'''.

There will be two important feature request review time per year in Aug. and Jan. (2 months before current release). In the review period, there will be 2~4 times review meetings by CCB. CCB will decide new features which will be included in next release, that will be released 8 months later. If feature request missed the review period, in theory it will be missed in next release. Any approved new feature will be reset Priority value and Target Version value. Non approved feature will keep "FEAT" priority.

=== Change Control Board ===
Following people should join CCB to review new feature request.
PME(Product Marketing Engineer), PM, Architect, Managers, Key developer and QA leader

=== Feature Request Bug Requirement ===
Feature request bug should be added specific Keywords in subject and Keywords field.

Following message should be added at the beginning of subject.
[FEAT_REQ Company Yocto_Target_Version]

For example: [FEAT_REQ xxx 1.0] Add Connman for network connection.

Following words should be added in Keywords field.
FEATURE_REQUEST

=== Feature Request Bug Template ===
<pre>
1. Feature Description:

2. Feature Present Code Status(including location and version):

3. Code License (e.g. GPLv2):

4. Business Impaction:

5. Other Justification:

</pre>

Bugzilla Configuration and Bug Tracking

2011-11-22T20:49:13Z

Scottrifw: /* Hardware */

Yocto Project Bug Process version

{|border="1"
|Version|| Modifier || Comments
|-
| 0.3 || Yongkang You || Initial Version
|-
| 0.5 || Yongkang You || Apply comments from Richard, Dave and Susie. Add Feature Request Process and Add a new Priority "FEAT" for it.
|-
| 0.8 || Yongkang You || Internal review and agree bug life cycle and bug Triage process.
|-
| 0.85 || Saul Wold || Add Bug Status / Sub-Status Definitions.
|-
| 0.9 || davest || Cleanup for 0.9 release.
|}

You should also read our [[Community Guidelines]] before submitting bugs.

------
== Defect Management ==
Yocto uses '''[http://www.bugzilla.org/ Bugzilla]''' as its defect tracking tool.

=== Home Address ===
http://bugzilla.yoctoproject.org

=== Get an Account ===
Anyone working on the Yocto project can query existing bugs in Bugzilla. You must have an account to submit a bug, edit a bug, or take action on a bug.

To set up an account, go to the '''[http://www.bugzilla.yoctoproject.org/ Yocto Bugzilla]''' home page and click on "New Account" in the footer area. Follow the directions there to set up your account.

=== Classification Product and Components ===
Yocto Bugzilla uses these Classifications, Products and Components. Configurations change over time and should be defined by module owners:

<pre>
+=======================+======================+======================+
| Classification | Product | Components |
|=====================================================================|
| Yocto Projects | Anjuta Plug-in | General |
| +----------------------+----------------------|
| | BSPs | General |
| +----------------------+----------------------|
| | Cross-prelink | General |
| | +----------------------|
| | | Poky Integration |
| +----------------------+----------------------|
| | Documentation | Handbook |
| | +----------------------|
| | | Other |
| | +----------------------|
| | | PRD |
| | +----------------------|
| | | SDK |
| +----------------------+----------------------|
| | Eclipse Plug-in | General |
| +----------------------+----------------------|
| | Kernel | Build |
| | +----------------------|
| | | Configuration |
| | +----------------------|
| | | General |
| | +----------------------|
| | | Runtime |
| +----------------------+----------------------|
| | Pseudo | General |
| | +----------------------|
| | | Poky Configuration |
| +----------------------+----------------------|
| | Runtime Distribution | Installation |
| | +----------------------|
| | | System Startup |
| +----------------------+----------------------|
| | SDK Tools | General |
| +----------------------+----------------------|
| | Swabber | General |
| | +----------------------|
| | | Poky Integration |
| +----------------------+----------------------|
| | Yocto Test Suite | General |
|-----------------------+----------------------+----------------------|
| Infrastructure | AutoBuilder | General |
| +----------------------+----------------------|
| | Bugzilla | General |
| +----------------------+----------------------|
| | Website | General |
|-----------------------+----------------------+----------------------|
| Poky | ADT | General |
| +----------------------+----------------------|
| | Build System | BitBake |
| | +----------------------|
| | | Configuration |
| | +----------------------|
| | | General |
| | +----------------------|
| | | Hob |
| | +----------------------|
| | | Image Creator |
| | +----------------------|
| | | Layers |
| +----------------------+----------------------|
| | Security | General |
|-----------------------+----------------------+----------------------|
| Yocto Metadata Layers | Layers | dlna |
| | +----------------------|
| | | extra |
| | +----------------------|
| | | general |
| | +----------------------|
| | | intel |
| | +----------------------|
| | | linaro |
| | +----------------------|
| | | xilinx |
| |----------------------+----------------------|
| | Meta Recipes | connectivity |
| | +----------------------|
| | | core |
| | +----------------------|
| | | demoapps |
| | +----------------------|
| | | devtools / toolchain |
| | +----------------------|
| | | general |
| | +----------------------|
| | | graphics |
| | +----------------------|
| | | kernel |
| | +----------------------|
| | | multimedia |
| |----------------------+----------------------|
| | Sato | General |
| | +----------------------|
| | | gtk-engine |
| | +----------------------|
| | | Icon |
| | +----------------------|
| | | Matchbox |
|-----------------------+----------------------+----------------------+
</pre>

=== Hardware ===

* All
* PC
* Netbook
* e-Menlow
* Blacksand
* JasperForest
* TunnelCreek
* Macintosh
* Beagleboard
* mpc8315e-rdb
* Routerstationpro
* Other

=== Version and Target ===
* Version includes Yocto 0.9 and Yocto 1.0
* Target milestone includes 0.9_M1, 0.9_M2, 0.9_M3 and 0.9_M4

=== Priority and Severity ===
* The priority classifies bug fixing order. It can not be set when open a bug. It was set when doing Triage. The Priorities should be following 5 kinds.
** High -- Bug fixing is planned within 2 weeks, no later than the up-coming milestone, or critical issue for out of cycle release. e.g. highly reproducible crash issues (system or related to key apps/components need to deliver in the upcoming milestone); issues which cause major function loss of a specific feature which is POR of the up-comping milestone; issues which are easy to hit by user and greatly impact user experience or customer requirements; and urgent security issues which needs to be fixed in last release.
** Medium -- Bug fixing is planned before the milestone and must be fixed before the release is finalized.
** Low -- Bug fixing is not planned for the up-coming project release. Non POR feature request, hard to reproduce will fall into this category.
** Undecided -- New reported bug is '''undecided''', before Triage.
** FEAT -- A feature request bug, which isn't approved for future release yet. It will be changed to real priority after Change Control Board (CCB) approves it.
** Note: High impact but Low Priority bugs can be documented in the release notes.

* The Severity indicates bug's impacting level to reporter. It can be categorized to following 5 kinds. The '''default''' is '''Normal'''.
** Critical -- Crashes, hang, loss of data, negative impact to other components, memory leak etc.
** Major -- Major loss of functionality of POR
** Normal -- Regular issue, some loss of functionality under certain circumstance
** Minor -- Minor loss of functionality, or issues with easy workaround available
** Enhancement -- Request for enhancement work

=== Bug Status ===
* Open -- A new reported bug with default assignee.
* ACCEPTED-- The assigned developer has reviewed and accept the bug.
* Resolved -- bug is fixed or closed by other resolved method.
** Fixed -- This is fixed and in the master branch will be set automatically during build
** NotABug -- This is verified as not a bug
** WontFix -- We will not fix this bug, possibly because a newer package fixes it
** Duplicate -- Duplicate of another bug, possibly different failure mode
** Invalid -- The bug is invalid, sometimes this is used when the author of the bug does not provide accurate information, these will be reviewed by Triage team, and could be changed to '''NeedInfo'''
** Obsolete -- The bug is obsolete, old bug that is no longer appropriate, or a package that is depercated.
** WorksForMe -- The bug does not appear when tested by engineer, more appropriately, this may be '''NeedInfo'''
* Verified -- bug is double checked and agreed with the resolved method by original reporter.
* Reopen: bug can be reopened, if it is in Resolved, Verified or Close stage.
* NeedInfo: bug needs be set to NeedInfo, if there is important information missing to understand or reproduce bug.
* WaitForUpstream: The owner does bug analysis and finds this bug comes from upstream. Owner can post a new bug in upstream bugzilla, change status to '''WaitForUpstream''' and add the upstream bugzilla URL in comment area. When upstream bug is fixed, put the bug fixing into Yocto repository. After the patch is built into weekly build, change its status to Resolved/FIXED.
* '''Close''' stage is not used in normal bug life. When reported two same bugs by wrongly click button twice, the 2nd one can be closed. Generally it(close stage) is just for keeping wrong bug out of scrub cycle and statistic.

=== Bug Life Cycle ===
A normal Bug's life is started from '''Open''' and ended by '''Verified'''. Triage team will select "verified: Program Management", after confirm the verification.

[[Image:Yocto_Bug_Life_Cycle.jpg|frame|none|Bug Life Cycle]]

Bug should be marked as Resolved/Fixed, after its fixing patch is built into formal build (weekly build or milestone build). There is an automation method to update bugs to "RESOVLED/FIXED" status by following steps.
# Developer fixed bug and check in patch to his ''contrib'' branch with special words in commit description: '''[BUGFIX #4321]'''
# Developer asked tree gatekeeper to pull patch.
# Release Engineer do formal build. The build script will read new commit description and find out bug ID.
# Build script will notify bugzilla and update bugs status to "RESOLVE/FIXED"

If a weekly build includes a new commit, which reverts another patch, there should be a tool to judge whether the reverted patch summary include any bug fixing ID. If the reverted patch does include any bug fixing, the bug should be reopen.

[[Image:Yocto_Bug_Fix_Process.PNG|frame|none|Bug Fixing Process]]

=== Defect Submission ===
Defects may be entered by anyone working on the Yocto. Bug submission should include severity, thorough environment information, proper and clear reproduce steps and logs.

=== Bug Group ===
Bug group is used to control bug visibility. Couple of groups will be set up. When reporting or updating bugs, group check box could be edit.

* '''Security''' -- Bugs can only be viewed by Security group user. Bugs will be in Security Group, when it is reported to security component.
* No_Group_Check_Box_Selection-- Bugs are public. (Be careful)''' '''
* TBD

=== Bug Reporter ===
* Provide clear and simple bug subject. It is recommended to put a '''Fault Component Name''' with brackets at the beginning of subject as a keyword, e.g. [Poky].
* Validate all fields are correct. If fields are not filled out correctly, the bug might be sent back to the submitter.
* Judge the right Severity.
* Adds any additional information from the bug scrub.
* Assigns the bug to the correct person to disposition the bug.
* If a bug is too vague to make a determination then the Resolution Field of the bug will be set to need more information and sent back the bug submitter.
* '''Bug Priority can't be set when report a bug. It will be set when doing bug Triage'''

=== Bug Owner ===
* Review bugs to check if there are enough information. If not, set the bug to NeedInfo. Try to reproduce bug, if there are clear steps.
* Based on bug Priority and Severity to fix bugs in time. For example, High Priority bugs usually should be fixed in 2 weeks. High/critical bugs should be fixed as soon as possible, which has impaction to whole system.
* Update bugs in time with comments. Set the bug to Fixed and provide the tree/commit info, after bug fixing. '''Bug should not be marked as "fix", if patch is not checked into repository. '''

== Bug Tracking ==
Yocto is a cross many Geo project. Single bug scrub meeting is not easy to maintain. Considering Embedded Linux will be a big project, it brings a concept named ''Triage'' to effectively track bug. Triage is mainly for setting new bug priority. Triage virtual team will based on bug's severity, features and schedule to suggest bug fixing priority. Developer teams will receive triage email in time. If reach agreement, bugs will be followed up based on priority. Team manager should be responsible for monitoring the bug fixing schedule to align with related priority. This process is to make the high priority bug be fixed in time and reduce the schedule risk. There are still separated bug review or discussion meeting, which is held through Jabber.

=== Triage Management Team ===
* Program Manager
* Architect
* Engineering Manager
* QA leader

=== Triage Process ===
The triage process will be held frequently to make sure new coming bugs are set with correct priority in time. Triage chairman scrubs new bugs and set priority everyday. PDT meeting will review past week's overall triage result once per week.

The Bugzilla system will send emails to component owner and related engineers about creating or changing of bugs. Before Triage, new bugs could be discussed and even fixed.

'''Bug Triage Process '''

[[Image:bug_triage_process.PNG|frame|none|bug traiage process]]

'''Triage email example'''
<pre>
To: Yocto OTC
Subject: [Yocto-bug-triage] Bug Triage Review - ww26.1

Manager: MGR_A
==================
Bug ID Sev Priority Assignee Summary
1 maj High dev_A [Poky] XYZ Build Failure

Manager: MGR_B
====================
Bug ID Sev Priority Assignee Summary
2 maj High dev_B [SDK] ABC button error
3 nor Medium dev_C [X] Can't start X
</pre>

=== Responsibility ===
* Triage Chairman
** Triage new bugs: set initial priority, correct bug component and owner and mark duplicated bugs.
** Monitor overall bug fix progress with indicators: find out aging bugs.
** Send out triage result email to yocto mailing list (or Triage management team member) for review.
** Escalate aging high priority open bugs.
* Triage Management Team
** Development/Distribution managers are mandatory to review triage result and commit to fix
* Development/Distribution Manager
** Ensure developer/distro ACCEPT bugs in bugzilla within 3 days
** Commit developer to fix high priority bugs
* Program Manager
** Coordinate and push bugs to be fixed in time
* Triage Decision Forum (PDT Meeting)
** Make decision on controversial bugs
** Review and Monitor previous decision
** Triage Chairman update bugzilla based on decision
** Discuss and approve bug whose priority needs to be downgraded

=== Triage Chairman ===
Triage chairman role will be rotated in distribution leaders, engineer manager, SDK leader and QA leader. Each chairman will own 1 milestone cycle. Triage chairman starts from Yocto 0.9 M2 cycle and rotate in following order.
# Saul Wold -- Distro leader
# Susie Li -- engineer manager
# Kevin Tian -- distro leader
# Jessica Zhang -- SDK leader
# QA Leader

=== Bug Data Reporting ===
Defect Data is tracked and presented to the PDT meeting on a weekly basis by QA team. Any escalation items should be discussed and resolved in the PDT meeting.

=== External Owned Bug Triage ===
There might be some bugs owned by external developers. These bugs' triage results will be sent to Yocto public mailing list weekly.

=== Re-Triage for Next Milestone and Release ===
After a new milestone, there will be a time to review all medium priority bugs and set new Priority for next coming milestone.
After a new release, there will be a time to review all low priority bugs and set new Priority for next coming release.

== Feature Request Process ==
New feature request should be applied through Bugzilla as a bug. User could select corresponding Severity to indicate how important the feature is. User needs to follow Feature Request template to submit new request. Triage chairman will mark new feature request bug priority to '''FEAT'''.

There will be two important feature request review time per year in Aug. and Jan. (2 months before current release). In the review period, there will be 2~4 times review meetings by CCB. CCB will decide new features which will be included in next release, that will be released 8 months later. If feature request missed the review period, in theory it will be missed in next release. Any approved new feature will be reset Priority value and Target Version value. Non approved feature will keep "FEAT" priority.

=== Change Control Board ===
Following people should join CCB to review new feature request.
PME(Product Marketing Engineer), PM, Architect, Managers, Key developer and QA leader

=== Feature Request Bug Requirement ===
Feature request bug should be added specific Keywords in subject and Keywords field.

Following message should be added at the beginning of subject.
[FEAT_REQ Company Yocto_Target_Version]

For example: [FEAT_REQ xxx 1.0] Add Connman for network connection.

Following words should be added in Keywords field.
FEATURE_REQUEST

=== Feature Request Bug Template ===
<pre>
1. Feature Description:

2. Feature Present Code Status(including location and version):

3. Code License (e.g. GPLv2):

4. Business Impaction:

5. Other Justification:

</pre>

Bugzilla Configuration and Bug Tracking

2011-11-22T19:55:13Z

Scottrifw: /* Classification Product and Components */

Yocto Project Bug Process version

{|border="1"
|Version|| Modifier || Comments
|-
| 0.3 || Yongkang You || Initial Version
|-
| 0.5 || Yongkang You || Apply comments from Richard, Dave and Susie. Add Feature Request Process and Add a new Priority "FEAT" for it.
|-
| 0.8 || Yongkang You || Internal review and agree bug life cycle and bug Triage process.
|-
| 0.85 || Saul Wold || Add Bug Status / Sub-Status Definitions.
|-
| 0.9 || davest || Cleanup for 0.9 release.
|}

You should also read our [[Community Guidelines]] before submitting bugs.

------
== Defect Management ==
Yocto uses '''[http://www.bugzilla.org/ Bugzilla]''' as its defect tracking tool.

=== Home Address ===
http://bugzilla.yoctoproject.org

=== Get an Account ===
Anyone working on the Yocto project can query existing bugs in Bugzilla. You must have an account to submit a bug, edit a bug, or take action on a bug.

To set up an account, go to the '''[http://www.bugzilla.yoctoproject.org/ Yocto Bugzilla]''' home page and click on "New Account" in the footer area. Follow the directions there to set up your account.

=== Classification Product and Components ===
Yocto Bugzilla uses these Classifications, Products and Components. Configurations change over time and should be defined by module owners:

<pre>
+=======================+======================+======================+
| Classification | Product | Components |
|=====================================================================|
| Yocto Projects | Anjuta Plug-in | General |
| +----------------------+----------------------|
| | BSPs | General |
| +----------------------+----------------------|
| | Cross-prelink | General |
| | +----------------------|
| | | Poky Integration |
| +----------------------+----------------------|
| | Documentation | Handbook |
| | +----------------------|
| | | Other |
| | +----------------------|
| | | PRD |
| | +----------------------|
| | | SDK |
| +----------------------+----------------------|
| | Eclipse Plug-in | General |
| +----------------------+----------------------|
| | Kernel | Build |
| | +----------------------|
| | | Configuration |
| | +----------------------|
| | | General |
| | +----------------------|
| | | Runtime |
| +----------------------+----------------------|
| | Pseudo | General |
| | +----------------------|
| | | Poky Configuration |
| +----------------------+----------------------|
| | Runtime Distribution | Installation |
| | +----------------------|
| | | System Startup |
| +----------------------+----------------------|
| | SDK Tools | General |
| +----------------------+----------------------|
| | Swabber | General |
| | +----------------------|
| | | Poky Integration |
| +----------------------+----------------------|
| | Yocto Test Suite | General |
|-----------------------+----------------------+----------------------|
| Infrastructure | AutoBuilder | General |
| +----------------------+----------------------|
| | Bugzilla | General |
| +----------------------+----------------------|
| | Website | General |
|-----------------------+----------------------+----------------------|
| Poky | ADT | General |
| +----------------------+----------------------|
| | Build System | BitBake |
| | +----------------------|
| | | Configuration |
| | +----------------------|
| | | General |
| | +----------------------|
| | | Hob |
| | +----------------------|
| | | Image Creator |
| | +----------------------|
| | | Layers |
| +----------------------+----------------------|
| | Security | General |
|-----------------------+----------------------+----------------------|
| Yocto Metadata Layers | Layers | dlna |
| | +----------------------|
| | | extra |
| | +----------------------|
| | | general |
| | +----------------------|
| | | intel |
| | +----------------------|
| | | linaro |
| | +----------------------|
| | | xilinx |
| |----------------------+----------------------|
| | Meta Recipes | connectivity |
| | +----------------------|
| | | core |
| | +----------------------|
| | | demoapps |
| | +----------------------|
| | | devtools / toolchain |
| | +----------------------|
| | | general |
| | +----------------------|
| | | graphics |
| | +----------------------|
| | | kernel |
| | +----------------------|
| | | multimedia |
| |----------------------+----------------------|
| | Sato | General |
| | +----------------------|
| | | gtk-engine |
| | +----------------------|
| | | Icon |
| | +----------------------|
| | | Matchbox |
|-----------------------+----------------------+----------------------+
</pre>

=== Hardware ===
* eMenlow
* netbook
* Mips
* Power PC
* ARM

=== Version and Target ===
* Version includes Yocto 0.9 and Yocto 1.0
* Target milestone includes 0.9_M1, 0.9_M2, 0.9_M3 and 0.9_M4

=== Priority and Severity ===
* The priority classifies bug fixing order. It can not be set when open a bug. It was set when doing Triage. The Priorities should be following 5 kinds.
** High -- Bug fixing is planned within 2 weeks, no later than the up-coming milestone, or critical issue for out of cycle release. e.g. highly reproducible crash issues (system or related to key apps/components need to deliver in the upcoming milestone); issues which cause major function loss of a specific feature which is POR of the up-comping milestone; issues which are easy to hit by user and greatly impact user experience or customer requirements; and urgent security issues which needs to be fixed in last release.
** Medium -- Bug fixing is planned before the milestone and must be fixed before the release is finalized.
** Low -- Bug fixing is not planned for the up-coming project release. Non POR feature request, hard to reproduce will fall into this category.
** Undecided -- New reported bug is '''undecided''', before Triage.
** FEAT -- A feature request bug, which isn't approved for future release yet. It will be changed to real priority after Change Control Board (CCB) approves it.
** Note: High impact but Low Priority bugs can be documented in the release notes.

* The Severity indicates bug's impacting level to reporter. It can be categorized to following 5 kinds. The '''default''' is '''Normal'''.
** Critical -- Crashes, hang, loss of data, negative impact to other components, memory leak etc.
** Major -- Major loss of functionality of POR
** Normal -- Regular issue, some loss of functionality under certain circumstance
** Minor -- Minor loss of functionality, or issues with easy workaround available
** Enhancement -- Request for enhancement work

=== Bug Status ===
* Open -- A new reported bug with default assignee.
* ACCEPTED-- The assigned developer has reviewed and accept the bug.
* Resolved -- bug is fixed or closed by other resolved method.
** Fixed -- This is fixed and in the master branch will be set automatically during build
** NotABug -- This is verified as not a bug
** WontFix -- We will not fix this bug, possibly because a newer package fixes it
** Duplicate -- Duplicate of another bug, possibly different failure mode
** Invalid -- The bug is invalid, sometimes this is used when the author of the bug does not provide accurate information, these will be reviewed by Triage team, and could be changed to '''NeedInfo'''
** Obsolete -- The bug is obsolete, old bug that is no longer appropriate, or a package that is depercated.
** WorksForMe -- The bug does not appear when tested by engineer, more appropriately, this may be '''NeedInfo'''
* Verified -- bug is double checked and agreed with the resolved method by original reporter.
* Reopen: bug can be reopened, if it is in Resolved, Verified or Close stage.
* NeedInfo: bug needs be set to NeedInfo, if there is important information missing to understand or reproduce bug.
* WaitForUpstream: The owner does bug analysis and finds this bug comes from upstream. Owner can post a new bug in upstream bugzilla, change status to '''WaitForUpstream''' and add the upstream bugzilla URL in comment area. When upstream bug is fixed, put the bug fixing into Yocto repository. After the patch is built into weekly build, change its status to Resolved/FIXED.
* '''Close''' stage is not used in normal bug life. When reported two same bugs by wrongly click button twice, the 2nd one can be closed. Generally it(close stage) is just for keeping wrong bug out of scrub cycle and statistic.

=== Bug Life Cycle ===
A normal Bug's life is started from '''Open''' and ended by '''Verified'''. Triage team will select "verified: Program Management", after confirm the verification.

[[Image:Yocto_Bug_Life_Cycle.jpg|frame|none|Bug Life Cycle]]

Bug should be marked as Resolved/Fixed, after its fixing patch is built into formal build (weekly build or milestone build). There is an automation method to update bugs to "RESOVLED/FIXED" status by following steps.
# Developer fixed bug and check in patch to his ''contrib'' branch with special words in commit description: '''[BUGFIX #4321]'''
# Developer asked tree gatekeeper to pull patch.
# Release Engineer do formal build. The build script will read new commit description and find out bug ID.
# Build script will notify bugzilla and update bugs status to "RESOLVE/FIXED"

If a weekly build includes a new commit, which reverts another patch, there should be a tool to judge whether the reverted patch summary include any bug fixing ID. If the reverted patch does include any bug fixing, the bug should be reopen.

[[Image:Yocto_Bug_Fix_Process.PNG|frame|none|Bug Fixing Process]]

=== Defect Submission ===
Defects may be entered by anyone working on the Yocto. Bug submission should include severity, thorough environment information, proper and clear reproduce steps and logs.

=== Bug Group ===
Bug group is used to control bug visibility. Couple of groups will be set up. When reporting or updating bugs, group check box could be edit.

* '''Security''' -- Bugs can only be viewed by Security group user. Bugs will be in Security Group, when it is reported to security component.
* No_Group_Check_Box_Selection-- Bugs are public. (Be careful)''' '''
* TBD

=== Bug Reporter ===
* Provide clear and simple bug subject. It is recommended to put a '''Fault Component Name''' with brackets at the beginning of subject as a keyword, e.g. [Poky].
* Validate all fields are correct. If fields are not filled out correctly, the bug might be sent back to the submitter.
* Judge the right Severity.
* Adds any additional information from the bug scrub.
* Assigns the bug to the correct person to disposition the bug.
* If a bug is too vague to make a determination then the Resolution Field of the bug will be set to need more information and sent back the bug submitter.
* '''Bug Priority can't be set when report a bug. It will be set when doing bug Triage'''

=== Bug Owner ===
* Review bugs to check if there are enough information. If not, set the bug to NeedInfo. Try to reproduce bug, if there are clear steps.
* Based on bug Priority and Severity to fix bugs in time. For example, High Priority bugs usually should be fixed in 2 weeks. High/critical bugs should be fixed as soon as possible, which has impaction to whole system.
* Update bugs in time with comments. Set the bug to Fixed and provide the tree/commit info, after bug fixing. '''Bug should not be marked as "fix", if patch is not checked into repository. '''

== Bug Tracking ==
Yocto is a cross many Geo project. Single bug scrub meeting is not easy to maintain. Considering Embedded Linux will be a big project, it brings a concept named ''Triage'' to effectively track bug. Triage is mainly for setting new bug priority. Triage virtual team will based on bug's severity, features and schedule to suggest bug fixing priority. Developer teams will receive triage email in time. If reach agreement, bugs will be followed up based on priority. Team manager should be responsible for monitoring the bug fixing schedule to align with related priority. This process is to make the high priority bug be fixed in time and reduce the schedule risk. There are still separated bug review or discussion meeting, which is held through Jabber.

=== Triage Management Team ===
* Program Manager
* Architect
* Engineering Manager
* QA leader

=== Triage Process ===
The triage process will be held frequently to make sure new coming bugs are set with correct priority in time. Triage chairman scrubs new bugs and set priority everyday. PDT meeting will review past week's overall triage result once per week.

The Bugzilla system will send emails to component owner and related engineers about creating or changing of bugs. Before Triage, new bugs could be discussed and even fixed.

'''Bug Triage Process '''

[[Image:bug_triage_process.PNG|frame|none|bug traiage process]]

'''Triage email example'''
<pre>
To: Yocto OTC
Subject: [Yocto-bug-triage] Bug Triage Review - ww26.1

Manager: MGR_A
==================
Bug ID Sev Priority Assignee Summary
1 maj High dev_A [Poky] XYZ Build Failure

Manager: MGR_B
====================
Bug ID Sev Priority Assignee Summary
2 maj High dev_B [SDK] ABC button error
3 nor Medium dev_C [X] Can't start X
</pre>

=== Responsibility ===
* Triage Chairman
** Triage new bugs: set initial priority, correct bug component and owner and mark duplicated bugs.
** Monitor overall bug fix progress with indicators: find out aging bugs.
** Send out triage result email to yocto mailing list (or Triage management team member) for review.
** Escalate aging high priority open bugs.
* Triage Management Team
** Development/Distribution managers are mandatory to review triage result and commit to fix
* Development/Distribution Manager
** Ensure developer/distro ACCEPT bugs in bugzilla within 3 days
** Commit developer to fix high priority bugs
* Program Manager
** Coordinate and push bugs to be fixed in time
* Triage Decision Forum (PDT Meeting)
** Make decision on controversial bugs
** Review and Monitor previous decision
** Triage Chairman update bugzilla based on decision
** Discuss and approve bug whose priority needs to be downgraded

=== Triage Chairman ===
Triage chairman role will be rotated in distribution leaders, engineer manager, SDK leader and QA leader. Each chairman will own 1 milestone cycle. Triage chairman starts from Yocto 0.9 M2 cycle and rotate in following order.
# Saul Wold -- Distro leader
# Susie Li -- engineer manager
# Kevin Tian -- distro leader
# Jessica Zhang -- SDK leader
# QA Leader

=== Bug Data Reporting ===
Defect Data is tracked and presented to the PDT meeting on a weekly basis by QA team. Any escalation items should be discussed and resolved in the PDT meeting.

=== External Owned Bug Triage ===
There might be some bugs owned by external developers. These bugs' triage results will be sent to Yocto public mailing list weekly.

=== Re-Triage for Next Milestone and Release ===
After a new milestone, there will be a time to review all medium priority bugs and set new Priority for next coming milestone.
After a new release, there will be a time to review all low priority bugs and set new Priority for next coming release.

== Feature Request Process ==
New feature request should be applied through Bugzilla as a bug. User could select corresponding Severity to indicate how important the feature is. User needs to follow Feature Request template to submit new request. Triage chairman will mark new feature request bug priority to '''FEAT'''.

There will be two important feature request review time per year in Aug. and Jan. (2 months before current release). In the review period, there will be 2~4 times review meetings by CCB. CCB will decide new features which will be included in next release, that will be released 8 months later. If feature request missed the review period, in theory it will be missed in next release. Any approved new feature will be reset Priority value and Target Version value. Non approved feature will keep "FEAT" priority.

=== Change Control Board ===
Following people should join CCB to review new feature request.
PME(Product Marketing Engineer), PM, Architect, Managers, Key developer and QA leader

=== Feature Request Bug Requirement ===
Feature request bug should be added specific Keywords in subject and Keywords field.

Following message should be added at the beginning of subject.
[FEAT_REQ Company Yocto_Target_Version]

For example: [FEAT_REQ xxx 1.0] Add Connman for network connection.

Following words should be added in Keywords field.
FEATURE_REQUEST

=== Feature Request Bug Template ===
<pre>
1. Feature Description:

2. Feature Present Code Status(including location and version):

3. Code License (e.g. GPLv2):

4. Business Impaction:

5. Other Justification:

</pre>

Bugzilla Configuration and Bug Tracking

2011-11-22T19:52:54Z

Scottrifw: /* Classification Product and Components */

Yocto Project Bug Process version

{|border="1"
|Version|| Modifier || Comments
|-
| 0.3 || Yongkang You || Initial Version
|-
| 0.5 || Yongkang You || Apply comments from Richard, Dave and Susie. Add Feature Request Process and Add a new Priority "FEAT" for it.
|-
| 0.8 || Yongkang You || Internal review and agree bug life cycle and bug Triage process.
|-
| 0.85 || Saul Wold || Add Bug Status / Sub-Status Definitions.
|-
| 0.9 || davest || Cleanup for 0.9 release.
|}

You should also read our [[Community Guidelines]] before submitting bugs.

------
== Defect Management ==
Yocto uses '''[http://www.bugzilla.org/ Bugzilla]''' as its defect tracking tool.

=== Home Address ===
http://bugzilla.yoctoproject.org

=== Get an Account ===
Anyone working on the Yocto project can query existing bugs in Bugzilla. You must have an account to submit a bug, edit a bug, or take action on a bug.

To set up an account, go to the '''[http://www.bugzilla.yoctoproject.org/ Yocto Bugzilla]''' home page and click on "New Account" in the footer area. Follow the directions there to set up your account.

=== Classification Product and Components ===
Yocto Bugzilla uses these Classifications, Products and Components:

<pre>
+=======================+======================+======================+
| Classification | Product | Components |
|=====================================================================|
| Yocto Projects | Anjuta Plug-in | General |
| +----------------------+----------------------|
| | BSPs | General |
| +----------------------+----------------------|
| | Cross-prelink | General |
| | +----------------------|
| | | Poky Integration |
| +----------------------+----------------------|
| | Documentation | Handbook |
| | +----------------------|
| | | Other |
| | +----------------------|
| | | PRD |
| | +----------------------|
| | | SDK |
| +----------------------+----------------------|
| | Eclipse Plug-in | General |
| +----------------------+----------------------|
| | Kernel | Build |
| | +----------------------|
| | | Configuration |
| | +----------------------|
| | | General |
| | +----------------------|
| | | Runtime |
| +----------------------+----------------------|
| | Pseudo | General |
| | +----------------------|
| | | Poky Configuration |
| +----------------------+----------------------|
| | Runtime Distribution | Installation |
| | +----------------------|
| | | System Startup |
| +----------------------+----------------------|
| | SDK Tools | General |
| +----------------------+----------------------|
| | Swabber | General |
| | +----------------------|
| | | Poky Integration |
| +----------------------+----------------------|
| | Yocto Test Suite | General |
|-----------------------+----------------------+----------------------|
| Infrastructure | AutoBuilder | General |
| +----------------------+----------------------|
| | Bugzilla | General |
| +----------------------+----------------------|
| | Website | General |
|-----------------------+----------------------+----------------------|
| Poky | ADT | General |
| +----------------------+----------------------|
| | Build System | BitBake |
| | +----------------------|
| | | Configuration |
| | +----------------------|
| | | General |
| | +----------------------|
| | | Hob |
| | +----------------------|
| | | Image Creator |
| | +----------------------|
| | | Layers |
| +----------------------+----------------------|
| | Security | General |
|-----------------------+----------------------+----------------------|
| Yocto Metadata Layers | Layers | dlna |
| | +----------------------|
| | | extra |
| | +----------------------|
| | | general |
| | +----------------------|
| | | intel |
| | +----------------------|
| | | linaro |
| | +----------------------|
| | | xilinx |
| |----------------------+----------------------|
| | Meta Recipes | connectivity |
| | +----------------------|
| | | core |
| | +----------------------|
| | | demoapps |
| | +----------------------|
| | | devtools / toolchain |
| | +----------------------|
| | | general |
| | +----------------------|
| | | graphics |
| | +----------------------|
| | | kernel |
| | +----------------------|
| | | multimedia |
| |----------------------+----------------------|
| | Sato | General |
| | +----------------------|
| | | gtk-engine |
| | +----------------------|
| | | Icon |
| | +----------------------|
| | | Matchbox |
|-----------------------+----------------------+----------------------+
</pre>

The detailed configuration should be suggested by component owners.

=== Hardware ===
* eMenlow
* netbook
* Mips
* Power PC
* ARM

=== Version and Target ===
* Version includes Yocto 0.9 and Yocto 1.0
* Target milestone includes 0.9_M1, 0.9_M2, 0.9_M3 and 0.9_M4

=== Priority and Severity ===
* The priority classifies bug fixing order. It can not be set when open a bug. It was set when doing Triage. The Priorities should be following 5 kinds.
** High -- Bug fixing is planned within 2 weeks, no later than the up-coming milestone, or critical issue for out of cycle release. e.g. highly reproducible crash issues (system or related to key apps/components need to deliver in the upcoming milestone); issues which cause major function loss of a specific feature which is POR of the up-comping milestone; issues which are easy to hit by user and greatly impact user experience or customer requirements; and urgent security issues which needs to be fixed in last release.
** Medium -- Bug fixing is planned before the milestone and must be fixed before the release is finalized.
** Low -- Bug fixing is not planned for the up-coming project release. Non POR feature request, hard to reproduce will fall into this category.
** Undecided -- New reported bug is '''undecided''', before Triage.
** FEAT -- A feature request bug, which isn't approved for future release yet. It will be changed to real priority after Change Control Board (CCB) approves it.
** Note: High impact but Low Priority bugs can be documented in the release notes.

* The Severity indicates bug's impacting level to reporter. It can be categorized to following 5 kinds. The '''default''' is '''Normal'''.
** Critical -- Crashes, hang, loss of data, negative impact to other components, memory leak etc.
** Major -- Major loss of functionality of POR
** Normal -- Regular issue, some loss of functionality under certain circumstance
** Minor -- Minor loss of functionality, or issues with easy workaround available
** Enhancement -- Request for enhancement work

=== Bug Status ===
* Open -- A new reported bug with default assignee.
* ACCEPTED-- The assigned developer has reviewed and accept the bug.
* Resolved -- bug is fixed or closed by other resolved method.
** Fixed -- This is fixed and in the master branch will be set automatically during build
** NotABug -- This is verified as not a bug
** WontFix -- We will not fix this bug, possibly because a newer package fixes it
** Duplicate -- Duplicate of another bug, possibly different failure mode
** Invalid -- The bug is invalid, sometimes this is used when the author of the bug does not provide accurate information, these will be reviewed by Triage team, and could be changed to '''NeedInfo'''
** Obsolete -- The bug is obsolete, old bug that is no longer appropriate, or a package that is depercated.
** WorksForMe -- The bug does not appear when tested by engineer, more appropriately, this may be '''NeedInfo'''
* Verified -- bug is double checked and agreed with the resolved method by original reporter.
* Reopen: bug can be reopened, if it is in Resolved, Verified or Close stage.
* NeedInfo: bug needs be set to NeedInfo, if there is important information missing to understand or reproduce bug.
* WaitForUpstream: The owner does bug analysis and finds this bug comes from upstream. Owner can post a new bug in upstream bugzilla, change status to '''WaitForUpstream''' and add the upstream bugzilla URL in comment area. When upstream bug is fixed, put the bug fixing into Yocto repository. After the patch is built into weekly build, change its status to Resolved/FIXED.
* '''Close''' stage is not used in normal bug life. When reported two same bugs by wrongly click button twice, the 2nd one can be closed. Generally it(close stage) is just for keeping wrong bug out of scrub cycle and statistic.

=== Bug Life Cycle ===
A normal Bug's life is started from '''Open''' and ended by '''Verified'''. Triage team will select "verified: Program Management", after confirm the verification.

[[Image:Yocto_Bug_Life_Cycle.jpg|frame|none|Bug Life Cycle]]

Bug should be marked as Resolved/Fixed, after its fixing patch is built into formal build (weekly build or milestone build). There is an automation method to update bugs to "RESOVLED/FIXED" status by following steps.
# Developer fixed bug and check in patch to his ''contrib'' branch with special words in commit description: '''[BUGFIX #4321]'''
# Developer asked tree gatekeeper to pull patch.
# Release Engineer do formal build. The build script will read new commit description and find out bug ID.
# Build script will notify bugzilla and update bugs status to "RESOLVE/FIXED"

If a weekly build includes a new commit, which reverts another patch, there should be a tool to judge whether the reverted patch summary include any bug fixing ID. If the reverted patch does include any bug fixing, the bug should be reopen.

[[Image:Yocto_Bug_Fix_Process.PNG|frame|none|Bug Fixing Process]]

=== Defect Submission ===
Defects may be entered by anyone working on the Yocto. Bug submission should include severity, thorough environment information, proper and clear reproduce steps and logs.

=== Bug Group ===
Bug group is used to control bug visibility. Couple of groups will be set up. When reporting or updating bugs, group check box could be edit.

* '''Security''' -- Bugs can only be viewed by Security group user. Bugs will be in Security Group, when it is reported to security component.
* No_Group_Check_Box_Selection-- Bugs are public. (Be careful)''' '''
* TBD

=== Bug Reporter ===
* Provide clear and simple bug subject. It is recommended to put a '''Fault Component Name''' with brackets at the beginning of subject as a keyword, e.g. [Poky].
* Validate all fields are correct. If fields are not filled out correctly, the bug might be sent back to the submitter.
* Judge the right Severity.
* Adds any additional information from the bug scrub.
* Assigns the bug to the correct person to disposition the bug.
* If a bug is too vague to make a determination then the Resolution Field of the bug will be set to need more information and sent back the bug submitter.
* '''Bug Priority can't be set when report a bug. It will be set when doing bug Triage'''

=== Bug Owner ===
* Review bugs to check if there are enough information. If not, set the bug to NeedInfo. Try to reproduce bug, if there are clear steps.
* Based on bug Priority and Severity to fix bugs in time. For example, High Priority bugs usually should be fixed in 2 weeks. High/critical bugs should be fixed as soon as possible, which has impaction to whole system.
* Update bugs in time with comments. Set the bug to Fixed and provide the tree/commit info, after bug fixing. '''Bug should not be marked as "fix", if patch is not checked into repository. '''

== Bug Tracking ==
Yocto is a cross many Geo project. Single bug scrub meeting is not easy to maintain. Considering Embedded Linux will be a big project, it brings a concept named ''Triage'' to effectively track bug. Triage is mainly for setting new bug priority. Triage virtual team will based on bug's severity, features and schedule to suggest bug fixing priority. Developer teams will receive triage email in time. If reach agreement, bugs will be followed up based on priority. Team manager should be responsible for monitoring the bug fixing schedule to align with related priority. This process is to make the high priority bug be fixed in time and reduce the schedule risk. There are still separated bug review or discussion meeting, which is held through Jabber.

=== Triage Management Team ===
* Program Manager
* Architect
* Engineering Manager
* QA leader

=== Triage Process ===
The triage process will be held frequently to make sure new coming bugs are set with correct priority in time. Triage chairman scrubs new bugs and set priority everyday. PDT meeting will review past week's overall triage result once per week.

The Bugzilla system will send emails to component owner and related engineers about creating or changing of bugs. Before Triage, new bugs could be discussed and even fixed.

'''Bug Triage Process '''

[[Image:bug_triage_process.PNG|frame|none|bug traiage process]]

'''Triage email example'''
<pre>
To: Yocto OTC
Subject: [Yocto-bug-triage] Bug Triage Review - ww26.1

Manager: MGR_A
==================
Bug ID Sev Priority Assignee Summary
1 maj High dev_A [Poky] XYZ Build Failure

Manager: MGR_B
====================
Bug ID Sev Priority Assignee Summary
2 maj High dev_B [SDK] ABC button error
3 nor Medium dev_C [X] Can't start X
</pre>

=== Responsibility ===
* Triage Chairman
** Triage new bugs: set initial priority, correct bug component and owner and mark duplicated bugs.
** Monitor overall bug fix progress with indicators: find out aging bugs.
** Send out triage result email to yocto mailing list (or Triage management team member) for review.
** Escalate aging high priority open bugs.
* Triage Management Team
** Development/Distribution managers are mandatory to review triage result and commit to fix
* Development/Distribution Manager
** Ensure developer/distro ACCEPT bugs in bugzilla within 3 days
** Commit developer to fix high priority bugs
* Program Manager
** Coordinate and push bugs to be fixed in time
* Triage Decision Forum (PDT Meeting)
** Make decision on controversial bugs
** Review and Monitor previous decision
** Triage Chairman update bugzilla based on decision
** Discuss and approve bug whose priority needs to be downgraded

=== Triage Chairman ===
Triage chairman role will be rotated in distribution leaders, engineer manager, SDK leader and QA leader. Each chairman will own 1 milestone cycle. Triage chairman starts from Yocto 0.9 M2 cycle and rotate in following order.
# Saul Wold -- Distro leader
# Susie Li -- engineer manager
# Kevin Tian -- distro leader
# Jessica Zhang -- SDK leader
# QA Leader

=== Bug Data Reporting ===
Defect Data is tracked and presented to the PDT meeting on a weekly basis by QA team. Any escalation items should be discussed and resolved in the PDT meeting.

=== External Owned Bug Triage ===
There might be some bugs owned by external developers. These bugs' triage results will be sent to Yocto public mailing list weekly.

=== Re-Triage for Next Milestone and Release ===
After a new milestone, there will be a time to review all medium priority bugs and set new Priority for next coming milestone.
After a new release, there will be a time to review all low priority bugs and set new Priority for next coming release.

== Feature Request Process ==
New feature request should be applied through Bugzilla as a bug. User could select corresponding Severity to indicate how important the feature is. User needs to follow Feature Request template to submit new request. Triage chairman will mark new feature request bug priority to '''FEAT'''.

There will be two important feature request review time per year in Aug. and Jan. (2 months before current release). In the review period, there will be 2~4 times review meetings by CCB. CCB will decide new features which will be included in next release, that will be released 8 months later. If feature request missed the review period, in theory it will be missed in next release. Any approved new feature will be reset Priority value and Target Version value. Non approved feature will keep "FEAT" priority.

=== Change Control Board ===
Following people should join CCB to review new feature request.
PME(Product Marketing Engineer), PM, Architect, Managers, Key developer and QA leader

=== Feature Request Bug Requirement ===
Feature request bug should be added specific Keywords in subject and Keywords field.

Following message should be added at the beginning of subject.
[FEAT_REQ Company Yocto_Target_Version]

For example: [FEAT_REQ xxx 1.0] Add Connman for network connection.

Following words should be added in Keywords field.
FEATURE_REQUEST

=== Feature Request Bug Template ===
<pre>
1. Feature Description:

2. Feature Present Code Status(including location and version):

3. Code License (e.g. GPLv2):

4. Business Impaction:

5. Other Justification:

</pre>

Bugzilla Configuration and Bug Tracking

2011-11-22T19:50:53Z

Scottrifw: /* Classification Product and Components */

Yocto Project Bug Process version

{|border="1"
|Version|| Modifier || Comments
|-
| 0.3 || Yongkang You || Initial Version
|-
| 0.5 || Yongkang You || Apply comments from Richard, Dave and Susie. Add Feature Request Process and Add a new Priority "FEAT" for it.
|-
| 0.8 || Yongkang You || Internal review and agree bug life cycle and bug Triage process.
|-
| 0.85 || Saul Wold || Add Bug Status / Sub-Status Definitions.
|-
| 0.9 || davest || Cleanup for 0.9 release.
|}

You should also read our [[Community Guidelines]] before submitting bugs.

------
== Defect Management ==
Yocto uses '''[http://www.bugzilla.org/ Bugzilla]''' as its defect tracking tool.

=== Home Address ===
http://bugzilla.yoctoproject.org

=== Get an Account ===
Anyone working on the Yocto project can query existing bugs in Bugzilla. You must have an account to submit a bug, edit a bug, or take action on a bug.

To set up an account, go to the '''[http://www.bugzilla.yoctoproject.org/ Yocto Bugzilla]''' home page and click on "New Account" in the footer area. Follow the directions there to set up your account.

=== Classification Product and Components ===
Bugzilla uses these Products and Components:

<pre>
| Classification | Product | Components |
|=====================================================================|
| Yocto Projects | Anjuta Plug-in | General |
| +----------------------+----------------------|
| | BSPs | General |
| +----------------------+----------------------|
| | Cross-prelink | General |
| | +----------------------|
| | | Poky Integration |
| +----------------------+----------------------|
| | Documentation | Handbook |
| | +----------------------|
| | | Other |
| | +----------------------|
| | | PRD |
| | +----------------------|
| | | SDK |
| +----------------------+----------------------|
| | Eclipse Plug-in | General |
| +----------------------+----------------------|
| | Kernel | Build |
| | +----------------------|
| | | Configuration |
| | +----------------------|
| | | General |
| | +----------------------|
| | | Runtime |
| +----------------------+----------------------|
| | Pseudo | General |
| | +----------------------|
| | | Poky Configuration |
| +----------------------+----------------------|
| | Runtime Distribution | Installation |
| | +----------------------|
| | | System Startup |
| +----------------------+----------------------|
| | SDK Tools | General |
| +----------------------+----------------------|
| | Swabber | General |
| | +----------------------|
| | | Poky Integration |
| +----------------------+----------------------|
| | Yocto Test Suite | General |
|-----------------------+----------------------+----------------------|
| Infrastructure | AutoBuilder | General |
| +----------------------+----------------------|
| | Bugzilla | General |
| +----------------------+----------------------|
| | Website | General |
|-----------------------+----------------------+----------------------|
| Poky | ADT | General |
| +----------------------+----------------------|
| | Build System | BitBake |
| | +----------------------|
| | | Configuration |
| | +----------------------|
| | | General |
| | +----------------------|
| | | Hob |
| | +----------------------|
| | | Image Creator |
| | +----------------------|
| | | Layers |
| +----------------------+----------------------|
| | Security | General |
|-----------------------+----------------------+----------------------|
| Yocto Metadata Layers | Layers | dlna |
| | +----------------------|
| | | extra |
| | +----------------------|
| | | general |
| | +----------------------|
| | | intel |
| | +----------------------|
| | | linaro |
| | +----------------------|
| | | xilinx |
| |----------------------+----------------------|
| | Meta Recipes | connectivity |
| | +----------------------|
| | | core |
| | +----------------------|
| | | demoapps |
| | +----------------------|
| | | devtools / toolchain |
| | +----------------------|
| | | general |
| | +----------------------|
| | | graphics |
| | +----------------------|
| | | kernel |
| | +----------------------|
| | | multimedia |
|-----------------------+----------------------+----------------------|
| | Sato | General |
| | +----------------------|
| | | gtk-engine |
| | +----------------------|
| | | Icon |
| | +----------------------|
| | | Matchbox |
|-----------------------+----------------------+----------------------+
</pre>

The detailed configuration should be suggested by component owners.

=== Hardware ===
* eMenlow
* netbook
* Mips
* Power PC
* ARM

=== Version and Target ===
* Version includes Yocto 0.9 and Yocto 1.0
* Target milestone includes 0.9_M1, 0.9_M2, 0.9_M3 and 0.9_M4

=== Priority and Severity ===
* The priority classifies bug fixing order. It can not be set when open a bug. It was set when doing Triage. The Priorities should be following 5 kinds.
** High -- Bug fixing is planned within 2 weeks, no later than the up-coming milestone, or critical issue for out of cycle release. e.g. highly reproducible crash issues (system or related to key apps/components need to deliver in the upcoming milestone); issues which cause major function loss of a specific feature which is POR of the up-comping milestone; issues which are easy to hit by user and greatly impact user experience or customer requirements; and urgent security issues which needs to be fixed in last release.
** Medium -- Bug fixing is planned before the milestone and must be fixed before the release is finalized.
** Low -- Bug fixing is not planned for the up-coming project release. Non POR feature request, hard to reproduce will fall into this category.
** Undecided -- New reported bug is '''undecided''', before Triage.
** FEAT -- A feature request bug, which isn't approved for future release yet. It will be changed to real priority after Change Control Board (CCB) approves it.
** Note: High impact but Low Priority bugs can be documented in the release notes.

* The Severity indicates bug's impacting level to reporter. It can be categorized to following 5 kinds. The '''default''' is '''Normal'''.
** Critical -- Crashes, hang, loss of data, negative impact to other components, memory leak etc.
** Major -- Major loss of functionality of POR
** Normal -- Regular issue, some loss of functionality under certain circumstance
** Minor -- Minor loss of functionality, or issues with easy workaround available
** Enhancement -- Request for enhancement work

=== Bug Status ===
* Open -- A new reported bug with default assignee.
* ACCEPTED-- The assigned developer has reviewed and accept the bug.
* Resolved -- bug is fixed or closed by other resolved method.
** Fixed -- This is fixed and in the master branch will be set automatically during build
** NotABug -- This is verified as not a bug
** WontFix -- We will not fix this bug, possibly because a newer package fixes it
** Duplicate -- Duplicate of another bug, possibly different failure mode
** Invalid -- The bug is invalid, sometimes this is used when the author of the bug does not provide accurate information, these will be reviewed by Triage team, and could be changed to '''NeedInfo'''
** Obsolete -- The bug is obsolete, old bug that is no longer appropriate, or a package that is depercated.
** WorksForMe -- The bug does not appear when tested by engineer, more appropriately, this may be '''NeedInfo'''
* Verified -- bug is double checked and agreed with the resolved method by original reporter.
* Reopen: bug can be reopened, if it is in Resolved, Verified or Close stage.
* NeedInfo: bug needs be set to NeedInfo, if there is important information missing to understand or reproduce bug.
* WaitForUpstream: The owner does bug analysis and finds this bug comes from upstream. Owner can post a new bug in upstream bugzilla, change status to '''WaitForUpstream''' and add the upstream bugzilla URL in comment area. When upstream bug is fixed, put the bug fixing into Yocto repository. After the patch is built into weekly build, change its status to Resolved/FIXED.
* '''Close''' stage is not used in normal bug life. When reported two same bugs by wrongly click button twice, the 2nd one can be closed. Generally it(close stage) is just for keeping wrong bug out of scrub cycle and statistic.

=== Bug Life Cycle ===
A normal Bug's life is started from '''Open''' and ended by '''Verified'''. Triage team will select "verified: Program Management", after confirm the verification.

[[Image:Yocto_Bug_Life_Cycle.jpg|frame|none|Bug Life Cycle]]

Bug should be marked as Resolved/Fixed, after its fixing patch is built into formal build (weekly build or milestone build). There is an automation method to update bugs to "RESOVLED/FIXED" status by following steps.
# Developer fixed bug and check in patch to his ''contrib'' branch with special words in commit description: '''[BUGFIX #4321]'''
# Developer asked tree gatekeeper to pull patch.
# Release Engineer do formal build. The build script will read new commit description and find out bug ID.
# Build script will notify bugzilla and update bugs status to "RESOLVE/FIXED"

If a weekly build includes a new commit, which reverts another patch, there should be a tool to judge whether the reverted patch summary include any bug fixing ID. If the reverted patch does include any bug fixing, the bug should be reopen.

[[Image:Yocto_Bug_Fix_Process.PNG|frame|none|Bug Fixing Process]]

=== Defect Submission ===
Defects may be entered by anyone working on the Yocto. Bug submission should include severity, thorough environment information, proper and clear reproduce steps and logs.

=== Bug Group ===
Bug group is used to control bug visibility. Couple of groups will be set up. When reporting or updating bugs, group check box could be edit.

* '''Security''' -- Bugs can only be viewed by Security group user. Bugs will be in Security Group, when it is reported to security component.
* No_Group_Check_Box_Selection-- Bugs are public. (Be careful)''' '''
* TBD

=== Bug Reporter ===
* Provide clear and simple bug subject. It is recommended to put a '''Fault Component Name''' with brackets at the beginning of subject as a keyword, e.g. [Poky].
* Validate all fields are correct. If fields are not filled out correctly, the bug might be sent back to the submitter.
* Judge the right Severity.
* Adds any additional information from the bug scrub.
* Assigns the bug to the correct person to disposition the bug.
* If a bug is too vague to make a determination then the Resolution Field of the bug will be set to need more information and sent back the bug submitter.
* '''Bug Priority can't be set when report a bug. It will be set when doing bug Triage'''

=== Bug Owner ===
* Review bugs to check if there are enough information. If not, set the bug to NeedInfo. Try to reproduce bug, if there are clear steps.
* Based on bug Priority and Severity to fix bugs in time. For example, High Priority bugs usually should be fixed in 2 weeks. High/critical bugs should be fixed as soon as possible, which has impaction to whole system.
* Update bugs in time with comments. Set the bug to Fixed and provide the tree/commit info, after bug fixing. '''Bug should not be marked as "fix", if patch is not checked into repository. '''

== Bug Tracking ==
Yocto is a cross many Geo project. Single bug scrub meeting is not easy to maintain. Considering Embedded Linux will be a big project, it brings a concept named ''Triage'' to effectively track bug. Triage is mainly for setting new bug priority. Triage virtual team will based on bug's severity, features and schedule to suggest bug fixing priority. Developer teams will receive triage email in time. If reach agreement, bugs will be followed up based on priority. Team manager should be responsible for monitoring the bug fixing schedule to align with related priority. This process is to make the high priority bug be fixed in time and reduce the schedule risk. There are still separated bug review or discussion meeting, which is held through Jabber.

=== Triage Management Team ===
* Program Manager
* Architect
* Engineering Manager
* QA leader

=== Triage Process ===
The triage process will be held frequently to make sure new coming bugs are set with correct priority in time. Triage chairman scrubs new bugs and set priority everyday. PDT meeting will review past week's overall triage result once per week.

The Bugzilla system will send emails to component owner and related engineers about creating or changing of bugs. Before Triage, new bugs could be discussed and even fixed.

'''Bug Triage Process '''

[[Image:bug_triage_process.PNG|frame|none|bug traiage process]]

'''Triage email example'''
<pre>
To: Yocto OTC
Subject: [Yocto-bug-triage] Bug Triage Review - ww26.1

Manager: MGR_A
==================
Bug ID Sev Priority Assignee Summary
1 maj High dev_A [Poky] XYZ Build Failure

Manager: MGR_B
====================
Bug ID Sev Priority Assignee Summary
2 maj High dev_B [SDK] ABC button error
3 nor Medium dev_C [X] Can't start X
</pre>

=== Responsibility ===
* Triage Chairman
** Triage new bugs: set initial priority, correct bug component and owner and mark duplicated bugs.
** Monitor overall bug fix progress with indicators: find out aging bugs.
** Send out triage result email to yocto mailing list (or Triage management team member) for review.
** Escalate aging high priority open bugs.
* Triage Management Team
** Development/Distribution managers are mandatory to review triage result and commit to fix
* Development/Distribution Manager
** Ensure developer/distro ACCEPT bugs in bugzilla within 3 days
** Commit developer to fix high priority bugs
* Program Manager
** Coordinate and push bugs to be fixed in time
* Triage Decision Forum (PDT Meeting)
** Make decision on controversial bugs
** Review and Monitor previous decision
** Triage Chairman update bugzilla based on decision
** Discuss and approve bug whose priority needs to be downgraded

=== Triage Chairman ===
Triage chairman role will be rotated in distribution leaders, engineer manager, SDK leader and QA leader. Each chairman will own 1 milestone cycle. Triage chairman starts from Yocto 0.9 M2 cycle and rotate in following order.
# Saul Wold -- Distro leader
# Susie Li -- engineer manager
# Kevin Tian -- distro leader
# Jessica Zhang -- SDK leader
# QA Leader

=== Bug Data Reporting ===
Defect Data is tracked and presented to the PDT meeting on a weekly basis by QA team. Any escalation items should be discussed and resolved in the PDT meeting.

=== External Owned Bug Triage ===
There might be some bugs owned by external developers. These bugs' triage results will be sent to Yocto public mailing list weekly.

=== Re-Triage for Next Milestone and Release ===
After a new milestone, there will be a time to review all medium priority bugs and set new Priority for next coming milestone.
After a new release, there will be a time to review all low priority bugs and set new Priority for next coming release.

== Feature Request Process ==
New feature request should be applied through Bugzilla as a bug. User could select corresponding Severity to indicate how important the feature is. User needs to follow Feature Request template to submit new request. Triage chairman will mark new feature request bug priority to '''FEAT'''.

There will be two important feature request review time per year in Aug. and Jan. (2 months before current release). In the review period, there will be 2~4 times review meetings by CCB. CCB will decide new features which will be included in next release, that will be released 8 months later. If feature request missed the review period, in theory it will be missed in next release. Any approved new feature will be reset Priority value and Target Version value. Non approved feature will keep "FEAT" priority.

=== Change Control Board ===
Following people should join CCB to review new feature request.
PME(Product Marketing Engineer), PM, Architect, Managers, Key developer and QA leader

=== Feature Request Bug Requirement ===
Feature request bug should be added specific Keywords in subject and Keywords field.

Following message should be added at the beginning of subject.
[FEAT_REQ Company Yocto_Target_Version]

For example: [FEAT_REQ xxx 1.0] Add Connman for network connection.

Following words should be added in Keywords field.
FEATURE_REQUEST

=== Feature Request Bug Template ===
<pre>
1. Feature Description:

2. Feature Present Code Status(including location and version):

3. Code License (e.g. GPLv2):

4. Business Impaction:

5. Other Justification:

</pre>

Bugzilla Configuration and Bug Tracking

2011-11-22T19:46:49Z

Scottrifw: /* Classification Product and Components */

Yocto Project Bug Process version

{|border="1"
|Version|| Modifier || Comments
|-
| 0.3 || Yongkang You || Initial Version
|-
| 0.5 || Yongkang You || Apply comments from Richard, Dave and Susie. Add Feature Request Process and Add a new Priority "FEAT" for it.
|-
| 0.8 || Yongkang You || Internal review and agree bug life cycle and bug Triage process.
|-
| 0.85 || Saul Wold || Add Bug Status / Sub-Status Definitions.
|-
| 0.9 || davest || Cleanup for 0.9 release.
|}

You should also read our [[Community Guidelines]] before submitting bugs.

------
== Defect Management ==
Yocto uses '''[http://www.bugzilla.org/ Bugzilla]''' as its defect tracking tool.

=== Home Address ===
http://bugzilla.yoctoproject.org

=== Get an Account ===
Anyone working on the Yocto project can query existing bugs in Bugzilla. You must have an account to submit a bug, edit a bug, or take action on a bug.

To set up an account, go to the '''[http://www.bugzilla.yoctoproject.org/ Yocto Bugzilla]''' home page and click on "New Account" in the footer area. Follow the directions there to set up your account.

=== Classification Product and Components ===
Bugzilla uses these Products and Components:

<pre>
| Classification | Product | Components |
|=====================================================================|
| Yocto Projects | Anjuta Plug-in | General |
| +----------------------+----------------------|
| | BSPs | General |
| +----------------------+----------------------|
| | Cross-prelink | General |
| | +----------------------|
| | | Poky Integration |
| +----------------------+----------------------|
| | Documentation | Handbook |
| | +----------------------|
| | | Other |
| | +----------------------|
| | | PRD |
| | +----------------------|
| | | SDK |
| +----------------------+----------------------|
| | Eclipse Plug-in | General |
| +----------------------+----------------------|
| | Kernel | Build |
| | +----------------------|
| | | Configuration |
| | +----------------------|
| | | General |
| | +----------------------|
| | | Runtime |
| +----------------------+----------------------|
| | Pseudo | General |
| | +----------------------|
| | | Poky Configuration |
| +----------------------+----------------------|
| | Runtime Distribution | Installation |
| | +----------------------|
| | | System Startup |
| +----------------------+----------------------|
| | SDK Tools | General |
| +----------------------+----------------------|
| | Swabber | General |
| | +----------------------|
| | | Poky Integration |
| +----------------------+----------------------|
| | Yocto Test Suite | General |
|-----------------------+----------------------+----------------------|
| Infrastructure | AutoBuilder | General |
| +----------------------+----------------------|
| | Bugzilla | General |
| +----------------------+----------------------|
| | Website | General |
|-----------------------+----------------------+----------------------|
| Poky | ADT | General |
| +----------------------+----------------------|
| | Build System | BitBake |
| | +----------------------|
| | | Configuration |
| | +----------------------|
| | | General |
| | +----------------------|
| | | Hob |
| | +----------------------|
| | | Image Creator |
| | +----------------------|
| | | Layers |
| +----------------------+----------------------|
| | Security | General |
|-----------------------+----------------------+----------------------|
| Yocto Metadata Layers | Layers | dlna |
| | +----------------------|
| | | extra |
| | +----------------------|
| | | general |
| | +----------------------|
| | | intel |
| | +----------------------|
| | | linaro |
| | +----------------------|
| | | xilinx |
| |----------------------+----------------------|
| | Meta Recipes | connectivity |
| | +----------------------|
| | | core |
| | +----------------------|
| | | demoapps |
| | +----------------------|
| | | devtools / toolchain |
| | +----------------------|
| | | general |
| | +----------------------|
| | | graphics |
| | +----------------------|
| | | kernel |
| | +----------------------|
| | | multimedia |
|-----------------------+----------------------+----------------------|

|-------------------\Swabber--------------general
| |--------------------poky integration
|
|-------------------\Yocto Test Suite-----General

|-------------------\Poky-----------------General
| `--------------------SDK Tools
|
|-------------------\Core OS--------------General
| |--------------------Kernel
| |--------------------Graphics Driver
| `--------------------Tool Chain
|
|-------------------\Runtime Distribution-General
| |--------------------System Startup
| |--------------------Installation
| `--------------------connman ...
|
|-------------------\SDK Anjuta Plugin----General
|
|-------------------\SDK Eclipse Plugin---General
|
|-------------------\Security-------------General
|
`-------------------\Documentation
|--------------------SDK-Doc
`--------------------PRD

\Yocto Infrastructure
|-------------------\AutoBuilder----------General
|-------------------\Bugzilla-------------General
|-------------------\Website--------------General
`-------------------\Yocto Test------------Sanity Test

</pre>

The detailed configuration should be suggested by component owners.

=== Hardware ===
* eMenlow
* netbook
* Mips
* Power PC
* ARM

=== Version and Target ===
* Version includes Yocto 0.9 and Yocto 1.0
* Target milestone includes 0.9_M1, 0.9_M2, 0.9_M3 and 0.9_M4

=== Priority and Severity ===
* The priority classifies bug fixing order. It can not be set when open a bug. It was set when doing Triage. The Priorities should be following 5 kinds.
** High -- Bug fixing is planned within 2 weeks, no later than the up-coming milestone, or critical issue for out of cycle release. e.g. highly reproducible crash issues (system or related to key apps/components need to deliver in the upcoming milestone); issues which cause major function loss of a specific feature which is POR of the up-comping milestone; issues which are easy to hit by user and greatly impact user experience or customer requirements; and urgent security issues which needs to be fixed in last release.
** Medium -- Bug fixing is planned before the milestone and must be fixed before the release is finalized.
** Low -- Bug fixing is not planned for the up-coming project release. Non POR feature request, hard to reproduce will fall into this category.
** Undecided -- New reported bug is '''undecided''', before Triage.
** FEAT -- A feature request bug, which isn't approved for future release yet. It will be changed to real priority after Change Control Board (CCB) approves it.
** Note: High impact but Low Priority bugs can be documented in the release notes.

* The Severity indicates bug's impacting level to reporter. It can be categorized to following 5 kinds. The '''default''' is '''Normal'''.
** Critical -- Crashes, hang, loss of data, negative impact to other components, memory leak etc.
** Major -- Major loss of functionality of POR
** Normal -- Regular issue, some loss of functionality under certain circumstance
** Minor -- Minor loss of functionality, or issues with easy workaround available
** Enhancement -- Request for enhancement work

=== Bug Status ===
* Open -- A new reported bug with default assignee.
* ACCEPTED-- The assigned developer has reviewed and accept the bug.
* Resolved -- bug is fixed or closed by other resolved method.
** Fixed -- This is fixed and in the master branch will be set automatically during build
** NotABug -- This is verified as not a bug
** WontFix -- We will not fix this bug, possibly because a newer package fixes it
** Duplicate -- Duplicate of another bug, possibly different failure mode
** Invalid -- The bug is invalid, sometimes this is used when the author of the bug does not provide accurate information, these will be reviewed by Triage team, and could be changed to '''NeedInfo'''
** Obsolete -- The bug is obsolete, old bug that is no longer appropriate, or a package that is depercated.
** WorksForMe -- The bug does not appear when tested by engineer, more appropriately, this may be '''NeedInfo'''
* Verified -- bug is double checked and agreed with the resolved method by original reporter.
* Reopen: bug can be reopened, if it is in Resolved, Verified or Close stage.
* NeedInfo: bug needs be set to NeedInfo, if there is important information missing to understand or reproduce bug.
* WaitForUpstream: The owner does bug analysis and finds this bug comes from upstream. Owner can post a new bug in upstream bugzilla, change status to '''WaitForUpstream''' and add the upstream bugzilla URL in comment area. When upstream bug is fixed, put the bug fixing into Yocto repository. After the patch is built into weekly build, change its status to Resolved/FIXED.
* '''Close''' stage is not used in normal bug life. When reported two same bugs by wrongly click button twice, the 2nd one can be closed. Generally it(close stage) is just for keeping wrong bug out of scrub cycle and statistic.

=== Bug Life Cycle ===
A normal Bug's life is started from '''Open''' and ended by '''Verified'''. Triage team will select "verified: Program Management", after confirm the verification.

[[Image:Yocto_Bug_Life_Cycle.jpg|frame|none|Bug Life Cycle]]

Bug should be marked as Resolved/Fixed, after its fixing patch is built into formal build (weekly build or milestone build). There is an automation method to update bugs to "RESOVLED/FIXED" status by following steps.
# Developer fixed bug and check in patch to his ''contrib'' branch with special words in commit description: '''[BUGFIX #4321]'''
# Developer asked tree gatekeeper to pull patch.
# Release Engineer do formal build. The build script will read new commit description and find out bug ID.
# Build script will notify bugzilla and update bugs status to "RESOLVE/FIXED"

If a weekly build includes a new commit, which reverts another patch, there should be a tool to judge whether the reverted patch summary include any bug fixing ID. If the reverted patch does include any bug fixing, the bug should be reopen.

[[Image:Yocto_Bug_Fix_Process.PNG|frame|none|Bug Fixing Process]]

=== Defect Submission ===
Defects may be entered by anyone working on the Yocto. Bug submission should include severity, thorough environment information, proper and clear reproduce steps and logs.

=== Bug Group ===
Bug group is used to control bug visibility. Couple of groups will be set up. When reporting or updating bugs, group check box could be edit.

* '''Security''' -- Bugs can only be viewed by Security group user. Bugs will be in Security Group, when it is reported to security component.
* No_Group_Check_Box_Selection-- Bugs are public. (Be careful)''' '''
* TBD

=== Bug Reporter ===
* Provide clear and simple bug subject. It is recommended to put a '''Fault Component Name''' with brackets at the beginning of subject as a keyword, e.g. [Poky].
* Validate all fields are correct. If fields are not filled out correctly, the bug might be sent back to the submitter.
* Judge the right Severity.
* Adds any additional information from the bug scrub.
* Assigns the bug to the correct person to disposition the bug.
* If a bug is too vague to make a determination then the Resolution Field of the bug will be set to need more information and sent back the bug submitter.
* '''Bug Priority can't be set when report a bug. It will be set when doing bug Triage'''

=== Bug Owner ===
* Review bugs to check if there are enough information. If not, set the bug to NeedInfo. Try to reproduce bug, if there are clear steps.
* Based on bug Priority and Severity to fix bugs in time. For example, High Priority bugs usually should be fixed in 2 weeks. High/critical bugs should be fixed as soon as possible, which has impaction to whole system.
* Update bugs in time with comments. Set the bug to Fixed and provide the tree/commit info, after bug fixing. '''Bug should not be marked as "fix", if patch is not checked into repository. '''

== Bug Tracking ==
Yocto is a cross many Geo project. Single bug scrub meeting is not easy to maintain. Considering Embedded Linux will be a big project, it brings a concept named ''Triage'' to effectively track bug. Triage is mainly for setting new bug priority. Triage virtual team will based on bug's severity, features and schedule to suggest bug fixing priority. Developer teams will receive triage email in time. If reach agreement, bugs will be followed up based on priority. Team manager should be responsible for monitoring the bug fixing schedule to align with related priority. This process is to make the high priority bug be fixed in time and reduce the schedule risk. There are still separated bug review or discussion meeting, which is held through Jabber.

=== Triage Management Team ===
* Program Manager
* Architect
* Engineering Manager
* QA leader

=== Triage Process ===
The triage process will be held frequently to make sure new coming bugs are set with correct priority in time. Triage chairman scrubs new bugs and set priority everyday. PDT meeting will review past week's overall triage result once per week.

The Bugzilla system will send emails to component owner and related engineers about creating or changing of bugs. Before Triage, new bugs could be discussed and even fixed.

'''Bug Triage Process '''

[[Image:bug_triage_process.PNG|frame|none|bug traiage process]]

'''Triage email example'''
<pre>
To: Yocto OTC
Subject: [Yocto-bug-triage] Bug Triage Review - ww26.1

Manager: MGR_A
==================
Bug ID Sev Priority Assignee Summary
1 maj High dev_A [Poky] XYZ Build Failure

Manager: MGR_B
====================
Bug ID Sev Priority Assignee Summary
2 maj High dev_B [SDK] ABC button error
3 nor Medium dev_C [X] Can't start X
</pre>

=== Responsibility ===
* Triage Chairman
** Triage new bugs: set initial priority, correct bug component and owner and mark duplicated bugs.
** Monitor overall bug fix progress with indicators: find out aging bugs.
** Send out triage result email to yocto mailing list (or Triage management team member) for review.
** Escalate aging high priority open bugs.
* Triage Management Team
** Development/Distribution managers are mandatory to review triage result and commit to fix
* Development/Distribution Manager
** Ensure developer/distro ACCEPT bugs in bugzilla within 3 days
** Commit developer to fix high priority bugs
* Program Manager
** Coordinate and push bugs to be fixed in time
* Triage Decision Forum (PDT Meeting)
** Make decision on controversial bugs
** Review and Monitor previous decision
** Triage Chairman update bugzilla based on decision
** Discuss and approve bug whose priority needs to be downgraded

=== Triage Chairman ===
Triage chairman role will be rotated in distribution leaders, engineer manager, SDK leader and QA leader. Each chairman will own 1 milestone cycle. Triage chairman starts from Yocto 0.9 M2 cycle and rotate in following order.
# Saul Wold -- Distro leader
# Susie Li -- engineer manager
# Kevin Tian -- distro leader
# Jessica Zhang -- SDK leader
# QA Leader

=== Bug Data Reporting ===
Defect Data is tracked and presented to the PDT meeting on a weekly basis by QA team. Any escalation items should be discussed and resolved in the PDT meeting.

=== External Owned Bug Triage ===
There might be some bugs owned by external developers. These bugs' triage results will be sent to Yocto public mailing list weekly.

=== Re-Triage for Next Milestone and Release ===
After a new milestone, there will be a time to review all medium priority bugs and set new Priority for next coming milestone.
After a new release, there will be a time to review all low priority bugs and set new Priority for next coming release.

== Feature Request Process ==
New feature request should be applied through Bugzilla as a bug. User could select corresponding Severity to indicate how important the feature is. User needs to follow Feature Request template to submit new request. Triage chairman will mark new feature request bug priority to '''FEAT'''.

There will be two important feature request review time per year in Aug. and Jan. (2 months before current release). In the review period, there will be 2~4 times review meetings by CCB. CCB will decide new features which will be included in next release, that will be released 8 months later. If feature request missed the review period, in theory it will be missed in next release. Any approved new feature will be reset Priority value and Target Version value. Non approved feature will keep "FEAT" priority.

=== Change Control Board ===
Following people should join CCB to review new feature request.
PME(Product Marketing Engineer), PM, Architect, Managers, Key developer and QA leader

=== Feature Request Bug Requirement ===
Feature request bug should be added specific Keywords in subject and Keywords field.

Following message should be added at the beginning of subject.
[FEAT_REQ Company Yocto_Target_Version]

For example: [FEAT_REQ xxx 1.0] Add Connman for network connection.

Following words should be added in Keywords field.
FEATURE_REQUEST

=== Feature Request Bug Template ===
<pre>
1. Feature Description:

2. Feature Present Code Status(including location and version):

3. Code License (e.g. GPLv2):

4. Business Impaction:

5. Other Justification:

</pre>

Bugzilla Configuration and Bug Tracking

2011-11-22T19:18:24Z

Scottrifw: /* Classification Product and Components */

Yocto Project Bug Process version

{|border="1"
|Version|| Modifier || Comments
|-
| 0.3 || Yongkang You || Initial Version
|-
| 0.5 || Yongkang You || Apply comments from Richard, Dave and Susie. Add Feature Request Process and Add a new Priority "FEAT" for it.
|-
| 0.8 || Yongkang You || Internal review and agree bug life cycle and bug Triage process.
|-
| 0.85 || Saul Wold || Add Bug Status / Sub-Status Definitions.
|-
| 0.9 || davest || Cleanup for 0.9 release.
|}

You should also read our [[Community Guidelines]] before submitting bugs.

------
== Defect Management ==
Yocto uses '''[http://www.bugzilla.org/ Bugzilla]''' as its defect tracking tool.

=== Home Address ===
http://bugzilla.yoctoproject.org

=== Get an Account ===
Anyone working on the Yocto project can query existing bugs in Bugzilla. You must have an account to submit a bug, edit a bug, or take action on a bug.

To set up an account, go to the '''[http://www.bugzilla.yoctoproject.org/ Yocto Bugzilla]''' home page and click on "New Account" in the footer area. Follow the directions there to set up your account.

=== Classification Product and Components ===
Bugzilla uses these Products and Components:

<pre>
| Classification | Product | Components |
|==================+===================+====================|
| Yocto Projects | Anjuta Plug-in | General |
| +-------------------+--------------------|
| | BSPs | General |
| +-------------------+--------------------|
| | Cross-prelink | General |
| | +--------------------|
| | | Poky Integration |
| +-------------------+--------------------+
| | Documentation | Handbook |
| | +--------------------+
| | | Other |
| | +--------------------+
| | | PRD |
| | +--------------------+
| | | SDK |
| +-------------------+--------------------+
| | Eclipse Plug-in | General |
| +-------------------+--------------------+
| | Kernel | Build |
| | +--------------------+
| | | Configuration |
| | +--------------------+
| | | General |
| | +--------------------+
| | | Runtime |
| +-------------------+--------------------+
| | Pseudo | General |
| | +--------------------+
| | | Poky Configuration |
| +-------------------+--------------------+
|-------------------\Pseudo---------------general
| |--------------------poky configuration
|
|-------------------\Runtime Distribution-Installation
| |--------------------System Startup
|
|-------------------\SDK Tools------------general
|
|-------------------\Swabber--------------general
| |--------------------poky integration
|
|-------------------\Yocto Test Suite-----General

|-------------------\Poky-----------------General
| `--------------------SDK Tools
|
|-------------------\Core OS--------------General
| |--------------------Kernel
| |--------------------Graphics Driver
| `--------------------Tool Chain
|
|-------------------\Runtime Distribution-General
| |--------------------System Startup
| |--------------------Installation
| `--------------------connman ...
|
|-------------------\SDK Anjuta Plugin----General
|
|-------------------\SDK Eclipse Plugin---General
|
|-------------------\Security-------------General
|
`-------------------\Documentation
|--------------------SDK-Doc
`--------------------PRD

\Yocto Infrastructure
|-------------------\AutoBuilder----------General
|-------------------\Bugzilla-------------General
|-------------------\Website--------------General
`-------------------\Yocto Test------------Sanity Test

</pre>

The detailed configuration should be suggested by component owners.

=== Hardware ===
* eMenlow
* netbook
* Mips
* Power PC
* ARM

=== Version and Target ===
* Version includes Yocto 0.9 and Yocto 1.0
* Target milestone includes 0.9_M1, 0.9_M2, 0.9_M3 and 0.9_M4

=== Priority and Severity ===
* The priority classifies bug fixing order. It can not be set when open a bug. It was set when doing Triage. The Priorities should be following 5 kinds.
** High -- Bug fixing is planned within 2 weeks, no later than the up-coming milestone, or critical issue for out of cycle release. e.g. highly reproducible crash issues (system or related to key apps/components need to deliver in the upcoming milestone); issues which cause major function loss of a specific feature which is POR of the up-comping milestone; issues which are easy to hit by user and greatly impact user experience or customer requirements; and urgent security issues which needs to be fixed in last release.
** Medium -- Bug fixing is planned before the milestone and must be fixed before the release is finalized.
** Low -- Bug fixing is not planned for the up-coming project release. Non POR feature request, hard to reproduce will fall into this category.
** Undecided -- New reported bug is '''undecided''', before Triage.
** FEAT -- A feature request bug, which isn't approved for future release yet. It will be changed to real priority after Change Control Board (CCB) approves it.
** Note: High impact but Low Priority bugs can be documented in the release notes.

* The Severity indicates bug's impacting level to reporter. It can be categorized to following 5 kinds. The '''default''' is '''Normal'''.
** Critical -- Crashes, hang, loss of data, negative impact to other components, memory leak etc.
** Major -- Major loss of functionality of POR
** Normal -- Regular issue, some loss of functionality under certain circumstance
** Minor -- Minor loss of functionality, or issues with easy workaround available
** Enhancement -- Request for enhancement work

=== Bug Status ===
* Open -- A new reported bug with default assignee.
* ACCEPTED-- The assigned developer has reviewed and accept the bug.
* Resolved -- bug is fixed or closed by other resolved method.
** Fixed -- This is fixed and in the master branch will be set automatically during build
** NotABug -- This is verified as not a bug
** WontFix -- We will not fix this bug, possibly because a newer package fixes it
** Duplicate -- Duplicate of another bug, possibly different failure mode
** Invalid -- The bug is invalid, sometimes this is used when the author of the bug does not provide accurate information, these will be reviewed by Triage team, and could be changed to '''NeedInfo'''
** Obsolete -- The bug is obsolete, old bug that is no longer appropriate, or a package that is depercated.
** WorksForMe -- The bug does not appear when tested by engineer, more appropriately, this may be '''NeedInfo'''
* Verified -- bug is double checked and agreed with the resolved method by original reporter.
* Reopen: bug can be reopened, if it is in Resolved, Verified or Close stage.
* NeedInfo: bug needs be set to NeedInfo, if there is important information missing to understand or reproduce bug.
* WaitForUpstream: The owner does bug analysis and finds this bug comes from upstream. Owner can post a new bug in upstream bugzilla, change status to '''WaitForUpstream''' and add the upstream bugzilla URL in comment area. When upstream bug is fixed, put the bug fixing into Yocto repository. After the patch is built into weekly build, change its status to Resolved/FIXED.
* '''Close''' stage is not used in normal bug life. When reported two same bugs by wrongly click button twice, the 2nd one can be closed. Generally it(close stage) is just for keeping wrong bug out of scrub cycle and statistic.

=== Bug Life Cycle ===
A normal Bug's life is started from '''Open''' and ended by '''Verified'''. Triage team will select "verified: Program Management", after confirm the verification.

[[Image:Yocto_Bug_Life_Cycle.jpg|frame|none|Bug Life Cycle]]

Bug should be marked as Resolved/Fixed, after its fixing patch is built into formal build (weekly build or milestone build). There is an automation method to update bugs to "RESOVLED/FIXED" status by following steps.
# Developer fixed bug and check in patch to his ''contrib'' branch with special words in commit description: '''[BUGFIX #4321]'''
# Developer asked tree gatekeeper to pull patch.
# Release Engineer do formal build. The build script will read new commit description and find out bug ID.
# Build script will notify bugzilla and update bugs status to "RESOLVE/FIXED"

If a weekly build includes a new commit, which reverts another patch, there should be a tool to judge whether the reverted patch summary include any bug fixing ID. If the reverted patch does include any bug fixing, the bug should be reopen.

[[Image:Yocto_Bug_Fix_Process.PNG|frame|none|Bug Fixing Process]]

=== Defect Submission ===
Defects may be entered by anyone working on the Yocto. Bug submission should include severity, thorough environment information, proper and clear reproduce steps and logs.

=== Bug Group ===
Bug group is used to control bug visibility. Couple of groups will be set up. When reporting or updating bugs, group check box could be edit.

* '''Security''' -- Bugs can only be viewed by Security group user. Bugs will be in Security Group, when it is reported to security component.
* No_Group_Check_Box_Selection-- Bugs are public. (Be careful)''' '''
* TBD

=== Bug Reporter ===
* Provide clear and simple bug subject. It is recommended to put a '''Fault Component Name''' with brackets at the beginning of subject as a keyword, e.g. [Poky].
* Validate all fields are correct. If fields are not filled out correctly, the bug might be sent back to the submitter.
* Judge the right Severity.
* Adds any additional information from the bug scrub.
* Assigns the bug to the correct person to disposition the bug.
* If a bug is too vague to make a determination then the Resolution Field of the bug will be set to need more information and sent back the bug submitter.
* '''Bug Priority can't be set when report a bug. It will be set when doing bug Triage'''

=== Bug Owner ===
* Review bugs to check if there are enough information. If not, set the bug to NeedInfo. Try to reproduce bug, if there are clear steps.
* Based on bug Priority and Severity to fix bugs in time. For example, High Priority bugs usually should be fixed in 2 weeks. High/critical bugs should be fixed as soon as possible, which has impaction to whole system.
* Update bugs in time with comments. Set the bug to Fixed and provide the tree/commit info, after bug fixing. '''Bug should not be marked as "fix", if patch is not checked into repository. '''

== Bug Tracking ==
Yocto is a cross many Geo project. Single bug scrub meeting is not easy to maintain. Considering Embedded Linux will be a big project, it brings a concept named ''Triage'' to effectively track bug. Triage is mainly for setting new bug priority. Triage virtual team will based on bug's severity, features and schedule to suggest bug fixing priority. Developer teams will receive triage email in time. If reach agreement, bugs will be followed up based on priority. Team manager should be responsible for monitoring the bug fixing schedule to align with related priority. This process is to make the high priority bug be fixed in time and reduce the schedule risk. There are still separated bug review or discussion meeting, which is held through Jabber.

=== Triage Management Team ===
* Program Manager
* Architect
* Engineering Manager
* QA leader

=== Triage Process ===
The triage process will be held frequently to make sure new coming bugs are set with correct priority in time. Triage chairman scrubs new bugs and set priority everyday. PDT meeting will review past week's overall triage result once per week.

The Bugzilla system will send emails to component owner and related engineers about creating or changing of bugs. Before Triage, new bugs could be discussed and even fixed.

'''Bug Triage Process '''

[[Image:bug_triage_process.PNG|frame|none|bug traiage process]]

'''Triage email example'''
<pre>
To: Yocto OTC
Subject: [Yocto-bug-triage] Bug Triage Review - ww26.1

Manager: MGR_A
==================
Bug ID Sev Priority Assignee Summary
1 maj High dev_A [Poky] XYZ Build Failure

Manager: MGR_B
====================
Bug ID Sev Priority Assignee Summary
2 maj High dev_B [SDK] ABC button error
3 nor Medium dev_C [X] Can't start X
</pre>

=== Responsibility ===
* Triage Chairman
** Triage new bugs: set initial priority, correct bug component and owner and mark duplicated bugs.
** Monitor overall bug fix progress with indicators: find out aging bugs.
** Send out triage result email to yocto mailing list (or Triage management team member) for review.
** Escalate aging high priority open bugs.
* Triage Management Team
** Development/Distribution managers are mandatory to review triage result and commit to fix
* Development/Distribution Manager
** Ensure developer/distro ACCEPT bugs in bugzilla within 3 days
** Commit developer to fix high priority bugs
* Program Manager
** Coordinate and push bugs to be fixed in time
* Triage Decision Forum (PDT Meeting)
** Make decision on controversial bugs
** Review and Monitor previous decision
** Triage Chairman update bugzilla based on decision
** Discuss and approve bug whose priority needs to be downgraded

=== Triage Chairman ===
Triage chairman role will be rotated in distribution leaders, engineer manager, SDK leader and QA leader. Each chairman will own 1 milestone cycle. Triage chairman starts from Yocto 0.9 M2 cycle and rotate in following order.
# Saul Wold -- Distro leader
# Susie Li -- engineer manager
# Kevin Tian -- distro leader
# Jessica Zhang -- SDK leader
# QA Leader

=== Bug Data Reporting ===
Defect Data is tracked and presented to the PDT meeting on a weekly basis by QA team. Any escalation items should be discussed and resolved in the PDT meeting.

=== External Owned Bug Triage ===
There might be some bugs owned by external developers. These bugs' triage results will be sent to Yocto public mailing list weekly.

=== Re-Triage for Next Milestone and Release ===
After a new milestone, there will be a time to review all medium priority bugs and set new Priority for next coming milestone.
After a new release, there will be a time to review all low priority bugs and set new Priority for next coming release.

== Feature Request Process ==
New feature request should be applied through Bugzilla as a bug. User could select corresponding Severity to indicate how important the feature is. User needs to follow Feature Request template to submit new request. Triage chairman will mark new feature request bug priority to '''FEAT'''.

There will be two important feature request review time per year in Aug. and Jan. (2 months before current release). In the review period, there will be 2~4 times review meetings by CCB. CCB will decide new features which will be included in next release, that will be released 8 months later. If feature request missed the review period, in theory it will be missed in next release. Any approved new feature will be reset Priority value and Target Version value. Non approved feature will keep "FEAT" priority.

=== Change Control Board ===
Following people should join CCB to review new feature request.
PME(Product Marketing Engineer), PM, Architect, Managers, Key developer and QA leader

=== Feature Request Bug Requirement ===
Feature request bug should be added specific Keywords in subject and Keywords field.

Following message should be added at the beginning of subject.
[FEAT_REQ Company Yocto_Target_Version]

For example: [FEAT_REQ xxx 1.0] Add Connman for network connection.

Following words should be added in Keywords field.
FEATURE_REQUEST

=== Feature Request Bug Template ===
<pre>
1. Feature Description:

2. Feature Present Code Status(including location and version):

3. Code License (e.g. GPLv2):

4. Business Impaction:

5. Other Justification:

</pre>

Bugzilla Configuration and Bug Tracking

2011-11-22T18:46:47Z

Scottrifw:

Yocto Project Bug Process version

{|border="1"
|Version|| Modifier || Comments
|-
| 0.3 || Yongkang You || Initial Version
|-
| 0.5 || Yongkang You || Apply comments from Richard, Dave and Susie. Add Feature Request Process and Add a new Priority "FEAT" for it.
|-
| 0.8 || Yongkang You || Internal review and agree bug life cycle and bug Triage process.
|-
| 0.85 || Saul Wold || Add Bug Status / Sub-Status Definitions.
|-
| 0.9 || davest || Cleanup for 0.9 release.
|}

You should also read our [[Community Guidelines]] before submitting bugs.

------
== Defect Management ==
Yocto uses '''[http://www.bugzilla.org/ Bugzilla]''' as its defect tracking tool.

=== Home Address ===
http://bugzilla.yoctoproject.org

=== Get an Account ===
Anyone working on the Yocto project can query existing bugs in Bugzilla. You must have an account to submit a bug, edit a bug, or take action on a bug.

To set up an account, go to the '''[http://www.bugzilla.yoctoproject.org/ Yocto Bugzilla]''' home page and click on "New Account" in the footer area. Follow the directions there to set up your account.

=== Classification Product and Components ===
Bugzilla uses these Products and Components:

<pre>
| Classification | Product | Components |
\Yocto Platform
|-------------------\Poky-----------------General
| `--------------------SDK Tools
|
|-------------------\Core OS--------------General
| |--------------------Kernel
| |--------------------Graphics Driver
| `--------------------Tool Chain
|
|-------------------\Runtime Distribution-General
| |--------------------System Startup
| |--------------------Installation
| `--------------------connman ...
|
|-------------------\SDK Anjuta Plugin----General
|
|-------------------\SDK Eclipse Plugin---General
|
|-------------------\Security-------------General
|
`-------------------\Documentation
|--------------------SDK-Doc
`--------------------PRD

\Yocto Infrastructure
|-------------------\AutoBuilder----------General
|-------------------\Bugzilla-------------General
|-------------------\Website--------------General
`-------------------\Yocto Test------------Sanity Test

</pre>

The detailed configuration should be suggested by component owners.

=== Hardware ===
* eMenlow
* netbook
* Mips
* Power PC
* ARM

=== Version and Target ===
* Version includes Yocto 0.9 and Yocto 1.0
* Target milestone includes 0.9_M1, 0.9_M2, 0.9_M3 and 0.9_M4

=== Priority and Severity ===
* The priority classifies bug fixing order. It can not be set when open a bug. It was set when doing Triage. The Priorities should be following 5 kinds.
** High -- Bug fixing is planned within 2 weeks, no later than the up-coming milestone, or critical issue for out of cycle release. e.g. highly reproducible crash issues (system or related to key apps/components need to deliver in the upcoming milestone); issues which cause major function loss of a specific feature which is POR of the up-comping milestone; issues which are easy to hit by user and greatly impact user experience or customer requirements; and urgent security issues which needs to be fixed in last release.
** Medium -- Bug fixing is planned before the milestone and must be fixed before the release is finalized.
** Low -- Bug fixing is not planned for the up-coming project release. Non POR feature request, hard to reproduce will fall into this category.
** Undecided -- New reported bug is '''undecided''', before Triage.
** FEAT -- A feature request bug, which isn't approved for future release yet. It will be changed to real priority after Change Control Board (CCB) approves it.
** Note: High impact but Low Priority bugs can be documented in the release notes.

* The Severity indicates bug's impacting level to reporter. It can be categorized to following 5 kinds. The '''default''' is '''Normal'''.
** Critical -- Crashes, hang, loss of data, negative impact to other components, memory leak etc.
** Major -- Major loss of functionality of POR
** Normal -- Regular issue, some loss of functionality under certain circumstance
** Minor -- Minor loss of functionality, or issues with easy workaround available
** Enhancement -- Request for enhancement work

=== Bug Status ===
* Open -- A new reported bug with default assignee.
* ACCEPTED-- The assigned developer has reviewed and accept the bug.
* Resolved -- bug is fixed or closed by other resolved method.
** Fixed -- This is fixed and in the master branch will be set automatically during build
** NotABug -- This is verified as not a bug
** WontFix -- We will not fix this bug, possibly because a newer package fixes it
** Duplicate -- Duplicate of another bug, possibly different failure mode
** Invalid -- The bug is invalid, sometimes this is used when the author of the bug does not provide accurate information, these will be reviewed by Triage team, and could be changed to '''NeedInfo'''
** Obsolete -- The bug is obsolete, old bug that is no longer appropriate, or a package that is depercated.
** WorksForMe -- The bug does not appear when tested by engineer, more appropriately, this may be '''NeedInfo'''
* Verified -- bug is double checked and agreed with the resolved method by original reporter.
* Reopen: bug can be reopened, if it is in Resolved, Verified or Close stage.
* NeedInfo: bug needs be set to NeedInfo, if there is important information missing to understand or reproduce bug.
* WaitForUpstream: The owner does bug analysis and finds this bug comes from upstream. Owner can post a new bug in upstream bugzilla, change status to '''WaitForUpstream''' and add the upstream bugzilla URL in comment area. When upstream bug is fixed, put the bug fixing into Yocto repository. After the patch is built into weekly build, change its status to Resolved/FIXED.
* '''Close''' stage is not used in normal bug life. When reported two same bugs by wrongly click button twice, the 2nd one can be closed. Generally it(close stage) is just for keeping wrong bug out of scrub cycle and statistic.

=== Bug Life Cycle ===
A normal Bug's life is started from '''Open''' and ended by '''Verified'''. Triage team will select "verified: Program Management", after confirm the verification.

[[Image:Yocto_Bug_Life_Cycle.jpg|frame|none|Bug Life Cycle]]

Bug should be marked as Resolved/Fixed, after its fixing patch is built into formal build (weekly build or milestone build). There is an automation method to update bugs to "RESOVLED/FIXED" status by following steps.
# Developer fixed bug and check in patch to his ''contrib'' branch with special words in commit description: '''[BUGFIX #4321]'''
# Developer asked tree gatekeeper to pull patch.
# Release Engineer do formal build. The build script will read new commit description and find out bug ID.
# Build script will notify bugzilla and update bugs status to "RESOLVE/FIXED"

If a weekly build includes a new commit, which reverts another patch, there should be a tool to judge whether the reverted patch summary include any bug fixing ID. If the reverted patch does include any bug fixing, the bug should be reopen.

[[Image:Yocto_Bug_Fix_Process.PNG|frame|none|Bug Fixing Process]]

=== Defect Submission ===
Defects may be entered by anyone working on the Yocto. Bug submission should include severity, thorough environment information, proper and clear reproduce steps and logs.

=== Bug Group ===
Bug group is used to control bug visibility. Couple of groups will be set up. When reporting or updating bugs, group check box could be edit.

* '''Security''' -- Bugs can only be viewed by Security group user. Bugs will be in Security Group, when it is reported to security component.
* No_Group_Check_Box_Selection-- Bugs are public. (Be careful)''' '''
* TBD

=== Bug Reporter ===
* Provide clear and simple bug subject. It is recommended to put a '''Fault Component Name''' with brackets at the beginning of subject as a keyword, e.g. [Poky].
* Validate all fields are correct. If fields are not filled out correctly, the bug might be sent back to the submitter.
* Judge the right Severity.
* Adds any additional information from the bug scrub.
* Assigns the bug to the correct person to disposition the bug.
* If a bug is too vague to make a determination then the Resolution Field of the bug will be set to need more information and sent back the bug submitter.
* '''Bug Priority can't be set when report a bug. It will be set when doing bug Triage'''

=== Bug Owner ===
* Review bugs to check if there are enough information. If not, set the bug to NeedInfo. Try to reproduce bug, if there are clear steps.
* Based on bug Priority and Severity to fix bugs in time. For example, High Priority bugs usually should be fixed in 2 weeks. High/critical bugs should be fixed as soon as possible, which has impaction to whole system.
* Update bugs in time with comments. Set the bug to Fixed and provide the tree/commit info, after bug fixing. '''Bug should not be marked as "fix", if patch is not checked into repository. '''

== Bug Tracking ==
Yocto is a cross many Geo project. Single bug scrub meeting is not easy to maintain. Considering Embedded Linux will be a big project, it brings a concept named ''Triage'' to effectively track bug. Triage is mainly for setting new bug priority. Triage virtual team will based on bug's severity, features and schedule to suggest bug fixing priority. Developer teams will receive triage email in time. If reach agreement, bugs will be followed up based on priority. Team manager should be responsible for monitoring the bug fixing schedule to align with related priority. This process is to make the high priority bug be fixed in time and reduce the schedule risk. There are still separated bug review or discussion meeting, which is held through Jabber.

=== Triage Management Team ===
* Program Manager
* Architect
* Engineering Manager
* QA leader

=== Triage Process ===
The triage process will be held frequently to make sure new coming bugs are set with correct priority in time. Triage chairman scrubs new bugs and set priority everyday. PDT meeting will review past week's overall triage result once per week.

The Bugzilla system will send emails to component owner and related engineers about creating or changing of bugs. Before Triage, new bugs could be discussed and even fixed.

'''Bug Triage Process '''

[[Image:bug_triage_process.PNG|frame|none|bug traiage process]]

'''Triage email example'''
<pre>
To: Yocto OTC
Subject: [Yocto-bug-triage] Bug Triage Review - ww26.1

Manager: MGR_A
==================
Bug ID Sev Priority Assignee Summary
1 maj High dev_A [Poky] XYZ Build Failure

Manager: MGR_B
====================
Bug ID Sev Priority Assignee Summary
2 maj High dev_B [SDK] ABC button error
3 nor Medium dev_C [X] Can't start X
</pre>

=== Responsibility ===
* Triage Chairman
** Triage new bugs: set initial priority, correct bug component and owner and mark duplicated bugs.
** Monitor overall bug fix progress with indicators: find out aging bugs.
** Send out triage result email to yocto mailing list (or Triage management team member) for review.
** Escalate aging high priority open bugs.
* Triage Management Team
** Development/Distribution managers are mandatory to review triage result and commit to fix
* Development/Distribution Manager
** Ensure developer/distro ACCEPT bugs in bugzilla within 3 days
** Commit developer to fix high priority bugs
* Program Manager
** Coordinate and push bugs to be fixed in time
* Triage Decision Forum (PDT Meeting)
** Make decision on controversial bugs
** Review and Monitor previous decision
** Triage Chairman update bugzilla based on decision
** Discuss and approve bug whose priority needs to be downgraded

=== Triage Chairman ===
Triage chairman role will be rotated in distribution leaders, engineer manager, SDK leader and QA leader. Each chairman will own 1 milestone cycle. Triage chairman starts from Yocto 0.9 M2 cycle and rotate in following order.
# Saul Wold -- Distro leader
# Susie Li -- engineer manager
# Kevin Tian -- distro leader
# Jessica Zhang -- SDK leader
# QA Leader

=== Bug Data Reporting ===
Defect Data is tracked and presented to the PDT meeting on a weekly basis by QA team. Any escalation items should be discussed and resolved in the PDT meeting.

=== External Owned Bug Triage ===
There might be some bugs owned by external developers. These bugs' triage results will be sent to Yocto public mailing list weekly.

=== Re-Triage for Next Milestone and Release ===
After a new milestone, there will be a time to review all medium priority bugs and set new Priority for next coming milestone.
After a new release, there will be a time to review all low priority bugs and set new Priority for next coming release.

== Feature Request Process ==
New feature request should be applied through Bugzilla as a bug. User could select corresponding Severity to indicate how important the feature is. User needs to follow Feature Request template to submit new request. Triage chairman will mark new feature request bug priority to '''FEAT'''.

There will be two important feature request review time per year in Aug. and Jan. (2 months before current release). In the review period, there will be 2~4 times review meetings by CCB. CCB will decide new features which will be included in next release, that will be released 8 months later. If feature request missed the review period, in theory it will be missed in next release. Any approved new feature will be reset Priority value and Target Version value. Non approved feature will keep "FEAT" priority.

=== Change Control Board ===
Following people should join CCB to review new feature request.
PME(Product Marketing Engineer), PM, Architect, Managers, Key developer and QA leader

=== Feature Request Bug Requirement ===
Feature request bug should be added specific Keywords in subject and Keywords field.

Following message should be added at the beginning of subject.
[FEAT_REQ Company Yocto_Target_Version]

For example: [FEAT_REQ xxx 1.0] Add Connman for network connection.

Following words should be added in Keywords field.
FEATURE_REQUEST

=== Feature Request Bug Template ===
<pre>
1. Feature Description:

2. Feature Present Code Status(including location and version):

3. Code License (e.g. GPLv2):

4. Business Impaction:

5. Other Justification:

</pre>

Bugzilla Configuration and Bug Tracking

2011-11-22T18:35:50Z

Scottrifw:

Yocto Project Bug Process version

{|border="1"
|Version|| Modifier || Comments
|-
| 0.3 || Yongkang You || Initial Version
|-
| 0.5 || Yongkang You || Apply comments from Richard, Dave and Susie. Add Feature Request Process and Add a new Priority "FEAT" for it.
|-
| 0.8 || Yongkang You || Internal review and agree bug life cycle and bug Triage process.
|-
| 0.85 || Saul Wold || Add Bug Status / Sub-Status Definitions.
|-
| 0.9 || davest || Cleanup for 0.9 release.
|}

You should also read our [[Community Guidelines]] before submitting bugs.

------
== Defect Management ==
Yocto uses '''[http://www.bugzilla.org/ Bugzilla]''' as its defect tracking tool.

=== Home Address ===
http://bugzilla.yoctoproject.org

=== Get an Account ===
Anyone working on the Yocto project can query existing bugs in Bugzilla. You must have an account to submit a bug, edit a bug, or take action on a bug.

To set up an account, go to the '''[http://bugzilla.yoctoproject.org]''' page and click on "New Account" in the footer area. Follow the directions there to set up your account.

=== Classification Product and Components ===
Bugzilla will have initial setting like:

<pre>
| Classification | Product | Components |
\Yocto Platform
|-------------------\Poky-----------------General
| `--------------------SDK Tools
|
|-------------------\Core OS--------------General
| |--------------------Kernel
| |--------------------Graphics Driver
| `--------------------Tool Chain
|
|-------------------\Runtime Distribution-General
| |--------------------System Startup
| |--------------------Installation
| `--------------------connman ...
|
|-------------------\SDK Anjuta Plugin----General
|
|-------------------\SDK Eclipse Plugin---General
|
|-------------------\Security-------------General
|
`-------------------\Documentation
|--------------------SDK-Doc
`--------------------PRD

\Yocto Infrastructure
|-------------------\AutoBuilder----------General
|-------------------\Bugzilla-------------General
|-------------------\Website--------------General
`-------------------\Yocto Test------------Sanity Test

</pre>

The detailed configuration should be suggested by component owners.

=== Hardware ===
* eMenlow
* netbook
* Mips
* Power PC
* ARM

=== Version and Target ===
* Version includes Yocto 0.9 and Yocto 1.0
* Target milestone includes 0.9_M1, 0.9_M2, 0.9_M3 and 0.9_M4

=== Priority and Severity ===
* The priority classifies bug fixing order. It can not be set when open a bug. It was set when doing Triage. The Priorities should be following 5 kinds.
** High -- Bug fixing is planned within 2 weeks, no later than the up-coming milestone, or critical issue for out of cycle release. e.g. highly reproducible crash issues (system or related to key apps/components need to deliver in the upcoming milestone); issues which cause major function loss of a specific feature which is POR of the up-comping milestone; issues which are easy to hit by user and greatly impact user experience or customer requirements; and urgent security issues which needs to be fixed in last release.
** Medium -- Bug fixing is planned before the milestone and must be fixed before the release is finalized.
** Low -- Bug fixing is not planned for the up-coming project release. Non POR feature request, hard to reproduce will fall into this category.
** Undecided -- New reported bug is '''undecided''', before Triage.
** FEAT -- A feature request bug, which isn't approved for future release yet. It will be changed to real priority after Change Control Board (CCB) approves it.
** Note: High impact but Low Priority bugs can be documented in the release notes.

* The Severity indicates bug's impacting level to reporter. It can be categorized to following 5 kinds. The '''default''' is '''Normal'''.
** Critical -- Crashes, hang, loss of data, negative impact to other components, memory leak etc.
** Major -- Major loss of functionality of POR
** Normal -- Regular issue, some loss of functionality under certain circumstance
** Minor -- Minor loss of functionality, or issues with easy workaround available
** Enhancement -- Request for enhancement work

=== Bug Status ===
* Open -- A new reported bug with default assignee.
* ACCEPTED-- The assigned developer has reviewed and accept the bug.
* Resolved -- bug is fixed or closed by other resolved method.
** Fixed -- This is fixed and in the master branch will be set automatically during build
** NotABug -- This is verified as not a bug
** WontFix -- We will not fix this bug, possibly because a newer package fixes it
** Duplicate -- Duplicate of another bug, possibly different failure mode
** Invalid -- The bug is invalid, sometimes this is used when the author of the bug does not provide accurate information, these will be reviewed by Triage team, and could be changed to '''NeedInfo'''
** Obsolete -- The bug is obsolete, old bug that is no longer appropriate, or a package that is depercated.
** WorksForMe -- The bug does not appear when tested by engineer, more appropriately, this may be '''NeedInfo'''
* Verified -- bug is double checked and agreed with the resolved method by original reporter.
* Reopen: bug can be reopened, if it is in Resolved, Verified or Close stage.
* NeedInfo: bug needs be set to NeedInfo, if there is important information missing to understand or reproduce bug.
* WaitForUpstream: The owner does bug analysis and finds this bug comes from upstream. Owner can post a new bug in upstream bugzilla, change status to '''WaitForUpstream''' and add the upstream bugzilla URL in comment area. When upstream bug is fixed, put the bug fixing into Yocto repository. After the patch is built into weekly build, change its status to Resolved/FIXED.
* '''Close''' stage is not used in normal bug life. When reported two same bugs by wrongly click button twice, the 2nd one can be closed. Generally it(close stage) is just for keeping wrong bug out of scrub cycle and statistic.

=== Bug Life Cycle ===
A normal Bug's life is started from '''Open''' and ended by '''Verified'''. Triage team will select "verified: Program Management", after confirm the verification.

[[Image:Yocto_Bug_Life_Cycle.jpg|frame|none|Bug Life Cycle]]

Bug should be marked as Resolved/Fixed, after its fixing patch is built into formal build (weekly build or milestone build). There is an automation method to update bugs to "RESOVLED/FIXED" status by following steps.
# Developer fixed bug and check in patch to his ''contrib'' branch with special words in commit description: '''[BUGFIX #4321]'''
# Developer asked tree gatekeeper to pull patch.
# Release Engineer do formal build. The build script will read new commit description and find out bug ID.
# Build script will notify bugzilla and update bugs status to "RESOLVE/FIXED"

If a weekly build includes a new commit, which reverts another patch, there should be a tool to judge whether the reverted patch summary include any bug fixing ID. If the reverted patch does include any bug fixing, the bug should be reopen.

[[Image:Yocto_Bug_Fix_Process.PNG|frame|none|Bug Fixing Process]]

=== Defect Submission ===
Defects may be entered by anyone working on the Yocto. Bug submission should include severity, thorough environment information, proper and clear reproduce steps and logs.

=== Bug Group ===
Bug group is used to control bug visibility. Couple of groups will be set up. When reporting or updating bugs, group check box could be edit.

* '''Security''' -- Bugs can only be viewed by Security group user. Bugs will be in Security Group, when it is reported to security component.
* No_Group_Check_Box_Selection-- Bugs are public. (Be careful)''' '''
* TBD

=== Bug Reporter ===
* Provide clear and simple bug subject. It is recommended to put a '''Fault Component Name''' with brackets at the beginning of subject as a keyword, e.g. [Poky].
* Validate all fields are correct. If fields are not filled out correctly, the bug might be sent back to the submitter.
* Judge the right Severity.
* Adds any additional information from the bug scrub.
* Assigns the bug to the correct person to disposition the bug.
* If a bug is too vague to make a determination then the Resolution Field of the bug will be set to need more information and sent back the bug submitter.
* '''Bug Priority can't be set when report a bug. It will be set when doing bug Triage'''

=== Bug Owner ===
* Review bugs to check if there are enough information. If not, set the bug to NeedInfo. Try to reproduce bug, if there are clear steps.
* Based on bug Priority and Severity to fix bugs in time. For example, High Priority bugs usually should be fixed in 2 weeks. High/critical bugs should be fixed as soon as possible, which has impaction to whole system.
* Update bugs in time with comments. Set the bug to Fixed and provide the tree/commit info, after bug fixing. '''Bug should not be marked as "fix", if patch is not checked into repository. '''

== Bug Tracking ==
Yocto is a cross many Geo project. Single bug scrub meeting is not easy to maintain. Considering Embedded Linux will be a big project, it brings a concept named ''Triage'' to effectively track bug. Triage is mainly for setting new bug priority. Triage virtual team will based on bug's severity, features and schedule to suggest bug fixing priority. Developer teams will receive triage email in time. If reach agreement, bugs will be followed up based on priority. Team manager should be responsible for monitoring the bug fixing schedule to align with related priority. This process is to make the high priority bug be fixed in time and reduce the schedule risk. There are still separated bug review or discussion meeting, which is held through Jabber.

=== Triage Management Team ===
* Program Manager
* Architect
* Engineering Manager
* QA leader

=== Triage Process ===
The triage process will be held frequently to make sure new coming bugs are set with correct priority in time. Triage chairman scrubs new bugs and set priority everyday. PDT meeting will review past week's overall triage result once per week.

The Bugzilla system will send emails to component owner and related engineers about creating or changing of bugs. Before Triage, new bugs could be discussed and even fixed.

'''Bug Triage Process '''

[[Image:bug_triage_process.PNG|frame|none|bug traiage process]]

'''Triage email example'''
<pre>
To: Yocto OTC
Subject: [Yocto-bug-triage] Bug Triage Review - ww26.1

Manager: MGR_A
==================
Bug ID Sev Priority Assignee Summary
1 maj High dev_A [Poky] XYZ Build Failure

Manager: MGR_B
====================
Bug ID Sev Priority Assignee Summary
2 maj High dev_B [SDK] ABC button error
3 nor Medium dev_C [X] Can't start X
</pre>

=== Responsibility ===
* Triage Chairman
** Triage new bugs: set initial priority, correct bug component and owner and mark duplicated bugs.
** Monitor overall bug fix progress with indicators: find out aging bugs.
** Send out triage result email to yocto mailing list (or Triage management team member) for review.
** Escalate aging high priority open bugs.
* Triage Management Team
** Development/Distribution managers are mandatory to review triage result and commit to fix
* Development/Distribution Manager
** Ensure developer/distro ACCEPT bugs in bugzilla within 3 days
** Commit developer to fix high priority bugs
* Program Manager
** Coordinate and push bugs to be fixed in time
* Triage Decision Forum (PDT Meeting)
** Make decision on controversial bugs
** Review and Monitor previous decision
** Triage Chairman update bugzilla based on decision
** Discuss and approve bug whose priority needs to be downgraded

=== Triage Chairman ===
Triage chairman role will be rotated in distribution leaders, engineer manager, SDK leader and QA leader. Each chairman will own 1 milestone cycle. Triage chairman starts from Yocto 0.9 M2 cycle and rotate in following order.
# Saul Wold -- Distro leader
# Susie Li -- engineer manager
# Kevin Tian -- distro leader
# Jessica Zhang -- SDK leader
# QA Leader

=== Bug Data Reporting ===
Defect Data is tracked and presented to the PDT meeting on a weekly basis by QA team. Any escalation items should be discussed and resolved in the PDT meeting.

=== External Owned Bug Triage ===
There might be some bugs owned by external developers. These bugs' triage results will be sent to Yocto public mailing list weekly.

=== Re-Triage for Next Milestone and Release ===
After a new milestone, there will be a time to review all medium priority bugs and set new Priority for next coming milestone.
After a new release, there will be a time to review all low priority bugs and set new Priority for next coming release.

== Feature Request Process ==
New feature request should be applied through Bugzilla as a bug. User could select corresponding Severity to indicate how important the feature is. User needs to follow Feature Request template to submit new request. Triage chairman will mark new feature request bug priority to '''FEAT'''.

There will be two important feature request review time per year in Aug. and Jan. (2 months before current release). In the review period, there will be 2~4 times review meetings by CCB. CCB will decide new features which will be included in next release, that will be released 8 months later. If feature request missed the review period, in theory it will be missed in next release. Any approved new feature will be reset Priority value and Target Version value. Non approved feature will keep "FEAT" priority.

=== Change Control Board ===
Following people should join CCB to review new feature request.
PME(Product Marketing Engineer), PM, Architect, Managers, Key developer and QA leader

=== Feature Request Bug Requirement ===
Feature request bug should be added specific Keywords in subject and Keywords field.

Following message should be added at the beginning of subject.
[FEAT_REQ Company Yocto_Target_Version]

For example: [FEAT_REQ xxx 1.0] Add Connman for network connection.

Following words should be added in Keywords field.
FEATURE_REQUEST

=== Feature Request Bug Template ===
<pre>
1. Feature Description:

2. Feature Present Code Status(including location and version):

3. Code License (e.g. GPLv2):

4. Business Impaction:

5. Other Justification:

</pre>

FAQ

2011-11-15T22:23:22Z

Scottrifw:

'''Yocto Project Public Messages and FAQ'''

Last edited: 10 November, 2011

'''Q: What is the Yocto Project?'''

'''A:''' The Yocto Project provides open source, high-quality infrastructure and tools to help developers create their own custom Linux distributions for any hardware architecture and across multiple market segments. The Yocto Project is intended to provide a helpful starting point for developers. The Yocto Project hosts other projects as well, including the Poky build system, Autobuilder automated build and test system, and the Embedded GLIBC (EGLIBC)C library. The Linux Foundation welcomes the participation of embedded vendors, developers, and other open source projects.

'''Q: What does the Linux Foundation hope to achieve with the Yocto Project?'''

'''A:''' This year’s annual survey of embedded developers conducted by Embedded Market Forecasters reported that the two primary factors contributing to embedded developers’ choice of Operating Systems (OS) in their designs are cost (44.6%) and the availability of source code (33.1%). These factors have contributed to the explosion of demand for Linux in embedded devices. Until now, embedded vendors and their partners relied on deep customization, requiring developers to wrestle with rapidly changing software and difficult build and maintenance cycles. The Linux Foundation recognized that an opportunity existed for a collaboratively developed, open source project that would build high-quality tools for the embedded Linux ecosystem.

'''Q: How does the Yocto Project help Linux reach a wider embedded audience?'''

'''A:''' This set of collaboratively developed, open source development tools focused on the embedded segment speeds embedded vendors’ time to market by establishing a shared build infrastructure. This enables Linux across the widest possible spectrum of devices, projects, and platforms. The Yocto Project has a great start on the code required to solve these problems.

'''Q: Isn’t the Yocto Project just yet another Linux distribution?'''

'''A:''' No. The Yocto Project is a set of tools and components, including a highly configurable build system, that enables developers to construct their own custom distributions, targeted for specific embedded devices. It is not, itself, a Linux distribution. Rather, it is capable of producing an image for a particular embedded device without dictating the composition of the Linux distribution actually built or the hardware architecture used.

'''Q: What benefits does the Yocto Project provide embedded developers and how is the Yocto Project superior to existing, similar tools?'''

'''A:''' Unlike build systems based on shell scripts or makefiles, the Yocto Project automates how source is fetched from a variety of upstream sources or from local project repositories. Updating to a new version of a package is often as easy as renaming a recipe file. It has a powerful customization architecture that allows the choice of a wide variety of footprint sizes as well as control over the choice or absence of components such as graphics subsystems, visualization middleware, and services.

A complete set of Linux package versions is specified in the metadata for the project; these versions are known to work correctly together. A robust effort within the project is dedicated to keeping this selection of packages fresh and up-to-date. Unlike other systems, however, only a single version of each package is typically provided with the project at any given time. This ensures that the packages are known to work well together, while providing the freedom to replace them at any time as the needs of a given embedded project mature.

The Yocto Project is package-format agnostic - supporting both major Linux packaging systems (.rpm and .deb), as well as the embedded-friendly ipkg format. The Yocto Project is also architecturally agnostic - supporting all major embedded architectures: ARM, 32- and 64-bit x86, PowerPC, and MIPS.

The Yocto Project shares the core build tool (BitBake) and metadata syntax with OpenEmbedded, particularly the core set of components known as openembedded-core. This commonality provides automatic familiarity for developers already using OpenEmbedded. However, the learning curve for getting started with the Yocto Project is less steep. It is easier for new users to create a working distribution with the Yocto Project, and more work is being done currently on this subject with the new Hob graphical user interface.

When a distribution is created with the Yocto Project, the build tool creates an application development SDK tailored to that distribution. This SDK can plug into the Eclipse IDE or it can be run as a command-line development system, complete with cross tools for the host and development tools for the device being developed.

'''Q: How does the existing embedded workflow compare to the Yocto Project and where can embedded developers save time?'''

'''A:''' Existing embedded developers have many systems from which to choose. Once a system is chosen and a device's OS has been created, it can often be very difficult and time consuming to trim the distribution to an appropriate footprint size and assemble a working set of components. Then, for the developer’s next project, if updated components are needed, perhaps for bug fixes, security fixes, or new hardware support, the developer typically must start over, with little ability to re-use prior work on distributions. The Yocto Project solves these problems by providing a single focus for embedded development, requiring less time to get a working and up-to-date distribution together. In addition, if commercial support is desired, it is quite simple to transition to a supporting operating system vendor (OSV) who offers products and services compatible with the Yocto Project. All of the major embedded Linux OSVs are active members of the Yocto Project.

'''Q: Does the Yocto Project have a special governance model, or is it managed as an open source project?'''

'''A:''' The Yocto Project is governed as an open source project working group under the auspices of the Linux Foundation. The Yocto Project Advisory Board consists of representatives from the major sponsoring organizations. This group advises the project on direction and provides resources, but all decisions are made by the project's Maintainers. In addition, there are Interest Groups who drive project feature requirements and provide direction on various aspects of project governance, including finances and infrastructure, and an Architect who coordinates the work of the Maintainers and sets project direction under the guidance of the Advisory Board and its subgroups.

'''Q: Why not just call this project Poky? What has changed between Poky and the Yocto Project?'''

'''A:''' The Yocto Project is an umbrella project. Accordingly, it includes a number of projects and resources specifically intended for facilitating development with Linux on embedded devices, and it is an appropriate place for larger organizations to collaborate on the development of build infrastructure for embedded Linux. Poky is one of the the largest components of the Yocto Project, and Poky continues as an independent, open source project developing the build system used by the Yocto Project, as well as by other open source projects.

'''Q: What is the difference between OpenEmbedded and the Yocto Project?'''

'''A:''' The Yocto Project and OpenEmbedded share a core collection of metadata called openembedded-core. However, the two organizations remain separate, each with its own focus. OpenEmbedded provides a comprehensive set of metadata for a wide variety of architectures, features, and applications. The Yocto Project focuses on providing powerful, easy-to-use, well-tested tools, metadata, and board support packages (BSPs) for a core set of architectures and specific boards.

'''Q: Who defines the root filesystem and metadata?'''

'''A:''' Metadata represents the versions of the various components in a distribution, such as the particular versions of the Linux kernel or libraries. The project supplies an example set of metadata that can generate several example distributions. The actual metadata used for the construction of a custom distribution may be supplied by a commercial vendor or created by an embedded developer. The root filesystem is defined in the metadata for a given build of a distribution.

'''Q: What are the criteria for baseline metadata?'''

'''A:''' The project has selected several major embedded architectures (32- and 64-bit x86, ARM, MIPS, and PowerPC) and footprint sizes (minimal, sato, lsb). Metadata has been created that generates a working build for these architectures and footprints while providing up-to-date and modern versions of the various open source components. We also supply metadata for a number of other components ("world"), which can be pulled into a custom distribution.

'''Q: What tool sets are included in the Yocto Project? When will they be available?'''

'''A:''' The development toolchain is based on GCC. However, if a project contributor wished to add metadata that uses another toolchain, the project would be happy to consider it.

'''Q: What about graphics drivers? Will they be validated and integrated?'''

'''A:''' Yes.

'''Q: How will graphics IP in GPL drivers be handled?'''

'''A:''' The Board Support Packages (BSPs) supplied in the open source project are generally focused on open source code.

'''Q: Where do BSPs come from? Who creates them? What if they need to include proprietary information?'''

'''A:''' A small set of example BSPs has been created and is maintained for our supported architectures. Commercial Linux vendors, OSVs, silicon suppliers, and board vendors may supply their own BSPs. Proprietary information can be delivered in a BSP, and its distribution is handled by the supplier.

'''Q: Are there tools that allow the removal of a package from the build?'''

'''A:''' Yes. The recipe for a given distribution can be modified to remove a package. An end developer may add or remove packages from the specified path in the build process. This allows for a completely customized Linux distribution.

'''Q: How can one view the dependencies of packages and the resulting growth in code size as packages are added?'''

'''A:''' There are tools within BitBake that enable this level of examination.

“bitbake -g targetname” creates depends.dot and task-depends.dot files in the current directory. These files show which packages and tasks depend on which other packages and tasks and are useful for debugging purposes.

"bitbake -g -u depexp targetname" shows results in a more human-readable, GUI style. A simple mount of the resulting root image will show how much storage space is being used.

In addition, the Hob is a new graphical user interface for BitBake that makes these tools much easier to use.

'''Q: What is the path for upgrading just drivers, or for upgrading drivers and related updates to the kernel?'''

'''A:''' For a given 6-month release of the Yocto Project, the version of the kernel is frozen 6 weeks before release.

'''Q: How often is the kernel updated? How will we know what version of the kernel is used in any particular Yocto Project release?'''

'''A:''' Given the release cycle for the kernel, every 6-month release of the Yocto Project usually has a new kernel. Specific announcements are made on the Yocto Project mailing list and blogs. In addition, the release notes for any release contains specific information about which kernel is included with that release.

'''Q: Is the kernel included in the Yocto Project?'''

'''A:''' Metadata referring to a particular kernel version is provided in Yocto Project releases. Of course, patches to the kernel (as with any of the source code in the project) can be applied by the developer. The Yocto Project’s kernel patching system is based on "git" and looks for patches in a Git branch.

'''Q: What are some possible debugging targets?'''

'''A:''' QEMU is the target for emulation. Several actual hardware targets are also supported, as well as software emulators for various hardware models as provided by silicon vendors.

'''Q: What is the overall support plan for the Yocto Project?'''

'''A:''' Security patches and critical bug fixes are supplied one release back. No toolchain or kernel changes are allowed for these updates. Support for longer periods of time can be supplied by commercial OSVs.

'''Q: What is meant by automated test capability?'''

'''A:''' The Yocto Project includes a standard framework for testing on target devices. This allows many existing tests to be reused across projects, reducing rework.

'''Q: If a customer wants a commercial distribution of the Yocto Project, are there potential candidates for productization and commercial distribution?'''

'''A:''' Yes, all major commercial OSVs currently participate in the Yocto Project.

'''Q: For which software development boards is the Yocto Project validated?'''

'''A:''' Version 1.1 was validated against:
* ARM Beagleboard C4 and xM
* Several Intel Atom SoCs
* PowerPC - fsl-mpc8315e-rdb
* MIPS - Ubiquity Networks Router Station Pro

'''Q: Is user interface development possible with the Yocto Project?'''

'''A:''' User Interface development is supported with the Yocto Project. The distribution resulting from a Yocto Project build is just like any other Linux distribution. Developers may build graphical interfaces using frameworks like QT, Clutter, or GTK+, all of which are included.

'''Q: Is the Yocto Project a project or a product? How much customer effort is required to productize the Yocto Project?'''

'''A:''' The Yocto Project is an open source project with support provided by the open source community. Products can be created by OSVs who use the Yocto Project as their upstream or by customers who create their own “roll your own” Linux products from the Yocto Project.

'''Q: Who may I contact for further questions regarding the Yocto Project?'''

'''A:''' For any additional questions, please contact [mailto:jeffrey.osier-mixon@intel.com Jeff Osier-Mixon], the Yocto Project Community Manager.

FAQ

2011-11-15T22:19:20Z

Scottrifw:

'''Yocto Project Public Messages and FAQ'''

Last edited: 10 November, 2011

'''Q: What is the Yocto Project?'''

'''A:''' The Yocto Project provides open source, high-quality infrastructure and tools to help developers create their own custom Linux distributions for any hardware architecture and across multiple market segments. The Yocto Project is intended to provide a helpful starting point for developers. The Yocto Project hosts other projects as well, including the Poky build system, Autobuilder automated build and test system, and the Embedded GLIBC (EGLIBC)C library. The Linux Foundation welcomes the participation of embedded vendors, developers, and other open source projects.

'''Q: What does the Linux Foundation hope to achieve with the Yocto Project?'''

'''A:''' This year’s annual survey of embedded developers conducted by Embedded Market Forecasters reported that the two primary factors contributing to embedded developers’ choice of Operating Systems (OS) in their designs are cost (44.6%) and the availability of source code (33.1%). These factors have contributed to the explosion of demand for Linux in embedded devices. Until now, embedded vendors and their partners relied on deep customization, requiring developers to wrestle with rapidly changing software and difficult build and maintenance cycles. The Linux Foundation recognized that an opportunity existed for a collaboratively developed, open source project that would build high-quality tools for the embedded Linux ecosystem.

'''Q: How does the Yocto Project help Linux reach a wider embedded audience?'''

'''A:''' This set of collaboratively developed, open source development tools focused on the embedded segment speeds embedded vendors’ time to market by establishing a shared build infrastructure. This enables Linux across the widest possible spectrum of devices, projects, and platforms. The Yocto Project has a great start on the code required to solve these problems.

'''Q: Isn’t the Yocto Project just yet another Linux distribution?'''

'''A:''' No. The Yocto Project is a set of tools and components, including a highly configurable build system, that enables developers to construct their own custom distributions, targeted for specific embedded devices. It is not, itself, a Linux distribution. Rather, it is capable of producing an image for a particular embedded device without dictating the composition of the Linux distribution actually built or the hardware architecture used.

'''Q: What benefits does the Yocto Project provide embedded developers and how is the Yocto Project superior to existing, similar tools?'''

'''A:''' Unlike build systems based on shell scripts or makefiles, the Yocto Project automates how source is fetched from a variety of upstream sources or from local project repositories. Updating to a new version of a package is often as easy as renaming a recipe file. It has a powerful customization architecture that allows the choice of a wide variety of footprint sizes as well as control over the choice or absence of components such as graphics subsystems, visualization middleware, and services.

A complete set of Linux package versions is specified in the metadata for the project; these versions are known to work correctly together. A robust effort within the project is dedicated to keeping this selection of packages fresh and up-to-date. Unlike other systems, however, only a single version of each package is typically provided with the project at any given time. This ensures that the packages are known to work well together, while providing the freedom to replace them at any time as the needs of a given embedded project mature.

The Yocto Project is package-format agnostic - supporting both major Linux packaging systems (.rpm and .deb), as well as the embedded-friendly ipkg format. The Yocto Project is also architecturally agnostic - supporting all major embedded architectures: ARM, 32- and 64-bit x86, PowerPC, and MIPS.

The Yocto Project shares the core build tool (BitBake) and metadata syntax with OpenEmbedded, particularly the core set of components known as openembedded-core. This commonality provides automatic familiarity for developers already using OpenEmbedded. However, the learning curve for getting started with the Yocto Project is less steep. It is easier for new users to create a working distribution with the Yocto Project, and more work is being done currently on this subject with the new Hob graphical user interface.

When a distribution is created with the Yocto Project, the build tool creates an application development SDK tailored to that distribution. This SDK can plug into the Eclipse IDE or it can be run as a command-line development system, complete with cross tools for the host and development tools for the device being developed.

'''Q: How does the existing embedded workflow compare to the Yocto Project and where can embedded developers save time?'''

'''A:''' Existing embedded developers have many systems from which to choose. Once a system is chosen and a device's OS has been created, it can often be very difficult and time consuming to trim the distribution to an appropriate footprint size and assemble a working set of components. Then, for the developer’s next project, if updated components are needed, perhaps for bug fixes, security fixes, or new hardware support, the developer typically must start over, with little ability to re-use prior work on distributions. The Yocto Project solves these problems by providing a single focus for embedded development, requiring less time to get a working and up-to-date distribution together. In addition, if commercial support is desired, it is quite simple to transition to a supporting operating system vendor (OSV) who offers products and services compatible with the Yocto Project. All of the major embedded Linux OSVs are active members of the Yocto Project.

'''Q: Does the Yocto Project have a special governance model, or is it managed as an open source project?'''

'''A:''' The Yocto Project is governed as an open source project working group under the auspices of the Linux Foundation. The Yocto Project Advisory Board consists of representatives from the major sponsoring organizations. This group advises the project on direction and provides resources, but all decisions are made by the project's Maintainers. In addition, there are Interest Groups who drive project feature requirements and provide direction on various aspects of project governance, including finances and infrastructure, and an Architect who coordinates the work of the Maintainers and sets project direction under the guidance of the Advisory Board and its subgroups.

'''Q: Why not just call this project Poky? What has changed between Poky and the Yocto Project?'''

'''A:''' The Yocto Project is an umbrella project. Accordingly, it includes a number of projects and resources specifically intended for facilitating development with Linux on embedded devices, and it is an appropriate place for larger organizations to collaborate on the development of build infrastructure for embedded Linux. Poky is one of the the largest components of the Yocto Project, and Poky continues as an independent, open source project developing the build system used by the Yocto Project, as well as by other open source projects.

'''Q: What is the difference between OpenEmbedded and the Yocto Project?'''

'''A:''' The Yocto Project and OpenEmbedded share a core collection of metadata called openembedded-core. However, the two organizations remain separate, each with its own focus. OpenEmbedded provides a comprehensive set of metadata for a wide variety of architectures, features, and applications. The Yocto Project focuses on providing powerful, easy-to-use, well-tested tools, metadata, and board support packages (BSPs) for a core set of architectures and specific boards.

'''Q: Who defines the root filesystem and metadata?'''

'''A:''' Metadata represents the versions of the various components in a distribution, such as the particular versions of the Linux kernel or libraries. The project supplies an example set of metadata that can generate several example distributions. The actual metadata used for the construction of a custom distribution may be supplied by a commercial vendor or created by an embedded developer. The root filesystem is defined in the metadata for a given build of a distribution.

'''Q: What are the criteria for baseline metadata?'''

'''A:''' The project has selected several major embedded architectures (32- and 64-bit x86, ARM, MIPS, and PowerPC) and footprint sizes (minimal, sato, lsb). Metadata has been created that generates a working build for these architectures and footprints while providing up-to-date and modern versions of the various open source components. We also supply metadata for a number of other components ("world"), which can be pulled into a custom distribution.

'''Q: What tool sets are included in the Yocto Project? When will they be available?'''

'''A:''' The development toolchain is based on GCC. However, if a project contributor wished to add metadata that uses another toolchain, the project would be happy to consider it.

'''Q: What about graphics drivers? Will they be validated and integrated?'''

'''A:''' Yes.

'''Q: How will graphics IP in GPL drivers be handled?'''

'''A:''' The Board Support Packages (BSPs) supplied in the open source project are generally focused on open source code.

'''Q: Where do BSPs come from? Who creates them? What if they need to include proprietary information?'''

'''A:''' A small set of example BSPs has been created and is maintained for our supported architectures. Commercial Linux vendors, OSVs, silicon suppliers, and board vendors may supply their own BSPs. Proprietary information can be delivered in a BSP, and its distribution is handled by the supplier.

'''Q: Are there tools that allow the removal of a package from the build?'''

'''A:''' Yes. The recipe for a given distribution can be modified to remove a package. An end developer may add or remove packages from the specified path in the build process. This allows for a completely customized Linux distribution.

'''Q: How can one view the dependencies of packages and the resulting growth in code size as packages are added?'''

'''A:''' There are tools within BitBake that enable this level of examination.

“bitbake -g targetname” creates depends.dot and task-depends.dot files in the current directory. These files show which packages and tasks depend on which other packages and tasks and are useful for debugging purposes.

"bitbake -g -u depexp targetname" shows results in a more human-readable, GUI style. A simple mount of the resulting root image will show how much storage space is being used.

In addition, the Hob is a new graphical user interface for BitBake that makes these tools much easier to use.

'''Q: What is the path for upgrading just drivers, or for upgrading drivers and related updates to the kernel?'''

'''A:''' For a given 6-month release of the Yocto Project, the version of the kernel is frozen 6 weeks before release.

'''Q: How often is the kernel updated? How will we know what version of the kernel is used in any particular Yocto Project release?'''

'''A:''' Given the release cycle for the kernel, every 6-month release of the Yocto Project usually has a new kernel. Specific announcements are made on the Yocto Project mailing list and blogs. In addition, the release notes for any release contains specific information about which kernel is included with that release.

'''Q: Is the kernel included in the Yocto Project?'''

'''A:''' Metadata referring to a particular kernel version is provided in Yocto Project releases. Of course, patches to the kernel (as with any of the source code in the project) can be applied by the developer. The Yocto Project’s kernel patching system is based on "git" and looks for patches in a git branch.

'''Q: What are some possible debugging targets?'''

'''A:''' QEMU is the target for emulation. Several actual hardware targets are also supported, as well as software emulators for various hardware models as provided by silicon vendors.

'''Q: What is the overall support plan for the Yocto Project?'''

'''A:''' Security patches and critical bug fixes are supplied one release back. No tool chain or kernel changes are allowed for these updates. Support for longer periods of time can be supplied by commercial OSVs.

'''Q: What is meant by automated test capability?'''

'''A:''' The Yocto Project includes a standard framework for testing on target devices. This allows many existing tests to be reused across projects, reducing rework.

'''Q: If a customer wants a commercial distribution of the Yocto Project, are there potential candidates for productization and commercial distribution?'''

'''A:''' Yes, all major commercial OSVs currently participate in the Yocto Project.

'''Q: For which software development boards is the Yocto Project validated?'''

'''A:''' Version 1.1 was validated against:
* ARM Beagleboard C4 and xM
* Several Intel Atom SoCs
* PowerPC - fsl-mpc8315e-rdb
* MIPS - Ubiquity Networks Router Station Pro

'''Q: Is user interface development possible with the Yocto Project?'''

'''A:''' User Interface development is supported with the Yocto Project. The distribution resulting from a Yocto Project build is just like any other Linux distribution. Developers may build graphical interfaces using frameworks like QT, Clutter, or GTK+, all of which are included.

'''Q: Is the Yocto Project a project or a product? How much customer effort is required to productize the Yocto Project?'''

'''A:''' The Yocto Project is an open source project with support provided by the open source community. Products can be created by OSVs who use the Yocto Project as their upstream or by customers who create their own “roll your own” Linux products from the Yocto Project.

'''Q: Who may I contact for further questions regarding the Yocto Project?'''

'''A:''' For any additional questions, please contact [mailto:jeffrey.osier-mixon@intel.com Jeff Osier-Mixon], the Yocto Project Community Manager.

FAQ

2011-11-15T22:10:27Z

Scottrifw:

'''Yocto Project Public Messages and FAQ'''

Last edited: 10 November, 2011

'''Q: What is the Yocto Project?'''

'''A:''' The Yocto Project provides open source, high-quality infrastructure and tools to help developers create their own custom Linux distributions for any hardware architecture and across multiple market segments. The Yocto Project is intended to provide a helpful starting point for developers. The Yocto Project hosts other projects as well, including the Poky build system, Autobuilder automated build and test system, and the Embedded GLIBC (EGLIBC)C library. The Linux Foundation welcomes the participation of embedded vendors, developers, and other open source projects.

'''Q: What does the Linux Foundation hope to achieve with the Yocto Project?'''

'''A:''' This year’s annual survey of embedded developers conducted by Embedded Market Forecasters reported that the two primary factors contributing to embedded developers’ choice of Operating Systems (OS) in their designs are cost (44.6%) and the availability of source code (33.1%). These factors have contributed to the explosion of demand for Linux in embedded devices. Until now, embedded vendors and their partners relied on deep customization, requiring developers to wrestle with rapidly changing software and difficult build and maintenance cycles. The Linux Foundation recognized that an opportunity existed for a collaboratively developed, open source project that would build high-quality tools for the embedded Linux ecosystem.

'''Q: How does the Yocto Project help Linux reach a wider embedded audience?'''

'''A:''' This set of collaboratively developed, open source development tools focused on the embedded segment speeds embedded vendors’ time to market by establishing a shared build infrastructure. This enables Linux across the widest possible spectrum of devices, projects, and platforms. The Yocto Project has a great start on the code required to solve these problems.

'''Q: Isn’t the Yocto Project just yet another Linux distribution?'''

'''A:''' No. The Yocto Project is a set of tools and components, including a highly configurable build system, that enables developers to construct their own custom distributions, targeted for specific embedded devices. It is not, itself, a Linux distribution. Rather, it is capable of producing an image for a particular embedded device without dictating the composition of the Linux distribution actually built or the hardware architecture used.

'''Q: What benefits does the Yocto Project provide embedded developers and how is the Yocto Project superior to existing, similar tools?'''

'''A:''' Unlike build systems based on shell scripts or makefiles, the Yocto Project automates how source is fetched from a variety of upstream sources or from local project repositories. Updating to a new version of a package is often as easy as renaming a recipe file. It has a powerful customization architecture that allows the choice of a wide variety of footprint sizes as well as control over the choice or absence of components such as graphics subsystems, visualization middleware, and services.

A complete set of Linux package versions is specified in the metadata for the project; these versions are known to work correctly together. A robust effort within the project is dedicated to keeping this selection of packages fresh and up-to-date. Unlike other systems, however, only a single version of each package is typically provided with the project at any given time. This ensures that the packages are known to work well together, while providing the freedom to replace them at any time as the needs of a given embedded project mature.

The Yocto Project is package-format agnostic - supporting both major Linux packaging systems (.rpm and .deb), as well as the embedded-friendly ipkg format. The Yocto Project is also architecturally agnostic - supporting all major embedded architectures: ARM, 32- and 64-bit x86, PowerPC, and MIPS.

The Yocto Project shares the core build tool (BitBake) and metadata syntax with OpenEmbedded, particularly the core set of components known as openembedded-core. This commonality provides automatic familiarity for developers already using OpenEmbedded. However, the learning curve for getting started with the Yocto Project is less steep. It is easier for new users to create a working distribution with the Yocto Project, and more work is being done currently on this subject with the new Hob graphical user interface.

When a distribution is created with the Yocto Project, the build tool creates an application development SDK tailored to that distribution. This SDK can plug into the Eclipse IDE or it can be run as a command-line development system, complete with cross tools for the host and development tools for the device being developed.

'''Q: How does the existing embedded workflow compare to the Yocto Project and where can embedded developers save time?'''

'''A:''' Existing embedded developers have many systems from which to choose. Once a system is chosen and a device's OS has been created, it can often be very difficult and time consuming to trim the distribution to an appropriate footprint size and assemble a working set of components. Then, for the developer’s next project, if updated components are needed, perhaps for bug fixes, security fixes, or new hardware support, the developer typically must start over, with little ability to re-use prior work on distributions. The Yocto Project solves these problems by providing a single focus for embedded development, requiring less time to get a working and up-to-date distribution together. In addition, if commercial support is desired, it is quite simple to transition to a supporting operating system vendor (OSV) who offers products and services compatible with the Yocto Project. All of the major embedded Linux OSVs are active members of the Yocto Project.

'''Q: Does the Yocto Project have a special governance model, or is it be managed as an open source project?'''

'''A:''' The Yocto Project is governed as an open source project working group under the auspices of the Linux Foundation. The Yocto Project Advisory Board consists of representatives from the major sponsoring organizations. This group advises the project on direction and provides resources, but all decisions are made by the project's Maintainers. In addition, there are Interest Groups who drive project feature requirements and provide direction on various aspects of project governance, including finances and infrastructure, and an Architect who coordinates the work of the Maintainers and sets project direction under the guidance of the Advisory Board and its subgroups.

'''Q: Why not just call this project Poky? What has changed between Poky and the Yocto Project?'''

'''A:''' The Yocto Project is an umbrella project. Accordingly, it includes a number of projects and resources specifically intended for facilitating development with Linux on embedded devices, and it is an appropriate place for larger organizations to collaborate on the development of build infrastructure for embedded Linux. Poky is one of the the largest components of the Yocto Project, and Poky continues as an independent, open source project developing the build system used by the Yocto Project, as well as by other open source projects.

'''Q: What is the difference between OpenEmbedded and the Yocto Project?'''

'''A:''' The Yocto Project and OpenEmbedded share a core collection metadata called openembedded-core. However, the two organizations remain separate, each with its own focus. OpenEmbedded provides a comprehensive set of metadata for a wide variety of architectures, features, and applications. The Yocto Project focuses on providing powerful, easy-to-use, well-tested tools, metadata, and board support packages (BSPs) for a core set of architectures and specific boards.

'''Q: Who defines the root filesystem and metadata?'''

'''A:''' Metadata represents the versions of the various components in a distribution, such as the particular versions of the Linux kernel or libraries. The project supplies an example set of metadata that can generate several example distributions. The actual metadata used for the construction of a custom distribution may be supplied by a commercial vendor or created by an embedded developer. The root filesystem is defined in the metadata for a given build of a distribution.

'''Q: What are the criteria for baseline metadata?'''

'''A:''' The project has selected several major embedded architectures (32- and 64-bit x86, ARM, MIPS, and PowerPC) and footprint sizes (minimal, sato, lsb). Metadata has been created that generates a working build for these architectures and footprints while providing up-to-date and modern versions of the various open source components. We also supply metadata for a number of other components ("world"), which can be pulled into a custom distribution.

'''Q: What tool sets are included in the Yocto Project? When will they be available?'''

'''A:''' The development tool chain is based on GCC. However, if a project contributor wished to add metadata that uses another tool chain, the project would be happy to consider it.

'''Q: What about graphics drivers? Will they be validated and integrated?'''

'''A:''' Yes.

'''Q: How will graphics IP in GPL drivers be handled?'''

'''A:''' The BSPs supplied in the open source project are generally focused on open source code.

'''Q: Where do BSPs come from? Who creates them? What if they need to include proprietary information?'''

'''A:''' A small set of example BSPs has been created and is maintained for our supported architectures. Commercial Linux vendors, OSVs, silicon suppliers, and board vendors may supply their own BSPs. Proprietary information can be delivered in a BSP, and its distribution is handled by the supplier.

'''Q: Are there tools that allow the removal of a package from the build?'''

'''A:''' Yes. The recipe for a given distribution can be modified to remove a package. An end developer may add or remove packages from the specified path in the build process. This allows for a completely customized Linux distribution.

'''Q: How can one view the dependencies of packages and the resulting growth in code size as packages are added?'''

'''A:''' There are tools within BitBake which enable this.

“bitbake -g targetname” creates depends.dot and task-depends.dot files in the current directory. These files show which packages and tasks depend on which other packages and tasks and are useful for debugging purposes.

"bitbake -g -u depexp targetname" shows results in a more human-readable, GUI style. A simple mount of the resulting root image will show how much storage space is being used.

In addition, the Hob is a new graphical user interface for BitBake which makes these tools much easier to use.

'''Q: What is the path for upgrading just drivers, or for upgrading drivers and related updates to the kernel?'''

'''A:''' For a given 6-month release of the Yocto Project, the version of the kernel is frozen 6 weeks before release.

'''Q: How often is the kernel updated? How will we know what version of the kernel is used in any particular Yocto Project release?'''

'''A:''' Given the release cycle for the kernel, every 6-month release of the Yocto Project usually has a new kernel. Specific announcements are made on the Yocto Project mailing list and blogs. In addition, the release notes for any release contains specific information about which kernel is included with that release.

'''Q: Is the kernel included in the Yocto Project?'''

'''A:''' Metadata referring to a particular kernel version is provided in Yocto Project releases. Of course, patches to the kernel (as with any of the source code in the project) can be applied by the developer. The Yocto Project’s kernel patching system is based on "git" and looks for patches in a git branch.

'''Q: What are some possible debugging targets?'''

'''A:''' QEMU is the target for emulation. Several actual hardware targets are also supported, as well as software emulators for various hardware models as provided by silicon vendors.

'''Q: What is the overall support plan for the Yocto Project?'''

'''A:''' Security patches and critical bug fixes are supplied one release back. No tool chain or kernel changes are allowed for these updates. Support for longer periods of time can be supplied by commercial OSVs.

'''Q: What is meant by automated test capability?'''

'''A:''' The Yocto Project includes a standard framework for testing on target devices. This allows many existing tests to be reused across projects, reducing rework.

'''Q: If a customer wants a commercial distribution of the Yocto Project, are there potential candidates for productization and commercial distribution?'''

'''A:''' Yes, all major commercial OSVs currently participate in the Yocto Project.

'''Q: For which software development boards is the Yocto Project validated?'''

'''A:''' Version 1.1 was validated against:
* ARM Beagleboard C4 and xM
* Several Intel Atom SoCs
* PowerPC - fsl-mpc8315e-rdb
* MIPS - Ubiquity Networks Router Station Pro

'''Q: Is user interface development possible with the Yocto Project?'''

'''A:''' User Interface development is supported with the Yocto Project. The distribution resulting from a Yocto Project build is just like any other Linux distribution. Developers may build graphical interfaces using frameworks like QT, Clutter, or GTK+, all of which are included.

'''Q: Is the Yocto Project a project or a product? How much customer effort is required to productize the Yocto Project?'''

'''A:''' The Yocto Project is an open source project with support provided by the open source community. Products can be created by OSVs who use the Yocto Project as their upstream or by customers who create their own “roll your own” Linux products from the Yocto Project.

'''Q: Who may I contact for further questions regarding the Yocto Project?'''

'''A:''' For any additional questions, please contact [mailto:jeffrey.osier-mixon@intel.com Jeff Osier-Mixon], the Yocto Project Community Manager.

FAQ

2011-11-15T22:01:11Z

Scottrifw:

'''Yocto Project Public Messages and FAQ'''

Last edited: 10 November, 2011

'''Q: What is the Yocto Project?'''

'''A:''' The Yocto Project provides open source, high-quality infrastructure and tools to help developers create their own custom Linux distributions for any hardware architecture and across multiple market segments. The Yocto Project is intended to provide a helpful starting point for developers. The Yocto Project hosts other projects as well, including the Poky build system, Autobuilder automated build and test system, and the Embedded GLIBC (EGLIBC)C library. The Linux Foundation welcomes the participation of embedded vendors, developers, and other open source projects.

'''Q: What does the Linux Foundation hope to achieve with the Yocto Project?'''

'''A:''' This year’s annual survey of embedded developers conducted by Embedded Market Forecasters reported that the two primary factors contributing to embedded developers’ choice of Operating Systems (OS) in their designs are cost (44.6%) and the availability of source code (33.1%). These factors have contributed to the explosion of demand for Linux in embedded devices. Until now, embedded vendors and their partners relied on deep customization, requiring developers to wrestle with rapidly changing software and difficult build and maintenance cycles. The Linux Foundation recognized that an opportunity existed for a collaboratively developed, open source project that would build high-quality tools for the embedded Linux ecosystem.

'''Q: How does the Yocto Project help Linux reach a wider embedded audience?'''

'''A:''' This set of collaboratively developed, open source development tools focused on the embedded segment speeds embedded vendors’ time to market by establishing a shared build infrastructure. This enables Linux across the widest possible spectrum of devices, projects, and platforms. The Yocto Project has a great start on the code required to solve these problems.

'''Q: Isn’t the Yocto Project just yet another Linux distribution?'''

'''A:''' No. The Yocto Project is a set of tools and components, including a highly configurable build system, that enables developers to construct their own custom distributions, targeted for specific embedded devices. It is not, itself, a Linux distribution. Rather, it is capable of outputting an image for a particular embedded device without dictating the composition of the Linux distribution actually built or the hardware architecture used.

'''Q: What benefits does the Yocto Project provide embedded developers and how is the Yocto Project superior to existing, similar tools?'''

'''A:''' Unlike build systems based on shell scripts or makefiles, the Yocto Project automates the fetching of sources from a variety of upstream sources or from local project repositories. Updating to a new version of a package is often as easy as renaming a recipe file. It has a powerful customization architecture that allows the choice of a wide variety of footprint sizes as well as control over the choice or absence of components such as graphics subsystems, visualization middleware, and services.

A complete set of Linux package versions is specified in the metadata for the project; these versions are known to work correctly together. A robust effort within the project is dedicated to keeping this selection of packages fresh and up-to-date. Unlike other systems, however, only a single version of each package is typically provided with the project at any given time. This ensures that the packages are known to work well together, while providing the freedom to replace them at any time as the needs of a given embedded project mature.

The Yocto Project is package-format agnostic; it supports both major Linux packaging systems (.rpm and .deb), as well as the embedded-friendly ipkg format. The Yocto Project is also architecturally agnostic, supporting all major embedded architectures: ARM, 32- and 64-bit x86, PowerPC, and MIPS.

The Yocto Project shares the core build tool (BitBake) and metadata syntax with OpenEmbedded, particularly the core set of components known as openembedded-core. This commonality provides automatic familiarity for developers already using OpenEmbedded. However, the learning curve for getting started with the Yocto Project is shallower. It is easier for new users to create a working distribution with the Yocto Project, and more work is being done currently on this subject with the new Hob graphical user interface.

When a distribution is created with the Yocto Project, the build tool creates an application development SDK tailored to that distribution. This SDK can plug into the Eclipse IDE or it may be run as a command-line development system, complete with cross tools for the host and development tools for the device being developed.

'''Q: How does the existing embedded workflow compare to the Yocto Project and where can embedded developers save time?'''

'''A:''' Existing embedded developers have many systems from which to choose. Once a system is chosen and a device's OS has been created, it can often be very difficult and time consuming to trim the distribution to an appropriate footprint size and assemble a working set of components. Then, for the developer’s next project, if updated components are needed, perhaps for bug fixes, security fixes, or new hardware support, the developer typically must start over, with little ability to re-use prior work on distributions. The Yocto Project solves these problems by providing a single focus for embedded development, requiring less time to get a working and up-to-date distribution together. In addition, if commercial support is desired, it is quite simple to transition to a supporting operating system vendor (OSV) who offers products and services compatible with the Yocto Project. All of the major embedded Linux OSVs are active members of the Yocto Project.

'''Q: Does the Yocto Project have a special governance model, or is it be managed as an open source project?'''

'''A:''' The Yocto Project is governed as an open source project working group under the auspices of the Linux Foundation. The Yocto Project Advisory Board consists of representatives from the major sponsoring organizations. This group advises the project on direction and provides resources, but all decisions are made by the project's Maintainers. In addition, there are Interest Groups who drive project feature requirements and provide direction on various aspects of project governance, including finances and infrastructure, and an Architect who coordinates the work of the Maintainers and sets project direction under the guidance of the Advisory Board and its subgroups.

'''Q: Why not just call this project Poky? What has changed between Poky and the Yocto Project?'''

'''A:''' The Yocto Project is an umbrella project. Accordingly, it includes a number of projects and resources specifically intended for facilitating development with Linux on embedded devices, and it is an appropriate place for larger organizations to collaborate on the development of build infrastructure for embedded Linux. Poky is one of the the largest components of the Yocto Project, and Poky continues as an independent, open source project developing the build system used by the Yocto Project, as well as by other open source projects.

'''Q: What is the difference between OpenEmbedded and the Yocto Project?'''

'''A:''' The Yocto Project and OpenEmbedded share a core collection metadata called openembedded-core. However, the two organizations remain separate, each with its own focus. OpenEmbedded provides a comprehensive set of metadata for a wide variety of architectures, features, and applications. The Yocto Project focuses on providing powerful, easy-to-use, well-tested tools, metadata, and board support packages (BSPs) for a core set of architectures and specific boards.

'''Q: Who defines the root filesystem and metadata?'''

'''A:''' Metadata represents the versions of the various components in a distribution, such as the particular versions of the Linux kernel or libraries. The project supplies an example set of metadata that can generate several example distributions. The actual metadata used for the construction of a custom distribution may be supplied by a commercial vendor or created by an embedded developer. The root filesystem is defined in the metadata for a given build of a distribution.

'''Q: What are the criteria for baseline metadata?'''

'''A:''' The project has selected several major embedded architectures (32- and 64-bit x86, ARM, MIPS, and PowerPC) and footprint sizes (minimal, sato, lsb). Metadata has been created that generates a working build for these architectures and footprints while providing up-to-date and modern versions of the various open source components. We also supply metadata for a number of other components ("world"), which can be pulled into a custom distribution.

'''Q: What tool sets are included in the Yocto Project? When will they be available?'''

'''A:''' The development tool chain is based on GCC. However, if a project contributor wished to add metadata that uses another tool chain, the project would be happy to consider it.

'''Q: What about graphics drivers? Will they be validated and integrated?'''

'''A:''' Yes.

'''Q: How will graphics IP in GPL drivers be handled?'''

'''A:''' The BSPs supplied in the open source project are generally focused on open source code.

'''Q: Where do BSPs come from? Who creates them? What if they need to include proprietary information?'''

'''A:''' A small set of example BSPs has been created and is maintained for our supported architectures. Commercial Linux vendors, OSVs, silicon suppliers, and board vendors may supply their own BSPs. Proprietary information can be delivered in a BSP, and its distribution is handled by the supplier.

'''Q: Are there tools that allow the removal of a package from the build?'''

'''A:''' Yes. The recipe for a given distribution can be modified to remove a package. An end developer may add or remove packages from the specified path in the build process. This allows for a completely customized Linux distribution.

'''Q: How can one view the dependencies of packages and the resulting growth in code size as packages are added?'''

'''A:''' There are tools within BitBake which enable this.

“bitbake -g targetname” creates depends.dot and task-depends.dot files in the current directory. These files show which packages and tasks depend on which other packages and tasks and are useful for debugging purposes.

"bitbake -g -u depexp targetname" shows results in a more human-readable, GUI style. A simple mount of the resulting root image will show how much storage space is being used.

In addition, the Hob is a new graphical user interface for BitBake which makes these tools much easier to use.

'''Q: What is the path for upgrading just drivers, or for upgrading drivers and related updates to the kernel?'''

'''A:''' For a given 6-month release of the Yocto Project, the version of the kernel is frozen 6 weeks before release.

'''Q: How often is the kernel updated? How will we know what version of the kernel is used in any particular Yocto Project release?'''

'''A:''' Given the release cycle for the kernel, every 6-month release of the Yocto Project usually has a new kernel. Specific announcements are made on the Yocto Project mailing list and blogs. In addition, the release notes for any release contains specific information about which kernel is included with that release.

'''Q: Is the kernel included in the Yocto Project?'''

'''A:''' Metadata referring to a particular kernel version is provided in Yocto Project releases. Of course, patches to the kernel (as with any of the source code in the project) can be applied by the developer. The Yocto Project’s kernel patching system is based on "git" and looks for patches in a git branch.

'''Q: What are some possible debugging targets?'''

'''A:''' QEMU is the target for emulation. Several actual hardware targets are also supported, as well as software emulators for various hardware models as provided by silicon vendors.

'''Q: What is the overall support plan for the Yocto Project?'''

'''A:''' Security patches and critical bug fixes are supplied one release back. No tool chain or kernel changes are allowed for these updates. Support for longer periods of time can be supplied by commercial OSVs.

'''Q: What is meant by automated test capability?'''

'''A:''' The Yocto Project includes a standard framework for testing on target devices. This allows many existing tests to be reused across projects, reducing rework.

'''Q: If a customer wants a commercial distribution of the Yocto Project, are there potential candidates for productization and commercial distribution?'''

'''A:''' Yes, all major commercial OSVs currently participate in the Yocto Project.

'''Q: For which software development boards is the Yocto Project validated?'''

'''A:''' Version 1.1 was validated against:
* ARM Beagleboard C4 and xM
* Several Intel Atom SoCs
* PowerPC - fsl-mpc8315e-rdb
* MIPS - Ubiquity Networks Router Station Pro

'''Q: Is user interface development possible with the Yocto Project?'''

'''A:''' User Interface development is supported with the Yocto Project. The distribution resulting from a Yocto Project build is just like any other Linux distribution. Developers may build graphical interfaces using frameworks like QT, Clutter, or GTK+, all of which are included.

'''Q: Is the Yocto Project a project or a product? How much customer effort is required to productize the Yocto Project?'''

'''A:''' The Yocto Project is an open source project with support provided by the open source community. Products can be created by OSVs who use the Yocto Project as their upstream or by customers who create their own “roll your own” Linux products from the Yocto Project.

'''Q: Who may I contact for further questions regarding the Yocto Project?'''

'''A:''' For any additional questions, please contact [mailto:jeffrey.osier-mixon@intel.com Jeff Osier-Mixon], the Yocto Project Community Manager.

Transcript: creating one generic Atom BSP from another

2011-07-09T00:04:04Z

Scottrifw:

Starting from scratch, we'll take a relatively generic Atom-based BSP and create another Atom-based BSP from that, that stands a good chance of booting and even booting into graphics, to serve as a starting point for a new BSP.

First set up poky:

trz@elmorro:/usr/local/test/yocto$ git init
Initialized empty Git repository in /usr/local/test/yocto/.git/
trz@elmorro:/usr/local/test/yocto$ git remote add poky git://git.yoctoproject.org/poky.git
trz@elmorro:/usr/local/test/yocto$ git remote update
Fetching poky
remote: Counting objects: 106111, done.
remote: Compressing objects: 100% (36106/36106), done.
remote: Total 106111 (delta 72275), reused 99193 (delta 66808)
Receiving objects: 100% (106111/106111), 69.51 MiB | 518 KiB/s, done.
Resolving deltas: 100% (72275/72275), done.
From git://git.yoctoproject.org/poky
* [new branch] 1.1_M1 -> poky/1.1_M1
* [new branch] 1.1_M2 -> poky/1.1_M2
* [new branch] bernard -> poky/bernard
* [new branch] blinky -> poky/blinky
* [new branch] clyde -> poky/clyde
* [new branch] elroy -> poky/elroy
* [new branch] green -> poky/green
* [new branch] laverne -> poky/laverne
* [new branch] master -> poky/master
* [new branch] pinky -> poky/pinky
* [new branch] purple -> poky/purple
* [new tag] 1.1_M1.final -> 1.1_M1.final
* [new tag] 1.1_M2.rc1 -> 1.1_M2.rc1
* [new tag] bernard-5.0.1 -> bernard-5.0.1
* [new tag] pinky-3.1.2 -> pinky-3.1.2
From git://git.yoctoproject.org/poky
* [new tag] 1.1_M1.rc1 -> 1.1_M1.rc1
* [new tag] 1.1_M1.rc2 -> 1.1_M1.rc2
* [new tag] bernard-1.0rc1 -> bernard-1.0rc1
* [new tag] bernard-5.0 -> bernard-5.0
* [new tag] bernard-5.0-alpha -> bernard-5.0-alpha
* [new tag] bernard-5.0rc1 -> bernard-5.0rc1
* [new tag] bernard-5.0rc2 -> bernard-5.0rc2
* [new tag] laverne-4.0 -> laverne-4.0
* [new tag] laverne-4.0.1 -> laverne-4.0.1
* [new tag] m4 -> m4
* [new tag] purple-3.2 -> purple-3.2
* [new tag] purple-3.2.1 -> purple-3.2.1

trz@elmorro:/usr/local/test/yocto$ git checkout -b bernard0 poky/bernard
Branch bernard0 set up to track remote branch bernard from poky.
Switched to a new branch 'bernard0'
trz@elmorro:/usr/local/test/yocto$ git checkout -f

Now check out meta-intel:

trz@elmorro:/usr/local/test/yocto$ mkdir meta-intel
trz@elmorro:/usr/local/test/yocto$ cd meta-intel
trz@elmorro:/usr/local/test/yocto/meta-intel$ git init
Initialized empty Git repository in /usr/local/test/yocto/meta-intel/.git/

trz@elmorro:/usr/local/test/yocto/meta-intel$ git remote add meta-intel git://git.yoctoproject.org/meta-intel.git
trz@elmorro:/usr/local/test/yocto/meta-intel$ git remote update
Fetching meta-intel
remote: Counting objects: 1240, done.
remote: Compressing objects: 100% (1008/1008), done.
remote: Total 1240 (delta 513), reused 85 (delta 27)
Receiving objects: 100% (1240/1240), 1.55 MiB | 510 KiB/s, done.
Resolving deltas: 100% (513/513), done.
From git://git.yoctoproject.org/meta-intel
* [new branch] 1.1_M1 -> meta-intel/1.1_M1
* [new branch] 1.1_M2 -> meta-intel/1.1_M2
* [new branch] bernard -> meta-intel/bernard
* [new branch] dvhart/n450 -> meta-intel/dvhart/n450
* [new branch] laverne -> meta-intel/laverne
* [new branch] master -> meta-intel/master

trz@elmorro:/usr/local/test/yocto/meta-intel$ git checkout -b bernard0 meta-intel/bernard
Branch bernard0 set up to track remote branch bernard from meta-intel.
Switched to a new branch 'bernard0'
trz@elmorro:/usr/local/test/yocto/meta-intel$ git checkout -f

The crownbay-noemgd is the closest thing we have to generic for Atom-based BSPs, so let's start with that:

trz@elmorro:/usr/local/test/yocto/meta-intel$ cp -a meta-crownbay/ meta-mymachine

We want to get rid of anything crownbay, but keep and rename anything crownbay-noemgd. So:

trz@elmorro:/usr/local/test/yocto/meta-intel$ rm meta-mymachine/conf/machine/crownbay.conf
trz@elmorro:/usr/local/test/yocto/meta-intel$ mv meta-mymachine/conf/machine/crownbay-noemgd.conf meta-mymachine/conf/machine/mymachine.conf

Next, let's look at mymachine.conf and see which, if any, changes we need there. Aside from the obvious comment changes (lines starting with '#'), there's nothing to change except for the SRCREV lines at the end, which basically tell the recipe which kernel commits to use.

First, we need to figure out which kernel we're using. For our bernard checkout, we see from the line in the mymachine.conf we copied that it's linux-yocto-stable:

PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto-stable"

At the bottom of mymachine.conf, we see:

SRCREV_machine_pn-linux-yocto_crownbay-noemgd ?= "56fe215d3f1a2cc3a5a26482ac9809ba44495695"
SRCREV_meta_pn-linux-yocto_crownbay-noemgd ?= "e1f85a470934a0cf6abde5d95533e74501822c6b"

SRCREV_machine_pn-linux-yocto-stable_crownbay-noemgd ?= "56fe215d3f1a2cc3a5a26482ac9809ba44495695"
SRCREV_meta_pn-linux-yocto-stable_crownbay-noemgd ?= "e1f85a470934a0cf6abde5d95533e74501822c6b"

Since we're only interested in linux-yocto-stable, we can remove the linux-yocto SRCREVS, but we need to update the SRCREVs for linux-yocto-stable. So we'll change the linux-yocto-stable lines above to point to the machine and meta branches we'll use for our new BSP.

For the initial version of the BSP, we'll use the "atom-pc-standard" machine branch, since we don't yet have our own, which is something to do in future iterations (not covered by this transcript - see the other tutorials for further steps).

We can find the atom-pc-standard commit id to use by looking in the linux-yocto-2.6.34 kernel repo at http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-2.6.34/commit/?h=atom-pc-standard for the machine branch and http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-2.6.34/commit/?h=wrs_meta for the meta branch (note that branch names have changed in later repos e.g. linux-yocto, so keep that in mind if upgrading your kernel later. So the final SRCREVS for our new kernel are:

SRCREV_machine_pn-linux-yocto-stable_mymachine ?= "72ca49ab08b8eb475cec82a10049503602325791"
SRCREV_meta_pn-linux-yocto-stable_mymachine ?= "ec26387cb168e9e0976999b528b5a9dd62e3157a"

You also need to edit the meta-intel/meta-mymachine/conf/layer.conf to remove the crownbay lines and change the crownbay-noemgd lines from:

BBFILE_COLLECTIONS_crownbay-noemgd += "crownbay-noemgd"
BBFILE_PATTERN_crownbay-noemgd := "^${LAYERDIR}/"
BBFILE_PRIORITY_crownbay-noemgd = "6"

to:

BBFILE_COLLECTIONS_mymachine += "mymachine"
BBFILE_PATTERN_mymachine := "^${LAYERDIR}/"
BBFILE_PRIORITY_mymachine = "6"

Next, moving to recipes-bsp, we need to remove the crownbay formfactor and rename the crownbay-noemgd formfactor to mymachine:

trz@elmorro:/usr/local/test/yocto/meta-intel$ rm -rf meta-mymachine/recipes-bsp/formfactor/formfactor/crownbay
trz@elmorro:/usr/local/test/yocto/meta-intel$ mv meta-mymachine/recipes-bsp/formfactor/formfactor/crownbay-noemgd/ meta-mymachine/recipes-bsp/formfactor/formfactor/mymachine

Next, moving to recipes-graphics, remove anything with emgd in it - that's for crownbay and we don't care about it.

trz@elmorro:/usr/local/test/yocto/meta-intel$ rm -rf meta-mymachine/recipes-graphics/xorg-xserver/xserver-xf86-emgd*

We also need to remove the crownbay xorg.conf and rename the crownbay-noemgd xorg.conf:

trz@elmorro:/usr/local/test/yocto/meta-intel$ rm -rf meta-mymachine/recipes-graphics/xorg-xserver/xserver-xf86-config/crownbay
trz@elmorro:/usr/local/test/yocto/meta-intel$ mv meta-mymachine/recipes-graphics/xorg-xserver/xserver-xf86-config/crownbay-noemgd meta-mymachine/recipes-graphics/xorg-xserver/xserver-xf86-config/mymachine

This will leave us with a VESA xconfig.

Next, moving to recipes-kernel, we need to make a couple changes to meta-intel/meta-mymachine/recipes-kernel/linux/linux-yocto-stable_git.bbappend. Again, remove the crownbay lines and change the crownbay-noemgd lines from:

COMPATIBLE_MACHINE_crownbay-noemgd = "crownbay-noemgd"
KMACHINE_crownbay-noemgd = "crownbay"

to

COMPATIBLE_MACHINE_mymachine = "mymachine"
KMACHINE_mymachine = "mymachine"

Finally, don't forget to update the top-level README to reflect the capabilities of your new BSP.

You should now be able to build and boot a live image. Before running the bitbake command, however, be sure to source the environment setup script:

trz@elmorro:/usr/local/test/yocto$ source poky-init-build-env yocto-build
trz@elmorro:/usr/local/test/yocto/yocto-build$ bitbake poky-image-sato-live

If it doesn't build, you typed in something wrong.

If it doesn't boot, you have work to do that no transcript will help you with.

And remember, this transcript was based on bernard, which for this BSP was based on the 2.6.34 'stable' kernel. You probably don't want to base a new BSP on 2.6.34. The BSP this transcript was based on switched to 2.6.34 soon after bernard, so you should be able to look at later version of it or other BSPs for hints on how to switch to a more recent kernel. This BSP was chosen because the -noemgd branch was the most generic otherwise, and choosing something else would have caused more confusion than the simple text editing done here.

You might be further ahead to try a more recent 'milestone' branch of 1.1 to base your new BSP on, which would give you a more up-to-date system, but we used the bernard branch instead because that's more stable.

FAQ

2011-04-06T13:47:28Z

Scottrifw:

'''Yocto Project Public Messages and FAQ'''

6, April 2011

'''Q: What is the Yocto Project?'''

'''A:''' The Yocto Project provides open source, high-quality infrastructure and tools to help developers create their own custom Linux distributions for any hardware architecture and across multiple market segments. The Yocto Project is intended to provide a helpful starting point for developers. The Linux Foundation welcomes the participation of embedded vendors, developers, and other open source projects.

'''Q: What does the Linux Foundation hope to achieve with the Yocto Project?'''

'''A:''' This year’s annual survey of embedded developers conducted by Embedded Market Forecasters reported that the two primary factors contributing to embedded developers’ choice of Operating Systems (OS) in their designs are cost (44.6%) and the availability of source code (33.1%). These factors have contributed to the explosion of demand for Linux in embedded devices. Until now, embedded vendors and their partners relied on deep customization, requiring developers to wrestle with rapidly changing software and difficult build and maintenance cycles. The Linux Foundation recognized that an opportunity existed for a collaboratively developed, open source project that would build high-quality tools for the embedded Linux ecosystem.

'''Q: How will the Yocto Project help Linux reach a wider embedded audience?'''

'''A:''' This collaboratively developed, open source build system focused on the embedded segment will speed embedded vendors’ time to market by establishing a shared build infrastructure. This will enable Linux across the widest possible spectrum of devices, projects, and platforms. The Yocto Project has a great start on the code required to solve these problems.

'''Q: Isn’t the Yocto Project just yet another Linux distribution?'''

'''A:''' No. The Yocto Project is a build system and tools that enables developers to construct their own custom distributions, targeted for specific embedded devices. It is not, itself, a complete Linux distribution. Rather, it is capable of outputting an image for a particular embedded device without dictating the composition of the Linux distribution actually built or the hardware architecture used.

'''Q: What benefits does the Yocto Project provide embedded developers and how is the Yocto Project superior to existing, similar tools?'''

'''A:''' Unlike build systems based on shell scripts or makefiles, the Yocto Project automates the fetching of sources from a variety of upstream sources or from local project repositories. Updating to a new version of a package is often as easy as renaming a recipe file. It has a powerful customization architecture that allows the choice of a wide variety of footprint sizes as well as control over the choice or absence of components such as graphics subsystems, visualization middleware, and services.

A complete set of Linux package versions is specified in the metadata for the project; these versions are known to work correctly together. A robust effort within the project is dedicated to keeping this selection of packages fresh and up-to-date. Unlike other systems, however, only a single version of each package is typically provided with the project at any given time. This ensures that the packages are known to work well together, while providing the freedom to replace them at any time as the needs of a given embedded project mature.

The Yocto Project is package-format agnostic; it supports both major Linux packaging systems (.rpm and .deb), as well as the embedded-friendly ipkg format. The Yocto Project is also architecturally agnostic, supporting all major embedded architectures (ARM, 32- and 64-bit x86, PowerPC, and MIPS).

The Yocto Project inherits the core build tool (bitbake) and metadata syntax from OpenEmbedded, which is currently the most popular embedded development tool. This commonality will provide automatic familiarity for developers already using OpenEmbedded. However, the learning curve for getting started with the Yocto Project and Poky is shallower. It is easier for new users to create a working distribution with the Yocto Project.

When a distribution is created with the Yocto Project, the build tool creates an application development SDK tailored to that distribution. This SDK can plug into the Eclipse and Anjuta IDEs, or it may be run as a command-line development system, complete with cross tools for the host and development tools for the device being developed.

'''Q: How does the existing embedded workflow compare to the Yocto Project and where can embedded developers save time?'''

'''A:''' Existing embedded developers have many systems from which to choose. Once a system is chosen and a device's OS has been created, it can often be very difficult and time consuming to trim the distribution to an appropriate footprint size and assemble a working set of components. Then, for the developer’s next project, if updated components are needed, perhaps for bug fixes, security fixes, or new hardware support, the developer typically must start over, with little ability to re-use prior work on distributions. The Yocto Project solves these problems by providing a single focus for embedded development, requiring less time to get a working and up-to-date distribution together. In addition, if commercial support is desired, it is quite simple to transition to a supporting OSV who offers products and services compatible with the Yocto Project.

'''Q: Will the Yocto Project have a special governance model, or will it be managed as an open source project?'''

'''A:''' The Yocto Project will be governed as an open source project working group under the auspices of the Linux Foundation. There will be a Steering Group consisting of representatives from the major sponsoring organizations. This group will make decisions by majority vote, but the vast majority of decisions will be delegated to Maintainers; the Maintainers will only use the Steering Group to break deadlocks or to make final decisions about roadmaps. In addition, there will be Interest Groups who drive project feature requirements and an architect who will coordinate the work of the Maintainers and set project direction under the guidance of the Steering Group.

'''Q: Why not just call this project Poky? What has changed between Poky and the Yocto Project?'''

'''A:''' The Yocto Project is an umbrella project, similar to freedesktop.org. Accordingly, it includes a number of projects and resources specifically intended for facilitating development with Linux on embedded devices, and it is an appropriate place for larger organizations to collaborate on the development of build infrastructure for embedded Linux. Poky is indeed the largest part of the Yocto Project, and Poky will continue as an independent, open source project developing the build system used by the Yocto Project, as well as by other open source projects.

'''Q: Who defines the root filesystem and metadata?'''

'''A:''' Metadata represents the versions of the various components in a distribution, such as the particular versions of the Linux kernel or libraries. The project supplies an example set of metadata that can generate several example distributions. The actual metadata used for the construction of a custom distribution may be supplied by a commercial vendor or created by an embedded developer. The root filesystem is defined in the metadata for a given build of a distribution.

'''Q: What are the criteria for baseline metadata?'''

'''A:''' The project has selected several major embedded architectures (32- and 64-bit x86, ARM, MIPS, and PowerPC) and footprint sizes (minimal, sato, lsb). Metadata has been created that generates a working build for these architectures and footprints while providing up-to-date and modern versions of the various open source components. We also supply metadata for a number of other components ("world"), which can be pulled into a custom distribution.

'''Q: What tool sets are included in the Yocto Project? When will they be available?'''

'''A:''' The development tool chain is based on GCC. However, if a project contributor wished to add metadata that uses another tool chain, the project would be happy to consider it.

'''Q: What about graphics drivers? Will they be validated and integrated?'''

'''A:''' Yes.

'''Q: How will graphics IP in GPL drivers be handled?'''

'''A:''' The BSPs supplied in the open source project will generally be focused on open source code.

'''Q: Where do BSPs come from? Who creates them? What if they need to include proprietary information?'''

'''A:''' A small set of example BSPs will be created and maintained for our supported architectures. Commercial Linux vendors, OSVs, silicon suppliers, and board vendors may supply their own BSPs. Proprietary information can be delivered in a BSP, and its distribution will be handled by the supplier.

'''Q: Are there tools that allow the removal of a package from the build?'''

'''A:''' Yes. The recipe for a given distribution can be modified to remove a package. An end developer may remove a package from the specified path in the build process. This allows for a completely customized Linux distribution.

'''Q: How can one view the dependencies of packages and the resulting growth in code size as packages are added?'''

'''A:''' There are tools within Bitbake which allow this.

“bitbake -g targetname” will create depends.dot and task-depends.dot files in the current directory. They show which packages and tasks depend on which other packages and tasks and are useful for debugging purposes. "bitbake -g -u depexp targetname" will show results in a more human-readable, GUI style. A simple mount of the resulting root image will show how much storage space is being used.

'''Q: What is the path for upgrading just drivers, or for upgrading drivers and related updates to the kernel?'''

'''A:''' For a given 6-month release of the Yocto Project, the version of the kernel will be frozen 6 weeks before release.

'''Q: How often is the kernel updated? How will we know what version of the kernel will be used in any particular Yocto Project release?'''

'''A:''' Given the release cycle for the kernel, every 6-month release of the Yocto Project will usually have a new kernel. Specific announcements will be made on the Yocto Project mailing list and blogs.

'''Q: Is the kernel included in the Yocto Project?'''

'''A:''' Metadata referring to a particular kernel version is provided in Yocto Project releases. Of course, patches to the kernel (as with any of the source code in the project) can be applied by the developer. The Yocto Project’s kernel patching system is based on "git" and looks for patches in a git branch.

'''Q: What are some possible debugging targets?'''

'''A:''' QEMU is the target for emulation. Several actual hardware targets will also be supported, as well as software emulators for various hardware models as provided by silicon vendors.

'''Q: What is the overall support plan for the Yocto Project?'''

'''A:''' Security patches and critical bug fixes will be supplied one release back. No tool chain or kernel changes will be allowed for these updates. Support for longer periods of time can be supplied by commercial OSVs.

'''Q: What is meant by automated test capability?'''

'''A:''' The Yocto Project will include a standard framework for testing on target devices. This will allow many existing tests to be reused across projects, reducing rework.

'''Q: If a customer wants a commercial distribution of the Yocto Project, are there potential candidates for productization and commercial distribution?'''

'''A:''' Yes, the Yocto Project is currently in discussion with several commercial OSVs.

'''Q: For which software development boards will Yocto Project v0.9 be validated?'''

'''A:''' ARM Beagleboard, Intel Atom Black Sand, PowerPC - fsl-mpc8315e-rdb, and MIPS - Ubiquity Networks Router Station Pro

'''Q: Is user interface development possible with the Yocto Project?'''

'''A:''' User Interface development is supported with the Yocto Project. The distribution resulting from a Yocto Project build is just like any other Linux distribution. Developers may build graphical interfaces using frameworks like QT, Clutter, or GTK+, all of which are included.

'''Q: Will the Yocto Project be a project or a product? How much customer effort is required to productize the Yocto Project?'''

'''A:''' The Yocto Project is an open source project with support provided by the open source community. Products can be created by OSVs who use the Yocto Project as their upstream or by customers who create their own “roll your own” Linux products from the Yocto Project.

'''Q: Who may I contact for further questions regarding the Yocto Project?'''

'''A:''' For any additional questions, please contact Jennifer Cloer of the Linux Foundation at jennifer@linuxfoundation.org.

Yocto 1.1 Features

2011-04-06T13:29:02Z

Scottrifw: /* Documentation */

== Potential Yocto Project 2011.10 Features ==
Yocto Project 2011.10 (a.k.a. Yocto Project 1.1) - Target release = October 2011

== Yocto Project 2011.10 Themes ==
The topics below are the themes that some members of the team have started brainstorming for Yocto Project 2011.10. These will grow and change with community input.

=== Yocto Project 2011.10 Objectives ===
The objectives of the Yocto 2011.10 release are to grow participation in Yocto and increase the number of BSPs written for Yocto and partner products based on Yocto.

=== Yocto Project 2011.10 Theme List ===
The Yocto Project 2011.10 Themes towards the Objectives listed above are:

* Multilibs & OE-core config - This work, which began in Yocto Project 1.0, needs to be completed.
* Improve ease of BSP creation - Document the lifecycle and process. Possibly create walkthroughs or tutorials to integrate a new board into the linux-yocto kernel.
* Build performance – Get to the goal of 1 hour build time on a developer machine.
* Upstreaming – Submit patches to upstream projects in order to reduce the 2,000+ patches which are currently part of Yocto Project.

== Process for Entering New Feature Requests ==

* Create a new entry in the appropriate feature table below (Poky, SDK, Hardware)
** Suggestion: start by copying an existing request as a template
* Give the feature a short, descriptive name
* Provide a one or two sentence brief description of the feature
* Set the priority as appropriate (see the legend below)
* Set the Status to "Review"
* In the Source field, enter your name along with the origination of the request (e.g. OSV, OEM, Community) if applicable; provide as much detail here as you can
* In the Comments / Bugzilla field, provide any additional information for the request, such as a link to a bugzilla entry
* Preview your Entry to make sure it looks ok and then save it

''Legend''

'''Priority:''' 1 = Must Have, 2 = Nice to Have, 3 = Optional

'''Status:''' Accept = Engineering agreement to include in release, Review = Under Review for Inclusion in this release, Reject = Will not be included in this release
== Sample Table ==

This is a sample table to show how to submit features.

{| border="1"
||'''Feature Name''' ||'''Description''' ||'''Priority''' ||'''Status''' ||'''Source''' ||'''Comments / Bugzilla Links'''
|-
||Placeholder feature name || Placeholder description of the feature || 1, 2, or 3 || Review|| name|| Comment
|}

== Architecture ==
{| border="1"
||'''Feature Name''' ||'''Description''' ||'''Priority''' ||'''Status''' ||'''Source''' ||'''Comments / Bugzilla Links'''
|-
|| Layer Tooling || This includes the architectural work plus implementing the changes. || 1 || Review || Architect || M2; Owner = Richard
|-
|| OE-Core || Restructuring, renaming, rebranding || 1 || Review || RP Notes || M1; Owner = Richard
|}

== Poky/Bitbake ==
This section contains features for the Poky/Bitbake infastructure.
{| border="1"
||'''Feature Name''' ||'''Description''' ||'''Priority''' ||'''Status''' ||'''Source''' ||'''Comments / Bugzilla Links'''
|-
|| Error handling in bitbake || desc || 1 || Review || RP Notes || M2; Owner = Saul
|-
|| crazygit fetcher || TI issues with fetch2 || 2 || Review || RP Notes || Owner = Saul (Ke) Timescale: 2-3 days
|-
|| multi-lib || multi-lib support for 32-bit & 64-bit and capable of being installed at the same time || 1 || Review || from 1.0 || M1; Owner = Richard
|-
|| Image Creator || finish the Image Creator to add features pushed out from 1.0 || 1 || Review || from 1.0 || M2; Owner = Josh + someone else (Dave investigating someone on Jessica's team)
|-
|| Recipe-specific sysroot || || 3 || Review || from 1.0 || Not scheduled at this time
|-
|| Handle old versions in WORKDIR || || 3 || Review || from 1.0 || Not scheduled at this time
|-
|| Package config option enhancement || need to plan and then implement || 2 || Review || from 1.0 || Owner: RP for plan, Saul implementation
|-
|| Clean up warning messages || A build that runs correctly to completion still includes a ton of WARNING messages. We need a project to clean these up. || 2 || Review || davest and RP || Owner: Saul
|-
|| Monitor disk availability || Monitor disk availability and warn the user if it is running low. May only focus on a few directories, for example: poky/build and poky/build/downloads, this would solve the multiple mount point problem || 2 || Review || RP and Robert || M2; Owner: WR Distro Team
|}

== QA Items ==
{| border="1"
||'''Feature Name''' ||'''Description''' ||'''Priority''' ||'''Status''' ||'''Source''' ||'''Comments / Bugzilla Links'''
|-
||SDK support in sanity test framework || This task includes enabling unfs and toolchain testing in sanity test framework, enabling toolchain testing on PRC autobuilder|| 1 || Accept || QA || M1; Owner = Jiajun/Meilei
|-
|| Open Source Test Cases || Perform technical, legal, and QA steps necessary to move test cases into open source. || 3 || Review|| QA || M2;Owner = Jiajun
|-
|| Test framework || this is a test framework that we can include in the distribution || 3 || Review || RP Notes || M2;Is it the TI’s test framework we discussed before? Owner = Jiajun
|-
|| Be prepared for Distro upgrades || Our release is right around the time of the 6monthly distro release dates, we should accommodate for this in our testing plan || 2 || Review || Joshua || M3;Should we include more OSDs, besides fedora, ubuntu and opensuse? Owner = Jiajun
|}

== Meta-data ==
{| border="1"
||'''Feature Name''' ||'''Description''' ||'''Priority''' ||'''Status''' ||'''Source''' ||'''Comments / Bugzilla Links'''
|-
|| Upstream our patches || We'll add this as a task in a milestone to give people time to do
|| 1 || Review|| Meta-data|| M2; Owner = Saul
|-
|| 3G || We have an ofono recipe but need some integration work doing || 2 || Review|| Meta-data|| Owner: Saul
|-
|| btrfs || || 2 || Review|| Meta-data|| Owner: Saul (Nitin)
|-
|| Other components? || Saul will investigate other components. || 2 || Review|| Meta-data|| Owner: Saul
|-
|| Replacement for video/audio players currently in Yocto || Codec…
|| 3 || Review|| Meta-data|| Not scheduled at this time
|-
|| Investigate New UI || For demos, we would like need a reference UI that is not Sato. Investigate possibilities that the Yocto team won't need to maintain. OpenBox? Gnome-desktop? GP? LXDE? KDE Mobile?
|| 3 || Review|| Meta-data|| Not scheduled at this time
|-
|| Qemugl upstreaming || Opengl ES Support || 3 || Review|| Meta-data|| Not scheduled at this time
|-
|| Sync qemugl with MeeGo ||
|| 2 || Review|| Meta-data|| Owner: Saul (Edwin)
|-
|| Package reporting system enhancement||
|| 2 || Review|| Meta-data|| Owner: Saul
|-
|| pam patch integration || add PAM patches throughout the system switchable via the PAM feature (Mark H)
|| 2 || Review|| Meta-data|| Owner: WR Distro Team?
|-
|| selinux patch integration || add SE Linux patches in a similar way to PAM
|| 3 || Review|| Meta-data|| Not scheduled at this time
|-
|| Finish LSB "distribution" work || Merge patches which are pushed during ycoto 1.0. Add packages(qt3,xdg-* ...) LSB Test Suite need. Hardware platform x86, x86-64 and ppc32(if qt4 can be supported) can be finished.
|| 2 || Review|| Meta-data|| M1; Owner: WR Distro Team
|-
|| OE Comparison || Compare Yocto core set against integration work in OE and other distributions looking for bug fixes, (relevant) feature enhancements, and integration/policy hints.
|| 1 || Review|| Meta-data|| M1; Owner = Mark
|-
|| Framework to support multiple library versions co-existing || similar to recipe specific sysroot; needs documentation
|| 2 || Review|| Team || Owner: Saul
|-
|| Embedded java environment or even JDK support ||
|| 3 || Review|| Team || Not scheduled at this time
|-
|| Automatically generate package repos || automatically generate package repositories (and be able to "use them" -- to be defined) for both ipk and rpm/zypper combinations; NEEDS MORE DISCUSSION
|| 2|| Review|| Team || Owner: Saul
|-
|| MeeGo GPLv2 Sync || compare with Yocto, sync any patches || 2 || Review || RP Notes || Owner: Saul
|-
|| Incompatible License || || 2 || Review || Paul || Owner: Saul
|-
|| End of package revision || replace with a network service || 2 || Review || RP Notes || Owner = Jessica
|-
|| Target module build || Allow for building kernel modules on the target device || 2 || Review || RP Notes || Owner = Darren
|-
|| Live images || make live images their own image type || 2 || Review || RP Notes || Owner = Saul
|-
|| multiple update-alternatives || fixed? || 3 || Review || RP Notes || Owner: Saul
|-
|| init scripts || provide an image/recipe skeleton as a canonical example || 3 || Review || RP Notes || M1; Owner: WR Distro Team
|-
|| running post installs at rootfs gen time || || 2 || Review || RP Notes || Owner: Saul
|-
|| remove gnome-vfs || || 3 || Review || RP Notes || Owner: Saul
|-
|| gtk+ sato filechooser patch || || 3 || Review || RP Notes || Not scheduled at this time
|-
|| sato refresh || || 3 || Review || RP Notes || Not scheduled at this time
|-
|| adding eglibc config control || this goes with the package config options || 1.5 || Review || RP Notes || M2; Owner = Mark
|-
|| Sanity checks on per recipe basis || || 2 || Review || RP Notes || Owner: Saul
|-
|| x32 || layer to support toolchain, libc, and kernel || 2 || Review || RP Notes || Owner: Saul (Nitin)
|-
|| User Creation at postinstall || || 1 || Review || RP Notes || M1; Owner = Mark
|-
|| Directory Ownership || || 1.5 || Review || RP Notes || M2; Owner = Mark
|-
|| Optimise Configure || || 2 || Review || RP Notes || Performance idea, Owner: Saul
|-
|| Ability to build SRPM || || 3 || Review || RP Notes || Owner: Jeff Polk/Mark
|-
|| Check SRCREV in recipe files || should work, may need dev || 2 || Review || RP Notes || Owner: RP/Ke
|-
|| Add Directfb（license LGPL） function || Directfb is more appropriate embedded device than other graphic software|| 3 || Review ||Meta-data || M2; Owner: WR Distro Team
|}

== BSPs ==
{| border="1"
||'''Feature Name''' ||'''Description''' ||'''Priority''' ||'''Status''' ||'''Source''' ||'''Comments / Bugzilla Links'''
|-
|| Support for AVX as in kernel 2.6.30. - Already in 1.0 || Any toolchain support needed?
|| 1|| Review|| Jay || M1; Owner = Nitin
|-
|| Optimize support for Intel hardware features || We need to understand and track each important Intel hardware feature and how it should be optimally supported in the Intel BSPS. Items that immediately come to mind are power, video, and performance counter settings, etc. || 1|| Review|| Tom || Owner: Tom/Darren
|-
|| Fish River Island/Fish River Island II BSP(s) || The base Fish River Island BSP exists already, we now need to add support for the extra devices, and add support for changes introduced by Fish River Island II || 2|| Review|| Tom || Owner: Tom
|-
|| Support ECG (ongoing) || ECG is ramping up with Yocto BSPs and likely will require significant amounts of time and help. Also, since we're trading their BSP work for our help in upstreaming patches, we're also likely to have to spend a significant amount of time with upstream-related tasks too. || 1|| Review|| Tom || Owner: Tom
|-
|| Additional config options || The following configurations need to be enabled to support DPDK.
| bgcolor="yellow"| 1|| Review|| Rahul
|bgcolor="yellow"| Owner: TBD
|}

== ADT ==
{| border="1"
||'''Feature Name''' ||'''Description''' ||'''Priority''' ||'''Status''' ||'''Source''' ||'''Comments / Bugzilla Links'''
|-
|| More test cases about toolchain in autobuilder ||
|| 2 || Review|| ADT Team || Owner = Jessica
|-
|| Eclipse-native tools interface || More integrated with upstream once there's integrated Linux tools that meets our need, e.g. lttng-remote
|| 2 || Review|| ADT Team || Owner = Jessica
|-
|| Indigo update || Update to the latest Eclipse release (Indigo) || 2 || Review|| ADT Team || M2; Owner = Jessica
|-
|| Changes for Image Creator || Eclipse changes pending Image Creator || 1 || Review|| ADT Team || M2; Owner = Jessica
|-
|| Secure login || || 2 || Review|| ADT Team || Owner = Jessica
|-
|| Prebuit SDK integration || speedup target image generation by reusing prebuilt tools from SDK native and target binaries. See: http://wiki.secretlab.ca/Yocto_prebuilt_SDK_integration|| 2 || Deline || Adrian || This functionality looks to have been provided by sstate packages? Owner = Jessica
|-
|| Systemtap integration || Make it easy and convenient for the user to write and execute Systemtap scripts from the IDE. http://www.eclipse.org/linuxtools/projectPages/systemtap/ might provide a good starting point and may be something we can contribute to. We may also need to contribute further up the chain to provide e.g. remote target capabilities. || 2 || Review || Tom || Owner = Jessica
|-
|| 'perf scripting' integration || Make it easy and convenient for the user to write and execute 'perf scripts' from the IDE. We should be able to leverage and build on the Systemtap integration for this. || 2 || Review || Tom || Owner = Jessica
|-
|| Enhance the deploy part in remote debug || ADT is currently using org.eclipse.cdt.remote.launch for remote debug. One limitation in this plug-in is that it can only deploy one single file to the target during the debug. Though it is ok for debugging static linked program, debugging dynamic linked program might require deploying multiple files(including executables and libraries) to the target. || 2 || Review || Lianhao || Owner = Jessica
|-
|}

== Documentation ==
{| border="1"
||'''Feature Name''' ||'''Description''' ||'''Priority''' ||'''Status''' ||'''Source''' ||'''Comments / Bugzilla Links'''
|-
|| Package Documentation Audit || Make changes defined in the package documentation audit from Yocto 1.0
|| 2|| Review|| from 1.0 || Owner = Saul
|-
|| Yocto Project Development Guide || This manual would be an over-arching document that frames the complete development cycle within Yocto Project. The idea here is that the document would be an umbrella document that spawned and referenced subsequent documents. The organization would be the first chapter overviews the major development pieces such as recipe creation, building, debugging, publishing, fail-safing, back-door hook creation, etc. This manual will also include migration information. Scoping would be about two weeks and length would probably be about 40 pages. Overall development time will likely take up to the release given my experience on the creation of the ADT manual (there is no uniterruped time).
|| 1|| Not Started || from scratch || M4 (final) Owner = ScottR
|-
|| Various Demo Videos || The idea here is to create screen-capture type tutorials similar to what exists for the ADT Eclipse Plug-in. However, we want to contract out some help for professional voice-over talent to be used with the images. These don't have to be limited to screen-capture material but could include well-done PPT decks - similar to how other business units in Intel create various training modules. For 1.1 it would be good to capture the script for the existing ADT Eclipse Plug-in module and have it voiced over. Also, for 1.1 it would be good to create a similar module for the Image Creator application.
|| 2|| Not Started || From ADT module and scratch || M2 Owner = ScottR
|-
|| Open-source Newbie Information || This information will be for developers new to open-source. These people do not know what IRC means. Targeted for developers coming from a non-open-source environment. I think the best place for this information would be the website. I haven't looked yet but I suspect information already exists on the web. For Yocto it will be a matter of collecting the best and most useful information, orginizing it and properly referencing/leveraging it.
|| 2|| Not Started || From scratch || M4 (final) Owner = ScottR
|-
|| Tarball Doc process || Right now tarball docs are frozen shortly before a release. The tarball never gets updated beyond that during subsequent documentation development. However, website docs are periodically updated as changes are made during the next development cycle. We need a documentation process where the tarball docs are updated along with the website docs. Perhaps releasing and building a separate documentation tarball is an answer... This whole scheme needs thought about and something implemented.
|| 3|| Not Started || From scratch || M3 Owner = ScottR
|-
|| OOB documentation || Create an out of box guide for giveaway systems built using Yocto. || 1|| Review || Julie || M? Owner = ScottR
|-
|| Tracing/profiling HOWTOs || Create a document or extend the current Yocto tracing wiki page to explain in detail how to use all the tracing tools in Yocto. It should detail not only how to use each tool individually, but also how to use them in conjunction with each other, highlighting situations in which each is most useful. There should also be some extensive worked examples of real-life use-cases and how they could be investigated using the Yocto tracing/profiling tools. || 2|| Review || Tom ||
|}

== Build ==
This section contains requirements related to the build (autobuilder activities, performance, footprint, etc.)
{| border="1"
||'''Feature Name''' ||'''Description''' ||'''Priority''' ||'''Status''' ||'''Source''' ||'''Comments / Bugzilla Links'''
|-
|| Autobuilder maintenance || Bring scripts into configuration or get git repo working for those that can't be brought in. (takes 2 days)
|bgcolor="yellow"| 1 || Review || Beth || M1; Owner = Beth
|-
|| Meta targets || Part of the challenge of autobuilder is that you have to go into autobuilder, edit script, reconfigure, to change just one build target. This is error prone. What we need is a meta-target where Beth can say she wants to build Poky-image-sato for QEMU x86 and have it just do that. Beth thinks this is done via an override to the web page. (takes ~2 weeks)
|bgcolor="yellow"| 1 || Review || Beth || M2; Owner = Beth
|-
|| License tracking || Get common licenses for all packages and consolidate base file licenses. (takes ~3 days)
|bgcolor="yellow"| 1 || Review || Beth || M1; Owner = Beth
|-
|| License tracking || Build a parser to do license tracking more gracefully and make sure all recipes are correct. (takes ~2 weeks)
|bgcolor="yellow"| 1 || Review || Beth || M2; Owner = Beth
|-
|| Audotbuilder infrastructure || Bring up additional autobuilders and work with sysadmin to configure.
|bgcolor="yellow"| 1 || Review || Beth || M2; Owner = Beth
|-
|| Overall Project || Host a retrospective to discuss what went well and what can be improved in Yocto 1.0. (questions on this?)
|bgcolor="yellow"| 1 || Review || Beth || M1; Owner = Beth
|-
|| Release Scripts || Create Release Scripts that can be used for both a weekly release and for OCT 2011 release to be run by autobuilder (a week. testing on this may take longer)
|bgcolor="yellow"| 1 || Review || Beth || M3; Owner = Beth
|-
|| Enhanced Performance || Also, environmental requirements/suggestions for expected performance; Goal is to build in under 1 hour || 2 || Review || from 1.0 ||
|-
|| Disk Space Reduction ||
|| 2 || Review || Team ||
|-
|| Share gcc work directories ||
|| 2 || Review || Team ||
|-
|| Patch Test System || Create a machine where developers can upload/test patches before submitting them to master to ensure builds won't break when patches are added. (developer autobuilders? Fuzz builds?)
|| 2 || Review || Team ||
|-
|| build statistics reporting || As someone interested in how long it takes to build different images on different hardware configurations and other assorted build metrics, I would like a web based service, that takes output generated by an extended buildstats.bbclass and stores it, to compare against different machines. The end result should be a way to visualize the collected data. See: https://wiki.yoctoproject.org/wiki/Yocto_Buildbot_Autobuilder_Discussions
|| || Review || eflanagan/Jay7/ka6sox ||
|-
|| BSP builds || Autobuilder git fetcher improvements (3 days) || 2 || Review || from 1.0 || M1; Owner = Beth
|-
|| Implement Continuous Autobuilds || Build constantly instead of daily (need fuzz builds for this. once fuzz builds are implemented, this is trivial) || 2 || Review || from 1.0 || M1; Owner = Beth
|}

== Performance and Usability ==
This section contains general Yocto performance as well as usability items.
{| border="1"
||'''Feature Name''' ||'''Description''' ||'''Priority''' ||'''Status''' ||'''Source''' ||'''Comments / Bugzilla Links'''
|-
|| Fast boot time || 2 second boot time target
|| 1|| Review|| Team || M2; Owner = Darren
|-
|| Build Yocto behind firewall || Darren will investigate site.conf and documentation
|| 2 || Review|| Dave||
|-
|| Minimal Image unique || make minimal image smaller || 3 || Review|| Team || M2; Owner: WR Distro Team
|-
|| POSIX support || address POSIX failures found in 1.1
|| 2|| Review|| Team ||
|}

== Kernel ==
This section contains items specific to the Yocto kernel.
{| border="1"
||'''Feature Name''' ||'''Description''' ||'''Priority''' ||'''Status''' ||'''Source''' ||'''Comments / Bugzilla Links'''
|-
|| BSP kernel config audit || Audit kernel configs for the various BSPS. Should not be limited to just kernel config options -- it should also include discussion of overall strategies for defining and managing base branches, feature topic branches, config features, etc, and should result in not only the current kernels being changed to match, but also BKMs being published somewhere, probably in the kernel manual.
|| 1|| Review|| Team ||
|-
|| Ongoing kernel maintenance || There should be a task spread out over the whole release, say 10% of one person's time (just a guess), for monitoring LKML and Linus' master branch, and/or relevant lists for patches relevant to the BSPs we maintain. We also need to figure out if Bruce needs help with the management of the base branches e.g. re-enabling features after kernel uprevs, moving feature tags forward, etc.
|| 1|| Review|| Tom ||
|-
|| Tracing: perf trace scripting support || Basically this means allowing perf to be built with the Perl and Python bindings, which turned out to be a headache last time. || 2 || Review || from 1.0 ||
|-
|| Tracing: Add Systemtap support for userspace tracing || Add utrace, etc || 2 || Review || Tom ||
|-
|| Tracing: Systemtap usability in Yocto || Right now, there are instructions on the wiki on how to configure and use Systemtap with Yocto. While straightforward, they are tedious and unlikely to be useful to most people pressed for time. We need to make it easier to use - in addition to documentation/HOWTO tasks listed elsewhere on this page, we need to make it usable 'out of the box' (i.e. outside of ADT) e.g. all paths and configuration handled via script or something similar || 2 || Review || Tom ||
|-
|| Tracing: tuna, oscilloscope recipes || catch up with Tom, likely to remove || 3 || Review || from 1.0 ||
|}

== Project-Wide Features ==
This section contains features for the entire project or for the project website or mailing lists.
{| border="1"
||'''Feature Name''' ||'''Description''' ||'''Priority''' ||'''Status''' ||'''Source''' ||'''Comments / Bugzilla Links'''
|-
|| Patchwork || is it worth the overhead, are there alternatives || 3 || Review || RP Notes ||
|-
|| Alpha || Begin an alpha program after the stabilization period for M3. || 1 || Review || Team ||
|-
|| Bugzilla to Wiki || Create a script which automatically populates and updates the Wiki based on changes in bugzilla.
|bgcolor="yellow"| ? || Review || Darren ||
|}

Yocto 1.0 Release Checklist

2011-04-05T14:16:24Z

Scottrifw:

== Yocto 1.0 Release Checklist ==

{| border="1"
|+ Release Criteria
! scope="col" | Task
! scope="col" | Due Date
! scope="col" | Owner
! scope="col" | Status
|-
| RC4 Go/No-Go
| March 25th
| Julie
| bgcolor="green" | Done - but No-Go
|-
| Create IDK packages for ADT repo
| March 28th
| Scott G and Lianhao
| bgcolor="green" | DONE
|-
| RC5 Go/No-Go
| March 29th
| Julie
| bgcolor="green" | DONE - RC5 is a go
|-
| Copy over to mirror area with non-readable permissions.
| March 29th
| Beth
| bgcolor="green" | DONE
|-
| Provide ScottR with bug information for release notes
| March 30th
| Richard
| bgcolor="green" | DONE
|-
| Work with warthog9 to switch rsync server to autobuilder.pokylinux.org
| March 31st
| Beth
| bgcolor="green" | DONE
|-
| Upload Eclipse plug-ins for 1.0 release - these need to be hosted on a folder on the downloads directory.
| April 1st
| Beth
| bgcolor="green" | DONE
|-
| Yocto video complete
| April 1st
| Tracey (ScottR for status)
| bgcolor="green" | DONE - Final version delivered 5 April.
|-
| Push to mirror.
| April 1st
| Beth
| bgcolor="green" | DONE
|-
| Create Release Notes (Text version as well)
| April 4th
| ScottR
| bgcolor="green" | DONE - created and reviewed. TXT version delivered to Beth and Jefro.
|-
| Yocto new website improvements complete
| April 5th morning
| Jeff
| bgcolor="yellow" | on-track with high priority issues, others will come after launch; Beth will investigate certificate
|-
| Create release announcement for mailing lists
| April 5th
| Jeff
| bgcolor="yellow" | Draft is out for review
|-
| Prepare YP blog on release
| April 5th
| Dave
| bgcolor="yellow" | Does this need tech editing?
|-
| Create new directories for BSP, Kernel, and ADT HTML manuals with Mike S
| April 5th
| ScottR
| bgcolor="green" | Done.
|-
| Set permissions on release to readable
| April 5th 8pm Pacific
| Beth
| bgcolor="white" | -
|-
| Verify that release is on mirror.kernel.org
| April 5th
| Beth
| bgcolor="green" | -
|-
| Create Contributors list
| April 5th
| Jefro
| bgcolor="yellow" | Richard created log.
|-
| Yocto video on web
| April 5th
| Jefro
| bgcolor="white" | ScottR is checking on status of video
|-
| Crownbay EMGD tarball on S3 site
| April 5th
| Beth
| bgcolor="green" | -
|-
| Review Yocto 1.0 documentation against Yocto 1.0 code
| April 6th
| ScottR
| bgcolor="yellow" | in progress
|-
| Let Jeff know that we're ready.
| April 6th 8am Pacific
| Beth
| bgcolor="green" | -
|-
| Yocto new website live
| April 6th - 8am Pacific
| Jeff
| bgcolor="white" | Jeff is working with LF on the date they would like to see.
|-
| Update documentation on web with Yocto 1.0 information
| April 6th 8am Pacific
| ScottR
| bgcolor="white" | this will be done on new website
|-
| LF publishes Press Release
| April 6th - 9am Pacific
| Jeff (proxy for LF status)
| bgcolor="white" | -
|-
| Publish YP blog on release
| April 6th - 9am Pacific
| Dave
| bgcolor="white" | -
|-
| Change IRC room title
| April 6th - 9am Pacific
| Richard (Julie proxy)
| bgcolor="white" | -
|-
| Publish release announcement on all Yocto mailing lists (yocto-announce, yocto, poky)
| April 6th - 9am Pacific
| Jeff/Beth
| bgcolor="white" | Needs to be sent after Yocto 1.0 Press Release. Jeff and Beth will coordinate to send this out. Should include mention of contributors' list.
|-
| Point to new Crown Bay BSP
| April 6th - 9am Pacific
| MikeS (Beth proxy)
| bgcolor="green" | Beth will work with MikeS to ensure he is aware of the need.
|-
| Announce Yocto at LCS
| April 6th
| Jeff
| bgcolor="white" | Any prepwork needed?
|-
| Tweets on Yocto 1.0 throughout week
| April 6th-13th
| Jeff
| bgcolor="white" | -
|-
| Announce Yocto at ELC
| April 11th
| Jeff
| bgcolor="white" | Any prepwork needed?
|}

Yocto 1.0 Release Checklist

2011-04-05T14:15:45Z

Scottrifw:

== Yocto 1.0 Release Checklist ==

{| border="1"
|+ Release Criteria
! scope="col" | Task
! scope="col" | Due Date
! scope="col" | Owner
! scope="col" | Status
|-
| RC4 Go/No-Go
| March 25th
| Julie
| bgcolor="green" | Done - but No-Go
|-
| Create IDK packages for ADT repo
| March 28th
| Scott G and Lianhao
| bgcolor="green" | DONE
|-
| RC5 Go/No-Go
| March 29th
| Julie
| bgcolor="green" | DONE - RC5 is a go
|-
| Copy over to mirror area with non-readable permissions.
| March 29th
| Beth
| bgcolor="green" | DONE
|-
| Provide ScottR with bug information for release notes
| March 30th
| Richard
| bgcolor="green" | DONE
|-
| Work with warthog9 to switch rsync server to autobuilder.pokylinux.org
| March 31st
| Beth
| bgcolor="green" | DONE
|-
| Upload Eclipse plug-ins for 1.0 release - these need to be hosted on a folder on the downloads directory.
| April 1st
| Beth
| bgcolor="green" | DONE
|-
| Yocto video complete
| April 1st
| Tracey (ScottR for status)
| bgcolor="green" | Final version delivered.
|-
| Push to mirror.
| April 1st
| Beth
| bgcolor="green" | DONE
|-
| Create Release Notes (Text version as well)
| April 4th
| ScottR
| bgcolor="green" | DONE - created and reviewed. TXT version delivered to Beth and Jefro.
|-
| Yocto new website improvements complete
| April 5th morning
| Jeff
| bgcolor="yellow" | on-track with high priority issues, others will come after launch; Beth will investigate certificate
|-
| Create release announcement for mailing lists
| April 5th
| Jeff
| bgcolor="yellow" | Draft is out for review
|-
| Prepare YP blog on release
| April 5th
| Dave
| bgcolor="yellow" | Does this need tech editing?
|-
| Create new directories for BSP, Kernel, and ADT HTML manuals with Mike S
| April 5th
| ScottR
| bgcolor="green" | Done.
|-
| Set permissions on release to readable
| April 5th 8pm Pacific
| Beth
| bgcolor="white" | -
|-
| Verify that release is on mirror.kernel.org
| April 5th
| Beth
| bgcolor="green" | -
|-
| Create Contributors list
| April 5th
| Jefro
| bgcolor="yellow" | Richard created log.
|-
| Yocto video on web
| April 5th
| Jefro
| bgcolor="white" | ScottR is checking on status of video
|-
| Crownbay EMGD tarball on S3 site
| April 5th
| Beth
| bgcolor="green" | -
|-
| Review Yocto 1.0 documentation against Yocto 1.0 code
| April 6th
| ScottR
| bgcolor="yellow" | in progress
|-
| Let Jeff know that we're ready.
| April 6th 8am Pacific
| Beth
| bgcolor="green" | -
|-
| Yocto new website live
| April 6th - 8am Pacific
| Jeff
| bgcolor="white" | Jeff is working with LF on the date they would like to see.
|-
| Update documentation on web with Yocto 1.0 information
| April 6th 8am Pacific
| ScottR
| bgcolor="white" | this will be done on new website
|-
| LF publishes Press Release
| April 6th - 9am Pacific
| Jeff (proxy for LF status)
| bgcolor="white" | -
|-
| Publish YP blog on release
| April 6th - 9am Pacific
| Dave
| bgcolor="white" | -
|-
| Change IRC room title
| April 6th - 9am Pacific
| Richard (Julie proxy)
| bgcolor="white" | -
|-
| Publish release announcement on all Yocto mailing lists (yocto-announce, yocto, poky)
| April 6th - 9am Pacific
| Jeff/Beth
| bgcolor="white" | Needs to be sent after Yocto 1.0 Press Release. Jeff and Beth will coordinate to send this out. Should include mention of contributors' list.
|-
| Point to new Crown Bay BSP
| April 6th - 9am Pacific
| MikeS (Beth proxy)
| bgcolor="green" | Beth will work with MikeS to ensure he is aware of the need.
|-
| Announce Yocto at LCS
| April 6th
| Jeff
| bgcolor="white" | Any prepwork needed?
|-
| Tweets on Yocto 1.0 throughout week
| April 6th-13th
| Jeff
| bgcolor="white" | -
|-
| Announce Yocto at ELC
| April 11th
| Jeff
| bgcolor="white" | Any prepwork needed?
|}

Yocto 1.0 Release Checklist

2011-04-05T13:13:17Z

Scottrifw: /* Yocto 1.0 Release Checklist */

== Yocto 1.0 Release Checklist ==

{| border="1"
|+ Release Criteria
! scope="col" | Task
! scope="col" | Due Date
! scope="col" | Owner
! scope="col" | Status
|-
| RC4 Go/No-Go
| March 25th
| Julie
| bgcolor="green" | Done - but No-Go
|-
| Create IDK packages for ADT repo
| March 28th
| Scott G and Lianhao
| bgcolor="green" | DONE
|-
| RC5 Go/No-Go
| March 29th
| Julie
| bgcolor="green" | DONE - RC5 is a go
|-
| Copy over to mirror area with non-readable permissions.
| March 29th
| Beth
| bgcolor="green" | DONE
|-
| Provide ScottR with bug information for release notes
| March 30th
| Richard
| bgcolor="green" | DONE
|-
| Work with warthog9 to switch rsync server to autobuilder.pokylinux.org
| March 31st
| Beth
| bgcolor="green" | DONE
|-
| Upload Eclipse plug-ins for 1.0 release - these need to be hosted on a folder on the downloads directory.
| April 1st
| Beth
| bgcolor="green" | DONE
|-
| Yocto video complete
| April 1st
| Tracey (ScottR for status)
| bgcolor="yellow" | Non-high-resolution version delivered to Tracey. If this meets approval it will be used for the web. It is being looked at now. High-res version on the way.
|-
| Push to mirror.
| April 1st
| Beth
| bgcolor="green" | DONE
|-
| Create Release Notes (Text version as well)
| April 4th
| ScottR
| bgcolor="green" | DONE - created and reviewed. TXT version delivered to Beth and Jefro.
|-
| Yocto new website improvements complete
| April 5th morning
| Jeff
| bgcolor="yellow" | on-track with high priority issues, others will come after launch; Beth will investigate certificate
|-
| Create release announcement for mailing lists
| April 5th
| Jeff
| bgcolor="yellow" | Draft is out for review
|-
| Prepare YP blog on release
| April 5th
| Dave
| bgcolor="yellow" | Does this need tech editing?
|-
| Create new directories for BSP, Kernel, and ADT HTML manuals with Mike S
| April 5th
| ScottR
| bgcolor="green" | Done.
|-
| Set permissions on release to readable
| April 5th 8pm Pacific
| Beth
| bgcolor="white" | -
|-
| Verify that release is on mirror.kernel.org
| April 5th
| Beth
| bgcolor="green" | -
|-
| Create Contributors list
| April 5th
| Jefro
| bgcolor="yellow" | Richard created log.
|-
| Yocto video on web
| April 5th
| Jefro
| bgcolor="white" | ScottR is checking on status of video
|-
| Crownbay EMGD tarball on S3 site
| April 5th
| Beth
| bgcolor="green" | -
|-
| Review Yocto 1.0 documentation against Yocto 1.0 code
| April 6th
| ScottR
| bgcolor="yellow" | in progress
|-
| Let Jeff know that we're ready.
| April 6th 8am Pacific
| Beth
| bgcolor="green" | -
|-
| Yocto new website live
| April 6th - 8am Pacific
| Jeff
| bgcolor="white" | Jeff is working with LF on the date they would like to see.
|-
| Update documentation on web with Yocto 1.0 information
| April 6th 8am Pacific
| ScottR
| bgcolor="white" | this will be done on new website
|-
| LF publishes Press Release
| April 6th - 9am Pacific
| Jeff (proxy for LF status)
| bgcolor="white" | -
|-
| Publish YP blog on release
| April 6th - 9am Pacific
| Dave
| bgcolor="white" | -
|-
| Change IRC room title
| April 6th - 9am Pacific
| Richard (Julie proxy)
| bgcolor="white" | -
|-
| Publish release announcement on all Yocto mailing lists (yocto-announce, yocto, poky)
| April 6th - 9am Pacific
| Jeff/Beth
| bgcolor="white" | Needs to be sent after Yocto 1.0 Press Release. Jeff and Beth will coordinate to send this out. Should include mention of contributors' list.
|-
| Point to new Crown Bay BSP
| April 6th - 9am Pacific
| MikeS (Beth proxy)
| bgcolor="green" | Beth will work with MikeS to ensure he is aware of the need.
|-
| Announce Yocto at LCS
| April 6th
| Jeff
| bgcolor="white" | Any prepwork needed?
|-
| Tweets on Yocto 1.0 throughout week
| April 6th-13th
| Jeff
| bgcolor="white" | -
|-
| Announce Yocto at ELC
| April 11th
| Jeff
| bgcolor="white" | Any prepwork needed?
|}

Yocto 1.0 Release Checklist

2011-04-05T13:12:20Z

Scottrifw:

== Yocto 1.0 Release Checklist ==

{| border="1"
|+ Release Criteria
! scope="col" | Task
! scope="col" | Due Date
! scope="col" | Owner
! scope="col" | Status
|-
| RC4 Go/No-Go
| March 25th
| Julie
| bgcolor="green" | Done - but No-Go
|-
| Create IDK packages for ADT repo
| March 28th
| Scott G and Lianhao
| bgcolor="green" | DONE
|-
| RC5 Go/No-Go
| March 29th
| Julie
| bgcolor="green" | DONE - RC5 is a go
|-
| Copy over to mirror area with non-readable permissions.
| March 29th
| Beth
| bgcolor="green" | DONE
|-
| Provide ScottR with bug information for release notes
| March 30th
| Richard
| bgcolor="green" | DONE
|-
| Work with warthog9 to switch rsync server to autobuilder.pokylinux.org
| March 31st
| Beth
| bgcolor="green" | DONE
|-
| Upload Eclipse plug-ins for 1.0 release - these need to be hosted on a folder on the downloads directory.
| April 1st
| Beth
| bgcolor="green" | DONE
|-
| Yocto video complete
| April 1st
| Tracey (ScottR for status)
| bgcolor="yellow" | Non-high-resolution version delivered to Tracey. If this meets approval it will be used for the web. It is being looked at now. High-res version on the way.|-
| Push to mirror.
| April 1st
| Beth
| bgcolor="green" | DONE
|-
| Create Release Notes (Text version as well)
| April 4th
| ScottR
| bgcolor="green" | DONE - created and reviewed. TXT version delivered to Beth and Jefro.
|-
| Yocto new website improvements complete
| April 5th morning
| Jeff
| bgcolor="yellow" | on-track with high priority issues, others will come after launch; Beth will investigate certificate
|-
| Create release announcement for mailing lists
| April 5th
| Jeff
| bgcolor="yellow" | Draft is out for review
|-
| Prepare YP blog on release
| April 5th
| Dave
| bgcolor="yellow" | Does this need tech editing?
|-
| Create new directories for BSP, Kernel, and ADT HTML manuals with Mike S
| April 5th
| ScottR
| bgcolor="green" | Done.
|-
| Set permissions on release to readable
| April 5th 8pm Pacific
| Beth
| bgcolor="white" | -
|-
| Verify that release is on mirror.kernel.org
| April 5th
| Beth
| bgcolor="green" | -
|-
| Create Contributors list
| April 5th
| Jefro
| bgcolor="yellow" | Richard created log.
|-
| Yocto video on web
| April 5th
| Jefro
| bgcolor="white" | ScottR is checking on status of video
|-
| Crownbay EMGD tarball on S3 site
| April 5th
| Beth
| bgcolor="green" | -
|-
| Review Yocto 1.0 documentation against Yocto 1.0 code
| April 6th
| ScottR
| bgcolor="yellow" | in progress
|-
| Let Jeff know that we're ready.
| April 6th 8am Pacific
| Beth
| bgcolor="green" | -
|-
| Yocto new website live
| April 6th - 8am Pacific
| Jeff
| bgcolor="white" | Jeff is working with LF on the date they would like to see.
|-
| Update documentation on web with Yocto 1.0 information
| April 6th 8am Pacific
| ScottR
| bgcolor="white" | this will be done on new website
|-
| LF publishes Press Release
| April 6th - 9am Pacific
| Jeff (proxy for LF status)
| bgcolor="white" | -
|-
| Publish YP blog on release
| April 6th - 9am Pacific
| Dave
| bgcolor="white" | -
|-
| Change IRC room title
| April 6th - 9am Pacific
| Richard (Julie proxy)
| bgcolor="white" | -
|-
| Publish release announcement on all Yocto mailing lists (yocto-announce, yocto, poky)
| April 6th - 9am Pacific
| Jeff/Beth
| bgcolor="white" | Needs to be sent after Yocto 1.0 Press Release. Jeff and Beth will coordinate to send this out. Should include mention of contributors' list.
|-
| Point to new Crown Bay BSP
| April 6th - 9am Pacific
| MikeS (Beth proxy)
| bgcolor="green" | Beth will work with MikeS to ensure he is aware of the need.
|-
| Announce Yocto at LCS
| April 6th
| Jeff
| bgcolor="white" | Any prepwork needed?
|-
| Tweets on Yocto 1.0 throughout week
| April 6th-13th
| Jeff
| bgcolor="white" | -
|-
| Announce Yocto at ELC
| April 11th
| Jeff
| bgcolor="white" | Any prepwork needed?
|}

Yocto 1.1 Features

2011-03-21T18:58:18Z

Scottrifw: /* Documentation */

== Potential Yocto 1.1 Features ==
Yocto 1.1 - Target release = October 2011

This page contains a list of Yocto 1.1 features. In early March, the Yocto Architect will issue an official call for Yocto 1.1 features. This list contains reprioritized items from 1.0 or features that came up as a result of discussions among Yocto engineers. If you have a feature you would like to see added, send an email to the Yocto Architect with a description of the feature, its impat on the source code, and whether you are willing to help write the code to implement the feature. The Yocto Architect will add this to the potential Yocto 1.1 Features list. The potential Yocto 1.1 Features list will be turned into the Yocto Features List as described in the [[Program Management Plan]].

== Yocto 1.1 Themes ==
The topics below are the themes that some members of the team have started brainstorming for Yocto 1.1. These will grow and change with community input.

=== Yocto 1.1 Objectives ===
The objectives of the Yocto 1.1 release are to grow participation in Yocto and increase the number of BSPs written for Yocto and partner products based on Yocto.

=== Yocto 1.1 Theme List ===
The Yocto 1.1 Themes towards the Objectives listed above are:

* Multilibs & OE-core config - This work, which began in Yocto 1.0, needs to be completed.
* Improve ease of BSP creation - Document the lifecycle and process. Possibly create walkthroughs or tutorials to integrate a new board into the linux-yocto kernel.
* Build performance – Get to the goal of 1 hour build time on a developer machine.
* Upstreaming – Submit patches to upstream projects in order to reduce the 2,000+ patches which are currently part of Yocto Project.

== Process for Entering New Feature Requests ==

* Create a new entry in the appropriate feature table below (Poky, SDK, Hardware)
** Suggestion: start by copying an existing request as a template
* Give the feature a short, descriptive name
* Provide a one or two sentence brief description of the feature
* Set the priority as appropriate (see the legend below)
* Set the Status to "Review"
* In the Source field, enter your name along with the origination of the request (e.g. OSV, OEM, Community) if applicable; provide as much detail here as you can
* In the Comments / Bugzilla field, provide any additional information for the request, such as a link to a bugzilla entry
* Preview your Entry to make sure it looks ok and then save it

''Legend''

'''Priority:''' 1 = Must Have, 2 = Nice to Have, 3 = Optional

'''Status:''' Accept = Engineering agreement to include in release, Review = Under Review for Inclusion in this release, Reject = Will not be included in this release
== Sample Table ==

This is a sample table to show how to submit features.

{| border="1"
||'''Feature Name''' ||'''Description''' ||'''Priority''' ||'''Status''' ||'''Source''' ||'''Comments / Bugzilla Links'''
|-
||Placeholder feature name || Placeholder description of the feature || 1, 2, or 3 || Review|| name|| Comment
|}

== Architecture ==
{| border="1"
||'''Feature Name''' ||'''Description''' ||'''Priority''' ||'''Status''' ||'''Source''' ||'''Comments / Bugzilla Links'''
|-
|| Layer Tooling || This includes the architectural work plus implementing the changes. || 1 || Review || Architect || M2; Owner = Richard
|-
|| OE-Core || Restructuring, renaming, rebranding || 1 || Review || RP Notes || M1; Owner = Richard
|}

== Poky/Bitbake ==
This section contains features for the Poky/Bitbake infastructure.
{| border="1"
||'''Feature Name''' ||'''Description''' ||'''Priority''' ||'''Status''' ||'''Source''' ||'''Comments / Bugzilla Links'''
|-
|| Error handling in bitbake || desc || 1 || Review || RP Notes || M2; Owner = Saul
|-
|| crazygit fetcher || TI issues with fetch2 || 2 || Review || RP Notes ||
|-
|| multi-lib || multi-lib support for 32-bit & 64-bit and capable of being installed at the same time || 1 || Review || from 1.0 || M1; Owner = Richard
|-
|| Image Creator || finish the Image Creator to add features pushed out from 1.0 || 1 || Review || from 1.0 || M2; Owner = Josh + someone else (Dave investigating someone on Jessica's team)
|-
|| Recipe-specific sysroot || || 3 || Review || from 1.0 ||
|-
|| Handle old versions in WORKDIR || || 3 || Review || from 1.0 ||
|-
|| Package config option enhancement || need to plan and then implement || 2 || Review || from 1.0 ||
|}

== QA Items ==
{| border="1"
||'''Feature Name''' ||'''Description''' ||'''Priority''' ||'''Status''' ||'''Source''' ||'''Comments / Bugzilla Links'''
|-
||QA Framework Enhancements ||
* Add test for unfs_qemu bootup in the sanity test framework and give Liping his patch (Jiajun)
* Help to define long-term flexible framework for SDK/meta-toolchain testing.. Under the test folder, we have different groups of test, such as sanity, SDK(tools), meta-toolchain. User could freely select which test cases they want to test. (Control granularity/level group? Or even a single case has a switch) (Jiajun)
* More test-projects into existing manual test part for meta-toolchain. We should help to find the two typical projects, one c and o C++. (Jiajun)
* Transform the meta-toolchain manual testing into the unified test-framework. (Liping)
* Prepare a workable environment for testing all those newly added features. (Liping)
* After sanity test framework is in the upstream, collect data when selecting different kinds of test components. (MeiLei)
|bgcolor="yellow"| ?? || Review|| QA ||
|-
|| Open Source Test Cases || Perform technical, legal, and QA steps necessary to move test cases into open source. || 3 || Review|| QA ||
|-
|| Automated test infrastructure || Automate the test infrastructure
|| 2 || Review|| QA ||
|-
|| Test framework || this is a test framework that we can include in the distribution || 3 || Review || RP Notes ||
|}

== Meta-data ==
{| border="1"
||'''Feature Name''' ||'''Description''' ||'''Priority''' ||'''Status''' ||'''Source''' ||'''Comments / Bugzilla Links'''
|-
|| Upstream our patches || We'll add this as a task in a milestone to give people time to do
|| 1 || Review|| Meta-data|| M2; Owner = Saul
|-
|| 3G || We have an ofono recipe but need some integration work doing || 2 || Review|| Meta-data||
|-
|| btrfs || || 2 || Review|| Meta-data||
|-
|| Other components? || Saul will investigate other components. || 2 || Review|| Meta-data||
|-
|| Replacement for video/audio players currently in Yocto || Codec…
|| 3 || Review|| Meta-data||
|-
|| Investigate New UI || For demos, we would like need a reference UI that is not Sato. Investigate possibilities that the Yocto team won't need to maintain. OpenBox? Gnome-desktop? GP? LXDE? KDE Mobile?
|| 3 || Review|| Meta-data||
|-
|| Qemugl upstreaming || Opengl ES Support || 3 || Review|| Meta-data||
|-
|| Sync qemugl with MeeGo ||
|| 2 || Review|| Meta-data||
|-
|| Package reporting system enhancement||
|| 2 || Review|| Meta-data||
|-
|| pam patch integration || add PAM patches throughout the system switchable via the PAM feature (Mark H)
|| 2 || Review|| Meta-data||
|-
|| selinux patch integration || add SE Linux patches in a similar way to PAM
|| 3 || Review|| Meta-data||
|-
|| Finish LSB "distribution" work || Merge patches which are pushed during ycoto 1.0. Add packages LSB Test Suite need. Hardware platform x86, x86-64 and ppc32(if qt4 can be supported) can be finished.
|| 2 || Review|| Meta-data|| M2; Owner = Xiaofeng Yan, Jingdong Lu, Kai kang,Xudong Hao
|-
|| OE Comparison || Compare Yocto core set against integration work in OE and other distributions looking for bug fixes, (relevant) feature enhancements, and integration/policy hints.
|| 1 || Review|| Meta-data|| M1; Owner = Mark
|-
|| Framework to support multiple library versions co-existing || similar to recipe specific sysroot; needs documentation
|| 2 || Review|| Team ||
|-
|| Embedded java environment or even JDK support ||
|| 3 || Review|| Team ||
|-
|| Automatically generate package repos || automatically generate package repositories (and be able to "use them" -- to be defined) for both ipk and rpm/zypper combinations; NEEDS MORE DISCUSSION
|| 2|| Review|| Team ||
|-
|| MeeGo GPLv2 Sync || compare with Yocto, sync any patches || 2 || Review || RP Notes ||
|-
|| Incompatible License || || 2 || Review || Paul ||
|-
|| End of package revision || replace with a network service || 2 || Review || RP Notes || Owner = Jessica
|-
|| Target module build || Allow for building kernel modules on the target device || 2 || Review || RP Notes || Owner = Darren
|-
|| Live images || make live images their own image type || 2 || Review || RP Notes || Owner = Saul
|-
|| multiple update-alternatives || fixed? || 3 || Review || RP Notes ||
|-
|| init scripts || provide an image/recipe skeleton as a canonical example || 3 || Review || RP Notes ||
|-
|| running post installs at rootfs gen time || || 2 || Review || RP Notes ||
|-
|| remove gnome-vfs || || 3 || Review || RP Notes ||
|-
|| gtk+ sato filechooser patch || || 3 || Review || RP Notes ||
|-
|| sato refresh || || 3 || Review || RP Notes ||
|-
|| adding eglibc config control || this goes with the package config options || 1.5 || Review || RP Notes || M2; Owner = Mark
|-
|| Sanity checks on per recipe basis || || 2 || Review || RP Notes ||
|-
|| x32 || layer to support toolchain, libc, and kernel || 2 || Review || RP Notes ||
|-
|| User Creation at postinstall || || 1 || Review || RP Notes || M1; Owner = Mark
|-
|| Directory Ownership || || 1.5 || Review || RP Notes || M2; Owner = Mark
|-
|| Optimise Configure || || 2 || Review || RP Notes || Performance idea
|-
|| Ability to build SRPM || || 3 || Review || RP Notes ||
|-
|| Check SRCREV in recipe files || should work, may need dev || 2 || Review || RP Notes ||
|-
|| Add Directfb（license LGPL） function || Directfb is more appropriate embedded device than other graphic software|| 3 || Review ||Meta-data || M3;Owner = Xiaofeng Yan if possible
|}

== BSPs ==
{| border="1"
||'''Feature Name''' ||'''Description''' ||'''Priority''' ||'''Status''' ||'''Source''' ||'''Comments / Bugzilla Links'''
|-
|| Support for AVX as in kernel 2.6.30. - Already in 1.0 || Any toolchain support needed?
|| 1|| Review|| Jay || M1; Owner = Saul

|}

== ADT ==
{| border="1"
||'''Feature Name''' ||'''Description''' ||'''Priority''' ||'''Status''' ||'''Source''' ||'''Comments / Bugzilla Links'''
|-
|| More test cases about toolchain in autobuilder ||
|| 2 || Review|| ADT Team || Owner = Jessica
|-
|| Eclipse-native tools interface || not using oprofile-UI. More integrated with upstream
|| 2 || Review|| ADT Team ||
|-
|| Indigo update || Update to the latest Eclipse release (Indigo) || 2 || Review|| ADT Team || M2; Owner = Jessica
|-
|| Changes for Image Creator || Eclipse changes pending Image Creator || 1 || Review|| ADT Team || M2; Owner = Jessica
|-
|| Secure logging || || 2 || Review|| ADT Team ||
|-
|| Prebuit SDK integration || speedup target image generation by reusing prebuilt tools from SDK native and target binaries. See: http://wiki.secretlab.ca/Yocto_prebuilt_SDK_integration|| 2 || Review || Adrian ||
|}

== Documentation ==
{| border="1"
||'''Feature Name''' ||'''Description''' ||'''Priority''' ||'''Status''' ||'''Source''' ||'''Comments / Bugzilla Links'''
|-
|| Package Documentation Audit || Make changes defined in the package documentation audit from Yocto 1.0
|| 2|| Review|| from 1.0 || Owner = Saul
|-
|| Yocto Project Development Guide || This manual would be an over-arching document that frames the complete development cycle within Yocto Project. The idea here is that the document would be an umbrella document that spawned and referenced subsequent documents. The organization would be the first chapter overviews the major development pieces such as recipe creation, building, debugging, publishing, fail-safing, back-door hook creation, etc. This manual will also include migration information. Scoping would be about two weeks and length would probably be about 40 pages. Overall development time will likely take up to the release given my experience on the creation of the ADT manual (there is no uniterruped time).
|| 1|| Not Started || from scratch || Owner = ScottR
|-
|| Various Demo Videos || The idea here is to create screen-capture type tutorials similar to what exists for the ADT Eclipse Plug-in. However, we want to contract out some help for professional voice-over talent to be used with the images. These don't have to be limited to screen-capture material but could include well-done PPT decks - similar to how other business units in Intel create various training modules. For 1.1 it would be good to capture the script for the existing ADT Eclipse Plug-in module and have it voiced over. Also, for 1.1 it would be good to create a similar module for the Image Creator application.
|| 2|| Not Started || From ADT module and scratch || Owner = ScottR
|-
|| Open-source Newbie Information || This information will be for developers new to open-source. These people do not know what IRC means. Targeted for developers coming from a non-open-source environment. I think the best place for this information would be the website. I haven't looked yet but I suspect information already exists on the web. For Yocto it will be a matter of collecting the best and most useful information, orginizing it and properly referencing/leveraging it.
|| 2|| Not Started || From scratch || Owner = ScottR
|-
|| Tarball Doc process || Right now tarball docs are frozen shortly before a release. The tarball never gets updated beyond that during subsequent documentation development. However, website docs are periodically updated as changes are made during the next development cycle. We need a documentation process where the tarball docs are updated along with the website docs. Perhaps releasing and building a separate documentation tarball is an answer... This whole scheme needs thought about and something implemented.
|| 3|| Not Started || From scratch || Owner = ScottR
|}

== Build ==
This section contains requirements related to the build (autobuilder activities, performance, footprint, etc.)
{| border="1"
||'''Feature Name''' ||'''Description''' ||'''Priority''' ||'''Status''' ||'''Source''' ||'''Comments / Bugzilla Links'''
|-
|| Autobuilder maintenance || Bring scripts into configuration or get git repo working for those that can't be brought in.
|bgcolor="yellow"| 1 || Review || Beth || M1; Owner = Beth
|-
|| Meta targets || Part of the challenge of autobuilder is that you have to go into autobuilder, edit script, reconfigure, to change just one build target. This is error prone. What we need is a meta-target where Beth can say she wants to build Poky-image-sato for QEMU x86 and have it just do that. Beth thinks this is done via an override to the web page. (takes ~2 weeks)
|bgcolor="yellow"| 1 || Review || Beth || M2; Owner = Beth
|-
|| License tracking || Get common licenses for all packages. (takes ~3 days)
|bgcolor="yellow"| 1 || Review || Beth || M1; Owner = Beth
|-
|| License history || Build a parser to do license history more gracefully and make sure all recipes are correct. (takes ~2 weeks)
|bgcolor="yellow"| 1 || Review || Beth || M2; Owner = Beth
|-
|| Audotbuilder infrastructure || Bring up additional autobuilders and work with sysadmin to configure.
|bgcolor="yellow"| 1 || Review || Beth || M2; Owner = Beth
|-
|| Overall Project || Host a retrospective to discuss what went well and what can be improved in Yocto 1.0.
|bgcolor="yellow"| 1 || Review || Beth || M1; Owner = Beth
|-
|| Release Scripts || Create Release Scripts for OCT 2011 release.
|bgcolor="yellow"| 1 || Review || Beth || M3; Owner = Beth
|-
|| Enhanced Performance || Also, environmental requirements/suggestions for expected performance; Goal is to build in under 1 hour || 2 || Review || from 1.0 ||
|-
|| Disk Space Reduction ||
|| 2 || Review || Team ||
|-
|| Share gcc work directories ||
|| 2 || Review || Team ||
|-
|| Patch Test System || Create a machine where developers can upload/test patches before submitting them to master to ensure builds won't break when patches are added.
|| 2 || Review || Team ||
|-
|| build statistics reporting || As someone interested in how long it takes to build different images on different hardware configurations and other assorted build metrics, I would like a web based service, that takes output generated by an extended buildstats.bbclass and stores it, to compare against different machines. The end result should be a way to visualize the collected data. See: https://wiki.yoctoproject.org/wiki/Yocto_Buildbot_Autobuilder_Discussions
|| || Review || eflanagan/Jay7/ka6sox ||
|-
|| BSP builds || Autobuilder git fetcher improvements || 2 || Review || from 1.0 || M1; Owner = Beth
|-
|| Implement Continuous Autobuilds || Build constantly instead of daily || 2 || Review || from 1.0 || M1; Owner = Beth
|}

== Performance and Usability ==
This section contains general Yocto performance as well as usability items.
{| border="1"
||'''Feature Name''' ||'''Description''' ||'''Priority''' ||'''Status''' ||'''Source''' ||'''Comments / Bugzilla Links'''
|-
|| Fast boot time || 2 second boot time target
|| 1|| Review|| Team || M2; Owner = Darren
|-
|| Build Yocto behind firewall || Darren will investigate site.conf and documentation
|| 2 || Review|| Dave||
|-
|| Minimal Image unique || make minimal image smaller || 3 || Review|| Team ||
|-
|| POSIX support || address POSIX failures found in 1.1
|| 2|| Review|| Team ||
|}

== Kernel ==
This section contains items specific to the Yocto kernel.
{| border="1"
||'''Feature Name''' ||'''Description''' ||'''Priority''' ||'''Status''' ||'''Source''' ||'''Comments / Bugzilla Links'''
|-
|| BSP kernel config audit || audit kernel configs for the various BSPS
|| 2|| Review|| Team ||
|-
|| Tracing: perf trace scripting support || we think usability is the direction to focus on, we want to improve usability through documentation || 2 || Review || from 1.0 ||
|-
|| Tracing: tuna, oscilloscope recipes || catch up with Tom, likely to remove || 3 || Review || from 1.0 ||
|}

== Project-Wide Features ==
This section contains features for the entire project or for the project website or mailing lists.
{| border="1"
||'''Feature Name''' ||'''Description''' ||'''Priority''' ||'''Status''' ||'''Source''' ||'''Comments / Bugzilla Links'''
|-
|| Patchwork || is it worth the overhead, are there alternatives || 3 || Review || RP Notes ||
|-
|| Alpha || Begin an alpha program after the stabilization period for M3. || 1 || Review || Team ||
|-
|| Bugzilla to Wiki || Create a script which automatically populates and updates the Wiki based on changes in bugzilla.
|bgcolor="yellow"| ? || Review || Darren ||
|}

Yocto 1.1 Features

2011-03-21T18:50:18Z

Scottrifw: /* Documentation */

== Potential Yocto 1.1 Features ==
Yocto 1.1 - Target release = October 2011

This page contains a list of Yocto 1.1 features. In early March, the Yocto Architect will issue an official call for Yocto 1.1 features. This list contains reprioritized items from 1.0 or features that came up as a result of discussions among Yocto engineers. If you have a feature you would like to see added, send an email to the Yocto Architect with a description of the feature, its impat on the source code, and whether you are willing to help write the code to implement the feature. The Yocto Architect will add this to the potential Yocto 1.1 Features list. The potential Yocto 1.1 Features list will be turned into the Yocto Features List as described in the [[Program Management Plan]].

== Yocto 1.1 Themes ==
The topics below are the themes that some members of the team have started brainstorming for Yocto 1.1. These will grow and change with community input.

=== Yocto 1.1 Objectives ===
The objectives of the Yocto 1.1 release are to grow participation in Yocto and increase the number of BSPs written for Yocto and partner products based on Yocto.

=== Yocto 1.1 Theme List ===
The Yocto 1.1 Themes towards the Objectives listed above are:

* Multilibs & OE-core config - This work, which began in Yocto 1.0, needs to be completed.
* Improve ease of BSP creation - Document the lifecycle and process. Possibly create walkthroughs or tutorials to integrate a new board into the linux-yocto kernel.
* Build performance – Get to the goal of 1 hour build time on a developer machine.
* Upstreaming – Submit patches to upstream projects in order to reduce the 2,000+ patches which are currently part of Yocto Project.

== Process for Entering New Feature Requests ==

* Create a new entry in the appropriate feature table below (Poky, SDK, Hardware)
** Suggestion: start by copying an existing request as a template
* Give the feature a short, descriptive name
* Provide a one or two sentence brief description of the feature
* Set the priority as appropriate (see the legend below)
* Set the Status to "Review"
* In the Source field, enter your name along with the origination of the request (e.g. OSV, OEM, Community) if applicable; provide as much detail here as you can
* In the Comments / Bugzilla field, provide any additional information for the request, such as a link to a bugzilla entry
* Preview your Entry to make sure it looks ok and then save it

''Legend''

'''Priority:''' 1 = Must Have, 2 = Nice to Have, 3 = Optional

'''Status:''' Accept = Engineering agreement to include in release, Review = Under Review for Inclusion in this release, Reject = Will not be included in this release
== Sample Table ==

This is a sample table to show how to submit features.

{| border="1"
||'''Feature Name''' ||'''Description''' ||'''Priority''' ||'''Status''' ||'''Source''' ||'''Comments / Bugzilla Links'''
|-
||Placeholder feature name || Placeholder description of the feature || 1, 2, or 3 || Review|| name|| Comment
|}

== Architecture ==
{| border="1"
||'''Feature Name''' ||'''Description''' ||'''Priority''' ||'''Status''' ||'''Source''' ||'''Comments / Bugzilla Links'''
|-
|| Layer Tooling || This includes the architectural work plus implementing the changes. || 1 || Review || Architect || M2; Owner = Richard
|-
|| OE-Core || Restructuring, renaming, rebranding || 1 || Review || RP Notes || M1; Owner = Richard
|}

== Poky/Bitbake ==
This section contains features for the Poky/Bitbake infastructure.
{| border="1"
||'''Feature Name''' ||'''Description''' ||'''Priority''' ||'''Status''' ||'''Source''' ||'''Comments / Bugzilla Links'''
|-
|| Error handling in bitbake || desc || 1 || Review || RP Notes || M2; Owner = Saul
|-
|| crazygit fetcher || TI issues with fetch2 || 2 || Review || RP Notes ||
|-
|| multi-lib || multi-lib support for 32-bit & 64-bit and capable of being installed at the same time || 1 || Review || from 1.0 || M1; Owner = Richard
|-
|| Image Creator || finish the Image Creator to add features pushed out from 1.0 || 1 || Review || from 1.0 || M2; Owner = Josh + someone else (Dave investigating someone on Jessica's team)
|-
|| Recipe-specific sysroot || || 3 || Review || from 1.0 ||
|-
|| Handle old versions in WORKDIR || || 3 || Review || from 1.0 ||
|-
|| Package config option enhancement || need to plan and then implement || 2 || Review || from 1.0 ||
|}

== QA Items ==
{| border="1"
||'''Feature Name''' ||'''Description''' ||'''Priority''' ||'''Status''' ||'''Source''' ||'''Comments / Bugzilla Links'''
|-
||QA Framework Enhancements ||
* Add test for unfs_qemu bootup in the sanity test framework and give Liping his patch (Jiajun)
* Help to define long-term flexible framework for SDK/meta-toolchain testing.. Under the test folder, we have different groups of test, such as sanity, SDK(tools), meta-toolchain. User could freely select which test cases they want to test. (Control granularity/level group? Or even a single case has a switch) (Jiajun)
* More test-projects into existing manual test part for meta-toolchain. We should help to find the two typical projects, one c and o C++. (Jiajun)
* Transform the meta-toolchain manual testing into the unified test-framework. (Liping)
* Prepare a workable environment for testing all those newly added features. (Liping)
* After sanity test framework is in the upstream, collect data when selecting different kinds of test components. (MeiLei)
|bgcolor="yellow"| ?? || Review|| QA ||
|-
|| Open Source Test Cases || Perform technical, legal, and QA steps necessary to move test cases into open source. || 3 || Review|| QA ||
|-
|| Automated test infrastructure || Automate the test infrastructure
|| 2 || Review|| QA ||
|-
|| Test framework || this is a test framework that we can include in the distribution || 3 || Review || RP Notes ||
|}

== Meta-data ==
{| border="1"
||'''Feature Name''' ||'''Description''' ||'''Priority''' ||'''Status''' ||'''Source''' ||'''Comments / Bugzilla Links'''
|-
|| Upstream our patches || We'll add this as a task in a milestone to give people time to do
|| 1 || Review|| Meta-data|| M2; Owner = Saul
|-
|| 3G || We have an ofono recipe but need some integration work doing || 2 || Review|| Meta-data||
|-
|| btrfs || || 2 || Review|| Meta-data||
|-
|| Other components? || Saul will investigate other components. || 2 || Review|| Meta-data||
|-
|| Replacement for video/audio players currently in Yocto || Codec…
|| 3 || Review|| Meta-data||
|-
|| Investigate New UI || For demos, we would like need a reference UI that is not Sato. Investigate possibilities that the Yocto team won't need to maintain. OpenBox? Gnome-desktop? GP? LXDE? KDE Mobile?
|| 3 || Review|| Meta-data||
|-
|| Qemugl upstreaming || Opengl ES Support || 3 || Review|| Meta-data||
|-
|| Sync qemugl with MeeGo ||
|| 2 || Review|| Meta-data||
|-
|| Package reporting system enhancement||
|| 2 || Review|| Meta-data||
|-
|| pam patch integration || add PAM patches throughout the system switchable via the PAM feature (Mark H)
|| 2 || Review|| Meta-data||
|-
|| selinux patch integration || add SE Linux patches in a similar way to PAM
|| 3 || Review|| Meta-data||
|-
|| Finish LSB "distribution" work || Merge patches which are pushed during ycoto 1.0. Add packages LSB Test Suite need. Hardware platform x86, x86-64 and ppc32(if qt4 can be supported) can be finished.
|| 2 || Review|| Meta-data|| M2; Owner = Xiaofeng Yan, Jingdong Lu, Kai kang,Xudong Hao
|-
|| OE Comparison || Compare Yocto core set against integration work in OE and other distributions looking for bug fixes, (relevant) feature enhancements, and integration/policy hints.
|| 1 || Review|| Meta-data|| M1; Owner = Mark
|-
|| Framework to support multiple library versions co-existing || similar to recipe specific sysroot; needs documentation
|| 2 || Review|| Team ||
|-
|| Embedded java environment or even JDK support ||
|| 3 || Review|| Team ||
|-
|| Automatically generate package repos || automatically generate package repositories (and be able to "use them" -- to be defined) for both ipk and rpm/zypper combinations; NEEDS MORE DISCUSSION
|| 2|| Review|| Team ||
|-
|| MeeGo GPLv2 Sync || compare with Yocto, sync any patches || 2 || Review || RP Notes ||
|-
|| Incompatible License || || 2 || Review || Paul ||
|-
|| End of package revision || replace with a network service || 2 || Review || RP Notes || Owner = Jessica
|-
|| Target module build || Allow for building kernel modules on the target device || 2 || Review || RP Notes || Owner = Darren
|-
|| Live images || make live images their own image type || 2 || Review || RP Notes || Owner = Saul
|-
|| multiple update-alternatives || fixed? || 3 || Review || RP Notes ||
|-
|| init scripts || provide an image/recipe skeleton as a canonical example || 3 || Review || RP Notes ||
|-
|| running post installs at rootfs gen time || || 2 || Review || RP Notes ||
|-
|| remove gnome-vfs || || 3 || Review || RP Notes ||
|-
|| gtk+ sato filechooser patch || || 3 || Review || RP Notes ||
|-
|| sato refresh || || 3 || Review || RP Notes ||
|-
|| adding eglibc config control || this goes with the package config options || 1.5 || Review || RP Notes || M2; Owner = Mark
|-
|| Sanity checks on per recipe basis || || 2 || Review || RP Notes ||
|-
|| x32 || layer to support toolchain, libc, and kernel || 2 || Review || RP Notes ||
|-
|| User Creation at postinstall || || 1 || Review || RP Notes || M1; Owner = Mark
|-
|| Directory Ownership || || 1.5 || Review || RP Notes || M2; Owner = Mark
|-
|| Optimise Configure || || 2 || Review || RP Notes || Performance idea
|-
|| Ability to build SRPM || || 3 || Review || RP Notes ||
|-
|| Check SRCREV in recipe files || should work, may need dev || 2 || Review || RP Notes ||
|-
|| Add Directfb（license LGPL） function || Directfb is more appropriate embedded device than other graphic software|| 3 || Review ||Meta-data || M3;Owner = Xiaofeng Yan if possible
|}

== BSPs ==
{| border="1"
||'''Feature Name''' ||'''Description''' ||'''Priority''' ||'''Status''' ||'''Source''' ||'''Comments / Bugzilla Links'''
|-
|| Support for AVX as in kernel 2.6.30. - Already in 1.0 || Any toolchain support needed?
|| 1|| Review|| Jay || M1; Owner = Saul

|}

== ADT ==
{| border="1"
||'''Feature Name''' ||'''Description''' ||'''Priority''' ||'''Status''' ||'''Source''' ||'''Comments / Bugzilla Links'''
|-
|| More test cases about toolchain in autobuilder ||
|| 2 || Review|| ADT Team || Owner = Jessica
|-
|| Eclipse-native tools interface || not using oprofile-UI. More integrated with upstream
|| 2 || Review|| ADT Team ||
|-
|| Indigo update || Update to the latest Eclipse release (Indigo) || 2 || Review|| ADT Team || M2; Owner = Jessica
|-
|| Changes for Image Creator || Eclipse changes pending Image Creator || 1 || Review|| ADT Team || M2; Owner = Jessica
|-
|| Secure logging || || 2 || Review|| ADT Team ||
|-
|| Prebuit SDK integration || speedup target image generation by reusing prebuilt tools from SDK native and target binaries. See: http://wiki.secretlab.ca/Yocto_prebuilt_SDK_integration|| 2 || Review || Adrian ||
|}

== Documentation ==
{| border="1"
||'''Feature Name''' ||'''Description''' ||'''Priority''' ||'''Status''' ||'''Source''' ||'''Comments / Bugzilla Links'''
|-
|| Package Documentation Audit || Make changes defined in the package documentation audit from Yocto 1.0
|| 2|| Review|| from 1.0 || Owner = Saul
|-
|| Yocto Project Development Guide || This manual would be an over-arching document that frames the complete development cycle within Yocto Project. The idea here is that the document would be an umbrella document that spawned and referenced subsequent documents. The organization would be the first chapter overviews the major development pieces such as recipe creation, building, debugging, publishing, fail-safing, back-door hook creation, etc. This manual will also include migration information. Scoping would be about two weeks and length would probably be about 40 pages. Overall development time will likely take up to the release given my experience on the creation of the ADT manual (there is no uniterruped time).
|| 2|| Review || from 1.0 ||
|-
|| Various Demo Videos || The idea here is to create screen-capture type tutorials similar to what exists for the ADT Eclipse Plug-in. However, we want to contract out some help for professional voice-over talent to be used with the images. These don't have to be limited to screen-capture material but could include well-done PPT decks - similar to how other business units in Intel create various training modules. For 1.1 it would be good to capture the script for the existing ADT Eclipse Plug-in module and have it voiced over. Also, for 1.1 it would be good to create a similar module for the Image Creator application.
|| 2|| Review || from 1.0 ||
|}

== Build ==
This section contains requirements related to the build (autobuilder activities, performance, footprint, etc.)
{| border="1"
||'''Feature Name''' ||'''Description''' ||'''Priority''' ||'''Status''' ||'''Source''' ||'''Comments / Bugzilla Links'''
|-
|| Autobuilder maintenance || Bring scripts into configuration or get git repo working for those that can't be brought in.
|bgcolor="yellow"| 1 || Review || Beth || M1; Owner = Beth
|-
|| Meta targets || Part of the challenge of autobuilder is that you have to go into autobuilder, edit script, reconfigure, to change just one build target. This is error prone. What we need is a meta-target where Beth can say she wants to build Poky-image-sato for QEMU x86 and have it just do that. Beth thinks this is done via an override to the web page. (takes ~2 weeks)
|bgcolor="yellow"| 1 || Review || Beth || M2; Owner = Beth
|-
|| License tracking || Get common licenses for all packages. (takes ~3 days)
|bgcolor="yellow"| 1 || Review || Beth || M1; Owner = Beth
|-
|| License history || Build a parser to do license history more gracefully and make sure all recipes are correct. (takes ~2 weeks)
|bgcolor="yellow"| 1 || Review || Beth || M2; Owner = Beth
|-
|| Audotbuilder infrastructure || Bring up additional autobuilders and work with sysadmin to configure.
|bgcolor="yellow"| 1 || Review || Beth || M2; Owner = Beth
|-
|| Overall Project || Host a retrospective to discuss what went well and what can be improved in Yocto 1.0.
|bgcolor="yellow"| 1 || Review || Beth || M1; Owner = Beth
|-
|| Release Scripts || Create Release Scripts for OCT 2011 release.
|bgcolor="yellow"| 1 || Review || Beth || M3; Owner = Beth
|-
|| Enhanced Performance || Also, environmental requirements/suggestions for expected performance; Goal is to build in under 1 hour || 2 || Review || from 1.0 ||
|-
|| Disk Space Reduction ||
|| 2 || Review || Team ||
|-
|| Share gcc work directories ||
|| 2 || Review || Team ||
|-
|| Patch Test System || Create a machine where developers can upload/test patches before submitting them to master to ensure builds won't break when patches are added.
|| 2 || Review || Team ||
|-
|| build statistics reporting || As someone interested in how long it takes to build different images on different hardware configurations and other assorted build metrics, I would like a web based service, that takes output generated by an extended buildstats.bbclass and stores it, to compare against different machines. The end result should be a way to visualize the collected data. See: https://wiki.yoctoproject.org/wiki/Yocto_Buildbot_Autobuilder_Discussions
|| || Review || eflanagan/Jay7/ka6sox ||
|-
|| BSP builds || Autobuilder git fetcher improvements || 2 || Review || from 1.0 || M1; Owner = Beth
|-
|| Implement Continuous Autobuilds || Build constantly instead of daily || 2 || Review || from 1.0 || M1; Owner = Beth
|}

== Performance and Usability ==
This section contains general Yocto performance as well as usability items.
{| border="1"
||'''Feature Name''' ||'''Description''' ||'''Priority''' ||'''Status''' ||'''Source''' ||'''Comments / Bugzilla Links'''
|-
|| Fast boot time || 2 second boot time target
|| 1|| Review|| Team || M2; Owner = Darren
|-
|| Build Yocto behind firewall || Darren will investigate site.conf and documentation
|| 2 || Review|| Dave||
|-
|| Minimal Image unique || make minimal image smaller || 3 || Review|| Team ||
|-
|| POSIX support || address POSIX failures found in 1.1
|| 2|| Review|| Team ||
|}

== Kernel ==
This section contains items specific to the Yocto kernel.
{| border="1"
||'''Feature Name''' ||'''Description''' ||'''Priority''' ||'''Status''' ||'''Source''' ||'''Comments / Bugzilla Links'''
|-
|| BSP kernel config audit || audit kernel configs for the various BSPS
|| 2|| Review|| Team ||
|-
|| Tracing: perf trace scripting support || we think usability is the direction to focus on, we want to improve usability through documentation || 2 || Review || from 1.0 ||
|-
|| Tracing: tuna, oscilloscope recipes || catch up with Tom, likely to remove || 3 || Review || from 1.0 ||
|}

== Project-Wide Features ==
This section contains features for the entire project or for the project website or mailing lists.
{| border="1"
||'''Feature Name''' ||'''Description''' ||'''Priority''' ||'''Status''' ||'''Source''' ||'''Comments / Bugzilla Links'''
|-
|| Patchwork || is it worth the overhead, are there alternatives || 3 || Review || RP Notes ||
|-
|| Alpha || Begin an alpha program after the stabilization period for M3. || 1 || Review || Team ||
|-
|| Bugzilla to Wiki || Create a script which automatically populates and updates the Wiki based on changes in bugzilla.
|bgcolor="yellow"| ? || Review || Darren ||
|}

Yocto 1.0 Schedule

2010-12-14T15:59:44Z

Scottrifw: /* Sprint A (closes Dec 24, 11:59pm PDT -- pull request sent, initially reviewed) */

= v1.0 (release date: Apr 15, 2011) =
----
The detailed milestone map for v1.0 is as below. During the first week of each subsequent milestone past M1 we will have a demonstration of the previous milestone capabilities as well as a planning and design session for the current milestone. 

== M2 (Nov 08 to Dec 24 -- Dev Complete Dec 10, Stabilize Complete Dec 17, Release Complete Dec 24) ==
=== Sprint A (closes Nov 12, 11:59pm PDT -- pull request sent, initially reviewed) ===

{|border="1"
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''
|-
|| Poky Features || Kernel interactive targets || To support incremental kernel development having the ability to run menuconfig (or xconfig, etc) directly is a common request. We'll need to add this for commercialization anyway. i.e. bitbake -c menuconfig. This fuctionality already exists. || 1 || Completed || Richard || bruceashfield || Enhancement
|-
|| Distribution / components || Distro Audit: Upgrades Planned (Phase 1) || Complete plan for package upgrades in M2 || 1 || Done || Saul || || Continual Maintenance
|-
|| Validation || Runtime testing || Runtime testing of images as part of the autobuilder || 1 || Done || Jiajun/ScottG || rpurdie || project commitment
|-
|| || Poky Image Creator Wireframe/Interaction Plans Complete || || 1 || Done || Josh || ||
|-
|| || SDK Generator Interaction: Plans Complete || || 1 || Done || Jessica || ||
|-
|| || Tracing/Profiling Planning Complete || This needs to cover where we're at now, what we're missing and also propose the future enhancements that may be needed. M2 targets getting existing tools integrated and documented. F2f discussion n the future enhancements || || Done || Tom || ||
|-
|| || Swabber. (Still needs to be integrated into weekly build by default) || || 1 || Done || Josh || ||
|-
|| Build/Release || Release process documentation || || || Done || Beth || ||
|-
|| Validation || Test plan for v1.0 (to address any deficiencies in coverage from v0.9)|| || 1 || Done || Jiajun || ||
|}

=== Sprint B (closes Nov 19, 11:59pm PDT -- pull request sent, initially reviewed) ===

{|border="1"
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''
|-
|| Distribution / components|| Distro Audit: World Packages|| Audit world packages making sure it all build, making sure all are packages are required || 2|| Done || Saul|| sgw|| Hygiene
|-
|| Distribution / components|| Distro Audit: Package Description/Summary completed|| Ensure DESCRIPTION/SUMMARY fields are all audited|| 2|| WIP, Done by Dec 08|| Mark|| Mark|| Hygiene
|-
|| Tool Development and SDK Features|| SDK Generator Installer UI|| Look at different ways of Installer UI (GTK+ and ncurses) seems none of them is the right choice, decide to go with script to implement all the functionalities of installer and later add UI part on top of it || 1||Done|| Jessica|| jzhang|| Enhancement
|-
|| Tool Development and SDK Features|| Customize sysroot setup || Add and test out "--sysroot" config option to cross compiler within Eclipse IDE || 1|| Done || Jessica|| jzhang|| Enhancement
|-
|| Tool Development and SDK Features|| SDK Generator Installer design revision|| Close all open questions regarding Yocto SDK Generator Installer function design and come up HLD || 1|| Done || Jessica|| jzhang|| Enhancement
|-
|| Distribution / components|| kernel version|| keeping 2.6.34 as a -stable kernel is the best option. I've also got a newer -devel tree that can be made available or made the default. || 3|| Done || Bruce|| bruceashfield|| enhancement
|-
|| || assign Yocto Project PM|| acquire and assign a program manager for Yocto Project|| || Done || DaveST|| ||
|-
|| || assign Yocto Project Sys Admin|| || || Done || Saul|| ||
|-
|| Distribution / components|| Zypper/RPM|| Small write-up of the problems we're having w/ Zypper and what we plan to do. (i.e. create a roadmap/design) - Includes rootfs generation - Package uprev/install/removal || 1 || WIP, Done by Dec 06 || Mark/Qing || ||
|-
|| Tool Development and SDK Features|| oprofileUI|| Fixing various bugs of the oprofileUI to make it workable on big endian host.(i.e. ppc, mips) || 2 || WIP, bugs fixed, Josh work with Richard and oprofileUI maintainer (robsta) for upstreaming. WIP, done by Dec 10 || Jessica || lianhao.lu || Bug #382 / Bug #493
|-
|| Poky Feature|| SDK Version Control|| If we can expect that yocto SDK has lots of release in the future, we might need to consider SDK version control. Currently, every thing installed under /opt/poky which leads to things be overriden, we need to be able to use a scheme like /opt/poky-1.0, /opt/poky-2.0 to distiguish things. || 2|| Done || Josh|| jzhang|| Enhancement
|-
|| Kernel || Kernel plan complete || Flesh our kernel deliverables and add to Yocto 1.0 schedule || || Done|| Darren || dvhart ||
|}

=== Sprint C (closes Nov 26, 11:59pm PDT -- pull request sent, initially reviewed) :: NOTE: this is US Thanksgiving week ===

{|border="1"
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''
|-
|| Distribution / components|| Distro Audit: Licence Checksums|| Make the licence checksums fatal if not present || 1|| WIP, done by Dec 10 || Saul|| rpurdie|| Hygiene
|-
|| Poky Features || Performance Analysis Completed|| "I'd like someone to instrument a green release build, see where it spends time (hot/cold parsing time, individual task building time) and then compare this with our 0.9 release build. I'd also like to compare the disk usage between the two. Once we have a blame list we can then set about fixing it. Some things I know will come up: a) pseudo, b) checksums/signature code, c) exec() vs fork for executing tasks, d) task based prebuilds increasing disk usage, e) rpm dependency calculations, f) using rpm vs. ipk but I may be wrong and there may be others. We need numbers. "|| 1|| Done || Saul / Qing, Dongxiao|| rpurdie|| Enhancement
|-
|| Poky Features || environment variables for kernel builds|| switching a branch, or adding a configuration feature (and even changing the kernel repo) is often done during development of a BSP. Having some additional variables that are pass the bitbake environment scrub would be useful. i.e. KBRANCH=foo bitbake -c configure linux-yocto. This goes along with the other BSP bootstrapping suggestions. || 2|| Done || Bruce|| bruceashfield|| Enhancement
|-
|| Poky Features || kernel development layer|| The (correct) poky behaviour of building known revisions coupled with the fetcher requiring a BSP branch to already be present means that local modifications (and kernel source tree) are required for kernel development. I already have a layer that overrides/modifies the behaviour when added to the bblayers.conf and configured into an environment. This seems useful for more people to use. || 2|| Done || Bruce|| bruceashfield|| Enhancement
|-
|| Distribution / components|| Zypper/RPM|| RPM Uprev / Zypper Uprev [lets get to the latest versions]|| 1|| Starting, done by Dec 10, very doable|| Mark/Qing|| ||
|-
|| Supported Targets|| ARM Platform Support|| Replace beagleboard with Beagleboard XM - decision || 2|| Done || Bruce|| alex|| Basic Yocto hardware support
|-
|| Distribution / components|| push of all relevant Wind River patchs to Yocto (patch comparison)|| Ensure patches present to packages in WRS are also in Poky|| 1|| WIP, on track for completion by Dec 03|| Mark|| Mark||
|-
|| Distribution / components|| Security Process|| We need a dedicated person to scan and apply critical security updates to the distro. The MeeGo team already has a similar process with some scripts which may be leveraged. To complete the task, the process should be documented and a first pass over the metadata made to establish the current position on security. Any upgrades needed should be identified and a plan to address them should be in place but doesn't have to be implemented by this point.|| 1|| Done || ScottG|| ktian1|| enhancement
|-
|| Tool Development and SDK Features|| SDK Generator Installer Opkg repo design|| Come up a opkg repo design that will mimic the final Yocto package repo layout to be used by SDK Generator Installer to test against|| 2 || Done || Jessica || jzhang ||
|-
|| Tool Development and SDK Features|| Yocto Installer tar creaion|| Create a Yocto Installer tar ball which contains Installer script and supported opkg component that will be used for installing other Yocto components|| 2 || Done || Jessica || jzhang ||
|-
|| Documentation|| Kernel Framework Paper from WR|| The paper from WR needs to be re-written and then posted somewhere on the Yocto Project site. This will involve examiniation of the text and re-writing and formatting for presentation. Currently it is simply a text document. Completion time assuming uninterrupted time is one week.|| High|| Done || Scott Rifenbark|| 1 Week|| Documentation
|-
|| Documentation|| Poky Reference Manual|| This guide exists in the 0.9 form. The re-write of the text needs to be completed. So far, all the chapters have been rewritten but not re-posted on the site. Only the appendices remain for a text scrub. Time to complete this would be a week of uninterrupted time. Ideally, the manual would be a sub-manual that would be referenced and architected into the Yocto Project Development Guide.|| Medium|| Done|| Scott Rifenbark|| 1 Week|| Documentation
|-
|| Kernel || Initial meta-linaro layer || meta-linaro layer providing a kernel, tool-chain, and uboot loader. This deliverable is primarily to get the infrastructure in place and have a buildable kernel. Toolchain on best effort basis. || || Done || Darren || dvhart || Moderate risk of slippage due to holidays.
|-
|| Kernel || Tracing: blktrace and sysprof recipes || || || Blktrace patch submitted, sysprof by Dec 03 || Tom || dvhart ||
|}

=== Sprint D (closes Dec 3, 11:59pm PDT -- pull request sent, initially reviewed) :: NOTE: week of the F2F planning meeting ===

{|border="1"
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''
|-
|| Tool Development and SDK Features|| Yocto Installer for SDK Generator Installation functions support||Detailed feature request can be found at: http://bugzilla.pokylinux.org/show_bug.cgi?id=589|| 1|| Initial implementation is done. Under review and refinement|| Jessica|| rpurdie|| Enhancement
|-
|| Kernel || Kernel git branching structure revamped || || 1 || Done || Bruce || dvhart ||
|-
|| Kernel || Tunnel Creek (Crown Bay) || || 1 || Done || Tom || dvhart ||
|}

=== Sprint E (closes Dec 9 (THURSDAY), 11:59pm PDT -- pull request sent, initially reviewed) ===

{|border="1"
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''
|-
|| Distribution / components|| Zypper/RPM|| Integration based on design from Sprint B|| 1|| slipped out from sprint D || Mark/Qing|| sgw|| Functionality
|-
|| Distribution / components|| Distro Audit: Upgrades Completed (Phase 1)|| Update to new versions as per the agreed plan for M2 from Sprint A|| 1|| WIP, will hold off on updates to Master during milestone build|| Saul|| rpurdie|| Continual Maintenance
|-
|| Distribution / components|| Distro Audit: Src Checksums|| Make sure all SRC_URI components have checksums too || 1|| WIP, Done by Dec 9 || Saul|| rpurdie|| Hygiene
|-
|| Poky Features || enable KVM with qemu|| today all new Intel processors support VT, which are enabled on most desktop machines which are most frequently used build machine. with VT support, x86/x86-64 qemu target runs faster which is a good thing for emulation environment. This may require some qemu option tweaks and also poky-qemu script enhancement. || 2|| on track|| Saul / Edwin|| ktian1|| Enhancement
|-
|| Poky Features || Performance Enhancement Completed || Initial changes to reduce disk space || 1|| on track being reviewed || Saul / Qing, Dongxiao || rpurdie|| Enhancement
|-
|| Distribution / components|| User specified qemu config support|| We'll provide user an edit box which allows advanced qemu user to specify arbitrary qemu configuration to meet their needs, which the poky-qemu scrip will just append the config list towards the end of the list of parameters to bring up qemu, it also expect the poky-qemu script to do some basic sanity check on the user specifications to catch the obvious mistake || 2|| on track for Dec 9 || Saul / criping || criping|| enhancement
|-
|| Documentation Features|| Package report system|| finish major feature development and internal review [setup a package report system in an internal machine. We need push it publicly available. The basic features like search and report have been there. But there're still some enhancements in plan, to make it a fit place to feel Yocto metadata comfortably]|| 2|| Push to Dec 17 for new sys admin || KevinT / Lei || ktian1|| enhancement
|-
|| Tool Development and SDK Features|| SDK Version Control support in SDK generator installer|| If we can expect that yocto SDK has lots of release in the future, we might need to consider SDK version control. Currently, if we un-tar the sdk, it will override the older version. It's not good for app developers since they might need the old version to do something. And also, maybe a finer installer than untar is preferred. Installer will tied to certain SDK version and the installation will go under /opt/poky-versionNo.|| 1|| on track || Jessica|| criping|| Enhancement-expect planning process by Jessica to handle this task.
|-
|| Kernel || New kernel recipes || dev, -devel, -custom || 3 || Done || Bruce || dvhart ||
|-
|| Kernel || Tracing: Initial SystemTap recipe || || 3 || on track || Tom || dvhart ||
|-
|| Swabber || Documentation for swabber || || 1 || on track || Alex || ||
|-
|| CCB || Defect triage process in public documented and implemented || || 1 || || Saul || ||
|}

== M3 (Dec 20 to Feb 08 -- Dev Complete Feb 04, Stabilize Complete Feb 11, Release Complete Feb 18) ==
=== Sprint A (closes Dec 24, 11:59pm PDT -- pull request sent, initially reviewed) ===

{|border="1"
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''
|-
|| Kernel || Initial meta-rt layer || PREEMPT_RT kernel and related test-cases and benchmarks || 2 || slipped out from M2 || Darren || dvhart ||
|-
|| Poky Features || Fetcher Overhaul|| "The highlight summary would be merging of the fetch and unpack tasks. This would mean we could put git checkouts directly into WORKDIR/git and do fetching/handling of SCM based checkouts much more efficiently as we'd no longer have to tar/untar but could do a referenced clone. WORKDIR could be made a directory without the revision in the name so when the version increments, the WORKDIR can just be updated by the SCM and rebuilt. I'd propose we rewrite the fetcher code as lib/bb/fetch2, then switch poky over to use it, leaving the fetch directory around until we can get to it. Related to this task is storing SRCREV knowledge from the recipes at parse time for access by the bitbake core, there is an open bug about this enhancement. We can then nuke the central revisions file in the distro directory which users hate. Also, the fetcher should be checking the validity of what it does - checksums for everything in SRC_URI except file:// and scm urls. "|| 1|| slipped out from M2 || Saul / Ke, RP|| rpurdie|| Enhancement
|-
|| Distribution / components|| Distro Audit Upgrades Planned (Phase 2)|| Complete plan for package upgrades in M2|| 1|| Review|| Saul|| || Continual Maintenance
|-
|| Distribution / components|| MACHINE or Recipe specific sysroots|| Each machine should have its own sysroot. We'll probably have to split do_populate_sysroot into a two step process, creation of the package and than installtion of the package, which the installation of the package being made machine specific (put ${MACHINE} into ${STAMP} and bitbake should do that). Also allowing this to work per recipe would be desireable|| 1|| Review|| Saul / Dongxiao || rpurdie|| Hygiene
|-
|| Distribution / components|| Toolchain Bootstrap Process|| The toolchain as it bootstraps overwrites files like libc.so and libgcc.so in the sysroot directory which causes issues if you just try and rebuild part of the toolchain. Each step of the bootstrap process should use a separate sysroot. Once this is once, sstate file overwriting detection can be added and enabled. || 1|| Review|| Saul / Dexuan || rpurdie|| Hygiene
|-
|| Poky Features || Pseudo Performance || Implement the changes to bitbake based on pseudo's enable/disable switch|| 1|| slipped from M2 due to risk and not having Pseudo's change yet. || Saul / Qing, Dongxiao || rpurdie|| Enhancement
|-
|| || Multilib Support|| || 1|| || Richard|| ||
|-
|| Validation|| Alpha testing complete|| 4-5 internal developers unfamiliar with Yocto Project try to do a build and report on the experience and issues encountered|| 1|| Accept|| PM|| davest||
|-
|| Tool Development and SDK Features|| Fix the issue user target sysroot is owned by root || The ADT installer will use pseudo to extract user target sysroot which ended up owned by root, this need to be fixed || 1|| Review|| Jessica|| jzhang|| Cleanup
|-
|| Tool Development and SDK Features|| Eclipse poky tree interfacing (metadata file editor)|| Provide a metadata file editor with some syntax checking and keywords highlight capabilities|| 2|| Review|| Jessica|| jzhang|| Enhancement
|-
|| Tool Development and SDK Features|| IDE Project templates|| Templates for various project types: Clutter GUI, Gtk+ GUI, to help developers get started quickly || 2|| Done|| Jessica|| josh|| Enhancement
|-
|| Tool Development and SDK Features|| push TCF/RSE patches upstream|| work with community to finish up our TCF terminal service, TCF/RSE integration remaining patches taken by upstream. Blocking issues including Eclipse Bug #327865 || 1|| Done || Jessica|| jzhang|| Enhancement
|-
|| Documentation|| ADT Reference Guide || Outline complete|| High|| WIP || Scott Rifenbark|| 3-4 Weeks|| Documentation
|-
|| Poky Features || libtool sysroot option|| libtool 2.4 has a sysroot option. We should try and use it, see how it works and whether we can ditch some of our libtool hacks. || 1|| on track, he is piggybacking on work that Khem Raj did on OE, push to M3SA || Saul / ScottG || rpurdie|| Enhancement
|-
|| Distribution / components|| perl upgrade|| perl is the most cross un-friendly recipe pending upgrade. || 2|| Slipping due to Linaro layer, moves to end of Sprint E || Nitin|| Nitin Kamble|| enhancement
|-
|| Kernel || Tracing: trace-cmd python binding cleanup || || 3 || || Darren || dvhart ||
|-
|| Kernel || Tracing: KernelShark, tuna, oscillosope recipes || || 3 || || Tom || dvhart ||
|-
|| Pseudo || Pseudo enhancement to enable on/off switch || || 1 || || Mark || ||
|-
|| Pseudo || Bitbake enhancement for pseudo on/off switch || || 1 || || Richard || ||
|-
|| Swabber || Complete review of swabber outputs || || 1 || || Alex || ||
|-
|| bugzilla || Complete restructure of bugzilla categories || || 1 || || Saul || ||
|-
|| Poky Features || Image creator ground work || Nomenclature determined, existing gui's bug fixed and backend work implemented || 1 || In progress || Joshua || ||
|-
|}

=== Sprint B (closes Jan 07, 11:59pm PDT -- pull request sent, initially reviewed) ===

{|border="1"
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''
|-
|| Distribution / components|| Distro Audit Documentation Output|| Audit package documentation output || 2|| Review|| Saul / ScottG || rpurdie|| Hygiene
|-
|| Poky Features || Bitbake multi-threaded parsing|| Bitbake recipe parsing is currently single threaded. I want to make this multithreaded as the speedup would be nice. If I can only take a single task for myself for 1.0, I'm nominating this one as I enjoy this kind of thing and I have ideas on how to do it. || 1|| Review|| Richard|| rpurdie|| Enhancement
|-
|| Distribution / components|| Lock in Kernel/Toolchain version|| || || || Richard|| ||
|-
|| Distribution / components|| License Update|| For each of the licences we support, I'd really like to have a licences directory with a copy of that license contained within. When it comes to deciding what a given LICENSE field means, this would be the reference. It also means we can include the licences a given image includes with the image. This continues to make our license handling world class and ahead of the field. || 2|| Review|| Beth|| rpurdie|| Hygiene
|-
|| Poky Features || DSO linking changes|| "By the default the gcc linker will automatically link any dependant objects/libraries. ""Inherited"" linkages can cause issues, for example, where a shared object changes its dependencies but a program has come to rely on symbols from an implicitly linked library. Fedora implemented this change in F13, seems like it would be useful to have in Poky too. "|| 2|| Review|| Saul / Nitin || josh|| bug#516
|-
|| Distribution / components|| rootless X|| rootless x server has better security than x server launched by root. MeeGo already enable this feature. it would be nice for Yocto to also enable it. || 2|| Review|| Saul / Ke || yuke|| enhancement
|-
|| Tool Development and SDK Features|| Qemu configuration change|| Provice edit box for advanced user to specify qemu configurations|| 2|| Accept|| Jessica|| criping||
|-
|| Tool Development and SDK Features|| Eclipse Poky tree interfacing (bitbake commands support)|| Support user run bitbake commands within CDT console|| 2|| Review|| Jessica|| jzhang|| Enhancement
|-
|| Tool Development and SDK Features|| Lock down Eclipse+CDT+TCF version|| || 1|| Accept|| Jessica|| ||
|-
|| Tool Development and SDK Features|| Eclipse poky tree interfacing (git support)|| Use Eclipse git capability to install poky tree from git repo and able to interact with git repo at file level within Poky tree || 2|| Review|| Jessica|| jzhang|| Enhancement
|-

|| Documentation|| Migration chapter in the Poky Reference Manual|| This chapter would cover the four identified use-cases for migrating up to the most recent version of Yocto Project. Additionally, it would cover migration scenarios from other development systems. The chapter does not yet exist. The chapter has not been scoped outside of having a meeting that identified four use-cases that did not include migration from a development system outside of Yocto Project. It will take some more scoping time to cover those areas (a day or two). Again, I have no idea of the length. See earlier entries for standard industry writing estimates for software documentation|| Medium|| Not Started|| Scott Rifenbark|| 3-4 Weeks|| Documentation
|-
|| Supported Targets|| Intel Platform Support|| JasperForest|| 2|| Accept|| Tom|| davest|| Basic ECG support (Moved from Sprint A)
|-
|| Demo|| Finalize on demo plans for v1.0 launch || || 1|| Accept|| Dave || ||
|-
|| Release || Release plans for v1.0 launch || Fill out the M4 plan with the necessary release activities and timings || 1|| initial documentation in RFC process || Beth || ||
|-
|| Poky Features || Basic image creator GUI || Functional UI missing some Advanced features || 1 || accepted || Joshua || ||
|}

=== Sprint C (closes Jan 14, 11:59pm PDT -- pull request sent, initially reviewed) ===

{|border="1"
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''
|-
|| Poky Features || Poky Image Creator|| A standalone application you can run which asks you to select a distro and machine, then presents a list of packages you can select. Once the selection is made, it goes off and bakes you an image which is then presented to you. Implementation wise, it should use the sstate packages, be a bitbake UI and use the usual poky bbclass files to do the image construction behind the scenes. || 1|| Accepted || Joshua|| rpurdie|| Enhancement
|-
|| Validation|| Boottime/Performance Analysis|| Compare Yocto Project performance to other projects such as MeeGo|| 1|| Review|| Tom|| davest|| project commitment
|-
|| Distribution / components|| LSB Sanity|| execute LSB Test and improve passing rate and document failures with clear understanding|| 2|| Review|| MarkH/Saul|| sgw|| Hygiene
|-
|| Distribution / components|| Review & Fix Standards Tests|| Review the results from LTP, POSIX and asses the result, fix as appropriate and clearly document failures.|| 2|| Review|| Saul|| sgw|| Hygiene
|-
|| Tool Development and SDK Features|| (Bitbake commander)Poky tree interfacing integration|| Integrate all the features to support poky tree interfacing withing Eclipse IDE: poky tree install from git repo, edit metadata file using editor, commit back changes to git repo, and run bitbake commands withing CDT console|| 2|| Review|| Jessica|| jzhang|| Enhancement
|-
|| Kernel || Tracing: perf trace marger support || This is from feedback to the new trace command. Ingo appears to have this nearly complete already. || 3 || || Darren || dvhart ||
|-
|| Kernel || Tracing: perf trace scripting support || || 3 || || Tom || dvhart ||
|-
|| Cleanup || bitbake user experience error handling validation completed || || 2 || || Richard || ||
|-
|| Cleanup || variable scrub - ensure all metadata variables are documented || || 2 || || Scott/Darren || ||
|}

=== Sprint D (closes Jan 21, 11:59pm PDT -- pull request sent, initially reviewed) ===

{|border="1"
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''
|-
|| Documentation Features|| Package report system|| move to public server [setup a package report system in an internal machine. We need push it publicly available. The basic features like search and report have been there. But there're still some enhancements in plan, to make it a fit place to feel Yocto metadata comfortably]|| 2|| Review|| KevinT|| ktian1|| enhancement
|-
|| Distribution / components||Add headers and libraries to qemu images ||Since we'll be using qemu images as target sysroot, need to create a set of qemu images for minimal, sato, LSB that contains target header and libraries.|| 2|| Review|| Saul ||jzhang|| Enhancement
|-
|| Distribution / components|| push of all relevant Wind River patchs to Yocto (patch comparison)|| Update any additional patches needed since M2.|| 1|| Review|| Mark|| Mark||
|-
|| Distribution / components|| mklibs|| mklibs is a tool to optimize size of [e]glibc for a perticular root file system image. It is useful to save disk space on small devices. || 2|| Review|| Saul|| Nitin Kamble|| enhancement
|-
|| Distribution / components|| performance indicators|| define some indicators (boot time, footprint, build time, power, component benchmarks, etc.) and then collect them for tracking purpose. The result could be posted on the wiki site, and the initial indicators can be easy ones which can be easily retrieved from autobuilder or weekly qa report). This way we have a clear track about the healthy of the Yocto project, and also identify weak areas. We can include qemu targets and several representational boards as the targets. || 2|| Review|| Beth/Jiajun|| ktian1|| enhancement
|-
|}

=== Sprint E (closes Jan 28, 11:59pm PDT -- pull request sent, initially reviewed) ===

{|border="1"
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''
|-
|| Supported Targets|| Intel Platform Support|| Sandybridge|| 2|| Accept|| Tom|| davest|| Basic ECG support
|-
|| Tool Development and SDK Features|| SDK user workshop|| Have some developers sit down and use our tools to develop demo software for Yocto. || 2|| Review|| Jessica|| josh|| Enhancement
|-
|| Documentation|| SDK Reference Guide|| This would be a guide for developers using the SDK. Ideally, the manual would be a sub-manual that would be referenced and architected into the Yocto Project Development Guide. The manual has not been scoped and would take a week to scope. I have no idea of the length. Industry writing standards dictate that three to four pages of a manual can be developed per day. So, a 30 to 40 page manual would take a couple of weeks. However, these are just standards that are use for general estimates and assume dedicated, non-interrupted time.|| High|| Not Started|| Scott Rifenbark|| 3-4 Weeks|| Documentation
|-
|| Kernel || Final linux-yocto_git.bb || With 2.6.37 kernel || 1 || || Bruce || dvhart ||
|-
|| Kernel || Final meta-linaro layer || || || || Darren || dvhart ||
|-
|| Kernel || Final meta-rt layer || || || || Darren || dvhart ||
|-
|| Kernel || Sandy Bridge || || 1 || || Tom || dvhart ||
|}

=== Sprint F (closes Feb 03 (THURSDAY), 11:59pm PDT -- pull request sent, initially reviewed) :: NOTE: China New Year Holiday ===

{|border="1"
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''
|-
|| || || || || || || ||
|}

== M4 (Feb 07 to Apr 15 -- Stabilize Complete Mar 18, Release Complete Apr 01, Contingency to Apr 15) ==

This sprint is the [[Yocto Project v. 1.0 Release Cycle]].

{|border="1"
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''
|-
|| Documentation|| Yocto Project Development Guide|| This manual would be an over-arching document that frames the complete development cycle within Yocto Project. The idea here is that the document would be an umbrella document that spawned and referenced subsequent documents. The organization would be the first chapter overviewing the major development pieces such as recipe creation, building, debugging, publishing, fail-safing, back-door hook creation, etc. Scoping would be about two weeks and length would probably be about 40 pages. Overall development time would likely be a month of uniterruped time.|| Medium|| Not Started|| Scott Rifenbark|| 3 Weeks|| Documentation
|-
|| || || || || || || ||
|}

== Features needed and to be put into sprints by assigned owners: ==

{|border="1"
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''
|-
|| Poky Features || package config option enhancement|| there're several enhancements we may do here: * allow users setting specific config options (local or global) from external tool, such as poky image creator, instead of changing recipes manually. Need a mechanism to convert from variable assignments into exact config options (e.g. feature_${PN} = ""1"" -> ""--enable-feature""). Consequently dependency chain needs update with option status. * host contamination check. We have swabber to check host contamination, but I'm not sure whether it covers configuration phase. If not, this is one area to improve, as not ususually we see configure script checks host bits for available features * conditional option manipulation. In many recipes we enable/disable one option based on availability of other packages. Now this is done manually and not flexible. this should be made automatically though some new annotation to indicate condition, or just base_contains (not convenient: long line, need define distro features) || 2|| Review|| Richard/MarkH|| ktian1|| Enhancement
|-
|| Media|| Yocto Project Awareness Video|| This 2.5 minute video would introduce and describe the benefits of Yocto Project. The video would use entertaining animations that described concepts and benefits. The result would be suitable for YouTube, conferences, and the website. The production is called an "Epipheo" and will be created by Epipheo Studios. The engagement process has begun and the kick-off meeting will be soon. The PO is in place. Time for development is 10 weeks.|| High|| Kick-off Imminent|| Scott Rifenbark|| 10 Weeks|| Media
|-
|| Documentation|| Yocto Project Debugging Guide|| This would be a guide for the debugging and bug tracking process in Yocto Project. Originally, the thought was that we needed a Bugzilla User's Manual. However, since we don't own Bugzilla it doesn't make sense to produce documentation for it. Rather, we should document the process as it fits into the Yocto Project environment. Ideally, the manual would be a sub-manual that would be referenced and architected into the Yocto Project Development Guide. The manual has not been scoped and would take a week to scope. Again, I have no idea of the length. See the previous item for standard industry writing estimates for software documenation.|| Medium|| Not Started|| Scott Rifenbark|| 3-4 Weeks|| Documentation
|-
|| Website|| Yocto Project Website|| The 0.9 website is in place but needs updates. Items for consideration are the left-panel naviagation scheme, a contributions guidance page, color-scheming and theme (possibly).|| Medium|| Not Started|| Scott Rifenbark|| 1-2 Weeks|| Website
|}

== Features not believed to be needed in v1.0: ==

{|border="1"
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''
|-
|| Poky Features || OpenEmbedded/Bitbake Upstreaming|| "We firstly need to review where we are and where OE is. We then need to make a plan about what we're going to push upstream and what we're not. I'd suggest when we're in PRC, we do a crash course in ""dealing with OE"" and then many dedicate a block of time (a week) where the distro team comes up with a patch set we then propose and get merged into OE. I'd like to find a couple of interested people to monitor OE more regularly and start a workflow of things between Poky/OE where appropriate. The key thing to remember is we need to keep the architectures compatible. The team is now at the point where I'm happy for them to actually try building OpenEmbedded and not worry about it tainting them! "|| 2|| Review|| || rpurdie|| Process
|-
|| Poky Features || Handle old versions in WORKDIR|| an incremental build directory may finally include many old versions WORKDIRS. It'll be good to have those old versions tracked in the cache, which can then either generate a report or allow selectively cleaning up an specific version WORKDIR. Or else it's difficult to figure it out when people want to keep the whole tmp directory but like to cleanup some old bits when disk usage is under pressure. If it's not easy to do in bitbake, perhaps some separate scripts would be also helpful || 3|| Review|| || ktian1|| Enhancement
|-
|| Poky Features || run bitbake w/o rebuilding the cache|| "sometimes it's useful to allow run bitbake w/o re-parsing recipes, if we know nothing metadata is changed. we can just allow reusing existing persistent cache. this is useful when people is debugging WORKDIR w/o metadata change. also sometimes ""bitbake -e"" is used frequently to check poky variable information. with existing cache, several seconds can be saved which are not negligible for a developer daily working on Yocto "|| 2|| Review|| || ktian1|| Enhancement
|-
|| Poky Features || parallel make improvement|| parallel make experience is not good, especially when bb threads and make threads are increased larger than 8. So far we either try to fix package makefile or mark the recipe as no parallel make, when build faiures are reported. But this greatly impacts user experience for a successfully continuous build process. Could we define a safe number we do want to support for 1.0 release? and then have our autobuilder, QA test, and developers cover that number immediately and fix any issues accordingly. Then the safe number can be suggested to the Yocto user || 2|| Review|| || ktian1|| Enhancement
|-
|| Poky Features || Dependency packages rebuild/clean|| It is a mechanism to rebulid or clean a package and all other packages which have build/runtime dependency on it. With this change, we can find potential influences of package upgrade to its related packages, which can make the incremental build more trustable. For example, if we upgrade a package to a new vesion which changes its API, this mechanism can easily find out the incompatibility to other packages which have dependency on it. || 2|| Review|| || dongxiao.xu|| Enhancement, replaced by checksum feature
|-
|| Distribution / components|| FOSSology|| This may be similar to License Update above, but start to use FOSSology to track licenses. || 2|| Review|| || sgw|| Hygiene
|-
|| Distribution / components|| Package Developer Tools|| Create a set of Init scripts template and then review our current init scripts and modify them to confirm to the template. || 2|| Review|| || sgw|| Easy of Use
|-
|| Distribution / components|| Package Website|| Complete the work the intern has started on generating the distro tracking information and get it out on the external site. || 2|| Review|| || sgw|| "Hygiene, duplicate of ""Package report system"""
|-
|| Distribution / components|| Bluetooth UI support|| Currently we have bluez package in poky, and we need to have a workable graphic user interface to connect/configure BT devices. One choice may be gnome-bluetooth-applet. || 3|| Review|| || dongxiao.xu|| enhancement
|-
|| Distribution / components|| Connman-gnome enhancement features|| Enable connman-gnome to support features like, WPA Enterprise connection, hidden SSID, etc. || 3|| Review|| || dongxiao.xu|| enhancement
|-
|| Distribution / components|| Java Running Environment support|| Since most embedded systems support java applications running in it, maybe we'd better consider supporting some kinds of JVMs(Embeded JVM). The JVM may not run by default, but user can launch it if running java applications. Compared with GTK/QT, java user number is not small too. || 3|| Review|| || criping|| enhancement
|-
|| Distribution / components|| create more use cases|| UPnP demo is one really good use case showing how Yocto is utilized to make real functionality. and we could create more to show how Yocto is easily adapted to real use cases. Those use cases can be either maintained as seperate demo layers in yocto repo, or in seperate branches for reference. We can also call for community's contribution on this which would make 1.0 full-fledged. Or else the newbies to Yocto may be in puzzle how our sample profiles can satisfy their requirements. || 2|| Review|| || ktian1|| enhancement
|-
|| Distribution / components|| i18n support || internationalization is an important system wide feature. Many component like font, locale affect the i18n. Yocto alreay has some i18n related package like pango, but so far did not consider i18n systematically. so this is place holder to systematically add i18n support. || 2|| Review|| || yuke/qing|| enhancement
|-
|| Distribution / components|| more demos || demos are a good way to educate, push the envelope, and at the same time tout the strengths of the platform. This item just records a current set of ideas from various sources which could/should be implemented: * face-recognition/face-finding, * robotic control/application of face-finding to 'camera-as-sensor' (hexbug demo), * others [tbd, add here]|| 2|| Review|| || tzanussi|| enhancement
|-
|| Tool Development and SDK Features|| Yocto Installer support for image-creator and needed yocto-metadata design||Come up design what need to be created as packages to support using "opkg install" for image-creator and needed yocto-metadata|| 2|| WIP, pending comments from RP regarding how to packaging metadata|| Jessica|| rpurdie|| Enhancement
|-
|| Tool Development and SDK Features|| Yocto Installer image-creator and needed poky-metadata support|| The poky build system will build packages for image-creator and needed poky-metadata, which the Yocto Installer will be able to use "opkg install" to install them|| 2|| Review|| Jessica|| rpurdie|| Enhancement
|-
|| Tool Development and SDK Features|| Provide qemu management UI|| In current eclipse plugin, QEMU settings are put together with project configuration. So we can only have limited settings. If we can have a separate QEMU management UI, the end user could firstly create a QEMU config, such as (env file of arch, image location, unfs or not, sato or lsb, mem size, disk size). And then he can launch a QEMU with a specific config. The dependency between project configuration and QEMU config will be resolved. After all QEMU has nothing to do project configuration. Need to careful review the UI to ensure minimal impact to testing matrix. || 3|| Review|| || criping|| "Enhancement, duplicate of ""Qemu mem/disk size can be adjusted"""
|-
|| Tool Development and SDK Features|| QT plugin For Eclipse|| Integrate QT Ecplise plugin and extend for Yocto Project || 3|| Review|| || jzhang|| Enhancement
|-
|| Tool Development and SDK Features|| Profiling/Trace GUI's|| We have a wealth of great tracing and profiling tools but the UI's for them are all extremely minimal and usually quite ugly. Would be great if we could compete with, or even better, Apple's offerings here. We have the technology! || 2|| Review|| || josh|| "Enhancement, duplicate of ""Tracing/Profiling Planning Complete"""
|-
|| Tool Development and SDK Features|| Other profiling tools|| Complete Tom's review of profiling tools and architecture || 2|| Review|| || josh|| "Enhancement, duplicate of ""Tracing/Profiling Planning Complete"""
|-
|| Tool Development and SDK Features|| Design next-gen tracing/profiling tools|| Yocto 1.0 will include all the essential existing tracing/profiling tools expected by users, and Josh has proposed a UI integration of all those tools as far as it's possible to do so. That level of integration, basically a 'plugin-level' integration is necessary and useful, but doesn't go far enough. A next-generation tracing tool would integrate at a much more fundamental level; if done properly, it would provide unmatched levels of power and usability to users, and would allow Yocto to distinguish itself in the embedded tracing/profiling space in a way also unmatched by any other distro/build-tool. The implementation would of course not be available for Yocto 1.0, but a coherent design, including prototypes, that could be taken to the community and implemented in a V 1.5 or 2.0 should be done in that time frame. || 1|| Review|| || tzanussi|| "Enhancement, duplicate of ""Tracing/Profiling Planning Complete"""
|-
|| Documentation Features|| Self Documentation of image contents|| "I'd like to see the -doc packages Poky builds being combined into some kind of large documentation index representing the collective API docs of the target being built. This can then be placed on a webserver and viewed over the web. We'd have a demonstration of this for a ""bitbake world"" target. Part of the idea here is to start making good use of the docs as if developers see this they might start writing better docs too. Aim is to lead the field :). There are a number of places poky packages disable doc generation due to missing tools so we'd need to add these so we can enable the doc generation. Many packages already have many docs though too. "|| 2|| Review|| || rpurdie|| enhancement
|-
|| Validation|| Testing Framework|| Add a framework for doing automated testing in the project|| 1|| Review|| || davest|| project commitment
|-
|| Validation|| more SDK builds on autobuilder|| enable more SDK related tests on autobuilder such as meta-ide-support, etc.|| 2|| Review|| || ktian1|| project commitment, addressed by test plan (?)
|-
|| Validation|| more people should try using SDK|| this may not be a feature, but a requirement. SDK including meta-toolchain is one key factor impacting user experience on Yocto. It's not enough to have only SDK team play with it|| 2|| Review|| || ktian1|| project commitment, addressed by test plan (?)
|-
|| Validation|| Unit Testing Framework|| Add a mechanism to bitbake to parse source packages that have unit tests and then execute them on the target|| 3|| Review|| || sgw|| "project commitment, duplicate of ""Testing Framework"""
|-
|| Validation|| Test Case open source|| Open source Yocto test cases with xml format|| 1|| Review|| || yyou|| "project commitment, duplicate of ""Testing Framework"""
|}

Yocto Project Roadmap

2010-12-07T14:48:28Z

Scottrifw:

=== Yocto Project 1.0 – target release date, April 2011 ===

'''Theme''' – Improved Developer Experience

* Bugs fixed from 0.9 resulting in a better "out-of-box experience"
* Linux 2.6.37
* gcc 4.5.x, where x = 1 or 2
* New layer that supports the Linaro toolchain and kernel
* Yocto Image Creator
* Improved build performance over 0.9
* Improved fetcher
* Additional kernel tracing features for the target
* Improved documentation – for kernel tools and application development
* Yocto Eclipse plug-in improvements and demo videos
* Application development tools installation script
* Board Support Packages (BSPs) for additional embedded platforms

=== Post 1.0 – target release date, fall 2011 ===

* Bitbake Commander

Development Methodology

2010-12-07T14:44:46Z

Scottrifw:

The project will be managed as a series of 6-week milestones. The milestones will be broken out as follows:

* 1 week – planning for this milestone
* 4 weeks – development
* 1 week – stabilization
* 1 week – release

(The above time adds up to more than 6 weeks due to the planning week overlapping the release week).

The final project milestone is 4 weeks of stabilization and release.

At the end of each milestone there is a milestone release that:

* has been stabilized, with bugs tracked and showstoppers fixed
* has had some amount of QA applied beyond the nightly sanity test
* can demonstrate some feature or features

Milestones are divided into week-long "Sprints." This division prevents all of a milestone's functionality from hitting at the end of the milestone and causing a collision. Project developers must respect these divisions. it gives the maintainers a break.

Processes and Activities

2010-11-10T21:14:07Z

Scottrifw:

Welcome to the Processes and Activities Page!

* [[Best Known Methods (BKMs) for Package Updating]]
* [[Working Behind a Network Proxy]]
* [[SDK Generator]]
* [[QA]]
* [[Kernel]]
* [[Core]]
* [[Bugzilla Configuration and Bug Tracking]]
* [[Yocto Release Engineering]]

Processes and Activities

2010-11-10T21:12:26Z

Scottrifw:

Welcome to the Processes and Activities Page!

* [[Best Know Methods (BKMs) for Package Updating]]
* [[Working Behind a Network Proxy]]
* [[SDK Generator]]
* [[QA]]
* [[Kernel]]
* [[Core]]
* [[Bugzilla Configuration and Bug Tracking]]
* [[Yocto Release Engineering]]

Processes and Activities

2010-11-10T19:04:01Z

Scottrifw:

Welcome to the Processes and Activities Page!

* [[BKMs for Package Updating]]
* [[Working Behind a Network Proxy]]
* [[SDK Generator]]
* [[QA]]
* [[Kernel]]
* [[Core]]
* [[Bugzilla Configuration and Bug Tracking]]
* [[Yocto Release Engineering]]

Processes and Activities

2010-11-10T18:35:00Z

Scottrifw: Undo revision 271 by Scottrifw (Talk)

Welcome to the Processes and Activities Page!

* [[BKMs for Package Updating]]
* [[Best Known Methods (BKMs) for Package Updating]]
* [[Working Behind a Network Proxy]]
* [[SDK Generator]]
* [[QA]]
* [[Kernel]]
* [[Core]]
* [[Bugzilla Configuration and Bug Tracking]]
* [[Yocto Release Engineering]]

Processes and Activities

2010-11-10T18:30:51Z

Scottrifw:

Best Known Methods (BKMs) for Package Updating

2010-11-10T18:30:15Z

Scottrifw: Created page with 'This page is used for capturing the Best Known Methods (BKMs) of package upgrading as we get reviewed and process more of the packages. ==Don't Retain older Versions== Unless t…'

This page is used for capturing the Best Known Methods (BKMs) of package upgrading as we get reviewed and process more of the packages.

==Don't Retain older Versions==

Unless there is a specific need (which will probably occur for GPLv2, this has also happened in the past when platforms have known bugs in the latest version) don't retain older versions of the recipe files and patches.

== Use git mv to rename recipe and patches ==

From Josh:
Generally the way I perform recipe upgrades is to use git mv to rename the old file to the new version, this means that you don't have to consciously delete the old version later (win 1) and that git tracks the rename and the differences with the old file, which doesn't happen with a delete and add (win 2).

The advantage of this is that you and any reviewers can more easily see what has changed with the updated version of the recipe.

Nitin: Actually {git mv a b} is nothing but {mv a b; git rm a; git add b} And the file renames are detected by git automatically by looking at the file contents. Because of this git behavior, git shows some renames as renames and sometimes not. And I did not find a way to force git to understand renames. So if after "git mv" git is showing "file add & file remove", then don't get surprised, it's normal git operation.

=== Reset PR to 0 (or add PR) when upgrading recipes ===

This is a good visual reminder to bump in the future if needed.

== For upgrades it's ok to use OE for inspiration ==

When upgrading packages, do the git mv as above, and build if it breaks, it's OK to check the OE equivalent and grab new patch or configuration change, just don't grab the whole recipe.

Be sure to add a credit to OE in your commit message when you do take a change like this.

Review: [[Merging packages from OpenEmbedded]]

== For new package grab OE version, but sanitize them ==

Follow the recipe rules for Yocto when you take an OE recipe, be sure to clean all the OE'isms out

Again, give credit to OE in commit messages

Review: [[Merging packages from OpenEmbedded]]

== Do NOT Merge .inc / .bb files ==

This was a decision that slipped by me, and was not communicated well, we do not want to merge the common ".inc" files and recipe (.bb) files. This is the case even if the .bb only contains a require and a PR="r0" line. This does not mean split everything at this point, but don't merge going forward.

== White Space Management ==

* Most variables such as SRC_URI should use spaces.

* Shell functions should use tabs

* Python functions should use spaces (4 spaces per indent).

== Commenting in Patches ==

When you change or add patches, be sure to include attributions of where the patch came from, along with your full name and email similar to "Signed-off-by", no special tag is needed (yet?), but having your full name and email is important to track it.

== New style patch application ==

The patch and pnum parameters have been renamed to the more logical apply and striplevel. The apply parameter takes either "yes" or "no" and the striplevel parameter takes an integer (0, 1, etc).

Both parameters are now optional with "sane" defaults.

The apply parameter is optional for SRC_URI lines with patch or diff extensions, which will default to being applied.

The striplevel parameter is also optional with a default striplevel of 1.

Old style parameters (patch and pnum) will continue to work for some time but it would be useful to move to the new style syntax as people are updating other parts of their recipes.

Therefore a patch line would be changed from:

file://some.patch;patch=1;pnum=2

to:

file://some.patch;striplevel=2

and a patch line:

Processes and Activities

2010-11-10T18:29:46Z

Scottrifw:

Processes and Activities

2010-11-10T18:26:25Z

Scottrifw: Undo revision 267 by Scottrifw (Talk)

Processes and Activities

2010-11-10T18:22:08Z

Scottrifw: