<?xml version="1.0"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
	<id>https://wiki.yoctoproject.org/wiki/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=Trevor+Woerner</id>
	<title>Yocto Project - User contributions [en]</title>
	<link rel="self" type="application/atom+xml" href="https://wiki.yoctoproject.org/wiki/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=Trevor+Woerner"/>
	<link rel="alternate" type="text/html" href="https://wiki.yoctoproject.org/wiki/Special:Contributions/Trevor_Woerner"/>
	<updated>2026-05-07T11:41:27Z</updated>
	<subtitle>User contributions</subtitle>
	<generator>MediaWiki 1.39.5</generator>
	<entry>
		<id>https://wiki.yoctoproject.org/wiki/index.php?title=YoctoProject_Summit_yps2023.11&amp;diff=86078</id>
		<title>YoctoProject Summit yps2023.11</title>
		<link rel="alternate" type="text/html" href="https://wiki.yoctoproject.org/wiki/index.php?title=YoctoProject_Summit_yps2023.11&amp;diff=86078"/>
		<updated>2023-11-23T15:15:25Z</updated>

		<summary type="html">&lt;p&gt;Trevor Woerner: /* Organizing Committee */ oops! fix alphabeticalization&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= The Yocto Project Summit 2023.11 =&lt;br /&gt;
The Yocto Project Summit, yps2023.11, is a virtual conference from November 28th to 30th, 2023 to gather members of the Yocto Project community together to discuss ideas and present information related to The Yocto Project.&lt;br /&gt;
&lt;br /&gt;
== Organizing Committee ==&lt;br /&gt;
The organizing committee consists of (alphabetical by first name):&lt;br /&gt;
* David Reyna&lt;br /&gt;
* Josef Holzmayr-Khosh Amoz (YP Community Manager)&lt;br /&gt;
* Megan Knight (Advocacy Manager)&lt;br /&gt;
* Philip Balister&lt;br /&gt;
* Trevor Woerner&lt;br /&gt;
&lt;br /&gt;
== Registration ==&lt;br /&gt;
&lt;br /&gt;
Registration Link: https://cvent.me/YLyoQz&lt;br /&gt;
&lt;br /&gt;
== Platforms ==&lt;br /&gt;
In terms of platforms we&#039;re using:&lt;br /&gt;
* pretalx for the CfP and schedule&lt;br /&gt;
* the LF&#039;s cvent for registration&lt;br /&gt;
* Zoom for the conference video&lt;br /&gt;
* irc for the conference chat (channel #yocto-summit-2023.11 on Libera.Chat)&lt;br /&gt;
* Digital Ocean for the hands-on classes&lt;br /&gt;
&lt;br /&gt;
== Hands-on Servers Information (Pre-event Preparation) ==&lt;br /&gt;
# If you already have a Digital Ocean account, skip the next 2 steps&lt;br /&gt;
# To create a Digital Ocean account, please sign up @ [https://do.co/yoctoproject DigitalOcean] &lt;br /&gt;
# Confirm your email and add a payment method to satisfy abuse requirements - you won&#039;t be charged unless you leave the training machine running long past the summit&lt;br /&gt;
# Visit https://cloud.digitalocean.com/account/api/tokens and generate a new token named &#039;&#039;&#039;YPSummit&#039;&#039;&#039;, and copy the string that pops up.&lt;br /&gt;
# Please complete this [https://forms.gle/53NFyCRaEpmRWuaa8 form] so your API key can be added to the provisioning scripts and we can top up your account credit.&lt;br /&gt;
&lt;br /&gt;
After the form has been filled by all participants we will provision machines. When the machines are ready logins will be &amp;quot;ssh ilab01@AXAXAXA-summit.yocto.io&amp;quot; where AXAXAXA are the first 7 characters of your confirmation string. The password is the full 11 character confirmation string.&lt;br /&gt;
&lt;br /&gt;
Once you have a verified working server you may delete your api key at https://cloud.digitalocean.com/account/api/tokens. Otherwise all resources will be removed after the training. Any retained servers will be billed to you after the promotional credit expires in 60 days.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;!-- Lab files are available during the event at http://summit.yocto.io/yps2023.11.tgz --&amp;gt;&lt;br /&gt;
Lab files will be available for download once the event begins.&lt;br /&gt;
&lt;br /&gt;
== For more information ==&lt;br /&gt;
* https://yoctoproject.org/event/yocto-project-summit-2023-11/&lt;br /&gt;
* https://pretalx.com/yocto-project-summit-2023-11/&lt;br /&gt;
&lt;br /&gt;
== Slide template for presenters ==&lt;br /&gt;
* https://docs.google.com/presentation/d/1ttXgB8Z1gasL7ItCYZ-uXT_FmfnIgPoMK_JtjvBrj1g&lt;br /&gt;
** keep the first and last slides&lt;br /&gt;
** edit the first slide to include your name, presentation title, and (optionally) your company&lt;br /&gt;
** the rest of the slides are examples and can be duplicated, edited, and/or removed&lt;br /&gt;
** please upload your finished slides to your specific event in pretalx&lt;/div&gt;</summary>
		<author><name>Trevor Woerner</name></author>
	</entry>
	<entry>
		<id>https://wiki.yoctoproject.org/wiki/index.php?title=YoctoProject_Summit_yps2023.11&amp;diff=86065</id>
		<title>YoctoProject Summit yps2023.11</title>
		<link rel="alternate" type="text/html" href="https://wiki.yoctoproject.org/wiki/index.php?title=YoctoProject_Summit_yps2023.11&amp;diff=86065"/>
		<updated>2023-11-07T21:07:30Z</updated>

		<summary type="html">&lt;p&gt;Trevor Woerner: /* Organizing Committee */ add Philip&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= The Yocto Project Summit 2023.11 =&lt;br /&gt;
The Yocto Project Summit, yps2023.11, is a virtual conference from November 28th to 30th, 2023 to gather members of the Yocto Project community together to discuss ideas and present information related to The Yocto Project.&lt;br /&gt;
&lt;br /&gt;
== Organizing Committee ==&lt;br /&gt;
The organizing committee consists of (alphabetical by first name):&lt;br /&gt;
* David Reyna&lt;br /&gt;
* Josef Holzmayr-Khosh Amoz (YP Community Manager)&lt;br /&gt;
* Philip Balister&lt;br /&gt;
* Megan Knight (Advocacy Manager)&lt;br /&gt;
* Trevor Woerner&lt;br /&gt;
&lt;br /&gt;
== Platforms ==&lt;br /&gt;
In terms of platforms we&#039;re using:&lt;br /&gt;
* pretalx for the CfP and schedule&lt;br /&gt;
* the LF&#039;s cvent for registration&lt;br /&gt;
* Zoom for the conference video&lt;br /&gt;
* irc for the conference chat (channel #yocto-summit-2023.11 on Libera.Chat)&lt;br /&gt;
* Digital Ocean for the hands-on classes&lt;br /&gt;
&lt;br /&gt;
== Hands-on Servers Information (Pre-event Preparation) ==&lt;br /&gt;
# If you already have a Digital Ocean account, skip the next 2 steps&lt;br /&gt;
# To create a Digital Ocean account, please sign up @ [https://do.co/yoctoproject DigitalOcean] &lt;br /&gt;
# Confirm your email and add a payment method to satisfy abuse requirements - you won&#039;t be charged unless you leave the training machine running long past the summit&lt;br /&gt;
# Visit https://cloud.digitalocean.com/account/api/tokens and generate a new token named &#039;&#039;&#039;YPSummit&#039;&#039;&#039;, and copy the string that pops up.&lt;br /&gt;
# Please complete this [https://forms.gle/53NFyCRaEpmRWuaa8 form] so your API key can be added to the provisioning scripts and we can top up your account credit.&lt;br /&gt;
&lt;br /&gt;
After the form has been filled by all participants we will provision machines. When the machines are ready logins will be &amp;quot;ssh ilab01@AXAXAXA-summit.yocto.io&amp;quot; where AXAXAXA are the first 7 characters of your confirmation string. The password is the full 11 character confirmation string.&lt;br /&gt;
&lt;br /&gt;
Once you have a verified working server you may delete your api key at https://cloud.digitalocean.com/account/api/tokens. Otherwise all resources will be removed after the training. Any retained servers will be billed to you after the promotional credit expires in 60 days.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;!-- Lab files are available during the event at http://summit.yocto.io/yps2023.11.tgz --&amp;gt;&lt;br /&gt;
Lab files will be available for download once the event begins.&lt;br /&gt;
&lt;br /&gt;
== For more information ==&lt;br /&gt;
* https://yoctoproject.org/event/yocto-project-summit-2023-11/&lt;br /&gt;
* https://pretalx.com/yocto-project-summit-2023-11/&lt;br /&gt;
&lt;br /&gt;
== Slide template for presenters ==&lt;br /&gt;
* https://docs.google.com/presentation/d/1ttXgB8Z1gasL7ItCYZ-uXT_FmfnIgPoMK_JtjvBrj1g&lt;br /&gt;
** keep the first and last slides&lt;br /&gt;
** edit the first slide to include your name, presentation title, and (optionally) your company&lt;br /&gt;
** the rest of the slides are examples and can be duplicated, edited, and/or removed&lt;br /&gt;
** please upload your finished slides to your specific event in pretalx&lt;/div&gt;</summary>
		<author><name>Trevor Woerner</name></author>
	</entry>
	<entry>
		<id>https://wiki.yoctoproject.org/wiki/index.php?title=YoctoProject_Summit_yps2023.11&amp;diff=86064</id>
		<title>YoctoProject Summit yps2023.11</title>
		<link rel="alternate" type="text/html" href="https://wiki.yoctoproject.org/wiki/index.php?title=YoctoProject_Summit_yps2023.11&amp;diff=86064"/>
		<updated>2023-11-07T21:05:03Z</updated>

		<summary type="html">&lt;p&gt;Trevor Woerner: initial commit, copied from yps2022.11 and tweaked&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= The Yocto Project Summit 2023.11 =&lt;br /&gt;
The Yocto Project Summit, yps2023.11, is a virtual conference from November 28th to 30th, 2023 to gather members of the Yocto Project community together to discuss ideas and present information related to The Yocto Project.&lt;br /&gt;
&lt;br /&gt;
== Organizing Committee ==&lt;br /&gt;
The organizing committee consists of (alphabetical by first name):&lt;br /&gt;
* David Reyna&lt;br /&gt;
* Josef Holzmayr-Khosh Amoz (YP Community Manager)&lt;br /&gt;
* Megan Knight (Advocacy Manager)&lt;br /&gt;
* Trevor Woerner&lt;br /&gt;
&lt;br /&gt;
== Platforms ==&lt;br /&gt;
In terms of platforms we&#039;re using:&lt;br /&gt;
* pretalx for the CfP and schedule&lt;br /&gt;
* the LF&#039;s cvent for registration&lt;br /&gt;
* Zoom for the conference video&lt;br /&gt;
* irc for the conference chat (channel #yocto-summit-2023.11 on Libera.Chat)&lt;br /&gt;
* Digital Ocean for the hands-on classes&lt;br /&gt;
&lt;br /&gt;
== Hands-on Servers Information (Pre-event Preparation) ==&lt;br /&gt;
# If you already have a Digital Ocean account, skip the next 2 steps&lt;br /&gt;
# To create a Digital Ocean account, please sign up @ [https://do.co/yoctoproject DigitalOcean] &lt;br /&gt;
# Confirm your email and add a payment method to satisfy abuse requirements - you won&#039;t be charged unless you leave the training machine running long past the summit&lt;br /&gt;
# Visit https://cloud.digitalocean.com/account/api/tokens and generate a new token named &#039;&#039;&#039;YPSummit&#039;&#039;&#039;, and copy the string that pops up.&lt;br /&gt;
# Please complete this [https://forms.gle/53NFyCRaEpmRWuaa8 form] so your API key can be added to the provisioning scripts and we can top up your account credit.&lt;br /&gt;
&lt;br /&gt;
After the form has been filled by all participants we will provision machines. When the machines are ready logins will be &amp;quot;ssh ilab01@AXAXAXA-summit.yocto.io&amp;quot; where AXAXAXA are the first 7 characters of your confirmation string. The password is the full 11 character confirmation string.&lt;br /&gt;
&lt;br /&gt;
Once you have a verified working server you may delete your api key at https://cloud.digitalocean.com/account/api/tokens. Otherwise all resources will be removed after the training. Any retained servers will be billed to you after the promotional credit expires in 60 days.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;!-- Lab files are available during the event at http://summit.yocto.io/yps2023.11.tgz --&amp;gt;&lt;br /&gt;
Lab files will be available for download once the event begins.&lt;br /&gt;
&lt;br /&gt;
== For more information ==&lt;br /&gt;
* https://yoctoproject.org/event/yocto-project-summit-2023-11/&lt;br /&gt;
* https://pretalx.com/yocto-project-summit-2023-11/&lt;br /&gt;
&lt;br /&gt;
== Slide template for presenters ==&lt;br /&gt;
* https://docs.google.com/presentation/d/1ttXgB8Z1gasL7ItCYZ-uXT_FmfnIgPoMK_JtjvBrj1g&lt;br /&gt;
** keep the first and last slides&lt;br /&gt;
** edit the first slide to include your name, presentation title, and (optionally) your company&lt;br /&gt;
** the rest of the slides are examples and can be duplicated, edited, and/or removed&lt;br /&gt;
** please upload your finished slides to your specific event in pretalx&lt;/div&gt;</summary>
		<author><name>Trevor Woerner</name></author>
	</entry>
	<entry>
		<id>https://wiki.yoctoproject.org/wiki/index.php?title=Build_Appliance_2023&amp;diff=85748</id>
		<title>Build Appliance 2023</title>
		<link rel="alternate" type="text/html" href="https://wiki.yoctoproject.org/wiki/index.php?title=Build_Appliance_2023&amp;diff=85748"/>
		<updated>2023-04-14T11:54:02Z</updated>

		<summary type="html">&lt;p&gt;Trevor Woerner: native: update native build time after performing a couple builds&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;__TOC__&lt;br /&gt;
&lt;br /&gt;
== Build ==&lt;br /&gt;
&lt;br /&gt;
Using either poky or a no-distro oe-core simply run the following to generate the Build Appliance image:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;$ bitbake build-appliance-image&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
At a minimum the configuration requires:&lt;br /&gt;
* the &amp;lt;tt&amp;gt;MACHINE&amp;lt;/tt&amp;gt; should be set to &amp;lt;tt&amp;gt;qemux86-64&amp;lt;/tt&amp;gt;&lt;br /&gt;
* &amp;lt;tt&amp;gt;DISTRO_FEATURES&amp;lt;/tt&amp;gt; must include &amp;lt;tt&amp;gt;opengl&amp;lt;/tt&amp;gt;, &amp;lt;tt&amp;gt;x11&amp;lt;/tt&amp;gt;, &amp;lt;tt&amp;gt;xattr&amp;lt;/tt&amp;gt;&lt;br /&gt;
* &amp;lt;tt&amp;gt;VOLATILE_TMP_DIR&amp;lt;/tt&amp;gt; must not be set to &amp;lt;tt&amp;gt;yes&amp;lt;/tt&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Usage ==&lt;br /&gt;
&lt;br /&gt;
Currently, building the &amp;lt;tt&amp;gt;build-appliance-image&amp;lt;/tt&amp;gt; target generates the following artifacts (among others):&lt;br /&gt;
* &amp;lt;tt&amp;gt;build-appliance-image*rootfs.wic.vhd&amp;lt;/tt&amp;gt;&lt;br /&gt;
* &amp;lt;tt&amp;gt;build-appliance-image*rootfs.wic.vhdx&amp;lt;/tt&amp;gt;&lt;br /&gt;
* &amp;lt;tt&amp;gt;build-appliance-image*rootfs.wic.vmdk&amp;lt;/tt&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The resulting &amp;lt;tt&amp;gt;*vmdk&amp;lt;/tt&amp;gt; should be runnable in any of:&lt;br /&gt;
* qemu&lt;br /&gt;
* virtualbox&lt;br /&gt;
* vmware player&lt;br /&gt;
&lt;br /&gt;
=== qemu ===&lt;br /&gt;
&lt;br /&gt;
After successfully building the &amp;lt;tt&amp;gt;build-appliance-image&amp;lt;/tt&amp;gt;, from the same shell from which the build was performed, run:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;$ runqemu slirp kvm nographic serial tmp-glibc/deploy/images/qemux86-64/build-appliance-image-qemux86-64.wic.vmdk&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
To quit qemu non-gracefully use: &amp;lt;tt&amp;gt;Ctrl-A + x&amp;lt;/tt&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== virtualbox ===&lt;br /&gt;
&lt;br /&gt;
=== vmware player ===&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Issues ==&lt;br /&gt;
&lt;br /&gt;
Qemu has support for &amp;lt;tt&amp;gt;virtio-blk&amp;lt;/tt&amp;gt; and is using that. However, neither virtualbox nor vmware support virtio-blk. The ideal scenario would be to build one image, and for it to be usable in all virtualization platforms.&lt;br /&gt;
&lt;br /&gt;
== In-Appliance Build Performance ==&lt;br /&gt;
&lt;br /&gt;
The goal is to build core-image-sato in each of the virtualization platforms and see which one is able to build the image the fastest.&lt;br /&gt;
&lt;br /&gt;
Some virtualization platforms support some features, while other platforms support other features. On the one hand it would be great to build one image that can be usable in all virtualization platforms, on the other hand it would be nice to see how well these virtualization platforms perform when used optimally. As such, a number of tests will be performed and explained below in order to see how they compare to each other, and how they compare to a build done natively.&lt;br /&gt;
&lt;br /&gt;
It&#039;s important to eliminate the effects of connectivity on the build time measurements. As such each run will start with a &amp;lt;code&amp;gt;$ bitbake core-image-sato --runall=fetch&amp;lt;/code&amp;gt; before performing the actual &amp;lt;code&amp;gt;$ bitbake core-image-sato&amp;lt;/code&amp;gt; build. Also each build will be run from &amp;lt;code&amp;gt;poky&amp;lt;/code&amp;gt; at commit &amp;lt;code&amp;gt;311c76c8e8cf39fa41456561148cebe2b8b3c057&amp;lt;/code&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
=== native ===&lt;br /&gt;
&lt;br /&gt;
Virtualization platforms are not allowed to use all of the host&#039;s resources (CPU, memory). Therefore comparing the performance of a &amp;lt;code&amp;gt;$ bitbake core-image-sato&amp;lt;/code&amp;gt; build in each of the virtualization platforms versus the same build performed directly on my host machine (i.e. without virtualization) would not provide honest results since none of the virtualized builds would be able to use the same amount of resources for their builds as would my host machine.&lt;br /&gt;
&lt;br /&gt;
Also, it is hard to setup a build in such a way that the system is dedicated to nothing but the build under test. I didn&#039;t go out of my way to try to create a completely quiet system on which to perform the builds, but I did take some steps such as:&lt;br /&gt;
* to exit all browsers&lt;br /&gt;
* to stop the &amp;lt;tt&amp;gt;mlocate&amp;lt;/tt&amp;gt; process (which happened to be occurring at the time)&lt;br /&gt;
* stop all nightly or automatically triggered background builds (jenkins)&lt;br /&gt;
* and to otherwise not use the system while performing the benchmarks&lt;br /&gt;
&lt;br /&gt;
In the interest of providing a baseline, a &amp;lt;code&amp;gt;$ bitbake core-image-sato&amp;lt;/code&amp;gt; build performed directly on my host machine (i.e. without any resource constraints) takes:&lt;br /&gt;
&lt;br /&gt;
 real    78m28.352s&lt;br /&gt;
 user    0m54.934s&lt;br /&gt;
 sys     0m5.896s&lt;br /&gt;
&lt;br /&gt;
My host build machine has:&lt;br /&gt;
* 2x E5-2630 v4 Xeon CPUs, each has 10 real cores plus 10 threads for a total of 40 cores+threads&lt;br /&gt;
* 128 GB RAM&lt;br /&gt;
&lt;br /&gt;
Another test we can perform is to use &amp;lt;tt&amp;gt;cgroups&amp;lt;/tt&amp;gt; to create a bucket on the host machine with reduced system resources, in which we perform the same build. Of all the virtualization products, vmware is the most restrictive as it only allows us to use up to 16 CPUs and 64 GB of RAM. Therefore perform all tests using these parameters.&lt;br /&gt;
&lt;br /&gt;
Using &amp;lt;tt&amp;gt;cgroups&amp;lt;/tt&amp;gt;:&lt;br /&gt;
&lt;br /&gt;
 &amp;lt;nowiki&amp;gt;# cgcreate -a trevor -t trevor -g memory,cpuset:buildappliance&lt;br /&gt;
$ echo 0 &amp;gt; /sys/fs/cgroup/cpuset/buildappliance/cpuset.mems&lt;br /&gt;
$ echo &amp;quot;0-15&amp;quot; &amp;gt; /sys/fs/cgroup/cpuset/buildappliance/cpuset.cpus&lt;br /&gt;
$ echo 1 &amp;gt; /sys/fs/cgroup/cpuset/buildappliance/cpuset.cpu_exclusive&lt;br /&gt;
$ echo 1 &amp;gt; /sys/fs/cgroup/cpuset/buildappliance/cpuset.mem_exclusive&lt;br /&gt;
$ echo 0-1 &amp;gt; /sys/fs/cgroup/cpuset/buildappliance/cpuset.mems&lt;br /&gt;
$ echo 68719476736 &amp;gt; /sys/fs/cgroup/memory/buildappliance/memory.limit_in_bytes&lt;br /&gt;
$ cgexec -g memory,cpuset:buildappliance /bin/bash&lt;br /&gt;
$ time bitbake core-image-sato&lt;br /&gt;
# cgdelete memory,cpuset:buildappliance&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The result is:&lt;br /&gt;
 real    107m4.550s&lt;br /&gt;
 user    0m41.856s&lt;br /&gt;
 sys     0m4.859s&lt;br /&gt;
&lt;br /&gt;
=== qemu ===&lt;/div&gt;</summary>
		<author><name>Trevor Woerner</name></author>
	</entry>
	<entry>
		<id>https://wiki.yoctoproject.org/wiki/index.php?title=Build_Appliance_2023&amp;diff=85747</id>
		<title>Build Appliance 2023</title>
		<link rel="alternate" type="text/html" href="https://wiki.yoctoproject.org/wiki/index.php?title=Build_Appliance_2023&amp;diff=85747"/>
		<updated>2023-04-14T04:39:48Z</updated>

		<summary type="html">&lt;p&gt;Trevor Woerner: native: add results for building in a cgroup (comparable to the virtualized environments)&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;__TOC__&lt;br /&gt;
&lt;br /&gt;
== Build ==&lt;br /&gt;
&lt;br /&gt;
Using either poky or a no-distro oe-core simply run the following to generate the Build Appliance image:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;$ bitbake build-appliance-image&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
At a minimum the configuration requires:&lt;br /&gt;
* the &amp;lt;tt&amp;gt;MACHINE&amp;lt;/tt&amp;gt; should be set to &amp;lt;tt&amp;gt;qemux86-64&amp;lt;/tt&amp;gt;&lt;br /&gt;
* &amp;lt;tt&amp;gt;DISTRO_FEATURES&amp;lt;/tt&amp;gt; must include &amp;lt;tt&amp;gt;opengl&amp;lt;/tt&amp;gt;, &amp;lt;tt&amp;gt;x11&amp;lt;/tt&amp;gt;, &amp;lt;tt&amp;gt;xattr&amp;lt;/tt&amp;gt;&lt;br /&gt;
* &amp;lt;tt&amp;gt;VOLATILE_TMP_DIR&amp;lt;/tt&amp;gt; must not be set to &amp;lt;tt&amp;gt;yes&amp;lt;/tt&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Usage ==&lt;br /&gt;
&lt;br /&gt;
Currently, building the &amp;lt;tt&amp;gt;build-appliance-image&amp;lt;/tt&amp;gt; target generates the following artifacts (among others):&lt;br /&gt;
* &amp;lt;tt&amp;gt;build-appliance-image*rootfs.wic.vhd&amp;lt;/tt&amp;gt;&lt;br /&gt;
* &amp;lt;tt&amp;gt;build-appliance-image*rootfs.wic.vhdx&amp;lt;/tt&amp;gt;&lt;br /&gt;
* &amp;lt;tt&amp;gt;build-appliance-image*rootfs.wic.vmdk&amp;lt;/tt&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The resulting &amp;lt;tt&amp;gt;*vmdk&amp;lt;/tt&amp;gt; should be runnable in any of:&lt;br /&gt;
* qemu&lt;br /&gt;
* virtualbox&lt;br /&gt;
* vmware player&lt;br /&gt;
&lt;br /&gt;
=== qemu ===&lt;br /&gt;
&lt;br /&gt;
After successfully building the &amp;lt;tt&amp;gt;build-appliance-image&amp;lt;/tt&amp;gt;, from the same shell from which the build was performed, run:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;$ runqemu slirp kvm nographic serial tmp-glibc/deploy/images/qemux86-64/build-appliance-image-qemux86-64.wic.vmdk&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
To quit qemu non-gracefully use: &amp;lt;tt&amp;gt;Ctrl-A + x&amp;lt;/tt&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== virtualbox ===&lt;br /&gt;
&lt;br /&gt;
=== vmware player ===&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Issues ==&lt;br /&gt;
&lt;br /&gt;
Qemu has support for &amp;lt;tt&amp;gt;virtio-blk&amp;lt;/tt&amp;gt; and is using that. However, neither virtualbox nor vmware support virtio-blk. The ideal scenario would be to build one image, and for it to be usable in all virtualization platforms.&lt;br /&gt;
&lt;br /&gt;
== In-Appliance Build Performance ==&lt;br /&gt;
&lt;br /&gt;
The goal is to build core-image-sato in each of the virtualization platforms and see which one is able to build the image the fastest.&lt;br /&gt;
&lt;br /&gt;
Some virtualization platforms support some features, while other platforms support other features. On the one hand it would be great to build one image that can be usable in all virtualization platforms, on the other hand it would be nice to see how well these virtualization platforms perform when used optimally. As such, a number of tests will be performed and explained below in order to see how they compare to each other, and how they compare to a build done natively.&lt;br /&gt;
&lt;br /&gt;
It&#039;s important to eliminate the effects of connectivity on the build time measurements. As such each run will start with a &amp;lt;code&amp;gt;$ bitbake core-image-sato --runall=fetch&amp;lt;/code&amp;gt; before performing the actual &amp;lt;code&amp;gt;$ bitbake core-image-sato&amp;lt;/code&amp;gt; build. Also each build will be run from &amp;lt;code&amp;gt;poky&amp;lt;/code&amp;gt; at commit &amp;lt;code&amp;gt;311c76c8e8cf39fa41456561148cebe2b8b3c057&amp;lt;/code&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
=== native ===&lt;br /&gt;
&lt;br /&gt;
Virtualization platforms are not allowed to use all of the host&#039;s resources (CPU, memory). Therefore comparing the performance of a &amp;lt;code&amp;gt;$ bitbake core-image-sato&amp;lt;/code&amp;gt; build in each of the virtualization platforms versus the same build performed directly on my host machine (i.e. without virtualization) would not provide honest results since none of the virtualized builds would be able to use the same amount of resources for their builds as would my host machine.&lt;br /&gt;
&lt;br /&gt;
Also, it is hard to setup a build in such a way that the system is dedicated to nothing but the build under test. I didn&#039;t go out of my way to try to create a completely quiet system on which to perform the builds, but I did take some steps such as:&lt;br /&gt;
* to exit all browsers&lt;br /&gt;
* to stop the &amp;lt;tt&amp;gt;mlocate&amp;lt;/tt&amp;gt; process (which happened to be occurring at the time)&lt;br /&gt;
* stop all nightly or automatically triggered background builds (jenkins)&lt;br /&gt;
* and to otherwise not use the system while performing the benchmarks&lt;br /&gt;
&lt;br /&gt;
In the interest of providing a baseline, a &amp;lt;code&amp;gt;$ bitbake core-image-sato&amp;lt;/code&amp;gt; build performed directly on my host machine (i.e. without any resource constraints) takes:&lt;br /&gt;
&lt;br /&gt;
 real    86m8.781s&lt;br /&gt;
 user    1m7.070s&lt;br /&gt;
 sys     1m36.769s&lt;br /&gt;
&lt;br /&gt;
My host build machine has:&lt;br /&gt;
* 2x E5-2630 v4 Xeon CPUs, each has 10 real cores plus 10 threads for a total of 40 cores+threads&lt;br /&gt;
* 128 GB RAM&lt;br /&gt;
&lt;br /&gt;
Another test we can perform is to use &amp;lt;tt&amp;gt;cgroups&amp;lt;/tt&amp;gt; to create a bucket on the host machine with reduced system resources, in which we perform the same build. Of all the virtualization products, vmware is the most restrictive as it only allows us to use up to 16 CPUs and 64 GB of RAM. Therefore perform all tests using these parameters.&lt;br /&gt;
&lt;br /&gt;
Using &amp;lt;tt&amp;gt;cgroups&amp;lt;/tt&amp;gt;:&lt;br /&gt;
&lt;br /&gt;
 &amp;lt;nowiki&amp;gt;# cgcreate -a trevor -t trevor -g memory,cpuset:buildappliance&lt;br /&gt;
$ echo 0 &amp;gt; /sys/fs/cgroup/cpuset/buildappliance/cpuset.mems&lt;br /&gt;
$ echo &amp;quot;0-15&amp;quot; &amp;gt; /sys/fs/cgroup/cpuset/buildappliance/cpuset.cpus&lt;br /&gt;
$ echo 1 &amp;gt; /sys/fs/cgroup/cpuset/buildappliance/cpuset.cpu_exclusive&lt;br /&gt;
$ echo 1 &amp;gt; /sys/fs/cgroup/cpuset/buildappliance/cpuset.mem_exclusive&lt;br /&gt;
$ echo 0-1 &amp;gt; /sys/fs/cgroup/cpuset/buildappliance/cpuset.mems&lt;br /&gt;
$ echo 68719476736 &amp;gt; /sys/fs/cgroup/memory/buildappliance/memory.limit_in_bytes&lt;br /&gt;
$ cgexec -g memory,cpuset:buildappliance /bin/bash&lt;br /&gt;
$ time bitbake core-image-sato&lt;br /&gt;
# cgdelete memory,cpuset:buildappliance&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The result is:&lt;br /&gt;
 real    107m4.550s&lt;br /&gt;
 user    0m41.856s&lt;br /&gt;
 sys     0m4.859s&lt;br /&gt;
&lt;br /&gt;
=== qemu ===&lt;/div&gt;</summary>
		<author><name>Trevor Woerner</name></author>
	</entry>
	<entry>
		<id>https://wiki.yoctoproject.org/wiki/index.php?title=Build_Appliance_2023&amp;diff=85746</id>
		<title>Build Appliance 2023</title>
		<link rel="alternate" type="text/html" href="https://wiki.yoctoproject.org/wiki/index.php?title=Build_Appliance_2023&amp;diff=85746"/>
		<updated>2023-04-13T23:10:33Z</updated>

		<summary type="html">&lt;p&gt;Trevor Woerner: add more general details of the test parameters (repository=poky, commit)&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;__TOC__&lt;br /&gt;
&lt;br /&gt;
== Build ==&lt;br /&gt;
&lt;br /&gt;
Using either poky or a no-distro oe-core simply run the following to generate the Build Appliance image:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;$ bitbake build-appliance-image&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
At a minimum the configuration requires:&lt;br /&gt;
* the &amp;lt;tt&amp;gt;MACHINE&amp;lt;/tt&amp;gt; should be set to &amp;lt;tt&amp;gt;qemux86-64&amp;lt;/tt&amp;gt;&lt;br /&gt;
* &amp;lt;tt&amp;gt;DISTRO_FEATURES&amp;lt;/tt&amp;gt; must include &amp;lt;tt&amp;gt;opengl&amp;lt;/tt&amp;gt;, &amp;lt;tt&amp;gt;x11&amp;lt;/tt&amp;gt;, &amp;lt;tt&amp;gt;xattr&amp;lt;/tt&amp;gt;&lt;br /&gt;
* &amp;lt;tt&amp;gt;VOLATILE_TMP_DIR&amp;lt;/tt&amp;gt; must not be set to &amp;lt;tt&amp;gt;yes&amp;lt;/tt&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Usage ==&lt;br /&gt;
&lt;br /&gt;
Currently, building the &amp;lt;tt&amp;gt;build-appliance-image&amp;lt;/tt&amp;gt; target generates the following artifacts (among others):&lt;br /&gt;
* &amp;lt;tt&amp;gt;build-appliance-image*rootfs.wic.vhd&amp;lt;/tt&amp;gt;&lt;br /&gt;
* &amp;lt;tt&amp;gt;build-appliance-image*rootfs.wic.vhdx&amp;lt;/tt&amp;gt;&lt;br /&gt;
* &amp;lt;tt&amp;gt;build-appliance-image*rootfs.wic.vmdk&amp;lt;/tt&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The resulting &amp;lt;tt&amp;gt;*vmdk&amp;lt;/tt&amp;gt; should be runnable in any of:&lt;br /&gt;
* qemu&lt;br /&gt;
* virtualbox&lt;br /&gt;
* vmware player&lt;br /&gt;
&lt;br /&gt;
=== qemu ===&lt;br /&gt;
&lt;br /&gt;
After successfully building the &amp;lt;tt&amp;gt;build-appliance-image&amp;lt;/tt&amp;gt;, from the same shell from which the build was performed, run:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;$ runqemu slirp kvm nographic serial tmp-glibc/deploy/images/qemux86-64/build-appliance-image-qemux86-64.wic.vmdk&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
To quit qemu non-gracefully use: &amp;lt;tt&amp;gt;Ctrl-A + x&amp;lt;/tt&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== virtualbox ===&lt;br /&gt;
&lt;br /&gt;
=== vmware player ===&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Issues ==&lt;br /&gt;
&lt;br /&gt;
Qemu has support for &amp;lt;tt&amp;gt;virtio-blk&amp;lt;/tt&amp;gt; and is using that. However, neither virtualbox nor vmware support virtio-blk. The ideal scenario would be to build one image, and for it to be usable in all virtualization platforms.&lt;br /&gt;
&lt;br /&gt;
== In-Appliance Build Performance ==&lt;br /&gt;
&lt;br /&gt;
The goal is to build core-image-sato in each of the virtualization platforms and see which one is able to build the image the fastest.&lt;br /&gt;
&lt;br /&gt;
Some virtualization platforms support some features, while other platforms support other features. On the one hand it would be great to build one image that can be usable in all virtualization platforms, on the other hand it would be nice to see how well these virtualization platforms perform when used optimally. As such, a number of tests will be performed and explained below in order to see how they compare to each other, and how they compare to a build done natively.&lt;br /&gt;
&lt;br /&gt;
It&#039;s important to eliminate the effects of connectivity on the build time measurements. As such each run will start with a &amp;lt;code&amp;gt;$ bitbake core-image-sato --runall=fetch&amp;lt;/code&amp;gt; before performing the actual &amp;lt;code&amp;gt;$ bitbake core-image-sato&amp;lt;/code&amp;gt; build. Also each build will be run from &amp;lt;code&amp;gt;poky&amp;lt;/code&amp;gt; at commit &amp;lt;code&amp;gt;311c76c8e8cf39fa41456561148cebe2b8b3c057&amp;lt;/code&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
=== native ===&lt;br /&gt;
&lt;br /&gt;
Virtualization platforms are not allowed to use all of the host&#039;s resources (CPU, memory). Therefore comparing the performance of a &amp;lt;code&amp;gt;$ bitbake core-image-sato&amp;lt;/code&amp;gt; build in each of the virtualization platforms versus the same build performed directly on my host machine (i.e. without virtualization) would not provide honest results since none of the virtualized builds would be able to use the same amount of resources for their builds as would my host machine.&lt;br /&gt;
&lt;br /&gt;
However, in the interest of providing a baseline, a &amp;lt;code&amp;gt;$ bitbake core-image-sato&amp;lt;/code&amp;gt; build performed directly on my host machine takes:&lt;br /&gt;
&lt;br /&gt;
 real    86m8.781s&lt;br /&gt;
 user    1m7.070s&lt;br /&gt;
 sys     1m36.769s&lt;br /&gt;
&lt;br /&gt;
=== qemu ===&lt;/div&gt;</summary>
		<author><name>Trevor Woerner</name></author>
	</entry>
	<entry>
		<id>https://wiki.yoctoproject.org/wiki/index.php?title=Build_Appliance_2023&amp;diff=85745</id>
		<title>Build Appliance 2023</title>
		<link rel="alternate" type="text/html" href="https://wiki.yoctoproject.org/wiki/index.php?title=Build_Appliance_2023&amp;diff=85745"/>
		<updated>2023-04-13T23:08:22Z</updated>

		<summary type="html">&lt;p&gt;Trevor Woerner: native: add baseline results&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;__TOC__&lt;br /&gt;
&lt;br /&gt;
== Build ==&lt;br /&gt;
&lt;br /&gt;
Using either poky or a no-distro oe-core simply run the following to generate the Build Appliance image:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;$ bitbake build-appliance-image&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
At a minimum the configuration requires:&lt;br /&gt;
* the &amp;lt;tt&amp;gt;MACHINE&amp;lt;/tt&amp;gt; should be set to &amp;lt;tt&amp;gt;qemux86-64&amp;lt;/tt&amp;gt;&lt;br /&gt;
* &amp;lt;tt&amp;gt;DISTRO_FEATURES&amp;lt;/tt&amp;gt; must include &amp;lt;tt&amp;gt;opengl&amp;lt;/tt&amp;gt;, &amp;lt;tt&amp;gt;x11&amp;lt;/tt&amp;gt;, &amp;lt;tt&amp;gt;xattr&amp;lt;/tt&amp;gt;&lt;br /&gt;
* &amp;lt;tt&amp;gt;VOLATILE_TMP_DIR&amp;lt;/tt&amp;gt; must not be set to &amp;lt;tt&amp;gt;yes&amp;lt;/tt&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Usage ==&lt;br /&gt;
&lt;br /&gt;
Currently, building the &amp;lt;tt&amp;gt;build-appliance-image&amp;lt;/tt&amp;gt; target generates the following artifacts (among others):&lt;br /&gt;
* &amp;lt;tt&amp;gt;build-appliance-image*rootfs.wic.vhd&amp;lt;/tt&amp;gt;&lt;br /&gt;
* &amp;lt;tt&amp;gt;build-appliance-image*rootfs.wic.vhdx&amp;lt;/tt&amp;gt;&lt;br /&gt;
* &amp;lt;tt&amp;gt;build-appliance-image*rootfs.wic.vmdk&amp;lt;/tt&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The resulting &amp;lt;tt&amp;gt;*vmdk&amp;lt;/tt&amp;gt; should be runnable in any of:&lt;br /&gt;
* qemu&lt;br /&gt;
* virtualbox&lt;br /&gt;
* vmware player&lt;br /&gt;
&lt;br /&gt;
=== qemu ===&lt;br /&gt;
&lt;br /&gt;
After successfully building the &amp;lt;tt&amp;gt;build-appliance-image&amp;lt;/tt&amp;gt;, from the same shell from which the build was performed, run:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;$ runqemu slirp kvm nographic serial tmp-glibc/deploy/images/qemux86-64/build-appliance-image-qemux86-64.wic.vmdk&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
To quit qemu non-gracefully use: &amp;lt;tt&amp;gt;Ctrl-A + x&amp;lt;/tt&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== virtualbox ===&lt;br /&gt;
&lt;br /&gt;
=== vmware player ===&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Issues ==&lt;br /&gt;
&lt;br /&gt;
Qemu has support for &amp;lt;tt&amp;gt;virtio-blk&amp;lt;/tt&amp;gt; and is using that. However, neither virtualbox nor vmware support virtio-blk. The ideal scenario would be to build one image, and for it to be usable in all virtualization platforms.&lt;br /&gt;
&lt;br /&gt;
== In-Appliance Build Performance ==&lt;br /&gt;
&lt;br /&gt;
The goal is to build core-image-sato in each of the virtualization platforms and see which one is able to build the image the fastest.&lt;br /&gt;
&lt;br /&gt;
Some virtualization platforms support some features, while other platforms support other features. On the one hand it would be great to build one image that can be usable in all virtualization platforms, on the other hand it would be nice to see how well these virtualization platforms perform when used optimally. As such, a number of tests will be performed and explained below in order to see how they compare to each other, and how they compare to a build done natively.&lt;br /&gt;
&lt;br /&gt;
It&#039;s important to eliminate the effects of connectivity on the build time measurements. As such each run will start with a &amp;lt;code&amp;gt;$ bitbake core-image-sato --runall=fetch&amp;lt;/code&amp;gt; before performing the actual &amp;lt;code&amp;gt;$ bitbake core-image-sato&amp;lt;/code&amp;gt; build.&lt;br /&gt;
&lt;br /&gt;
=== native ===&lt;br /&gt;
&lt;br /&gt;
Virtualization platforms are not allowed to use all of the host&#039;s resources (CPU, memory). Therefore comparing the performance of a &amp;lt;code&amp;gt;$ bitbake core-image-sato&amp;lt;/code&amp;gt; build in each of the virtualization platforms versus the same build performed directly on my host machine (i.e. without virtualization) would not provide honest results since none of the virtualized builds would be able to use the same amount of resources for their builds as would my host machine.&lt;br /&gt;
&lt;br /&gt;
However, in the interest of providing a baseline, a &amp;lt;code&amp;gt;$ bitbake core-image-sato&amp;lt;/code&amp;gt; build from &amp;lt;code&amp;gt;poky:311c76c8e8cf39fa41456561148cebe2b8b3c057&amp;lt;/code&amp;gt; performed directly on my host machine takes:&lt;br /&gt;
&lt;br /&gt;
 real    86m8.781s&lt;br /&gt;
 user    1m7.070s&lt;br /&gt;
 sys     1m36.769s&lt;br /&gt;
&lt;br /&gt;
=== qemu ===&lt;/div&gt;</summary>
		<author><name>Trevor Woerner</name></author>
	</entry>
	<entry>
		<id>https://wiki.yoctoproject.org/wiki/index.php?title=Build_Appliance_2023&amp;diff=85744</id>
		<title>Build Appliance 2023</title>
		<link rel="alternate" type="text/html" href="https://wiki.yoctoproject.org/wiki/index.php?title=Build_Appliance_2023&amp;diff=85744"/>
		<updated>2023-04-13T19:57:45Z</updated>

		<summary type="html">&lt;p&gt;Trevor Woerner: add page (not yet complete)&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;__TOC__&lt;br /&gt;
&lt;br /&gt;
== Build ==&lt;br /&gt;
&lt;br /&gt;
Using either poky or a no-distro oe-core simply run the following to generate the Build Appliance image:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;$ bitbake build-appliance-image&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
At a minimum the configuration requires:&lt;br /&gt;
* the &amp;lt;tt&amp;gt;MACHINE&amp;lt;/tt&amp;gt; should be set to &amp;lt;tt&amp;gt;qemux86-64&amp;lt;/tt&amp;gt;&lt;br /&gt;
* &amp;lt;tt&amp;gt;DISTRO_FEATURES&amp;lt;/tt&amp;gt; must include &amp;lt;tt&amp;gt;opengl&amp;lt;/tt&amp;gt;, &amp;lt;tt&amp;gt;x11&amp;lt;/tt&amp;gt;, &amp;lt;tt&amp;gt;xattr&amp;lt;/tt&amp;gt;&lt;br /&gt;
* &amp;lt;tt&amp;gt;VOLATILE_TMP_DIR&amp;lt;/tt&amp;gt; must not be set to &amp;lt;tt&amp;gt;yes&amp;lt;/tt&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Usage ==&lt;br /&gt;
&lt;br /&gt;
Currently, building the &amp;lt;tt&amp;gt;build-appliance-image&amp;lt;/tt&amp;gt; target generates the following artifacts (among others):&lt;br /&gt;
* &amp;lt;tt&amp;gt;build-appliance-image*rootfs.wic.vhd&amp;lt;/tt&amp;gt;&lt;br /&gt;
* &amp;lt;tt&amp;gt;build-appliance-image*rootfs.wic.vhdx&amp;lt;/tt&amp;gt;&lt;br /&gt;
* &amp;lt;tt&amp;gt;build-appliance-image*rootfs.wic.vmdk&amp;lt;/tt&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The resulting &amp;lt;tt&amp;gt;*vmdk&amp;lt;/tt&amp;gt; should be runnable in any of:&lt;br /&gt;
* qemu&lt;br /&gt;
* virtualbox&lt;br /&gt;
* vmware player&lt;br /&gt;
&lt;br /&gt;
=== qemu ===&lt;br /&gt;
&lt;br /&gt;
After successfully building the &amp;lt;tt&amp;gt;build-appliance-image&amp;lt;/tt&amp;gt;, from the same shell from which the build was performed, run:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;$ runqemu slirp kvm nographic serial tmp-glibc/deploy/images/qemux86-64/build-appliance-image-qemux86-64.wic.vmdk&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
To quit qemu non-gracefully use: &amp;lt;tt&amp;gt;Ctrl-A + x&amp;lt;/tt&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== virtualbox ===&lt;br /&gt;
&lt;br /&gt;
=== vmware player ===&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Issues ==&lt;br /&gt;
&lt;br /&gt;
Qemu has support for &amp;lt;tt&amp;gt;virtio-blk&amp;lt;/tt&amp;gt; and is using that. However, neither virtualbox nor vmware support virtio-blk. The ideal scenario would be to build one image, and for it to be usable in all virtualization platforms.&lt;br /&gt;
&lt;br /&gt;
== In-Appliance Build Performance ==&lt;br /&gt;
&lt;br /&gt;
The goal is to build core-image-sato in each of the virtualization platforms and see which one is able to build the image the fastest.&lt;br /&gt;
&lt;br /&gt;
Some virtualization platforms support some features, while other platforms support other features. On the one hand it would be great to build one image that can be usable in all virtualization platforms, on the other hand it would be nice to see how well these virtualization platforms perform when used optimally. As such, a number of tests will be performed and explained below in order to see how they compare to each other, and how they compare to a build done natively.&lt;br /&gt;
&lt;br /&gt;
It&#039;s important to eliminate the effects of connectivity on the build time measurements. As such each run will start with a &amp;lt;code&amp;gt;$ bitbake core-image-sato --runall=fetch&amp;lt;/code&amp;gt; before performing the actual &amp;lt;code&amp;gt;$ bitbake core-image-sato&amp;lt;/code&amp;gt; build.&lt;br /&gt;
&lt;br /&gt;
=== native ===&lt;br /&gt;
&lt;br /&gt;
Virtualization platforms are not allowed to use all of the host&#039;s resources (CPU, memory). Therefore performing an unrestricted build on the host will not be the best comparison since none of the virtualized builds will have any chance of comparing; it won&#039;t be an apples-to-apples comparison.&lt;br /&gt;
&lt;br /&gt;
=== qemu ===&lt;/div&gt;</summary>
		<author><name>Trevor Woerner</name></author>
	</entry>
	<entry>
		<id>https://wiki.yoctoproject.org/wiki/index.php?title=Projects&amp;diff=85743</id>
		<title>Projects</title>
		<link rel="alternate" type="text/html" href="https://wiki.yoctoproject.org/wiki/index.php?title=Projects&amp;diff=85743"/>
		<updated>2023-04-12T22:57:25Z</updated>

		<summary type="html">&lt;p&gt;Trevor Woerner: update link to Build Appliance documentation&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Welcome to the Projects Page ==&lt;br /&gt;
* [[AutoBuilder]]&lt;br /&gt;
* [[Poky]]&lt;br /&gt;
* [[Pseudo]]&lt;br /&gt;
* [[Cross-Prelink]]&lt;br /&gt;
* [[QA]]&lt;br /&gt;
* [[Documentation]]&lt;br /&gt;
* [[BSPs]]&lt;br /&gt;
* [[Tracing and Profiling]]&lt;br /&gt;
* Linux Kernel&lt;br /&gt;
** [[Linux_Kernel/Boot_Time|Boot Time]]&lt;br /&gt;
** [[Linux_kernel/Image_Size|Image Size]]&lt;br /&gt;
* [[Multilib]]&lt;br /&gt;
* [[BitBake/GUI|BitBake GUI&#039;s]]&lt;br /&gt;
* [[x32 abi]]&lt;br /&gt;
* [[Build Appliance]]&lt;br /&gt;
* [[Toaster]]&lt;br /&gt;
* [[OpenGL pass-through in QEMU]]&lt;br /&gt;
* [[Running an x86 Yocto Linux image under QEMU KVM]]&lt;br /&gt;
* [[Web Application for Interactive Kiosk Devices]]&lt;br /&gt;
* [[Virtualization with KVM]]&lt;br /&gt;
* [[Poky-Tiny]]&lt;br /&gt;
* [[System Update]]&lt;br /&gt;
* [[Wayland]]&lt;br /&gt;
&lt;br /&gt;
== Archived Projects ==&lt;br /&gt;
* [[Eclipse Plug-in]]&lt;br /&gt;
* [[Anjuta Plug-in]]&lt;br /&gt;
* [[SDK Generator]]&lt;br /&gt;
* [[Hob2 (Hob v2)]]&lt;br /&gt;
* [[DLNA Media Server Virtual Appliance]]&lt;br /&gt;
* [[Swabber]]&lt;br /&gt;
* [[Baryon]]&lt;br /&gt;
* [[ELC2013kiosk_demo]]&lt;/div&gt;</summary>
		<author><name>Trevor Woerner</name></author>
	</entry>
	<entry>
		<id>https://wiki.yoctoproject.org/wiki/index.php?title=Build_Appliance&amp;diff=85742</id>
		<title>Build Appliance</title>
		<link rel="alternate" type="text/html" href="https://wiki.yoctoproject.org/wiki/index.php?title=Build_Appliance&amp;diff=85742"/>
		<updated>2023-04-12T22:56:54Z</updated>

		<summary type="html">&lt;p&gt;Trevor Woerner: initial page creation&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;__TOC__&lt;br /&gt;
&lt;br /&gt;
=== About ===&lt;br /&gt;
&lt;br /&gt;
The Build Appliance is a project under The Yocto Project umbrella.&lt;br /&gt;
The purpose of the Build Appliance is to use Yocto to build a virtual machine image, inside of which (i.e. when run) one can perform Yocto builds.&lt;br /&gt;
&lt;br /&gt;
Another tangential purpose of the Build Appliance is for testing [[Pseudo]]. The Yocto Project uses up-to-date packages for every component on master. An image built with master will include the latest glibc, etc. Using this Yocto-built image in which to build Yocto verifies that Yocto (and therefore pseudo) works with all the latest host packages.&lt;br /&gt;
&lt;br /&gt;
=== Design ===&lt;br /&gt;
&lt;br /&gt;
The following document was created when the Build Appliance was initial conceived. It is a planning/design document for the Build Appliance&#039;s initial inception:&lt;br /&gt;
[[Build Appliance Design]].&lt;br /&gt;
&lt;br /&gt;
In time the Build Appliance lost its maintainer and stopped working. In 2023 an effort was made to revive it. Updated notes about the Build Appliance from this time can be found at: [[Build Appliance 2023]].&lt;/div&gt;</summary>
		<author><name>Trevor Woerner</name></author>
	</entry>
	<entry>
		<id>https://wiki.yoctoproject.org/wiki/index.php?title=Linux_Yocto&amp;diff=85503</id>
		<title>Linux Yocto</title>
		<link rel="alternate" type="text/html" href="https://wiki.yoctoproject.org/wiki/index.php?title=Linux_Yocto&amp;diff=85503"/>
		<updated>2022-10-20T16:17:18Z</updated>

		<summary type="html">&lt;p&gt;Trevor Woerner: /* Release Cadence */ updated to clarify between the various LTSes and to reflect the current policy&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Release Cadence==&lt;br /&gt;
Each release of the Yocto Project, roughly every six months, includes one or more versions of the Linux kernel with a broad range of hardware support. While tooling is provided to use any Linux kernel you wish, the linux-yocto Linux kernel recipes are tested with all the emulated targets, the core hardware BSPs, and some vendor layers.&lt;br /&gt;
&lt;br /&gt;
The [https://ltsi.linuxfoundation.org/software/releases/ LTSI] is a Linux Foundation project that saw its first LTSI kernel released in 2011. The latest LTSI release was 4.14.75-ltsi, released in 2018. The work of the LTSI appears to have been taken over by another LF project: the [https://www.cip-project.org/ Civil Infrastructure Project] (CIP). The Linux kernel maintainers also maintain their own [https://www.kernel.org/category/releases.html LTS] kernels. Historically the Yocto Project tried to provide an LTSI plus a recent kernel.org kernel with each release. More recently the project works to provide at least a kernel.org LTS kernel plus a more recent kernel.org kernel.&lt;br /&gt;
&lt;br /&gt;
The final selection of which versions to ship in any release is made approximately two weeks prior to the feature freeze date for the release.&lt;br /&gt;
&lt;br /&gt;
==Prior Releases==&lt;br /&gt;
{|border=&amp;quot;1&amp;quot; {{table}}&lt;br /&gt;
| align=&amp;quot;center&amp;quot; style=&amp;quot;background:#f0f0f0;&amp;quot;|&#039;&#039;&#039;Yocto Project Release&#039;&#039;&#039;&lt;br /&gt;
| align=&amp;quot;center&amp;quot; style=&amp;quot;background:#f0f0f0;&amp;quot;|&#039;&#039;&#039;LTSI Kernel Version&#039;&#039;&#039;&lt;br /&gt;
| align=&amp;quot;center&amp;quot; style=&amp;quot;background:#f0f0f0;&amp;quot;|&#039;&#039;&#039;LTS Kernel Version&#039;&#039;&#039;&lt;br /&gt;
| align=&amp;quot;center&amp;quot; style=&amp;quot;background:#f0f0f0;&amp;quot;|&#039;&#039;&#039;Released Kernel Version&#039;&#039;&#039;&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot;&lt;br /&gt;
|Yocto Project 4.1&lt;br /&gt;
|&lt;br /&gt;
|linux-yocto_5.15&lt;br /&gt;
|linux-yocto_5.19&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot;&lt;br /&gt;
|Yocto Project 4.0&lt;br /&gt;
|&lt;br /&gt;
|linux-yocto_5.10&amp;lt;br&amp;gt;linux-yocto_5.15&lt;br /&gt;
|&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot;&lt;br /&gt;
|Yocto Project 3.4&lt;br /&gt;
|&lt;br /&gt;
|linux-yocto_5.10&lt;br /&gt;
|linux-yocto_5.14&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot;&lt;br /&gt;
|Yocto Project 3.3&lt;br /&gt;
|&lt;br /&gt;
|linux-yocto_5.4&amp;lt;br&amp;gt;linux-yocto_5.10&lt;br /&gt;
|&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot;&lt;br /&gt;
|Yocto Project 3.2&lt;br /&gt;
|&lt;br /&gt;
|linux-yocto_5.4&lt;br /&gt;
|linux-yocto_5.8&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot;&lt;br /&gt;
|Yocto Project 3.1&lt;br /&gt;
|&lt;br /&gt;
|linux-yocto_5.4&lt;br /&gt;
|&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot;&lt;br /&gt;
|Yocto Project 3.0&lt;br /&gt;
|&lt;br /&gt;
|linux-yocto_4.19&lt;br /&gt;
|linux-yocto_5.2&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot;&lt;br /&gt;
|Yocto Project 2.7&lt;br /&gt;
|&lt;br /&gt;
|linux-yocto_4.19&lt;br /&gt;
|linux-yocto_5.0&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot;&lt;br /&gt;
|Yocto Project 2.6&lt;br /&gt;
|linux-yocto_4.9&lt;br /&gt;
|linux-yocto_4.14&lt;br /&gt;
|linux-yocto_4.18&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot;&lt;br /&gt;
|Yocto Project 2.5&lt;br /&gt;
|linux-yocto_4.9&lt;br /&gt;
|linux-yocto_4.14&lt;br /&gt;
|linux-yocto_4.15&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot;&lt;br /&gt;
|Yocto Project 2.4&lt;br /&gt;
|linux-yocto_4.9&lt;br /&gt;
|linux-yocto_4.9&lt;br /&gt;
|linux-yocto_4.12&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot;&lt;br /&gt;
|Yocto Project 2.3&lt;br /&gt;
|linux-yocto_4.1&lt;br /&gt;
|linux-yocto_4.9&lt;br /&gt;
|linux-yocto_4.10&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot;&lt;br /&gt;
|Yocto Project 2.2&lt;br /&gt;
|linux-yocto_4.1&lt;br /&gt;
|linux-yocto_4.4&lt;br /&gt;
|linux-yocto_4.8&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot;&lt;br /&gt;
|Yocto Project 2.1&lt;br /&gt;
|linux-yocto_4.1&lt;br /&gt;
|linux-yocto_4.1&lt;br /&gt;
|linux-yocto_4.4&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot;&lt;br /&gt;
|Yocto Project 2.0&lt;br /&gt;
|linux-yocto_3.14&lt;br /&gt;
|linux-yocto_3.14&lt;br /&gt;
|linux-yocto_4.1&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot;&lt;br /&gt;
|Yocto Project 1.8&lt;br /&gt;
|linux-yocto_3.14&lt;br /&gt;
|linux-yocto_3.14&lt;br /&gt;
|linux-yocto_3.19&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot;&lt;br /&gt;
|Yocto Project 1.7&lt;br /&gt;
|linux-yocto_3.10&lt;br /&gt;
|linux-yocto_3.14&lt;br /&gt;
|linux-yocto_3.17&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot;&lt;br /&gt;
|Yocto Project 1.6&lt;br /&gt;
|linux-yocto_3.10&lt;br /&gt;
|linux-yocto_3.10&lt;br /&gt;
|linux-yocto_3.14&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot;&lt;br /&gt;
|Yocto Project 1.5&lt;br /&gt;
|linux-yocto_3.4&lt;br /&gt;
|linux-yocto_3.4&lt;br /&gt;
|linux-yocto_3.10&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot;&lt;br /&gt;
|Yocto Project 1.4&lt;br /&gt;
|linux-yocto_3.4&lt;br /&gt;
|linux-yocto_3.4&lt;br /&gt;
|linux-yocto_3.8&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot;&lt;br /&gt;
|Yocto Project 1.3&lt;br /&gt;
|linux-yocto_3.0&lt;br /&gt;
|linux-yocto_3.2&lt;br /&gt;
|linux-yocto_3.4&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot;&lt;br /&gt;
|Yocto Project 1.2&lt;br /&gt;
|linux-yocto_3.0&lt;br /&gt;
|linux-yocto_3.0&lt;br /&gt;
|linux-yocto_3.2&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot;&lt;br /&gt;
|Yocto Project 1.1&lt;br /&gt;
|linux-yocto_2.6&lt;br /&gt;
|linux-yocto_2.6&lt;br /&gt;
|linux-yocto_3.0&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot;&lt;br /&gt;
|Yocto Project 1.0&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|linux-yocto_2.6&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
==Version Lifecycle / Support==&lt;br /&gt;
While we make every effort to select a longterm Linux kernel for each new release kernel, occasionally our releases do not align with those of the Linux kernel, as was the case with the Yocto Project 1.4 release and the 3.8 kernel. In these cases, the non-longterm kernel version will be dropped in the subsequent release, rather than becoming the next LTSI kernel. This can be seen in the 1.5 release where 3.8 was effectively dropped, 3.4 remained as the LTSI kernel, and 3.10 was added as the new release kernel.&lt;br /&gt;
&lt;br /&gt;
In terms of support, the linux-yocto recipes are treated the same as all the other recipes in a given release. They are supported for the life of that release [[http://wiki.yoctoproject.org/wiki/Releases 3]] and the corresponding stable updates [[http://wiki.yoctoproject.org/wiki/Stable_branch_maintenance 4]].&lt;br /&gt;
&lt;br /&gt;
==FAQ==&lt;br /&gt;
*Q: Why don&#039;t you support an LTSI kernel across new Yocto Project releases for as long as the that LTSI kernel is supported by the LTSI project?&lt;br /&gt;
**A: A new LTSI kernel is selected once per year and supported for two years. This allows for multiple active LTSI kernels at any point in time. It would be infeasible purely from a support and QA perspective to support all of them in every release of the Yocto Project. Furthermore, the LTSI kernel is targeted at productization teams that want to minimize change across the life of their product. It stands to reason if the kernel version must remain static, then so should the OS stack on top of it. For these reasons, LTSI kernel versions are supported for the life of the release they originally ship with.&lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
# [https://www.kernel.org/category/releases.html Long Term Support Kernel Schedule]&lt;br /&gt;
# [http://ltsi.linuxfoundation.org/participate-in-ltsi/ltsi-development-guide LTSI Development Guide]&lt;br /&gt;
# [https://wiki.yoctoproject.org/wiki/Releases Yocto Project Releases]&lt;br /&gt;
# [https://wiki.yoctoproject.org/wiki/Stable_branch_maintenance Yocto Project Stable Branch Maintenance]&lt;/div&gt;</summary>
		<author><name>Trevor Woerner</name></author>
	</entry>
	<entry>
		<id>https://wiki.yoctoproject.org/wiki/index.php?title=Linux_Yocto&amp;diff=85502</id>
		<title>Linux Yocto</title>
		<link rel="alternate" type="text/html" href="https://wiki.yoctoproject.org/wiki/index.php?title=Linux_Yocto&amp;diff=85502"/>
		<updated>2022-10-20T15:41:46Z</updated>

		<summary type="html">&lt;p&gt;Trevor Woerner: /* Prior Releases */ updated to add entries post-dunfell&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;==Release Cadence==&lt;br /&gt;
Each release of the Yocto Project, roughly &#039;&#039;&#039;every six months&#039;&#039;&#039;, includes &#039;&#039;&#039;two or three versions&#039;&#039;&#039; of the Linux kernel with a broad range of hardware support. While tooling is provided to use any Linux kernel you wish, the linux-yocto Linux kernel recipes are tested with all the emulated targets, the core hardware BSPs, and some vendor layers.&lt;br /&gt;
&lt;br /&gt;
While the timing of Linux kernel releases is the domain of the upstream kernel maintainers and beyond the control of the linux-yocto maintainers, making version roadmaps predictions at best, the Yocto Project commits to providing a &#039;&#039;&#039;near-current, LTS [[https://www.kernel.org/category/releases.html 1]] and a latest LTSI&#039;&#039;&#039; [[https://ltsi.linuxfoundation.org/software/releases/ 2]] linux-yocto version with each release of the Yocto Project. The final selection of the versions is made approximately two weeks prior to the feature freeze date for the release.&lt;br /&gt;
&lt;br /&gt;
==Prior Releases==&lt;br /&gt;
{|border=&amp;quot;1&amp;quot; {{table}}&lt;br /&gt;
| align=&amp;quot;center&amp;quot; style=&amp;quot;background:#f0f0f0;&amp;quot;|&#039;&#039;&#039;Yocto Project Release&#039;&#039;&#039;&lt;br /&gt;
| align=&amp;quot;center&amp;quot; style=&amp;quot;background:#f0f0f0;&amp;quot;|&#039;&#039;&#039;LTSI Kernel Version&#039;&#039;&#039;&lt;br /&gt;
| align=&amp;quot;center&amp;quot; style=&amp;quot;background:#f0f0f0;&amp;quot;|&#039;&#039;&#039;LTS Kernel Version&#039;&#039;&#039;&lt;br /&gt;
| align=&amp;quot;center&amp;quot; style=&amp;quot;background:#f0f0f0;&amp;quot;|&#039;&#039;&#039;Released Kernel Version&#039;&#039;&#039;&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot;&lt;br /&gt;
|Yocto Project 4.1&lt;br /&gt;
|&lt;br /&gt;
|linux-yocto_5.15&lt;br /&gt;
|linux-yocto_5.19&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot;&lt;br /&gt;
|Yocto Project 4.0&lt;br /&gt;
|&lt;br /&gt;
|linux-yocto_5.10&amp;lt;br&amp;gt;linux-yocto_5.15&lt;br /&gt;
|&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot;&lt;br /&gt;
|Yocto Project 3.4&lt;br /&gt;
|&lt;br /&gt;
|linux-yocto_5.10&lt;br /&gt;
|linux-yocto_5.14&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot;&lt;br /&gt;
|Yocto Project 3.3&lt;br /&gt;
|&lt;br /&gt;
|linux-yocto_5.4&amp;lt;br&amp;gt;linux-yocto_5.10&lt;br /&gt;
|&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot;&lt;br /&gt;
|Yocto Project 3.2&lt;br /&gt;
|&lt;br /&gt;
|linux-yocto_5.4&lt;br /&gt;
|linux-yocto_5.8&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot;&lt;br /&gt;
|Yocto Project 3.1&lt;br /&gt;
|&lt;br /&gt;
|linux-yocto_5.4&lt;br /&gt;
|&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot;&lt;br /&gt;
|Yocto Project 3.0&lt;br /&gt;
|&lt;br /&gt;
|linux-yocto_4.19&lt;br /&gt;
|linux-yocto_5.2&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot;&lt;br /&gt;
|Yocto Project 2.7&lt;br /&gt;
|&lt;br /&gt;
|linux-yocto_4.19&lt;br /&gt;
|linux-yocto_5.0&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot;&lt;br /&gt;
|Yocto Project 2.6&lt;br /&gt;
|linux-yocto_4.9&lt;br /&gt;
|linux-yocto_4.14&lt;br /&gt;
|linux-yocto_4.18&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot;&lt;br /&gt;
|Yocto Project 2.5&lt;br /&gt;
|linux-yocto_4.9&lt;br /&gt;
|linux-yocto_4.14&lt;br /&gt;
|linux-yocto_4.15&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot;&lt;br /&gt;
|Yocto Project 2.4&lt;br /&gt;
|linux-yocto_4.9&lt;br /&gt;
|linux-yocto_4.9&lt;br /&gt;
|linux-yocto_4.12&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot;&lt;br /&gt;
|Yocto Project 2.3&lt;br /&gt;
|linux-yocto_4.1&lt;br /&gt;
|linux-yocto_4.9&lt;br /&gt;
|linux-yocto_4.10&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot;&lt;br /&gt;
|Yocto Project 2.2&lt;br /&gt;
|linux-yocto_4.1&lt;br /&gt;
|linux-yocto_4.4&lt;br /&gt;
|linux-yocto_4.8&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot;&lt;br /&gt;
|Yocto Project 2.1&lt;br /&gt;
|linux-yocto_4.1&lt;br /&gt;
|linux-yocto_4.1&lt;br /&gt;
|linux-yocto_4.4&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot;&lt;br /&gt;
|Yocto Project 2.0&lt;br /&gt;
|linux-yocto_3.14&lt;br /&gt;
|linux-yocto_3.14&lt;br /&gt;
|linux-yocto_4.1&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot;&lt;br /&gt;
|Yocto Project 1.8&lt;br /&gt;
|linux-yocto_3.14&lt;br /&gt;
|linux-yocto_3.14&lt;br /&gt;
|linux-yocto_3.19&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot;&lt;br /&gt;
|Yocto Project 1.7&lt;br /&gt;
|linux-yocto_3.10&lt;br /&gt;
|linux-yocto_3.14&lt;br /&gt;
|linux-yocto_3.17&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot;&lt;br /&gt;
|Yocto Project 1.6&lt;br /&gt;
|linux-yocto_3.10&lt;br /&gt;
|linux-yocto_3.10&lt;br /&gt;
|linux-yocto_3.14&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot;&lt;br /&gt;
|Yocto Project 1.5&lt;br /&gt;
|linux-yocto_3.4&lt;br /&gt;
|linux-yocto_3.4&lt;br /&gt;
|linux-yocto_3.10&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot;&lt;br /&gt;
|Yocto Project 1.4&lt;br /&gt;
|linux-yocto_3.4&lt;br /&gt;
|linux-yocto_3.4&lt;br /&gt;
|linux-yocto_3.8&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot;&lt;br /&gt;
|Yocto Project 1.3&lt;br /&gt;
|linux-yocto_3.0&lt;br /&gt;
|linux-yocto_3.2&lt;br /&gt;
|linux-yocto_3.4&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot;&lt;br /&gt;
|Yocto Project 1.2&lt;br /&gt;
|linux-yocto_3.0&lt;br /&gt;
|linux-yocto_3.0&lt;br /&gt;
|linux-yocto_3.2&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot;&lt;br /&gt;
|Yocto Project 1.1&lt;br /&gt;
|linux-yocto_2.6&lt;br /&gt;
|linux-yocto_2.6&lt;br /&gt;
|linux-yocto_3.0&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot;&lt;br /&gt;
|Yocto Project 1.0&lt;br /&gt;
|&lt;br /&gt;
|&lt;br /&gt;
|linux-yocto_2.6&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
==Version Lifecycle / Support==&lt;br /&gt;
While we make every effort to select a longterm Linux kernel for each new release kernel, occasionally our releases do not align with those of the Linux kernel, as was the case with the Yocto Project 1.4 release and the 3.8 kernel. In these cases, the non-longterm kernel version will be dropped in the subsequent release, rather than becoming the next LTSI kernel. This can be seen in the 1.5 release where 3.8 was effectively dropped, 3.4 remained as the LTSI kernel, and 3.10 was added as the new release kernel.&lt;br /&gt;
&lt;br /&gt;
In terms of support, the linux-yocto recipes are treated the same as all the other recipes in a given release. They are supported for the life of that release [[http://wiki.yoctoproject.org/wiki/Releases 3]] and the corresponding stable updates [[http://wiki.yoctoproject.org/wiki/Stable_branch_maintenance 4]].&lt;br /&gt;
&lt;br /&gt;
==FAQ==&lt;br /&gt;
*Q: Why don&#039;t you support an LTSI kernel across new Yocto Project releases for as long as the that LTSI kernel is supported by the LTSI project?&lt;br /&gt;
**A: A new LTSI kernel is selected once per year and supported for two years. This allows for multiple active LTSI kernels at any point in time. It would be infeasible purely from a support and QA perspective to support all of them in every release of the Yocto Project. Furthermore, the LTSI kernel is targeted at productization teams that want to minimize change across the life of their product. It stands to reason if the kernel version must remain static, then so should the OS stack on top of it. For these reasons, LTSI kernel versions are supported for the life of the release they originally ship with.&lt;br /&gt;
&lt;br /&gt;
==References==&lt;br /&gt;
# [https://www.kernel.org/category/releases.html Long Term Support Kernel Schedule]&lt;br /&gt;
# [http://ltsi.linuxfoundation.org/participate-in-ltsi/ltsi-development-guide LTSI Development Guide]&lt;br /&gt;
# [https://wiki.yoctoproject.org/wiki/Releases Yocto Project Releases]&lt;br /&gt;
# [https://wiki.yoctoproject.org/wiki/Stable_branch_maintenance Yocto Project Stable Branch Maintenance]&lt;/div&gt;</summary>
		<author><name>Trevor Woerner</name></author>
	</entry>
	<entry>
		<id>https://wiki.yoctoproject.org/wiki/index.php?title=YoctoProject_Summit_yps2022.05&amp;diff=85260</id>
		<title>YoctoProject Summit yps2022.05</title>
		<link rel="alternate" type="text/html" href="https://wiki.yoctoproject.org/wiki/index.php?title=YoctoProject_Summit_yps2022.05&amp;diff=85260"/>
		<updated>2022-05-04T16:49:46Z</updated>

		<summary type="html">&lt;p&gt;Trevor Woerner: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= The Yocto Project Summit 2022.05 =&lt;br /&gt;
The Yocto Project Summit, yps2022.05, is a virtual conference from May 17-19, 2022 to gather members of the Yocto Project community together to discuss ideas and present information related to The Yocto Project.&lt;br /&gt;
&lt;br /&gt;
== Organizing Committee ==&lt;br /&gt;
The organizing committee consists of (alphabetical by first name):&lt;br /&gt;
* Armin Kuster&lt;br /&gt;
* Behan Webster&lt;br /&gt;
* David Reyna&lt;br /&gt;
* Josef Holzmayr-Khosh Amoz&lt;br /&gt;
* Nicolas Dechesne (YP Community Manager)&lt;br /&gt;
* Trevor Woerner&lt;br /&gt;
&lt;br /&gt;
== Papers Committee ==&lt;br /&gt;
The papers committee consists of:&lt;br /&gt;
* (the organizing committee)&lt;br /&gt;
&lt;br /&gt;
== Platforms ==&lt;br /&gt;
In terms of platforms we&#039;re using:&lt;br /&gt;
* pretalx for the CfP and schedule&lt;br /&gt;
* the LF&#039;s cvent for registration&lt;br /&gt;
* Zoom for the conference video&lt;br /&gt;
* irc for the conference chat (channel #yocto-summit-2022.05 on Libera.Chat)&lt;br /&gt;
* Digital Ocean for the hands-on classes&lt;br /&gt;
&lt;br /&gt;
== Hands-on Servers Information ==&lt;br /&gt;
(coming soon!)&lt;br /&gt;
&lt;br /&gt;
== For more information ==&lt;br /&gt;
* https://www.yoctoproject.org/yocto-project-summit-2022-05/&lt;br /&gt;
* https://pretalx.com/yocto-project-summit-2022-05/&lt;br /&gt;
&lt;br /&gt;
== Slide template for presenters ==&lt;br /&gt;
* https://docs.google.com/presentation/d/1Z6FSvgyaDBZtPC1GtT6iQiMflArKl0BvNMP6rSHqnEg/&lt;br /&gt;
** keep the first and last slides&lt;br /&gt;
** edit the first slide to include your name, presentation title, and (optionally) your company&lt;br /&gt;
** the rest of the slides are examples and can be duplicated, edited, and/or removed&lt;br /&gt;
** please upload your finished slides to your specific event in pretalx&lt;/div&gt;</summary>
		<author><name>Trevor Woerner</name></author>
	</entry>
	<entry>
		<id>https://wiki.yoctoproject.org/wiki/index.php?title=YoctoProject_Summit_yps2022.05&amp;diff=85259</id>
		<title>YoctoProject Summit yps2022.05</title>
		<link rel="alternate" type="text/html" href="https://wiki.yoctoproject.org/wiki/index.php?title=YoctoProject_Summit_yps2022.05&amp;diff=85259"/>
		<updated>2022-05-04T00:56:42Z</updated>

		<summary type="html">&lt;p&gt;Trevor Woerner: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= The Yocto Project Summit 2022.05 =&lt;br /&gt;
The Yocto Project Summit, yps2022.05, is a virtual conference from May 17-19, 2022 to gather members of the Yocto Project community together to discuss ideas and present information related to The Yocto Project.&lt;br /&gt;
&lt;br /&gt;
== Organizing Committee ==&lt;br /&gt;
The organizing committee consists of (alphabetical by first name):&lt;br /&gt;
* Armin Kuster&lt;br /&gt;
* Behan Webster&lt;br /&gt;
* David Reyna&lt;br /&gt;
* Josef Holzmayr-Khosh Amoz&lt;br /&gt;
* Nicolas Dechesne (YP Community Manager)&lt;br /&gt;
* Trevor Woerner&lt;br /&gt;
&lt;br /&gt;
== Papers Committee ==&lt;br /&gt;
The papers committee consists of:&lt;br /&gt;
* (the organizing committee)&lt;br /&gt;
&lt;br /&gt;
== Platforms ==&lt;br /&gt;
In terms of platforms we&#039;re using:&lt;br /&gt;
* pretalx for the CfP and schedule&lt;br /&gt;
* the LF&#039;s cvent for registration&lt;br /&gt;
* Zoom for the conference video&lt;br /&gt;
* irc for the conference chat (channel #yocto-summit-2022.05 on Libera.Chat)&lt;br /&gt;
* Digital Ocean for the hands-on classes&lt;br /&gt;
&lt;br /&gt;
== Hands-on Servers Information ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== For more information ==&lt;br /&gt;
* https://www.yoctoproject.org/yocto-project-summit-2022-05/&lt;br /&gt;
* https://pretalx.com/yocto-project-summit-2022-05/&lt;br /&gt;
&lt;br /&gt;
== Slide template for presenters ==&lt;br /&gt;
* https://docs.google.com/presentation/d/1Z6FSvgyaDBZtPC1GtT6iQiMflArKl0BvNMP6rSHqnEg/&lt;br /&gt;
** keep the first and last slides&lt;br /&gt;
** edit the first slide to include your name, presentation title, and (optionally) your company&lt;br /&gt;
** the rest of the slides are examples and can be duplicated, edited, and/or removed&lt;br /&gt;
** please upload your finished slides to your specific event in pretalx&lt;/div&gt;</summary>
		<author><name>Trevor Woerner</name></author>
	</entry>
	<entry>
		<id>https://wiki.yoctoproject.org/wiki/index.php?title=YoctoProject_Summit_yps2022.05&amp;diff=85258</id>
		<title>YoctoProject Summit yps2022.05</title>
		<link rel="alternate" type="text/html" href="https://wiki.yoctoproject.org/wiki/index.php?title=YoctoProject_Summit_yps2022.05&amp;diff=85258"/>
		<updated>2022-05-04T00:29:30Z</updated>

		<summary type="html">&lt;p&gt;Trevor Woerner: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= The Yocto Project Summit 2022.05 =&lt;br /&gt;
The Yocto Project Summit, yps2022.05, is a virtual conference from May 17-19, 2022 to gather members of the Yocto Project community together to discuss ideas and present information related to The Yocto Project.&lt;br /&gt;
&lt;br /&gt;
== Organizing Committee ==&lt;br /&gt;
The organizing committee consists of (alphabetical by first name):&lt;br /&gt;
* Armin Kuster&lt;br /&gt;
* Behan Webster&lt;br /&gt;
* David Reyna&lt;br /&gt;
* Josef Holzmayr-Khosh Amoz&lt;br /&gt;
* Nicolas Dechesne (YP Community Manager)&lt;br /&gt;
* Trevor Woerner&lt;br /&gt;
&lt;br /&gt;
== Papers Committee ==&lt;br /&gt;
The papers committee consists of:&lt;br /&gt;
* (the organizing committee)&lt;br /&gt;
&lt;br /&gt;
== Platforms ==&lt;br /&gt;
In terms of platforms we&#039;re using:&lt;br /&gt;
* pretalx for the CfP and schedule&lt;br /&gt;
* the LF&#039;s cvent for registration&lt;br /&gt;
* Zoom for the conference video&lt;br /&gt;
* irc for the conference chat (channel #yocto-summit-2022.05 on Libera.Chat)&lt;br /&gt;
* Digital Ocean for the hands-on classes&lt;br /&gt;
&lt;br /&gt;
== Hands-on Servers Information ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== For more information ==&lt;br /&gt;
* https://www.yoctoproject.org/yocto-project-summit-2022-05/&lt;br /&gt;
* https://pretalx.com/yocto-project-summit-2022-05/&lt;br /&gt;
&lt;br /&gt;
== Slide template for presenters ==&lt;br /&gt;
* https://docs.google.com/presentation/d/1Z6FSvgyaDBZtPC1GtT6iQiMflArKl0BvNMP6rSHqnEg/&lt;br /&gt;
** keep the first and last slides&lt;br /&gt;
** edit the first slide to include your name, presentation title, and (optionally) your company&lt;br /&gt;
** the rest of the slides are examples and can be duplicated, edited, and/or removed&lt;br /&gt;
** please upload your finished slides to your specific event in TBD&lt;/div&gt;</summary>
		<author><name>Trevor Woerner</name></author>
	</entry>
	<entry>
		<id>https://wiki.yoctoproject.org/wiki/index.php?title=YoctoProject_Summit_yps2022.05&amp;diff=85255</id>
		<title>YoctoProject Summit yps2022.05</title>
		<link rel="alternate" type="text/html" href="https://wiki.yoctoproject.org/wiki/index.php?title=YoctoProject_Summit_yps2022.05&amp;diff=85255"/>
		<updated>2022-04-29T17:36:42Z</updated>

		<summary type="html">&lt;p&gt;Trevor Woerner: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= The Yocto Project Summit 2022.05 =&lt;br /&gt;
The Yocto Project Summit, yps2022.05, is a virtual conference from May 17-19, 2022 to gather members of the Yocto Project community together to discuss ideas and present information related to The Yocto Project.&lt;br /&gt;
&lt;br /&gt;
== Organizing Committee ==&lt;br /&gt;
The organizing committee consists of (alphabetical by first name):&lt;br /&gt;
* Armin Kuster&lt;br /&gt;
* Behan Webster&lt;br /&gt;
* David Reyna&lt;br /&gt;
* Josef Holzmayr-Khosh Amoz&lt;br /&gt;
* Nicolas Dechesne (YP Community Manager)&lt;br /&gt;
* Trevor Woerner&lt;br /&gt;
&lt;br /&gt;
== Papers Committee ==&lt;br /&gt;
The papers committee consists of:&lt;br /&gt;
* (the organizing committee)&lt;br /&gt;
&lt;br /&gt;
== Platforms ==&lt;br /&gt;
In terms of platforms we&#039;re using:&lt;br /&gt;
* pretalx for the CfP and schedule&lt;br /&gt;
* the LF&#039;s cvent for registration&lt;br /&gt;
* Zoom for the conference video&lt;br /&gt;
* irc for the conference chat (channel #yocto-summit-2022.05 on Libera.Chat)&lt;br /&gt;
* Digital Ocean for the hands-on classes&lt;br /&gt;
&lt;br /&gt;
== Digital Ocean Information ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== For more information ==&lt;br /&gt;
* https://www.yoctoproject.org/yocto-project-summit-2022-05/&lt;br /&gt;
* https://pretalx.com/yocto-project-summit-2022-05/&lt;br /&gt;
&lt;br /&gt;
== Slide template for presenters ==&lt;br /&gt;
* https://docs.google.com/presentation/d/1Z6FSvgyaDBZtPC1GtT6iQiMflArKl0BvNMP6rSHqnEg/&lt;br /&gt;
** keep the first and last slides&lt;br /&gt;
** edit the first slide to include your name, presentation title, and (optionally) your company&lt;br /&gt;
** the rest of the slides are examples and can be duplicated, edited, and/or removed&lt;br /&gt;
** please upload your finished slides to your specific event in TBD&lt;/div&gt;</summary>
		<author><name>Trevor Woerner</name></author>
	</entry>
	<entry>
		<id>https://wiki.yoctoproject.org/wiki/index.php?title=YoctoProject_Summit_yps2022.05&amp;diff=85254</id>
		<title>YoctoProject Summit yps2022.05</title>
		<link rel="alternate" type="text/html" href="https://wiki.yoctoproject.org/wiki/index.php?title=YoctoProject_Summit_yps2022.05&amp;diff=85254"/>
		<updated>2022-04-29T17:33:33Z</updated>

		<summary type="html">&lt;p&gt;Trevor Woerner: add section titles&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= The Yocto Project Summit 2022.05 =&lt;br /&gt;
yps2022.05&lt;br /&gt;
&lt;br /&gt;
== Organizing Committee ==&lt;br /&gt;
The organizing committee consists of (alphabetical by first name):&lt;br /&gt;
* Armin Kuster&lt;br /&gt;
* Behan Webster&lt;br /&gt;
* David Reyna&lt;br /&gt;
* Josef Holzmayr-Khosh Amoz&lt;br /&gt;
* Nicolas Dechesne (YP Community Manager)&lt;br /&gt;
* Trevor Woerner&lt;br /&gt;
&lt;br /&gt;
== Papers Committee ==&lt;br /&gt;
The papers committee consists of:&lt;br /&gt;
* (the organizing committee)&lt;br /&gt;
&lt;br /&gt;
== Platforms ==&lt;br /&gt;
In terms of platforms we&#039;re using:&lt;br /&gt;
* pretalx for the CfP and schedule&lt;br /&gt;
* the LF&#039;s cvent for registration&lt;br /&gt;
* Zoom for the conference video&lt;br /&gt;
* irc for the conference chat (channel #yocto-summit-2022.05 on Libera.Chat)&lt;br /&gt;
* Digital Ocean for the hands-on classes&lt;br /&gt;
&lt;br /&gt;
== Digital Ocean Information ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== For more information ==&lt;br /&gt;
* https://www.yoctoproject.org/yocto-project-summit-2022-05/&lt;br /&gt;
* https://pretalx.com/yocto-project-summit-2022-05/&lt;br /&gt;
&lt;br /&gt;
== Slide template for presenters ==&lt;br /&gt;
* https://docs.google.com/presentation/d/1Z6FSvgyaDBZtPC1GtT6iQiMflArKl0BvNMP6rSHqnEg/&lt;br /&gt;
** keep the first and last slides&lt;br /&gt;
** edit the first slide to include your name, presentation title, and (optionally) your company&lt;br /&gt;
** the rest of the slides are examples and can be duplicated, edited, and/or removed&lt;br /&gt;
** please upload your finished slides to your specific event in TBD&lt;/div&gt;</summary>
		<author><name>Trevor Woerner</name></author>
	</entry>
	<entry>
		<id>https://wiki.yoctoproject.org/wiki/index.php?title=YoctoProject_Summit_yps2022.05&amp;diff=85253</id>
		<title>YoctoProject Summit yps2022.05</title>
		<link rel="alternate" type="text/html" href="https://wiki.yoctoproject.org/wiki/index.php?title=YoctoProject_Summit_yps2022.05&amp;diff=85253"/>
		<updated>2022-04-29T17:28:26Z</updated>

		<summary type="html">&lt;p&gt;Trevor Woerner: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;The organizing committee consists of (alphabetical by first name):&lt;br /&gt;
* Armin Kuster&lt;br /&gt;
* Behan Webster&lt;br /&gt;
* David Reyna&lt;br /&gt;
* Josef Holzmayr-Khosh Amoz&lt;br /&gt;
* Nicolas Dechesne (YP Community Manager)&lt;br /&gt;
* Trevor Woerner&lt;br /&gt;
&lt;br /&gt;
The papers committee consists of:&lt;br /&gt;
* (the organizing committee)&lt;br /&gt;
&lt;br /&gt;
In terms of platforms we&#039;re using:&lt;br /&gt;
* pretalx for the CfP and schedule&lt;br /&gt;
* the LF&#039;s cvent for registration&lt;br /&gt;
* Zoom for the conference video&lt;br /&gt;
* irc for the conference chat (channel #yocto-summit-2022.05 on Libera.Chat)&lt;br /&gt;
* Digital Ocean for the hands-on classes&lt;br /&gt;
&lt;br /&gt;
For more information:&lt;br /&gt;
* https://www.yoctoproject.org/yocto-project-summit-2022-05/&lt;br /&gt;
* https://pretalx.com/yocto-project-summit-2022-05/&lt;br /&gt;
&lt;br /&gt;
Slide template for presenters:&lt;br /&gt;
* https://docs.google.com/presentation/d/1Z6FSvgyaDBZtPC1GtT6iQiMflArKl0BvNMP6rSHqnEg/&lt;br /&gt;
** keep the first and last slides&lt;br /&gt;
** edit the first slide to include your name, presentation title, and (optionally) your company&lt;br /&gt;
** the rest of the slides are examples and can be duplicated, edited, and/or removed&lt;br /&gt;
** please upload your finished slides to your specific event in TBD&lt;/div&gt;</summary>
		<author><name>Trevor Woerner</name></author>
	</entry>
	<entry>
		<id>https://wiki.yoctoproject.org/wiki/index.php?title=YoctoProject_Summit_yps2022.05&amp;diff=85252</id>
		<title>YoctoProject Summit yps2022.05</title>
		<link rel="alternate" type="text/html" href="https://wiki.yoctoproject.org/wiki/index.php?title=YoctoProject_Summit_yps2022.05&amp;diff=85252"/>
		<updated>2022-04-29T17:23:06Z</updated>

		<summary type="html">&lt;p&gt;Trevor Woerner: add irc channel and server&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;The organizing committee consists of (alphabetical by first name):&lt;br /&gt;
* Armin Kuster&lt;br /&gt;
* Behan Webster&lt;br /&gt;
* David Reyna&lt;br /&gt;
* Josef Holzmayr-Khosh Amoz&lt;br /&gt;
* Nicolas Dechesne (YP Community Manager)&lt;br /&gt;
* Trevor Woerner&lt;br /&gt;
&lt;br /&gt;
The papers committee consists of:&lt;br /&gt;
* (the organizing committee)&lt;br /&gt;
&lt;br /&gt;
In terms of platforms we&#039;re using:&lt;br /&gt;
* pretalx for the CfP and schedule&lt;br /&gt;
* the LF&#039;s cvent for registration&lt;br /&gt;
* Zoom for the conference video&lt;br /&gt;
* irc for the conference chat (channel #yocto-summit-2022.05 on Libera.Chat)&lt;br /&gt;
&lt;br /&gt;
For more information:&lt;br /&gt;
* https://www.yoctoproject.org/yocto-project-summit-2022-05/&lt;br /&gt;
* https://pretalx.com/yocto-project-summit-2022-05/&lt;br /&gt;
&lt;br /&gt;
Slide template for presenters:&lt;br /&gt;
* https://docs.google.com/presentation/d/1Z6FSvgyaDBZtPC1GtT6iQiMflArKl0BvNMP6rSHqnEg/&lt;br /&gt;
** keep the first and last slides&lt;br /&gt;
** edit the first slide to include your name, presentation title, and (optionally) your company&lt;br /&gt;
** the rest of the slides are examples and can be duplicated, edited, and/or removed&lt;br /&gt;
** please upload your finished slides to your specific event in TBD&lt;/div&gt;</summary>
		<author><name>Trevor Woerner</name></author>
	</entry>
	<entry>
		<id>https://wiki.yoctoproject.org/wiki/index.php?title=YoctoProject_Summit_yps2022.05&amp;diff=85251</id>
		<title>YoctoProject Summit yps2022.05</title>
		<link rel="alternate" type="text/html" href="https://wiki.yoctoproject.org/wiki/index.php?title=YoctoProject_Summit_yps2022.05&amp;diff=85251"/>
		<updated>2022-04-29T17:19:26Z</updated>

		<summary type="html">&lt;p&gt;Trevor Woerner: add slide template for yps2022.05&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;The organizing committee consists of (alphabetical by first name):&lt;br /&gt;
* Armin Kuster&lt;br /&gt;
* Behan Webster&lt;br /&gt;
* David Reyna&lt;br /&gt;
* Josef Holzmayr-Khosh Amoz&lt;br /&gt;
* Nicolas Dechesne (YP Community Manager)&lt;br /&gt;
* Trevor Woerner&lt;br /&gt;
&lt;br /&gt;
The papers committee consists of:&lt;br /&gt;
* (the organizing committee)&lt;br /&gt;
&lt;br /&gt;
In terms of platforms we&#039;re using:&lt;br /&gt;
* pretalx for the CfP and schedule&lt;br /&gt;
* the LF&#039;s cvent for registration&lt;br /&gt;
* Zoom for the conference video&lt;br /&gt;
* irc for the conference chat&lt;br /&gt;
&lt;br /&gt;
For more information:&lt;br /&gt;
* https://www.yoctoproject.org/yocto-project-summit-2022-05/&lt;br /&gt;
* https://pretalx.com/yocto-project-summit-2022-05/&lt;br /&gt;
&lt;br /&gt;
Slide template for presenters:&lt;br /&gt;
* https://docs.google.com/presentation/d/1Z6FSvgyaDBZtPC1GtT6iQiMflArKl0BvNMP6rSHqnEg/&lt;br /&gt;
** keep the first and last slides&lt;br /&gt;
** edit the first slide to include your name, presentation title, and (optionally) your company&lt;br /&gt;
** the rest of the slides are examples and can be duplicated, edited, and/or removed&lt;br /&gt;
** please upload your finished slides to your specific event in TBD&lt;/div&gt;</summary>
		<author><name>Trevor Woerner</name></author>
	</entry>
	<entry>
		<id>https://wiki.yoctoproject.org/wiki/index.php?title=YoctoProject_Summit_yps2022.05&amp;diff=85250</id>
		<title>YoctoProject Summit yps2022.05</title>
		<link rel="alternate" type="text/html" href="https://wiki.yoctoproject.org/wiki/index.php?title=YoctoProject_Summit_yps2022.05&amp;diff=85250"/>
		<updated>2022-04-29T16:20:59Z</updated>

		<summary type="html">&lt;p&gt;Trevor Woerner: initial content, copied from last year&amp;#039;s YPS&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;The organizing committee consists of (alphabetical by first name):&lt;br /&gt;
* Armin Kuster&lt;br /&gt;
* Behan Webster&lt;br /&gt;
* David Reyna&lt;br /&gt;
* Josef Holzmayr-Khosh Amoz&lt;br /&gt;
* Nicolas Dechesne (YP Community Manager)&lt;br /&gt;
* Trevor Woerner&lt;br /&gt;
&lt;br /&gt;
The papers committee consists of:&lt;br /&gt;
* (the organizing committee)&lt;br /&gt;
&lt;br /&gt;
In terms of platforms we&#039;re using:&lt;br /&gt;
* pretalx for the CfP and schedule&lt;br /&gt;
* the LF&#039;s cvent for registration&lt;br /&gt;
* Zoom for the conference video&lt;br /&gt;
* irc for the conference chat&lt;br /&gt;
&lt;br /&gt;
For more information:&lt;br /&gt;
* https://www.yoctoproject.org/yocto-project-summit-2022-05/&lt;br /&gt;
* https://pretalx.com/yocto-project-summit-2022-05/&lt;br /&gt;
&lt;br /&gt;
Slide template for presenters:&lt;br /&gt;
* TBD&lt;br /&gt;
** keep the first and last slides&lt;br /&gt;
** edit the first slide to include your name, presentation title, and (optionally) your company&lt;br /&gt;
** the rest of the slides are examples and can be duplicated, edited, and/or removed&lt;br /&gt;
** please upload your finished slides to your specific event in TBD&lt;/div&gt;</summary>
		<author><name>Trevor Woerner</name></author>
	</entry>
	<entry>
		<id>https://wiki.yoctoproject.org/wiki/index.php?title=YoctoProjectEvents&amp;diff=85247</id>
		<title>YoctoProjectEvents</title>
		<link rel="alternate" type="text/html" href="https://wiki.yoctoproject.org/wiki/index.php?title=YoctoProjectEvents&amp;diff=85247"/>
		<updated>2022-04-29T16:14:57Z</updated>

		<summary type="html">&lt;p&gt;Trevor Woerner: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Traditionally the Linux Foundation organizes the Embedded Linux Conference -- one in North America (ELC) and one in Europe (ELCE). The Yocto Project often has a considerable presence at these events in the form of:&lt;br /&gt;
* talks submitted/presented about The Yocto Project, OpenEmbedded, and related technologies including a community BoF (Birds of a Feather) session&lt;br /&gt;
* a 1-day pre-event OpenEmbedded Developers Day (OEDAM [OpenEmbedded Developers Americas Meeting] for ELC and OEDEM [OpenEmbedded Developers European Meeting] for ELCE)&lt;br /&gt;
* a 1-day post-event DevDay&lt;br /&gt;
* a conference booth in the ELC/ELCE event hall, usually with demos&lt;br /&gt;
&lt;br /&gt;
The ELC/ELCE events are often co-located with other LF-related events such as: the Linux Security Summit, Zephyr Summit, KVM Forum, Open Source Summit, etc… Starting around 2019, in an effort to better align some of these events, the early Embedded Linux Conference started moving later in the year, closing the gap between the ELC event and the ELCE event towards the end of the year and expanding the gap between the ELCE event and the ELC event. As a result there has been efforts to add YP/OE-specific events earlier in the year in order to maintain the roughly 6-month gap between events.&lt;br /&gt;
&lt;br /&gt;
=== OE Developers Meeting ===&lt;br /&gt;
The OpenEmbedded Developers {Americas|European} Meeting is a 1-day event, organized by the OpenEmbedded members, for an informal, free-form round-table-style discussion of core issues of concern to core OE/YP developers, BSP maintainers, etc&lt;br /&gt;
&lt;br /&gt;
=== DevDay ===&lt;br /&gt;
DevDay is a 1-day training event consisting of multiple tracks:&lt;br /&gt;
* a full-day beginners tutorial to get newcomers up-to-speed on basic YP/OE usage&lt;br /&gt;
* hands-on classes based on narrow topics of a more specialized nature&lt;br /&gt;
&lt;br /&gt;
== Events ==&lt;br /&gt;
future events:&lt;br /&gt;
* [https://wiki.yoctoproject.org/wiki/YoctoProject_Summit_yps2022.05 Yocto Project Summit yps2022.05]&lt;br /&gt;
&lt;br /&gt;
past events:&lt;br /&gt;
* [https://wiki.yoctoproject.org/wiki/YoctoProject_Summit_May2021 Yocto Project Summit May 2021]&lt;br /&gt;
* [https://wiki.yoctoproject.org/wiki/YP_Summit_Europe_2020 Yocto Project Summit Europe 2020]&lt;br /&gt;
* [https://wiki.yoctoproject.org/wiki/YP_DevDay_Austin_2020 DevDay Austin 2020]&lt;br /&gt;
* [https://wiki.yoctoproject.org/wiki/YP_Summit_Lyon_2019 Yocto Project Summit Lyon 2019]&lt;br /&gt;
* [https://www.socallinuxexpo.org/scale/17x/open-embedded-summit-0 OE Summit @ SCaLE 17x 2019]&lt;br /&gt;
* [https://wiki.yoctoproject.org/wiki/DevDay_San_Diego_2019 DevDay San Diego 2019]&lt;br /&gt;
* [https://wiki.yoctoproject.org/wiki/DevDay_Edinburgh_2018 DevDay Edinburgh 2018]&lt;br /&gt;
* [https://wiki.yoctoproject.org/wiki/DevDay_Portland_2018 DevDay Portland 2018]&lt;br /&gt;
* [https://wiki.yoctoproject.org/wiki/DevDay_Prague_2017 DevDay Prague 2017]&lt;br /&gt;
* [https://wiki.yoctoproject.org/wiki/DevDay_US_2017 DevDay US 2017]&lt;br /&gt;
&lt;br /&gt;
for a list of YP/OE-related talks at ELC/ELCE see:&lt;br /&gt;
* [https://elinux.org/Buildsystems https://elinux.org/Buildsystems]&lt;/div&gt;</summary>
		<author><name>Trevor Woerner</name></author>
	</entry>
	<entry>
		<id>https://wiki.yoctoproject.org/wiki/index.php?title=Project_Users&amp;diff=84719</id>
		<title>Project Users</title>
		<link rel="alternate" type="text/html" href="https://wiki.yoctoproject.org/wiki/index.php?title=Project_Users&amp;diff=84719"/>
		<updated>2021-05-26T15:35:16Z</updated>

		<summary type="html">&lt;p&gt;Trevor Woerner: /* Others */ add OVO Automotive (via Lurii Lunev during YP summit May 2021)&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;It&#039;s hard to know which companies or projects use the Yocto Project since there is no requirement to tell us. This list is here to informally collate the companies, projects and products that use the Yocto Project in some way.&lt;br /&gt;
&lt;br /&gt;
= Companies using the Yocto Project =&lt;br /&gt;
&lt;br /&gt;
== Semiconductor Vendors ==&lt;br /&gt;
* AMD (Silver Member)&lt;br /&gt;
* ARM (Platinum Member)&lt;br /&gt;
* Intel (Platinum Member)&lt;br /&gt;
* Microchip&lt;br /&gt;
* NXP (Silver Member)&lt;br /&gt;
* Qualcomm&lt;br /&gt;
* Renesas (Gold Member)&lt;br /&gt;
* STMicroelectronics (Silver Member)&lt;br /&gt;
* Texas Instruments (Gold Member)&lt;br /&gt;
* Xilinx (Platinum Member)&lt;br /&gt;
&lt;br /&gt;
== Operating System Vendors ==&lt;br /&gt;
* ENEA (Silver Member)&lt;br /&gt;
* Linaro (Silver Member)&lt;br /&gt;
* Lineo (Silver Member)&lt;br /&gt;
* Mentor Graphics (Gold Member)&lt;br /&gt;
* Montavista (Silver Member)&lt;br /&gt;
* Wind River (Gold Member)&lt;br /&gt;
&lt;br /&gt;
== Others ==&lt;br /&gt;
* [https://alladin.at/ alladin-IT GmbH]&lt;br /&gt;
* Atlas Copco&lt;br /&gt;
* AWS (Platinum Member)&lt;br /&gt;
* Axis Communications&lt;br /&gt;
* [https://www.balena.io/ Balena]&lt;br /&gt;
* BMW&lt;br /&gt;
* BMW Car IT&lt;br /&gt;
* Cisco (Platinum Member)&lt;br /&gt;
* Comcast (Platinum Member)&lt;br /&gt;
* [https://www.cytera.bio/ Cytera] (via Belena)&lt;br /&gt;
* Dell (Silver Member)&lt;br /&gt;
* Dynamic Devices&lt;br /&gt;
* Facebook (Platinum Member)&lt;br /&gt;
* Fujitsu&lt;br /&gt;
* General Electric&lt;br /&gt;
* Juniper&lt;br /&gt;
* [https://koansoftware.com/ KOAN sas]&lt;br /&gt;
* Kodak&lt;br /&gt;
* Lexmark&lt;br /&gt;
* LG (Silver Member)&lt;br /&gt;
* Microsoft (Platinum Member)&lt;br /&gt;
* National Instruments&lt;br /&gt;
* OVO Automotive&lt;br /&gt;
* Smile&lt;br /&gt;
* StreamUnlimited Engineering GmbH&lt;br /&gt;
* [https://www.witekio.com/values-expertise/ Witekio]&lt;br /&gt;
* [https://www.gardena.com/ GARDENA] (Husqvarna Group)&lt;br /&gt;
* [https://www.garmin.com/ Garmin]&lt;br /&gt;
&lt;br /&gt;
= Products that use the Yocto Project =&lt;br /&gt;
&lt;br /&gt;
* BMW cars&lt;br /&gt;
* Comcast set top boxes&lt;br /&gt;
* Go Pro (https://gopro.com/content/dam/help/open-source/2020-09-28%20-%20HERO9%20Black%20-GoPro%20Open%20Source%20Software%20Notice.pdf)&lt;br /&gt;
* Lexmark Printers&lt;br /&gt;
* LG webOS TVs&lt;br /&gt;
* Mellanox Bluefield SmartNIC&lt;br /&gt;
* [https://www.streamunlimited.com/hardware-modules/ StreamUnlimited hardware modules for voice assistants and connected speakers]&lt;br /&gt;
* Vernier LabQuest&lt;br /&gt;
* [https://www.gardena.com/int/products/smart/ GARDENA smart garden] (The smart garden gateway runs Yocto/OpenEmbedded. Open source parts can be found [https://github.com/husqvarnagroup/smart-garden-gateway-public on GitHub.])&lt;br /&gt;
* Some Garmin [https://www.garmin.com/marine/ Marine] Products&lt;br /&gt;
&lt;br /&gt;
= Projects that use the Yocto Project =&lt;br /&gt;
&lt;br /&gt;
* [https://www.automotivelinux.org/ Automotive Grade Linux (AGL)]&lt;br /&gt;
* [https://www.balena.io/ Balena]&lt;br /&gt;
* Comcast RDK&lt;br /&gt;
* Nvidia vibrante SDK [https://docs.nvidia.com/drive/archive/4.1.8.0L/nvoss_docs/index.html]&lt;br /&gt;
* OpenBMC&lt;br /&gt;
* [https://oryx-linux.org/ Oryx Linux]&lt;br /&gt;
* [https://www.streamunlimited.com/stream-sdk/ StreamSDK for voice assistants and connected speakers]&lt;br /&gt;
* Windows Subsystem Linux (v1+v2)&lt;br /&gt;
* webOS&lt;/div&gt;</summary>
		<author><name>Trevor Woerner</name></author>
	</entry>
	<entry>
		<id>https://wiki.yoctoproject.org/wiki/index.php?title=Project_Users&amp;diff=84700</id>
		<title>Project Users</title>
		<link rel="alternate" type="text/html" href="https://wiki.yoctoproject.org/wiki/index.php?title=Project_Users&amp;diff=84700"/>
		<updated>2021-05-19T15:52:51Z</updated>

		<summary type="html">&lt;p&gt;Trevor Woerner: /* Others */ oops, fixed name of alladin entry&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;It&#039;s hard to know which companies or projects use the Yocto Project since there is no requirement to tell us. This list is here to informally collate the companies, projects and products that use the Yocto Project in some way.&lt;br /&gt;
&lt;br /&gt;
= Companies using the Yocto Project =&lt;br /&gt;
&lt;br /&gt;
== Semiconductor Vendors ==&lt;br /&gt;
* AMD (Silver Member)&lt;br /&gt;
* ARM (Platinum Member)&lt;br /&gt;
* Intel (Platinum Member)&lt;br /&gt;
* Microchip&lt;br /&gt;
* NXP (Silver Member)&lt;br /&gt;
* Qualcomm&lt;br /&gt;
* Renesas (Gold Member)&lt;br /&gt;
* STMicroelectronics (Silver Member)&lt;br /&gt;
* Texas Instruments (Gold Member)&lt;br /&gt;
* Xilinx (Platinum Member)&lt;br /&gt;
&lt;br /&gt;
== Operating System Vendors ==&lt;br /&gt;
* ENEA (Silver Member)&lt;br /&gt;
* Linaro (Silver Member)&lt;br /&gt;
* Lineo (Silver Member)&lt;br /&gt;
* Mentor Graphics (Gold Member)&lt;br /&gt;
* Montavista (Silver Member)&lt;br /&gt;
* Wind River (Gold Member)&lt;br /&gt;
&lt;br /&gt;
== Others ==&lt;br /&gt;
* [https://alladin.at/ alladin-IT GmbH]&lt;br /&gt;
* Atlas Copco&lt;br /&gt;
* AWS (Platinum Member)&lt;br /&gt;
* Axis Communications&lt;br /&gt;
* [https://www.balena.io/ Balena]&lt;br /&gt;
* BMW&lt;br /&gt;
* BMW Car IT&lt;br /&gt;
* Cisco (Platinum Member)&lt;br /&gt;
* Comcast (Platinum Member)&lt;br /&gt;
* [https://www.cytera.bio/ Cytera] (via Belena)&lt;br /&gt;
* Dell (Silver Member)&lt;br /&gt;
* Dynamic Devices&lt;br /&gt;
* Facebook (Platinum Member)&lt;br /&gt;
* Fujitsu&lt;br /&gt;
* General Electric&lt;br /&gt;
* Juniper&lt;br /&gt;
* [https://koansoftware.com/ KOAN sas]&lt;br /&gt;
* Kodak&lt;br /&gt;
* Lexmark&lt;br /&gt;
* LG (Silver Member)&lt;br /&gt;
* Microsoft (Platinum Member)&lt;br /&gt;
* National Instruments&lt;br /&gt;
* Smile&lt;br /&gt;
* StreamUnlimited Engineering GmbH&lt;br /&gt;
* [https://www.witekio.com/values-expertise/ Witekio]&lt;br /&gt;
* [https://www.gardena.com/ GARDENA] (Husqvarna Group)&lt;br /&gt;
&lt;br /&gt;
= Products that use the Yocto Project =&lt;br /&gt;
&lt;br /&gt;
* BMW cars&lt;br /&gt;
* Comcast set top boxes&lt;br /&gt;
* Go Pro (https://gopro.com/content/dam/help/open-source/2020-09-28%20-%20HERO9%20Black%20-GoPro%20Open%20Source%20Software%20Notice.pdf)&lt;br /&gt;
* Lexmark Printers&lt;br /&gt;
* LG webOS TVs&lt;br /&gt;
* Mellanox Bluefield SmartNIC&lt;br /&gt;
* [https://www.streamunlimited.com/hardware-modules/ StreamUnlimited hardware modules for voice assistants and connected speakers]&lt;br /&gt;
* Vernier LabQuest&lt;br /&gt;
* [https://www.gardena.com/int/products/smart/ GARDENA smart garden] (The smart garden gateway runs Yocto/OpenEmbedded. Open source parts can be found [https://github.com/husqvarnagroup/smart-garden-gateway-public on GitHub.])&lt;br /&gt;
&lt;br /&gt;
= Projects that use the Yocto Project =&lt;br /&gt;
&lt;br /&gt;
* [https://www.automotivelinux.org/ Automotive Grade Linux (AGL)]&lt;br /&gt;
* [https://www.balena.io/ Balena]&lt;br /&gt;
* Comcast RDK&lt;br /&gt;
* Nvidia vibrante SDK [https://docs.nvidia.com/drive/archive/4.1.8.0L/nvoss_docs/index.html]&lt;br /&gt;
* OpenBMC&lt;br /&gt;
* [https://oryx-linux.org/ Oryx Linux]&lt;br /&gt;
* [https://www.streamunlimited.com/stream-sdk/ StreamSDK for voice assistants and connected speakers]&lt;br /&gt;
* Windows Subsystem Linux (v1+v2)&lt;br /&gt;
* webOS&lt;/div&gt;</summary>
		<author><name>Trevor Woerner</name></author>
	</entry>
	<entry>
		<id>https://wiki.yoctoproject.org/wiki/index.php?title=Project_Users&amp;diff=84699</id>
		<title>Project Users</title>
		<link rel="alternate" type="text/html" href="https://wiki.yoctoproject.org/wiki/index.php?title=Project_Users&amp;diff=84699"/>
		<updated>2021-05-19T15:52:09Z</updated>

		<summary type="html">&lt;p&gt;Trevor Woerner: /* Others */ added alladin.at on behalf of Sergey &amp;#039;Jin&amp;#039; Bostandzhyan (aka Jin^eLD on irc)&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;It&#039;s hard to know which companies or projects use the Yocto Project since there is no requirement to tell us. This list is here to informally collate the companies, projects and products that use the Yocto Project in some way.&lt;br /&gt;
&lt;br /&gt;
= Companies using the Yocto Project =&lt;br /&gt;
&lt;br /&gt;
== Semiconductor Vendors ==&lt;br /&gt;
* AMD (Silver Member)&lt;br /&gt;
* ARM (Platinum Member)&lt;br /&gt;
* Intel (Platinum Member)&lt;br /&gt;
* Microchip&lt;br /&gt;
* NXP (Silver Member)&lt;br /&gt;
* Qualcomm&lt;br /&gt;
* Renesas (Gold Member)&lt;br /&gt;
* STMicroelectronics (Silver Member)&lt;br /&gt;
* Texas Instruments (Gold Member)&lt;br /&gt;
* Xilinx (Platinum Member)&lt;br /&gt;
&lt;br /&gt;
== Operating System Vendors ==&lt;br /&gt;
* ENEA (Silver Member)&lt;br /&gt;
* Linaro (Silver Member)&lt;br /&gt;
* Lineo (Silver Member)&lt;br /&gt;
* Mentor Graphics (Gold Member)&lt;br /&gt;
* Montavista (Silver Member)&lt;br /&gt;
* Wind River (Gold Member)&lt;br /&gt;
&lt;br /&gt;
== Others ==&lt;br /&gt;
* [https://alladin.at/ alladin]&lt;br /&gt;
* Atlas Copco&lt;br /&gt;
* AWS (Platinum Member)&lt;br /&gt;
* Axis Communications&lt;br /&gt;
* [https://www.balena.io/ Balena]&lt;br /&gt;
* BMW&lt;br /&gt;
* BMW Car IT&lt;br /&gt;
* Cisco (Platinum Member)&lt;br /&gt;
* Comcast (Platinum Member)&lt;br /&gt;
* [https://www.cytera.bio/ Cytera] (via Belena)&lt;br /&gt;
* Dell (Silver Member)&lt;br /&gt;
* Dynamic Devices&lt;br /&gt;
* Facebook (Platinum Member)&lt;br /&gt;
* Fujitsu&lt;br /&gt;
* General Electric&lt;br /&gt;
* Juniper&lt;br /&gt;
* [https://koansoftware.com/ KOAN sas]&lt;br /&gt;
* Kodak&lt;br /&gt;
* Lexmark&lt;br /&gt;
* LG (Silver Member)&lt;br /&gt;
* Microsoft (Platinum Member)&lt;br /&gt;
* National Instruments&lt;br /&gt;
* Smile&lt;br /&gt;
* StreamUnlimited Engineering GmbH&lt;br /&gt;
* [https://www.witekio.com/values-expertise/ Witekio]&lt;br /&gt;
* [https://www.gardena.com/ GARDENA] (Husqvarna Group)&lt;br /&gt;
&lt;br /&gt;
= Products that use the Yocto Project =&lt;br /&gt;
&lt;br /&gt;
* BMW cars&lt;br /&gt;
* Comcast set top boxes&lt;br /&gt;
* Go Pro (https://gopro.com/content/dam/help/open-source/2020-09-28%20-%20HERO9%20Black%20-GoPro%20Open%20Source%20Software%20Notice.pdf)&lt;br /&gt;
* Lexmark Printers&lt;br /&gt;
* LG webOS TVs&lt;br /&gt;
* Mellanox Bluefield SmartNIC&lt;br /&gt;
* [https://www.streamunlimited.com/hardware-modules/ StreamUnlimited hardware modules for voice assistants and connected speakers]&lt;br /&gt;
* Vernier LabQuest&lt;br /&gt;
* [https://www.gardena.com/int/products/smart/ GARDENA smart garden] (The smart garden gateway runs Yocto/OpenEmbedded. Open source parts can be found [https://github.com/husqvarnagroup/smart-garden-gateway-public on GitHub.])&lt;br /&gt;
&lt;br /&gt;
= Projects that use the Yocto Project =&lt;br /&gt;
&lt;br /&gt;
* [https://www.automotivelinux.org/ Automotive Grade Linux (AGL)]&lt;br /&gt;
* [https://www.balena.io/ Balena]&lt;br /&gt;
* Comcast RDK&lt;br /&gt;
* Nvidia vibrante SDK [https://docs.nvidia.com/drive/archive/4.1.8.0L/nvoss_docs/index.html]&lt;br /&gt;
* OpenBMC&lt;br /&gt;
* [https://oryx-linux.org/ Oryx Linux]&lt;br /&gt;
* [https://www.streamunlimited.com/stream-sdk/ StreamSDK for voice assistants and connected speakers]&lt;br /&gt;
* Windows Subsystem Linux (v1+v2)&lt;br /&gt;
* webOS&lt;/div&gt;</summary>
		<author><name>Trevor Woerner</name></author>
	</entry>
	<entry>
		<id>https://wiki.yoctoproject.org/wiki/index.php?title=User:Trevor_Woerner&amp;diff=84698</id>
		<title>User:Trevor Woerner</title>
		<link rel="alternate" type="text/html" href="https://wiki.yoctoproject.org/wiki/index.php?title=User:Trevor_Woerner&amp;diff=84698"/>
		<updated>2021-05-19T12:35:52Z</updated>

		<summary type="html">&lt;p&gt;Trevor Woerner: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&amp;lt;pre&amp;gt;Embedded software developer&lt;br /&gt;
u-boot ­ linux kernel  YP/OE&amp;lt;/pre&amp;gt;&lt;/div&gt;</summary>
		<author><name>Trevor Woerner</name></author>
	</entry>
	<entry>
		<id>https://wiki.yoctoproject.org/wiki/index.php?title=User:Trevor_Woerner&amp;diff=84697</id>
		<title>User:Trevor Woerner</title>
		<link rel="alternate" type="text/html" href="https://wiki.yoctoproject.org/wiki/index.php?title=User:Trevor_Woerner&amp;diff=84697"/>
		<updated>2021-05-19T12:33:55Z</updated>

		<summary type="html">&lt;p&gt;Trevor Woerner: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Embedded software developer&lt;br /&gt;
u-boot ­ linux kernel  YP/OE&lt;/div&gt;</summary>
		<author><name>Trevor Woerner</name></author>
	</entry>
	<entry>
		<id>https://wiki.yoctoproject.org/wiki/index.php?title=YoctoProject_Summit_May2021&amp;diff=84689</id>
		<title>YoctoProject Summit May2021</title>
		<link rel="alternate" type="text/html" href="https://wiki.yoctoproject.org/wiki/index.php?title=YoctoProject_Summit_May2021&amp;diff=84689"/>
		<updated>2021-05-13T21:12:28Z</updated>

		<summary type="html">&lt;p&gt;Trevor Woerner: add slide template&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;There are no ELC/ELCE conferences scheduled by LF for the start of 2021, so we&#039;ve decided to run our own virtual conference at roughly the timeframe an ELC would have run.&lt;br /&gt;
&lt;br /&gt;
The organizing committee consists of (alphabetical by first name):&lt;br /&gt;
* Behan Webster&lt;br /&gt;
* David Reyna&lt;br /&gt;
* Josef Holzmayr-Khosh Amoz&lt;br /&gt;
* Nicolas Dechesne (YP Community Manager)&lt;br /&gt;
* Rudolf Streif&lt;br /&gt;
* Trevor Woerner&lt;br /&gt;
&lt;br /&gt;
The papers committee consists of:&lt;br /&gt;
* (the organizing committee)&lt;br /&gt;
* Armin Kuster&lt;br /&gt;
&lt;br /&gt;
In terms of platforms we&#039;re using:&lt;br /&gt;
* pretalx for the CfP and schedule&lt;br /&gt;
* the LF&#039;s cvent for registration&lt;br /&gt;
* Zoom for the conference video&lt;br /&gt;
* matrix for the conference chat&lt;br /&gt;
&lt;br /&gt;
For more information:&lt;br /&gt;
* https://www.yoctoproject.org/yocto-project-virtual-summit-2021/&lt;br /&gt;
* https://pretalx.com/yocto-project-summit-2021/&lt;br /&gt;
&lt;br /&gt;
Slide template for presenters:&lt;br /&gt;
* [https://wiki.yoctoproject.org/wiki/File:YoctoProjectSummit_May2021_Template.otp slide template]&lt;br /&gt;
** keep the first and last slides&lt;br /&gt;
** edit the first slide to include your name, presentation title, and (optionally) your company&lt;br /&gt;
** the rest of the slides are examples and can be duplicated, edited, and/or removed&lt;br /&gt;
** please upload your finished slides to your specific event in pretalx: https://pretalx.com/yocto-project-summit-2021/schedule/&lt;/div&gt;</summary>
		<author><name>Trevor Woerner</name></author>
	</entry>
	<entry>
		<id>https://wiki.yoctoproject.org/wiki/index.php?title=Main_Page&amp;diff=84688</id>
		<title>Main Page</title>
		<link rel="alternate" type="text/html" href="https://wiki.yoctoproject.org/wiki/index.php?title=Main_Page&amp;diff=84688"/>
		<updated>2021-05-13T21:07:31Z</updated>

		<summary type="html">&lt;p&gt;Trevor Woerner: /* Wiki reference sitemap */ add link to events page&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Welcome to the Yocto Project Wiki! ==&lt;br /&gt;
The [http://yoctoproject.org Yocto Project] is an open-source project that delivers a set of tools that create operating system images for embedded Linux systems. The Yocto Project tools are based on the [http://www.openembedded.org/wiki/Main_Page OpenEmbedded] (OE) project, which uses the BitBake build tool, to construct complete Linux images. BitBake and OE are combined to form a reference build host known as Poky which includes the following [[Core Components|core components]]. This [https://www.youtube.com/watch?v=utZpKM7i5Z4 video] will help explain what it&#039;s all about.&lt;br /&gt;
&lt;br /&gt;
===Where to Start?===&lt;br /&gt;
If you&#039;re new to Yocto take a look at the &#039;&#039;&#039;[[Glossary]]&#039;&#039;&#039; so you&#039;re familiar with the terms used in this wiki and the project documentation. Then take a look at the [http://www.yoctoproject.org/docs/current/yocto-project-qs/yocto-project-qs.html &#039;&#039;&#039;Quick Start Guide&#039;&#039;&#039;]. You can follow the steps in this document to clone the poky repository, quickly configure your build environment, and then try a build. Corporate firewalls can be problematic so network proxy configurations are detailed on the &#039;&#039;&#039;[[Working Behind a Network Proxy]]&#039;&#039;&#039; page. We advise you go straight for the [[Working_Behind_a_Network_Proxy#Option_2:_Chameleonsocks| Chameleonsocks option]].&lt;br /&gt;
&lt;br /&gt;
===Where to Next?===&lt;br /&gt;
Thanks to the quick start guide, it&#039;s pretty easy to get your first Linux image and and running. Here are some places to look for help when improving your Yocto skills.&lt;br /&gt;
* The [https://linuxfoundation.org Linux Foundation] have some great [https://docs.google.com/presentation/d/1LmI3mHoD_Dzl8wplIYcUBrFF8BzDb_EadTvfbnpSK7Q/edit training slides]. There is also an [https://docs.google.com/presentation/d/1HoDtyN5SzlmuTN47ab4Y7w_i6c_VEW6EBUD944ntf38/edit#slide advanced slide deck] for more more experienced users. &lt;br /&gt;
* The first tool you&#039;ll need to get familiar with is &#039;&#039;&#039;bitbake&#039;&#039;&#039;, so reading through the [https://www.yoctoproject.org/docs/current/bitbake-user-manual/bitbake-user-manual.html user manual] is recommended. You don&#039;t need to understand it all right now, but bookmark this page for reference. Implementation of bitake is covered in the [[Bitbake Internals Primer]] &lt;br /&gt;
* Once you start adding packages and configuring your image to create your own distribution, things can go wrong and it can hard to track down the root cause. There is no shortage of Yocto documentation resource, but if you&#039;re not exactly sure what you&#039;re looking for this &#039;&#039;&#039;[[Documentation Decoder]]&#039;&#039;&#039; will help you out. Also take a look at the [https://wiki.yoctoproject.org/wiki/Cookbook &#039;&#039;&#039;Cookbook&#039;&#039;&#039;] and [https://wiki.yoctoproject.org/wiki/Technical_FAQ troubleshooting guide]. Also [https://www.yoctoproject.org/blogs/jefro/2016/yocto-project-books these books] are helpful. &lt;br /&gt;
* Some new tools such as [http://www.yoctoproject.org/docs/current/toaster-manual/toaster-manual.html Toaster], [[Extensible SDK]] and [https://github.com/crops CROPS] are making it easier to get the best out of Yocto on Windows and Mac OS X. Take a look at the new workflow in [[Developer Workflow Improvements]].&lt;br /&gt;
* There is also a [https://wiki.yoctoproject.org/wiki/TipsAndTricks &#039;&#039;&#039;Tips and Tricks&#039;&#039;&#039;] section where more experienced developers contribute to articles that will help those new to Yocto Project.&lt;br /&gt;
* You can also read and participate on the [https://lists.yoctoproject.org mailing lists] - start with the [https://lists.yoctoproject.org/g/yocto main list] first - and the [https://www.yoctoproject.org/tools-resources/community/irc IRC channels].&lt;br /&gt;
&lt;br /&gt;
== Project planning ==&lt;br /&gt;
&lt;br /&gt;
=== Features === &lt;br /&gt;
* [[Yocto Feature Summary]] (Current and Next)&lt;br /&gt;
&lt;br /&gt;
=== Project Planning for current release  ===&lt;br /&gt;
&lt;br /&gt;
* [[Planning]]&lt;br /&gt;
&lt;br /&gt;
=== Project Status and Schedule ===&lt;br /&gt;
* [[Weekly_Status]]&lt;br /&gt;
* [[Yocto Project v2.8 Status]]&lt;br /&gt;
* [[Yocto 2.8 Schedule]]&lt;br /&gt;
* Testresults - https://git.yoctoproject.org/cgit/cgit.cgi/yocto-testresults-contrib/log/?h=intel-yocto-testresults&lt;br /&gt;
&lt;br /&gt;
=== Future Directions ===&lt;br /&gt;
* [[Future_Directions]]&lt;br /&gt;
&lt;br /&gt;
== Release Engineering ==&lt;br /&gt;
&lt;br /&gt;
* [[Yocto Release Engineering | Yocto Project Release Engineering]]&lt;br /&gt;
* [[Yocto Release Engineering | Release Activity (with status, version info, QA links, etc)]]&lt;br /&gt;
&lt;br /&gt;
== QA &amp;amp; Automation ==&lt;br /&gt;
&lt;br /&gt;
* [[The_Yocto_Autobuilder| The Yocto Project Autobuilder]]&lt;br /&gt;
* [[QA| Yocto Project QA Main Page]]&lt;br /&gt;
* [[QA/Archive| Yocto Project QA Test Report Archive ]]&lt;br /&gt;
&lt;br /&gt;
== Quick guide for newcomers ==&lt;br /&gt;
&lt;br /&gt;
If you are new to the project and are willing to contribute, please refer to our [[Newcomers|guide for newcomers]].&lt;br /&gt;
&lt;br /&gt;
== TSC ==&lt;br /&gt;
* Yocto Project Technical Steering Committee [[TSC]] &lt;br /&gt;
&lt;br /&gt;
== Wiki reference sitemap ==&lt;br /&gt;
* [[Glossary]]&lt;br /&gt;
* [[Documentation Decoder]]&lt;br /&gt;
* [[Working Behind a Network Proxy]]&lt;br /&gt;
* [[FAQ]] and [[Technical FAQ]]. These need to be unified.&lt;br /&gt;
* [[Cookbook]] and [[TipsAndTricks | Tips and Tricks]]. Need clear messaging on how these should be differentiated.&lt;br /&gt;
* [[Developer Workflow Improvements]], including [[Nodejs Workflow Improvements]]&lt;br /&gt;
* [[Planning and Governance]]&lt;br /&gt;
* [[Community Guidelines]]&lt;br /&gt;
* [[Yocto Release Engineering | Yocto Project Release Engineering]]&lt;br /&gt;
* [[License Infrastructure Interest Group | License Infrastructure]]&lt;br /&gt;
* [[Processes and Activities]]&lt;br /&gt;
* [[Technical Contributors]]&lt;br /&gt;
* [[Projects]]&lt;br /&gt;
* [[Security]] - find out what we do about CVEs and security&lt;br /&gt;
* [[Yocto Interest Groups]]&lt;br /&gt;
* [[Testopia]] - The Yocto Project&#039;s community-opened test case management platform&lt;br /&gt;
* [[Toaster]] - the web interface &lt;br /&gt;
* [[YoctoProjectEvents]] - links to YoctoProject/OpenEmbedded related conferences and events&lt;br /&gt;
* [[Archive]] - Graveyard for out of date articles.&lt;br /&gt;
&lt;br /&gt;
== Other resources ==&lt;br /&gt;
* [http://yoctoproject.org Yocto Project Front Page]&lt;br /&gt;
* [http://git.yoctoproject.org/ Yocto Project Git Source Repos]&lt;br /&gt;
* [https://bugzilla.yoctoproject.org/ Yocto Project Bugzilla]&lt;br /&gt;
* [https://www.yoctoproject.org/tools-resources/community/mailing-lists Yocto Project Mailing Lists]&lt;br /&gt;
* [http://recipes.yoctoproject.org/rrs Yocto Project Recipe Reporting System]&lt;br /&gt;
* [https://autobuilder.yoctoproject.org/typhoon Yocto Project Autobuilder]&lt;br /&gt;
* [http://downloads.yoctoproject.org/releases/yocto/ Yocto Project Releases Downloads]&lt;br /&gt;
* [http://autobuilder.yoctoproject.org/pub/nightly/ Yocto Project Nightly Build Images]&lt;br /&gt;
* [http://downloads.yoctoproject.org/mirror/sources/ Upstream Sources Mirror]&lt;br /&gt;
* [http://www.openembedded.org/wiki/Main_Page OpenEmbedded Wiki]&lt;br /&gt;
* [http://cgit.openembedded.org/ OpenEmbedded Git Repos]&lt;br /&gt;
* [http://layers.openembedded.org/ OpenEmbedded Community Layers] &lt;br /&gt;
* [http://patchwork.openembedded.org/ OpenEmbedded Patch Tracking System]&lt;br /&gt;
* &#039;&#039;&#039;IRC&#039;&#039;&#039;: irc.freenode.net&lt;br /&gt;
:* #yocto - Public discussions on the Yocto Project.&lt;br /&gt;
:* #oe - Public discussions on OpenEmbedded Core.&lt;/div&gt;</summary>
		<author><name>Trevor Woerner</name></author>
	</entry>
	<entry>
		<id>https://wiki.yoctoproject.org/wiki/index.php?title=File:YoctoProjectSummit_May2021_Template.otp&amp;diff=84687</id>
		<title>File:YoctoProjectSummit May2021 Template.otp</title>
		<link rel="alternate" type="text/html" href="https://wiki.yoctoproject.org/wiki/index.php?title=File:YoctoProjectSummit_May2021_Template.otp&amp;diff=84687"/>
		<updated>2021-05-13T21:04:10Z</updated>

		<summary type="html">&lt;p&gt;Trevor Woerner: slide template for the Yocto Project Summit May 2021
- keep the first and last slides
- edit the first slide to include your name, presentation, and (optionally) company
- the middle slides are for example purposes&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;slide template for the Yocto Project Summit May 2021&lt;br /&gt;
- keep the first and last slides&lt;br /&gt;
- edit the first slide to include your name, presentation, and (optionally) company&lt;br /&gt;
- the middle slides are for example purposes&lt;/div&gt;</summary>
		<author><name>Trevor Woerner</name></author>
	</entry>
	<entry>
		<id>https://wiki.yoctoproject.org/wiki/index.php?title=YoctoProjectEvents&amp;diff=84686</id>
		<title>YoctoProjectEvents</title>
		<link rel="alternate" type="text/html" href="https://wiki.yoctoproject.org/wiki/index.php?title=YoctoProjectEvents&amp;diff=84686"/>
		<updated>2021-05-13T20:15:46Z</updated>

		<summary type="html">&lt;p&gt;Trevor Woerner: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Traditionally the Linux Foundation organizes the Embedded Linux Conference -- one in North America (ELC) and one in Europe (ELCE). The Yocto Project often has a considerable presence at these events in the form of:&lt;br /&gt;
* talks submitted/presented about The Yocto Project, OpenEmbedded, and related technologies including a community BoF (Birds of a Feather) session&lt;br /&gt;
* a 1-day pre-event OpenEmbedded Developers Day (OEDAM [OpenEmbedded Developers Americas Meeting] for ELC and OEDEM [OpenEmbedded Developers European Meeting] for ELCE)&lt;br /&gt;
* a 1-day post-event DevDay&lt;br /&gt;
* a conference booth in the ELC/ELCE event hall, usually with demos&lt;br /&gt;
&lt;br /&gt;
The ELC/ELCE events are often co-located with other LF-related events such as: the Linux Security Summit, Zephyr Summit, KVM Forum, Open Source Summit, etc… Starting around 2019, in an effort to better align some of these events, the early Embedded Linux Conference started moving later in the year, closing the gap between the ELC event and the ELCE event towards the end of the year and expanding the gap between the ELCE event and the ELC event. As a result there has been efforts to add YP/OE-specific events earlier in the year in order to maintain the roughly 6-month gap between events.&lt;br /&gt;
&lt;br /&gt;
=== OE Developers Meeting ===&lt;br /&gt;
The OpenEmbedded Developers {Americas|European} Meeting is a 1-day event, organized by the OpenEmbedded members, for an informal, free-form round-table-style discussion of core issues of concern to core OE/YP developers, BSP maintainers, etc&lt;br /&gt;
&lt;br /&gt;
=== DevDay ===&lt;br /&gt;
DevDay is a 1-day training event consisting of multiple tracks:&lt;br /&gt;
* a full-day beginners tutorial to get newcomers up-to-speed on basic YP/OE usage&lt;br /&gt;
* hands-on classes based on narrow topics of a more specialized nature&lt;br /&gt;
&lt;br /&gt;
== Events ==&lt;br /&gt;
future events:&lt;br /&gt;
* [https://wiki.yoctoproject.org/wiki/YoctoProject_Summit_May2021 Yocto Project Summit May 2021]&lt;br /&gt;
&lt;br /&gt;
past events:&lt;br /&gt;
* [https://wiki.yoctoproject.org/wiki/YP_DevDay_Austin_2020 DevDay Austin 2020]&lt;br /&gt;
* [https://www.socallinuxexpo.org/scale/17x/open-embedded-summit-0 OE Summit @ SCaLE 17x 2019]&lt;br /&gt;
* [https://wiki.yoctoproject.org/wiki/DevDay_San_Diego_2019 DevDay San Diego 2019]&lt;br /&gt;
* [https://wiki.yoctoproject.org/wiki/DevDay_Edinburgh_2018 DevDay Edinburgh 2018]&lt;br /&gt;
* [https://wiki.yoctoproject.org/wiki/DevDay_Portland_2018 DevDay Portland 2018]&lt;br /&gt;
* [https://wiki.yoctoproject.org/wiki/DevDay_Prague_2017 DevDay Prague 2017]&lt;br /&gt;
* [https://wiki.yoctoproject.org/wiki/DevDay_US_2017 DevDay US 2017]&lt;br /&gt;
&lt;br /&gt;
for a list of YP/OE-related talks at ELC/ELCE see:&lt;br /&gt;
* [https://elinux.org/Buildsystems https://elinux.org/Buildsystems]&lt;/div&gt;</summary>
		<author><name>Trevor Woerner</name></author>
	</entry>
	<entry>
		<id>https://wiki.yoctoproject.org/wiki/index.php?title=YoctoProjectEvents&amp;diff=84685</id>
		<title>YoctoProjectEvents</title>
		<link rel="alternate" type="text/html" href="https://wiki.yoctoproject.org/wiki/index.php?title=YoctoProjectEvents&amp;diff=84685"/>
		<updated>2021-05-13T20:05:40Z</updated>

		<summary type="html">&lt;p&gt;Trevor Woerner: /* Events */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Yocto Project Events ==&lt;br /&gt;
&lt;br /&gt;
Traditionally the Linux Foundation organizes the Embedded Linux Conference -- one in North America (ELC) and one in Europe (ELCE). The Yocto Project often has a considerable presence at these events in the form of:&lt;br /&gt;
* talks submitted/presented about The Yocto Project, OpenEmbedded, and related technologies including a community BoF (Birds of a Feather) session&lt;br /&gt;
* a 1-day pre-event OpenEmbedded Developers Day (OEDAM [OpenEmbedded Developers Americas Meeting] for ELC and OEDEM [OpenEmbedded Developers European Meeting] for ELCE)&lt;br /&gt;
* a 1-day post-event DevDay&lt;br /&gt;
* a conference booth in the ELC/ELCE event hall, usually with demos&lt;br /&gt;
&lt;br /&gt;
The ELC/ELCE events are often co-located with other LF-related events such as: the Linux Security Summit, Zephyr Summit, KVM Forum, Open Source Summit, etc… Starting around 2019, in an effort to better align some of these events, the early Embedded Linux Conference started moving later in the year, closing the gap between the ELC event and the ELCE event towards the end of the year and expanding the gap between the ELCE event and the ELC event. As a result there has been efforts to add YP/OE-specific events earlier in the year in order to maintain the roughly 6-month gap between events.&lt;br /&gt;
&lt;br /&gt;
=== OE Developers Meeting ===&lt;br /&gt;
The OpenEmbedded Developers {Americas|European} Meeting is a 1-day event, organized by the OpenEmbedded members, for an informal, free-form round-table-style discussion of core issues of concern to core OE/YP developers, BSP maintainers, etc&lt;br /&gt;
&lt;br /&gt;
=== DevDay ===&lt;br /&gt;
DevDay is a 1-day training event consisting of multiple tracks:&lt;br /&gt;
* a full-day beginners tutorial to get newcomers up-to-speed on basic YP/OE usage&lt;br /&gt;
* hands-on classes based on narrow topics of a more specialized nature&lt;br /&gt;
&lt;br /&gt;
== Events ==&lt;br /&gt;
future events:&lt;br /&gt;
* [https://wiki.yoctoproject.org/wiki/YoctoProject_Summit_May2021 Yocto Project Summit May 2021]&lt;br /&gt;
&lt;br /&gt;
past events:&lt;br /&gt;
* [https://wiki.yoctoproject.org/wiki/YP_DevDay_Austin_2020 DevDay Austin 2020]&lt;br /&gt;
* [https://www.socallinuxexpo.org/scale/17x/open-embedded-summit-0 OE Summit @ SCaLE 17x 2019]&lt;br /&gt;
* [https://wiki.yoctoproject.org/wiki/DevDay_San_Diego_2019 DevDay San Diego 2019]&lt;br /&gt;
* [https://wiki.yoctoproject.org/wiki/DevDay_Edinburgh_2018 DevDay Edinburgh 2018]&lt;br /&gt;
* [https://wiki.yoctoproject.org/wiki/DevDay_Portland_2018 DevDay Portland 2018]&lt;br /&gt;
* [https://wiki.yoctoproject.org/wiki/DevDay_Prague_2017 DevDay Prague 2017]&lt;br /&gt;
* [https://wiki.yoctoproject.org/wiki/DevDay_US_2017 DevDay US 2017]&lt;br /&gt;
&lt;br /&gt;
for a list of YP/OE-related talks at ELC/ELCE see:&lt;br /&gt;
* [https://elinux.org/Buildsystems https://elinux.org/Buildsystems]&lt;/div&gt;</summary>
		<author><name>Trevor Woerner</name></author>
	</entry>
	<entry>
		<id>https://wiki.yoctoproject.org/wiki/index.php?title=YoctoProjectEvents&amp;diff=84684</id>
		<title>YoctoProjectEvents</title>
		<link rel="alternate" type="text/html" href="https://wiki.yoctoproject.org/wiki/index.php?title=YoctoProjectEvents&amp;diff=84684"/>
		<updated>2021-05-13T20:05:28Z</updated>

		<summary type="html">&lt;p&gt;Trevor Woerner: /* Events */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Yocto Project Events ==&lt;br /&gt;
&lt;br /&gt;
Traditionally the Linux Foundation organizes the Embedded Linux Conference -- one in North America (ELC) and one in Europe (ELCE). The Yocto Project often has a considerable presence at these events in the form of:&lt;br /&gt;
* talks submitted/presented about The Yocto Project, OpenEmbedded, and related technologies including a community BoF (Birds of a Feather) session&lt;br /&gt;
* a 1-day pre-event OpenEmbedded Developers Day (OEDAM [OpenEmbedded Developers Americas Meeting] for ELC and OEDEM [OpenEmbedded Developers European Meeting] for ELCE)&lt;br /&gt;
* a 1-day post-event DevDay&lt;br /&gt;
* a conference booth in the ELC/ELCE event hall, usually with demos&lt;br /&gt;
&lt;br /&gt;
The ELC/ELCE events are often co-located with other LF-related events such as: the Linux Security Summit, Zephyr Summit, KVM Forum, Open Source Summit, etc… Starting around 2019, in an effort to better align some of these events, the early Embedded Linux Conference started moving later in the year, closing the gap between the ELC event and the ELCE event towards the end of the year and expanding the gap between the ELCE event and the ELC event. As a result there has been efforts to add YP/OE-specific events earlier in the year in order to maintain the roughly 6-month gap between events.&lt;br /&gt;
&lt;br /&gt;
=== OE Developers Meeting ===&lt;br /&gt;
The OpenEmbedded Developers {Americas|European} Meeting is a 1-day event, organized by the OpenEmbedded members, for an informal, free-form round-table-style discussion of core issues of concern to core OE/YP developers, BSP maintainers, etc&lt;br /&gt;
&lt;br /&gt;
=== DevDay ===&lt;br /&gt;
DevDay is a 1-day training event consisting of multiple tracks:&lt;br /&gt;
* a full-day beginners tutorial to get newcomers up-to-speed on basic YP/OE usage&lt;br /&gt;
* hands-on classes based on narrow topics of a more specialized nature&lt;br /&gt;
&lt;br /&gt;
== Events ==&lt;br /&gt;
future events:&lt;br /&gt;
* [https://wiki.yoctoproject.org/wiki/YoctoProject_Summit_May2021 Yocto Project Summit May 2021]&lt;br /&gt;
&lt;br /&gt;
past events:&lt;br /&gt;
* [https://wiki.yoctoproject.org/wiki/YP_DevDay_Austin_2020 DevDay Austin 2020]&lt;br /&gt;
* [https://www.socallinuxexpo.org/scale/17x/open-embedded-summit-0 OE Summit @ SCaLE 17x 2019]&lt;br /&gt;
* [https://wiki.yoctoproject.org/wiki/DevDay_San_Diego_2019 DevDay San Diego 2019]&lt;br /&gt;
* [https://wiki.yoctoproject.org/wiki/DevDay_Edinburgh_2018 DevDay Edinburgh 2018]&lt;br /&gt;
* [https://wiki.yoctoproject.org/wiki/DevDay_Portland_2018 DevDay Portland 2018]&lt;br /&gt;
* [https://wiki.yoctoproject.org/wiki/DevDay_Prague_2017 DevDay Prague 2017]&lt;br /&gt;
* [https://wiki.yoctoproject.org/wiki/DevDay_US_2017 DevDay US 2017]&lt;br /&gt;
&lt;br /&gt;
For a list of YP/OE-related talks at ELC/ELCE see:&lt;br /&gt;
* [https://elinux.org/Buildsystems https://elinux.org/Buildsystems]&lt;/div&gt;</summary>
		<author><name>Trevor Woerner</name></author>
	</entry>
	<entry>
		<id>https://wiki.yoctoproject.org/wiki/index.php?title=YoctoProjectEvents&amp;diff=84683</id>
		<title>YoctoProjectEvents</title>
		<link rel="alternate" type="text/html" href="https://wiki.yoctoproject.org/wiki/index.php?title=YoctoProjectEvents&amp;diff=84683"/>
		<updated>2021-05-13T19:58:34Z</updated>

		<summary type="html">&lt;p&gt;Trevor Woerner: /* Events */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Yocto Project Events ==&lt;br /&gt;
&lt;br /&gt;
Traditionally the Linux Foundation organizes the Embedded Linux Conference -- one in North America (ELC) and one in Europe (ELCE). The Yocto Project often has a considerable presence at these events in the form of:&lt;br /&gt;
* talks submitted/presented about The Yocto Project, OpenEmbedded, and related technologies including a community BoF (Birds of a Feather) session&lt;br /&gt;
* a 1-day pre-event OpenEmbedded Developers Day (OEDAM [OpenEmbedded Developers Americas Meeting] for ELC and OEDEM [OpenEmbedded Developers European Meeting] for ELCE)&lt;br /&gt;
* a 1-day post-event DevDay&lt;br /&gt;
* a conference booth in the ELC/ELCE event hall, usually with demos&lt;br /&gt;
&lt;br /&gt;
The ELC/ELCE events are often co-located with other LF-related events such as: the Linux Security Summit, Zephyr Summit, KVM Forum, Open Source Summit, etc… Starting around 2019, in an effort to better align some of these events, the early Embedded Linux Conference started moving later in the year, closing the gap between the ELC event and the ELCE event towards the end of the year and expanding the gap between the ELCE event and the ELC event. As a result there has been efforts to add YP/OE-specific events earlier in the year in order to maintain the roughly 6-month gap between events.&lt;br /&gt;
&lt;br /&gt;
=== OE Developers Meeting ===&lt;br /&gt;
The OpenEmbedded Developers {Americas|European} Meeting is a 1-day event, organized by the OpenEmbedded members, for an informal, free-form round-table-style discussion of core issues of concern to core OE/YP developers, BSP maintainers, etc&lt;br /&gt;
&lt;br /&gt;
=== DevDay ===&lt;br /&gt;
DevDay is a 1-day training event consisting of multiple tracks:&lt;br /&gt;
* a full-day beginners tutorial to get newcomers up-to-speed on basic YP/OE usage&lt;br /&gt;
* hands-on classes based on narrow topics of a more specialized nature&lt;br /&gt;
&lt;br /&gt;
== Events ==&lt;br /&gt;
future events:&lt;br /&gt;
* [https://wiki.yoctoproject.org/wiki/YoctoProject_Summit_May2021 Yocto Project Summit May 2021]&lt;br /&gt;
&lt;br /&gt;
past events:&lt;br /&gt;
* [https://wiki.yoctoproject.org/wiki/YP_DevDay_Austin_2020 DevDay Austin 2020]&lt;br /&gt;
* [https://www.socallinuxexpo.org/scale/17x/open-embedded-summit-0 OE Summit @ SCaLE 17x 2019]&lt;br /&gt;
* [https://wiki.yoctoproject.org/wiki/DevDay_San_Diego_2019 DevDay San Diego 2019]&lt;br /&gt;
* [https://wiki.yoctoproject.org/wiki/DevDay_Edinburgh_2018 DevDay Edinburgh 2018]&lt;br /&gt;
* [https://wiki.yoctoproject.org/wiki/DevDay_Portland_2018 DevDay Portland 2018]&lt;br /&gt;
* [https://wiki.yoctoproject.org/wiki/DevDay_Prague_2017 DevDay Prague 2017]&lt;br /&gt;
* [https://wiki.yoctoproject.org/wiki/DevDay_US_2017 DevDay US 2017]&lt;/div&gt;</summary>
		<author><name>Trevor Woerner</name></author>
	</entry>
	<entry>
		<id>https://wiki.yoctoproject.org/wiki/index.php?title=YoctoProjectEvents&amp;diff=84682</id>
		<title>YoctoProjectEvents</title>
		<link rel="alternate" type="text/html" href="https://wiki.yoctoproject.org/wiki/index.php?title=YoctoProjectEvents&amp;diff=84682"/>
		<updated>2021-05-13T19:58:20Z</updated>

		<summary type="html">&lt;p&gt;Trevor Woerner: /* Events */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Yocto Project Events ==&lt;br /&gt;
&lt;br /&gt;
Traditionally the Linux Foundation organizes the Embedded Linux Conference -- one in North America (ELC) and one in Europe (ELCE). The Yocto Project often has a considerable presence at these events in the form of:&lt;br /&gt;
* talks submitted/presented about The Yocto Project, OpenEmbedded, and related technologies including a community BoF (Birds of a Feather) session&lt;br /&gt;
* a 1-day pre-event OpenEmbedded Developers Day (OEDAM [OpenEmbedded Developers Americas Meeting] for ELC and OEDEM [OpenEmbedded Developers European Meeting] for ELCE)&lt;br /&gt;
* a 1-day post-event DevDay&lt;br /&gt;
* a conference booth in the ELC/ELCE event hall, usually with demos&lt;br /&gt;
&lt;br /&gt;
The ELC/ELCE events are often co-located with other LF-related events such as: the Linux Security Summit, Zephyr Summit, KVM Forum, Open Source Summit, etc… Starting around 2019, in an effort to better align some of these events, the early Embedded Linux Conference started moving later in the year, closing the gap between the ELC event and the ELCE event towards the end of the year and expanding the gap between the ELCE event and the ELC event. As a result there has been efforts to add YP/OE-specific events earlier in the year in order to maintain the roughly 6-month gap between events.&lt;br /&gt;
&lt;br /&gt;
=== OE Developers Meeting ===&lt;br /&gt;
The OpenEmbedded Developers {Americas|European} Meeting is a 1-day event, organized by the OpenEmbedded members, for an informal, free-form round-table-style discussion of core issues of concern to core OE/YP developers, BSP maintainers, etc&lt;br /&gt;
&lt;br /&gt;
=== DevDay ===&lt;br /&gt;
DevDay is a 1-day training event consisting of multiple tracks:&lt;br /&gt;
* a full-day beginners tutorial to get newcomers up-to-speed on basic YP/OE usage&lt;br /&gt;
* hands-on classes based on narrow topics of a more specialized nature&lt;br /&gt;
&lt;br /&gt;
== Events ==&lt;br /&gt;
future events:&lt;br /&gt;
* [https://wiki.yoctoproject.org/wiki/YoctoProject_Summit_May2021 Yocto Project Summit May 2021]&lt;br /&gt;
&lt;br /&gt;
past events:&lt;br /&gt;
* [https://wiki.yoctoproject.org/wiki/YP_DevDay_Austin_2020 DevDay Austin 2020]&lt;br /&gt;
* [https://www.socallinuxexpo.org/scale/17x/open-embedded-summit-0 OE Summit @ SCaLE 17x (2019)]&lt;br /&gt;
* [https://wiki.yoctoproject.org/wiki/DevDay_San_Diego_2019 DevDay San Diego 2019]&lt;br /&gt;
* [https://wiki.yoctoproject.org/wiki/DevDay_Edinburgh_2018 DevDay Edinburgh 2018]&lt;br /&gt;
* [https://wiki.yoctoproject.org/wiki/DevDay_Portland_2018 DevDay Portland 2018]&lt;br /&gt;
* [https://wiki.yoctoproject.org/wiki/DevDay_Prague_2017 DevDay Prague 2017]&lt;br /&gt;
* [https://wiki.yoctoproject.org/wiki/DevDay_US_2017 DevDay US 2017]&lt;/div&gt;</summary>
		<author><name>Trevor Woerner</name></author>
	</entry>
	<entry>
		<id>https://wiki.yoctoproject.org/wiki/index.php?title=YoctoProjectEvents&amp;diff=84681</id>
		<title>YoctoProjectEvents</title>
		<link rel="alternate" type="text/html" href="https://wiki.yoctoproject.org/wiki/index.php?title=YoctoProjectEvents&amp;diff=84681"/>
		<updated>2021-05-13T19:57:57Z</updated>

		<summary type="html">&lt;p&gt;Trevor Woerner: /* Events */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Yocto Project Events ==&lt;br /&gt;
&lt;br /&gt;
Traditionally the Linux Foundation organizes the Embedded Linux Conference -- one in North America (ELC) and one in Europe (ELCE). The Yocto Project often has a considerable presence at these events in the form of:&lt;br /&gt;
* talks submitted/presented about The Yocto Project, OpenEmbedded, and related technologies including a community BoF (Birds of a Feather) session&lt;br /&gt;
* a 1-day pre-event OpenEmbedded Developers Day (OEDAM [OpenEmbedded Developers Americas Meeting] for ELC and OEDEM [OpenEmbedded Developers European Meeting] for ELCE)&lt;br /&gt;
* a 1-day post-event DevDay&lt;br /&gt;
* a conference booth in the ELC/ELCE event hall, usually with demos&lt;br /&gt;
&lt;br /&gt;
The ELC/ELCE events are often co-located with other LF-related events such as: the Linux Security Summit, Zephyr Summit, KVM Forum, Open Source Summit, etc… Starting around 2019, in an effort to better align some of these events, the early Embedded Linux Conference started moving later in the year, closing the gap between the ELC event and the ELCE event towards the end of the year and expanding the gap between the ELCE event and the ELC event. As a result there has been efforts to add YP/OE-specific events earlier in the year in order to maintain the roughly 6-month gap between events.&lt;br /&gt;
&lt;br /&gt;
=== OE Developers Meeting ===&lt;br /&gt;
The OpenEmbedded Developers {Americas|European} Meeting is a 1-day event, organized by the OpenEmbedded members, for an informal, free-form round-table-style discussion of core issues of concern to core OE/YP developers, BSP maintainers, etc&lt;br /&gt;
&lt;br /&gt;
=== DevDay ===&lt;br /&gt;
DevDay is a 1-day training event consisting of multiple tracks:&lt;br /&gt;
* a full-day beginners tutorial to get newcomers up-to-speed on basic YP/OE usage&lt;br /&gt;
* hands-on classes based on narrow topics of a more specialized nature&lt;br /&gt;
&lt;br /&gt;
== Events ==&lt;br /&gt;
future events:&lt;br /&gt;
* [https://wiki.yoctoproject.org/wiki/YoctoProject_Summit_May2021 Yocto Project Summit May 2021]&lt;br /&gt;
&lt;br /&gt;
past events:&lt;br /&gt;
* [https://wiki.yoctoproject.org/wiki/YP_DevDay_Austin_2020 DevDay Austin 2020]&lt;br /&gt;
* [https://www.socallinuxexpo.org/scale/17x/open-embedded-summit-0 OE Summit @ SCaLE 17x]&lt;br /&gt;
* [https://wiki.yoctoproject.org/wiki/DevDay_San_Diego_2019 DevDay San Diego 2019]&lt;br /&gt;
* [https://wiki.yoctoproject.org/wiki/DevDay_Edinburgh_2018 DevDay Edinburgh 2018]&lt;br /&gt;
* [https://wiki.yoctoproject.org/wiki/DevDay_Portland_2018 DevDay Portland 2018]&lt;br /&gt;
* [https://wiki.yoctoproject.org/wiki/DevDay_Prague_2017 DevDay Prague 2017]&lt;br /&gt;
* [https://wiki.yoctoproject.org/wiki/DevDay_US_2017 DevDay US 2017]&lt;/div&gt;</summary>
		<author><name>Trevor Woerner</name></author>
	</entry>
	<entry>
		<id>https://wiki.yoctoproject.org/wiki/index.php?title=YoctoProjectEvents&amp;diff=84680</id>
		<title>YoctoProjectEvents</title>
		<link rel="alternate" type="text/html" href="https://wiki.yoctoproject.org/wiki/index.php?title=YoctoProjectEvents&amp;diff=84680"/>
		<updated>2021-05-13T19:51:54Z</updated>

		<summary type="html">&lt;p&gt;Trevor Woerner: /* Yocto Project Events */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Yocto Project Events ==&lt;br /&gt;
&lt;br /&gt;
Traditionally the Linux Foundation organizes the Embedded Linux Conference -- one in North America (ELC) and one in Europe (ELCE). The Yocto Project often has a considerable presence at these events in the form of:&lt;br /&gt;
* talks submitted/presented about The Yocto Project, OpenEmbedded, and related technologies including a community BoF (Birds of a Feather) session&lt;br /&gt;
* a 1-day pre-event OpenEmbedded Developers Day (OEDAM [OpenEmbedded Developers Americas Meeting] for ELC and OEDEM [OpenEmbedded Developers European Meeting] for ELCE)&lt;br /&gt;
* a 1-day post-event DevDay&lt;br /&gt;
* a conference booth in the ELC/ELCE event hall, usually with demos&lt;br /&gt;
&lt;br /&gt;
The ELC/ELCE events are often co-located with other LF-related events such as: the Linux Security Summit, Zephyr Summit, KVM Forum, Open Source Summit, etc… Starting around 2019, in an effort to better align some of these events, the early Embedded Linux Conference started moving later in the year, closing the gap between the ELC event and the ELCE event towards the end of the year and expanding the gap between the ELCE event and the ELC event. As a result there has been efforts to add YP/OE-specific events earlier in the year in order to maintain the roughly 6-month gap between events.&lt;br /&gt;
&lt;br /&gt;
=== OE Developers Meeting ===&lt;br /&gt;
The OpenEmbedded Developers {Americas|European} Meeting is a 1-day event, organized by the OpenEmbedded members, for an informal, free-form round-table-style discussion of core issues of concern to core OE/YP developers, BSP maintainers, etc&lt;br /&gt;
&lt;br /&gt;
=== DevDay ===&lt;br /&gt;
DevDay is a 1-day training event consisting of multiple tracks:&lt;br /&gt;
* a full-day beginners tutorial to get newcomers up-to-speed on basic YP/OE usage&lt;br /&gt;
* hands-on classes based on narrow topics of a more specialized nature&lt;br /&gt;
&lt;br /&gt;
== Events ==&lt;br /&gt;
future events:&lt;br /&gt;
* [https://wiki.yoctoproject.org/wiki/YoctoProject_Summit_May2021 Yocto Project Summit May 2021]&lt;br /&gt;
&lt;br /&gt;
past events:&lt;br /&gt;
* [https://wiki.yoctoproject.org/wiki/YP_DevDay_Austin_2020 DevDay Austin 2020]&lt;br /&gt;
* [https://wiki.yoctoproject.org/wiki/DevDay_San_Diego_2019 DevDay San Diego 2019]&lt;br /&gt;
* [https://wiki.yoctoproject.org/wiki/DevDay_Edinburgh_2018 DevDay Edinburgh 2018]&lt;br /&gt;
* [https://wiki.yoctoproject.org/wiki/DevDay_Portland_2018 DevDay Portland 2018]&lt;br /&gt;
* [https://wiki.yoctoproject.org/wiki/DevDay_Prague_2017 DevDay Prague 2017]&lt;br /&gt;
* [https://wiki.yoctoproject.org/wiki/DevDay_US_2017 DevDay US 2017]&lt;/div&gt;</summary>
		<author><name>Trevor Woerner</name></author>
	</entry>
	<entry>
		<id>https://wiki.yoctoproject.org/wiki/index.php?title=YoctoProjectEvents&amp;diff=84679</id>
		<title>YoctoProjectEvents</title>
		<link rel="alternate" type="text/html" href="https://wiki.yoctoproject.org/wiki/index.php?title=YoctoProjectEvents&amp;diff=84679"/>
		<updated>2021-05-13T19:51:18Z</updated>

		<summary type="html">&lt;p&gt;Trevor Woerner: /* Yocto Project Events */ add booth&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Yocto Project Events ==&lt;br /&gt;
&lt;br /&gt;
Traditionally the Linux Foundation organizes the Embedded Linux Conference -- one in North America (ELC) and one in Europe (ELCE). The Yocto Project often has a considerable presence at these events in the form of:&lt;br /&gt;
* talks submitted/presented about The Yocto Project, OpenEmbedded, and related technologies&lt;br /&gt;
* a 1-day pre-event OpenEmbedded Developers Day (OEDAM [OpenEmbedded Developers Americas Meeting] for ELC and OEDEM [OpenEmbedded Developers European Meeting] for ELCE)&lt;br /&gt;
* a 1-day post-event DevDay&lt;br /&gt;
* a conference booth in the ELC/ELCE event hall, usually with demos&lt;br /&gt;
&lt;br /&gt;
The ELC/ELCE events are often co-located with other LF-related events such as: the Linux Security Summit, Zephyr Summit, KVM Forum, Open Source Summit, etc… Starting around 2019, in an effort to better align some of these events, the early Embedded Linux Conference started moving later in the year, closing the gap between the ELC event and the ELCE event towards the end of the year and expanding the gap between the ELCE event and the ELC event. As a result there has been efforts to add YP/OE-specific events earlier in the year in order to maintain the roughly 6-month gap between events.&lt;br /&gt;
&lt;br /&gt;
=== OE Developers Meeting ===&lt;br /&gt;
The OpenEmbedded Developers {Americas|European} Meeting is a 1-day event, organized by the OpenEmbedded members, for an informal, free-form round-table-style discussion of core issues of concern to core OE/YP developers, BSP maintainers, etc&lt;br /&gt;
&lt;br /&gt;
=== DevDay ===&lt;br /&gt;
DevDay is a 1-day training event consisting of multiple tracks:&lt;br /&gt;
* a full-day beginners tutorial to get newcomers up-to-speed on basic YP/OE usage&lt;br /&gt;
* hands-on classes based on narrow topics of a more specialized nature&lt;br /&gt;
&lt;br /&gt;
== Events ==&lt;br /&gt;
future events:&lt;br /&gt;
* [https://wiki.yoctoproject.org/wiki/YoctoProject_Summit_May2021 Yocto Project Summit May 2021]&lt;br /&gt;
&lt;br /&gt;
past events:&lt;br /&gt;
* [https://wiki.yoctoproject.org/wiki/YP_DevDay_Austin_2020 DevDay Austin 2020]&lt;br /&gt;
* [https://wiki.yoctoproject.org/wiki/DevDay_San_Diego_2019 DevDay San Diego 2019]&lt;br /&gt;
* [https://wiki.yoctoproject.org/wiki/DevDay_Edinburgh_2018 DevDay Edinburgh 2018]&lt;br /&gt;
* [https://wiki.yoctoproject.org/wiki/DevDay_Portland_2018 DevDay Portland 2018]&lt;br /&gt;
* [https://wiki.yoctoproject.org/wiki/DevDay_Prague_2017 DevDay Prague 2017]&lt;br /&gt;
* [https://wiki.yoctoproject.org/wiki/DevDay_US_2017 DevDay US 2017]&lt;/div&gt;</summary>
		<author><name>Trevor Woerner</name></author>
	</entry>
	<entry>
		<id>https://wiki.yoctoproject.org/wiki/index.php?title=YoctoProjectEvents&amp;diff=84678</id>
		<title>YoctoProjectEvents</title>
		<link rel="alternate" type="text/html" href="https://wiki.yoctoproject.org/wiki/index.php?title=YoctoProjectEvents&amp;diff=84678"/>
		<updated>2021-05-13T19:50:04Z</updated>

		<summary type="html">&lt;p&gt;Trevor Woerner: update &amp;quot;conference&amp;quot; to &amp;quot;event&amp;quot;&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Yocto Project Events ==&lt;br /&gt;
&lt;br /&gt;
Traditionally the Linux Foundation organizes the Embedded Linux Conference -- one in North America (ELC) and one in Europe (ELCE). The Yocto Project often has a considerable presence at these events in the form of:&lt;br /&gt;
* talks submitted/presented about The Yocto Project, OpenEmbedded, and related technologies&lt;br /&gt;
* a 1-day pre-event OpenEmbedded Developers Day (OEDAM [OpenEmbedded Developers Americas Meeting] for ELC and OEDEM [OpenEmbedded Developers European Meeting] for ELCE)&lt;br /&gt;
* a 1-day post-event DevDay&lt;br /&gt;
&lt;br /&gt;
The ELC/ELCE events are often co-located with other LF-related events such as: the Linux Security Summit, Zephyr Summit, KVM Forum, Open Source Summit, etc… Starting around 2019, in an effort to better align some of these events, the early Embedded Linux Conference started moving later in the year, closing the gap between the ELC event and the ELCE event towards the end of the year and expanding the gap between the ELCE event and the ELC event. As a result there has been efforts to add YP/OE-specific events earlier in the year in order to maintain the roughly 6-month gap between events.&lt;br /&gt;
&lt;br /&gt;
=== OE Developers Meeting ===&lt;br /&gt;
The OpenEmbedded Developers {Americas|European} Meeting is a 1-day event, organized by the OpenEmbedded members, for an informal, free-form round-table-style discussion of core issues of concern to core OE/YP developers, BSP maintainers, etc&lt;br /&gt;
&lt;br /&gt;
=== DevDay ===&lt;br /&gt;
DevDay is a 1-day training event consisting of multiple tracks:&lt;br /&gt;
* a full-day beginners tutorial to get newcomers up-to-speed on basic YP/OE usage&lt;br /&gt;
* hands-on classes based on narrow topics of a more specialized nature&lt;br /&gt;
&lt;br /&gt;
== Events ==&lt;br /&gt;
future events:&lt;br /&gt;
* [https://wiki.yoctoproject.org/wiki/YoctoProject_Summit_May2021 Yocto Project Summit May 2021]&lt;br /&gt;
&lt;br /&gt;
past events:&lt;br /&gt;
* [https://wiki.yoctoproject.org/wiki/YP_DevDay_Austin_2020 DevDay Austin 2020]&lt;br /&gt;
* [https://wiki.yoctoproject.org/wiki/DevDay_San_Diego_2019 DevDay San Diego 2019]&lt;br /&gt;
* [https://wiki.yoctoproject.org/wiki/DevDay_Edinburgh_2018 DevDay Edinburgh 2018]&lt;br /&gt;
* [https://wiki.yoctoproject.org/wiki/DevDay_Portland_2018 DevDay Portland 2018]&lt;br /&gt;
* [https://wiki.yoctoproject.org/wiki/DevDay_Prague_2017 DevDay Prague 2017]&lt;br /&gt;
* [https://wiki.yoctoproject.org/wiki/DevDay_US_2017 DevDay US 2017]&lt;/div&gt;</summary>
		<author><name>Trevor Woerner</name></author>
	</entry>
	<entry>
		<id>https://wiki.yoctoproject.org/wiki/index.php?title=YoctoProjectConferences&amp;diff=84677</id>
		<title>YoctoProjectConferences</title>
		<link rel="alternate" type="text/html" href="https://wiki.yoctoproject.org/wiki/index.php?title=YoctoProjectConferences&amp;diff=84677"/>
		<updated>2021-05-13T19:49:10Z</updated>

		<summary type="html">&lt;p&gt;Trevor Woerner: Trevor Woerner moved page YoctoProjectConferences to YoctoProjectEvents: not every event (e.g. devday) is a conference perse&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;#REDIRECT [[YoctoProjectEvents]]&lt;/div&gt;</summary>
		<author><name>Trevor Woerner</name></author>
	</entry>
	<entry>
		<id>https://wiki.yoctoproject.org/wiki/index.php?title=YoctoProjectEvents&amp;diff=84676</id>
		<title>YoctoProjectEvents</title>
		<link rel="alternate" type="text/html" href="https://wiki.yoctoproject.org/wiki/index.php?title=YoctoProjectEvents&amp;diff=84676"/>
		<updated>2021-05-13T19:49:10Z</updated>

		<summary type="html">&lt;p&gt;Trevor Woerner: Trevor Woerner moved page YoctoProjectConferences to YoctoProjectEvents: not every event (e.g. devday) is a conference perse&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Yocto Project Conferences ==&lt;br /&gt;
&lt;br /&gt;
Traditionally the Linux Foundation organizes the Embedded Linux Conference -- one in North America (ELC) and one in Europe (ELCE). The Yocto Project often has a considerable presence at these events in the form of:&lt;br /&gt;
* talks submitted/presented about The Yocto Project, OpenEmbedded, and related technologies&lt;br /&gt;
* a 1-day pre-event OpenEmbedded Developers Day (OEDAM [OpenEmbedded Developers Americas Meeting] for ELC and OEDEM [OpenEmbedded Developers European Meeting] for ELCE)&lt;br /&gt;
* a 1-day post-event DevDay&lt;br /&gt;
&lt;br /&gt;
The ELC/ELCE events are often co-located with other LF-related events such as: the Linux Security Summit, Zephyr Summit, KVM Forum, Open Source Summit, etc… Starting around 2019, in an effort to better align some of these events, the early Embedded Linux Conference started moving later in the year, closing the gap between the ELC event and the ELCE event towards the end of the year and expanding the gap between the ELCE event and the ELC event. As a result there has been efforts to add YP/OE-specific events earlier in the year in order to maintain the roughly 6-month gap between events.&lt;br /&gt;
&lt;br /&gt;
=== OE Developers Meeting ===&lt;br /&gt;
The OpenEmbedded Developers {Americas|European} Meeting is a 1-day event, organized by the OpenEmbedded members, for an informal, free-form round-table-style discussion of core issues of concern to core OE/YP developers, BSP maintainers, etc&lt;br /&gt;
&lt;br /&gt;
=== DevDay ===&lt;br /&gt;
DevDay is a 1-day training event consisting of multiple tracks:&lt;br /&gt;
* a full-day beginners tutorial to get newcomers up-to-speed on basic YP/OE usage&lt;br /&gt;
* hands-on classes based on narrow topics of a more specialized nature&lt;br /&gt;
&lt;br /&gt;
== Events ==&lt;br /&gt;
future events:&lt;br /&gt;
* [https://wiki.yoctoproject.org/wiki/YoctoProject_Summit_May2021 Yocto Project Summit May 2021]&lt;br /&gt;
&lt;br /&gt;
past events:&lt;br /&gt;
* [https://wiki.yoctoproject.org/wiki/YP_DevDay_Austin_2020 DevDay Austin 2020]&lt;br /&gt;
* [https://wiki.yoctoproject.org/wiki/DevDay_San_Diego_2019 DevDay San Diego 2019]&lt;br /&gt;
* [https://wiki.yoctoproject.org/wiki/DevDay_Edinburgh_2018 DevDay Edinburgh 2018]&lt;br /&gt;
* [https://wiki.yoctoproject.org/wiki/DevDay_Portland_2018 DevDay Portland 2018]&lt;br /&gt;
* [https://wiki.yoctoproject.org/wiki/DevDay_Prague_2017 DevDay Prague 2017]&lt;br /&gt;
* [https://wiki.yoctoproject.org/wiki/DevDay_US_2017 DevDay US 2017]&lt;/div&gt;</summary>
		<author><name>Trevor Woerner</name></author>
	</entry>
	<entry>
		<id>https://wiki.yoctoproject.org/wiki/index.php?title=YoctoProjectEvents&amp;diff=84675</id>
		<title>YoctoProjectEvents</title>
		<link rel="alternate" type="text/html" href="https://wiki.yoctoproject.org/wiki/index.php?title=YoctoProjectEvents&amp;diff=84675"/>
		<updated>2021-05-13T19:43:32Z</updated>

		<summary type="html">&lt;p&gt;Trevor Woerner: /* Yocto Project Conferences */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Yocto Project Conferences ==&lt;br /&gt;
&lt;br /&gt;
Traditionally the Linux Foundation organizes the Embedded Linux Conference -- one in North America (ELC) and one in Europe (ELCE). The Yocto Project often has a considerable presence at these events in the form of:&lt;br /&gt;
* talks submitted/presented about The Yocto Project, OpenEmbedded, and related technologies&lt;br /&gt;
* a 1-day pre-event OpenEmbedded Developers Day (OEDAM [OpenEmbedded Developers Americas Meeting] for ELC and OEDEM [OpenEmbedded Developers European Meeting] for ELCE)&lt;br /&gt;
* a 1-day post-event DevDay&lt;br /&gt;
&lt;br /&gt;
The ELC/ELCE events are often co-located with other LF-related events such as: the Linux Security Summit, Zephyr Summit, KVM Forum, Open Source Summit, etc… Starting around 2019, in an effort to better align some of these events, the early Embedded Linux Conference started moving later in the year, closing the gap between the ELC event and the ELCE event towards the end of the year and expanding the gap between the ELCE event and the ELC event. As a result there has been efforts to add YP/OE-specific events earlier in the year in order to maintain the roughly 6-month gap between events.&lt;br /&gt;
&lt;br /&gt;
=== OE Developers Meeting ===&lt;br /&gt;
The OpenEmbedded Developers {Americas|European} Meeting is a 1-day event, organized by the OpenEmbedded members, for an informal, free-form round-table-style discussion of core issues of concern to core OE/YP developers, BSP maintainers, etc&lt;br /&gt;
&lt;br /&gt;
=== DevDay ===&lt;br /&gt;
DevDay is a 1-day training event consisting of multiple tracks:&lt;br /&gt;
* a full-day beginners tutorial to get newcomers up-to-speed on basic YP/OE usage&lt;br /&gt;
* hands-on classes based on narrow topics of a more specialized nature&lt;br /&gt;
&lt;br /&gt;
== Events ==&lt;br /&gt;
future events:&lt;br /&gt;
* [https://wiki.yoctoproject.org/wiki/YoctoProject_Summit_May2021 Yocto Project Summit May 2021]&lt;br /&gt;
&lt;br /&gt;
past events:&lt;br /&gt;
* [https://wiki.yoctoproject.org/wiki/YP_DevDay_Austin_2020 DevDay Austin 2020]&lt;br /&gt;
* [https://wiki.yoctoproject.org/wiki/DevDay_San_Diego_2019 DevDay San Diego 2019]&lt;br /&gt;
* [https://wiki.yoctoproject.org/wiki/DevDay_Edinburgh_2018 DevDay Edinburgh 2018]&lt;br /&gt;
* [https://wiki.yoctoproject.org/wiki/DevDay_Portland_2018 DevDay Portland 2018]&lt;br /&gt;
* [https://wiki.yoctoproject.org/wiki/DevDay_Prague_2017 DevDay Prague 2017]&lt;br /&gt;
* [https://wiki.yoctoproject.org/wiki/DevDay_US_2017 DevDay US 2017]&lt;/div&gt;</summary>
		<author><name>Trevor Woerner</name></author>
	</entry>
	<entry>
		<id>https://wiki.yoctoproject.org/wiki/index.php?title=YoctoProjectEvents&amp;diff=84673</id>
		<title>YoctoProjectEvents</title>
		<link rel="alternate" type="text/html" href="https://wiki.yoctoproject.org/wiki/index.php?title=YoctoProjectEvents&amp;diff=84673"/>
		<updated>2021-05-13T19:18:45Z</updated>

		<summary type="html">&lt;p&gt;Trevor Woerner: initial commit&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Yocto Project Conferences ==&lt;br /&gt;
&lt;br /&gt;
Traditionally the Linux Foundation organizes the Embedded Linux Conference -- one in North America (ELC) and one in Europe (ELCE). The Yocto Project often has a considerable presence at these events in the form of:&lt;br /&gt;
* talks submitted/presented about The Yocto Project, OpenEmbedded, and related technologies&lt;br /&gt;
* a 1-day pre-event OpenEmbedded Developers Day (OEDAM [OpenEmbedded Developers Americas Meeting] for ELC and OEDEM [OpenEmbedded Developers European Meeting] for ELCE)&lt;br /&gt;
* a 1-day post-event DevDay&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== OE Developers Meeting ===&lt;br /&gt;
The OpenEmbedded Developers {Americas|European} Meeting is a 1-day event, organized by the OpenEmbedded members, for an informal, free-form round-table-style discussion of core issues of concern to core OE/YP developers, BSP maintainers, etc&lt;br /&gt;
&lt;br /&gt;
=== DevDay ===&lt;br /&gt;
DevDay is a 1-day training event consisting of multiple tracks:&lt;br /&gt;
* a full-day beginners tutorial to get newcomers up-to-speed on basic YP/OE usage&lt;br /&gt;
* hands-on classes based on narrow topics of a more specialized nature&lt;br /&gt;
&lt;br /&gt;
== Events ==&lt;br /&gt;
future events:&lt;br /&gt;
* [https://wiki.yoctoproject.org/wiki/YoctoProject_Summit_May2021 Yocto Project Summit May 2021]&lt;br /&gt;
&lt;br /&gt;
past events:&lt;br /&gt;
* [https://wiki.yoctoproject.org/wiki/YP_DevDay_Austin_2020 DevDay Austin 2020]&lt;br /&gt;
* [https://wiki.yoctoproject.org/wiki/DevDay_San_Diego_2019 DevDay San Diego 2019]&lt;br /&gt;
* [https://wiki.yoctoproject.org/wiki/DevDay_Edinburgh_2018 DevDay Edinburgh 2018]&lt;br /&gt;
* [https://wiki.yoctoproject.org/wiki/DevDay_Portland_2018 DevDay Portland 2018]&lt;br /&gt;
* [https://wiki.yoctoproject.org/wiki/DevDay_Prague_2017 DevDay Prague 2017]&lt;br /&gt;
* [https://wiki.yoctoproject.org/wiki/DevDay_US_2017 DevDay US 2017]&lt;/div&gt;</summary>
		<author><name>Trevor Woerner</name></author>
	</entry>
	<entry>
		<id>https://wiki.yoctoproject.org/wiki/index.php?title=YoctoProject_Summit_May2021&amp;diff=84672</id>
		<title>YoctoProject Summit May2021</title>
		<link rel="alternate" type="text/html" href="https://wiki.yoctoproject.org/wiki/index.php?title=YoctoProject_Summit_May2021&amp;diff=84672"/>
		<updated>2021-05-13T18:53:27Z</updated>

		<summary type="html">&lt;p&gt;Trevor Woerner: initial commit&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;There are no ELC/ELCE conferences scheduled by LF for the start of 2021, so we&#039;ve decided to run our own virtual conference at roughly the timeframe an ELC would have run.&lt;br /&gt;
&lt;br /&gt;
The organizing committee consists of (alphabetical by first name):&lt;br /&gt;
* Behan Webster&lt;br /&gt;
* David Reyna&lt;br /&gt;
* Josef Holzmayr-Khosh Amoz&lt;br /&gt;
* Nicolas Dechesne (YP Community Manager)&lt;br /&gt;
* Rudolf Streif&lt;br /&gt;
* Trevor Woerner&lt;br /&gt;
&lt;br /&gt;
The papers committee consists of:&lt;br /&gt;
* (the organizing committee)&lt;br /&gt;
* Armin Kuster&lt;br /&gt;
&lt;br /&gt;
In terms of platforms we&#039;re using:&lt;br /&gt;
* pretalx for the CfP and schedule&lt;br /&gt;
* the LF&#039;s cvent for registration&lt;br /&gt;
* Zoom for the conference video&lt;br /&gt;
* matrix for the conference chat&lt;br /&gt;
&lt;br /&gt;
For more information:&lt;br /&gt;
* https://www.yoctoproject.org/yocto-project-virtual-summit-2021/&lt;br /&gt;
* https://pretalx.com/yocto-project-summit-2021/&lt;/div&gt;</summary>
		<author><name>Trevor Woerner</name></author>
	</entry>
	<entry>
		<id>https://wiki.yoctoproject.org/wiki/index.php?title=SeasonOfDocs&amp;diff=73475</id>
		<title>SeasonOfDocs</title>
		<link rel="alternate" type="text/html" href="https://wiki.yoctoproject.org/wiki/index.php?title=SeasonOfDocs&amp;diff=73475"/>
		<updated>2020-04-30T18:43:12Z</updated>

		<summary type="html">&lt;p&gt;Trevor Woerner: /* Ideas */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= Yocto Project Season of Docs =&lt;br /&gt;
&lt;br /&gt;
==About==&lt;br /&gt;
The [http://yoctoproject.org Yocto Project] is an open-source project that delivers a set of tools that create operating system images for embedded Linux systems. The Yocto Project tools are based on the [http://www.openembedded.org/wiki/Main_Page OpenEmbedded] (OE) project, which uses the BitBake build tool, to construct complete Linux images. BitBake and OE are combined to form a reference build host known as Poky which includes the following [[Core Components|core components]]. This [https://www.youtube.com/watch?v=utZpKM7i5Z4 video] will help explain what it&#039;s all about.&lt;br /&gt;
&lt;br /&gt;
Richard Purdie, the Yocto Project&#039;s lead developer and Linux Foundation Fellow, considers documentation to be one of the cornerstones of this project. The quality and breadth of the documentation is one of the aspects of the project which is appreciated by and commented upon by our users. One of the very first members of that team to work on what became the Yocto Project 10 years ago was Scott Rifenbark, the project&#039;s tech writer. Sadly, Scott passed away early this year. The project is therefore at a cross roads with its documentation and with a need of new contributors and with that, the potential for new ideas and direction.&lt;br /&gt;
&lt;br /&gt;
Creating images and GNU/Linux-based distributions takes a wide breadth of knowledge. Even a simple and small image is the combination of dozens of individual software components, each of which has its own quirks and configurations. Each software component is free to choose whatever build system suits its developers, often with little regard for issues concerning cross-compilation. Users who are new to The Yocto Project, and especially new to image creation, are often overwhelmed by its necessary size and scope. Good, comprehensive documentation has always been at the core of The Yocto Project for both new and seasoned users alike.&lt;br /&gt;
&lt;br /&gt;
The Yocto Project hopes it will be successful in its bid for GSoD. But moreover is hoping to find the right person who will stay on with the project for years to come.&lt;br /&gt;
&lt;br /&gt;
==Google Season of Docs==&lt;br /&gt;
The Yocto Project is applying to the 2020 Google Season of Docs campaign. The deadline for the application is May 4th, 2020, and the results will be announced on May 11th, 2020. See https://developers.google.com/season-of-docs for additional information about this project.&lt;br /&gt;
&lt;br /&gt;
The following mailing list was created to discuss about the Season of Docs project: https://lists.yoctoproject.org/g/season-of-docs/.&lt;br /&gt;
&lt;br /&gt;
==Candidate Criteria==&lt;br /&gt;
&lt;br /&gt;
* excellent written command of the English language&lt;br /&gt;
* you have experience as a writer, preferably writing technical documentation&lt;br /&gt;
* able to distill &amp;quot;geek gobbledygook&amp;quot; into simple and understandable prose&lt;br /&gt;
* knowledge of and the ability to use various writing tools and schemes (sgml, xml, sphinx, etc)&lt;br /&gt;
* ability to draw simple but meaningful diagrams, and incorporate them into your writing&lt;br /&gt;
* strong ability to work with and use the Linux command-line&lt;br /&gt;
* it would be very beneficial for this role to know how to use git, at least at a basic level&lt;br /&gt;
* a &amp;quot;nice to have&amp;quot; skill would be the ability to read, run, and understand short snippets of python3 and shell code&lt;br /&gt;
* another &amp;quot;nice to have&amp;quot; skill would be the ability to run different Linux distros (e.g. Fedora, openSUSE, Ubuntu) in virtual environments&lt;br /&gt;
* willingness to hang out in the #yocto channel on freenode&#039;s irc server&lt;br /&gt;
&lt;br /&gt;
==Ideas==&lt;br /&gt;
&lt;br /&gt;
===Format Overhaul===&lt;br /&gt;
Currently the project&#039;s documentation is written in docbook, which is a natural choice for a documentation writer, but less so for, say, a developer. To make it as easy as possible for everyone to contribute to the documentation going forward, it would be a good time to convert the raw format of the documentation into a more modern format that is easier to learn. Hopefully this will encourage people who don&#039;t usually write project documentation to submit patches and updates. An experiment was undertaken to evaluate using Sphinx, see https://bugzilla.yoctoproject.org/show_bug.cgi?id=12970. In particular, there is significant potential to improve the way different versions of the manuals for different releases are handled and displayed to users through the website, as what is there today is not working for users.&lt;br /&gt;
&lt;br /&gt;
===One Voice===&lt;br /&gt;
Previously the project&#039;s documentation was written with one voice. Contributors would suggest updates, and Scott would make sure the flow had a certain uniformity; as though it had all been written in one go, by one person. Moving forward, it&#039;s likely the project&#039;s documentation updates will come from many contributors. It would be great to have someone review the current documentation and future updates with an eye towards maintaining one voice. Currently there are no style guidelines for the project; establishing some written guidelines for that &#039;voice&#039; may be part of this too.&lt;br /&gt;
&lt;br /&gt;
===Organization===&lt;br /&gt;
Currently the project&#039;s documentation is spread out in several places and formats. There are a number of manuals, some tutorials, a collection of wiki pages, and more. It would be great to see all this information collected together and organized in such a way as to make it easier for people new or experienced with the project to find exactly what they&#039;re looking for, quickly. Classify all existing documentation according to various attributes to identify areas that have weak or missing documentation. Fill any gaps in the documentation by creating new docs targeting specific users, tasks, or experience levels; or help motivate the right people to help generate the content. Work with the project&#039;s webmaster to present a unified location for all documentation. Perhaps run a survey to poll users on their thoughts regarding the usefulness of the current documentation, and generate an actionable report.&lt;br /&gt;
&lt;br /&gt;
===Tips and Tricks===&lt;br /&gt;
The project started a [[TipsAndTricks]] project which generated a significant amount of ideas and the start of content which it would be great to turn into sections in the manuals and better document some of these topics. Since the manual sections were never generated, the project stalled but could be restarted and the community would be keen to help with content and ideas.&lt;br /&gt;
&lt;br /&gt;
===Update/Release Process===&lt;br /&gt;
Currently the documentation generation and updating process is quite manual. We believe that integration into our CI and release process is desirable and would be the best way to handle this going forward.&lt;br /&gt;
&lt;br /&gt;
===How-to/Tasks Documentation===&lt;br /&gt;
There was work started to convert some of the manual to a more task oriented/&#039;how-to&#039; approach. https://bugzilla.yoctoproject.org/show_bug.cgi?id=11630 has some details but there is potential to significantly expand the task information. It would be great to see the manuals reach this goal of having a much more complete &amp;quot;how-to&amp;quot; task section.&lt;br /&gt;
&lt;br /&gt;
===Better Layer Integration===&lt;br /&gt;
The Yocto project is organized as a &amp;quot;core&amp;quot; (which is maintained by The Yocto Project) and &amp;quot;layers&amp;quot; (which are maintained by volunteers). Creating an image for a specific device will often require information for the core and information from individual layer components. There is an opportunity to investigate how to incorporate documentation from various layer projects into a unified whole.&lt;/div&gt;</summary>
		<author><name>Trevor Woerner</name></author>
	</entry>
	<entry>
		<id>https://wiki.yoctoproject.org/wiki/index.php?title=SeasonOfDocs&amp;diff=73474</id>
		<title>SeasonOfDocs</title>
		<link rel="alternate" type="text/html" href="https://wiki.yoctoproject.org/wiki/index.php?title=SeasonOfDocs&amp;diff=73474"/>
		<updated>2020-04-30T18:42:38Z</updated>

		<summary type="html">&lt;p&gt;Trevor Woerner: /* Ideas */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= Yocto Project Season of Docs =&lt;br /&gt;
&lt;br /&gt;
==About==&lt;br /&gt;
The [http://yoctoproject.org Yocto Project] is an open-source project that delivers a set of tools that create operating system images for embedded Linux systems. The Yocto Project tools are based on the [http://www.openembedded.org/wiki/Main_Page OpenEmbedded] (OE) project, which uses the BitBake build tool, to construct complete Linux images. BitBake and OE are combined to form a reference build host known as Poky which includes the following [[Core Components|core components]]. This [https://www.youtube.com/watch?v=utZpKM7i5Z4 video] will help explain what it&#039;s all about.&lt;br /&gt;
&lt;br /&gt;
Richard Purdie, the Yocto Project&#039;s lead developer and Linux Foundation Fellow, considers documentation to be one of the cornerstones of this project. The quality and breadth of the documentation is one of the aspects of the project which is appreciated by and commented upon by our users. One of the very first members of that team to work on what became the Yocto Project 10 years ago was Scott Rifenbark, the project&#039;s tech writer. Sadly, Scott passed away early this year. The project is therefore at a cross roads with its documentation and with a need of new contributors and with that, the potential for new ideas and direction.&lt;br /&gt;
&lt;br /&gt;
Creating images and GNU/Linux-based distributions takes a wide breadth of knowledge. Even a simple and small image is the combination of dozens of individual software components, each of which has its own quirks and configurations. Each software component is free to choose whatever build system suits its developers, often with little regard for issues concerning cross-compilation. Users who are new to The Yocto Project, and especially new to image creation, are often overwhelmed by its necessary size and scope. Good, comprehensive documentation has always been at the core of The Yocto Project for both new and seasoned users alike.&lt;br /&gt;
&lt;br /&gt;
The Yocto Project hopes it will be successful in its bid for GSoD. But moreover is hoping to find the right person who will stay on with the project for years to come.&lt;br /&gt;
&lt;br /&gt;
==Google Season of Docs==&lt;br /&gt;
The Yocto Project is applying to the 2020 Google Season of Docs campaign. The deadline for the application is May 4th, 2020, and the results will be announced on May 11th, 2020. See https://developers.google.com/season-of-docs for additional information about this project.&lt;br /&gt;
&lt;br /&gt;
The following mailing list was created to discuss about the Season of Docs project: https://lists.yoctoproject.org/g/season-of-docs/.&lt;br /&gt;
&lt;br /&gt;
==Candidate Criteria==&lt;br /&gt;
&lt;br /&gt;
* excellent written command of the English language&lt;br /&gt;
* you have experience as a writer, preferably writing technical documentation&lt;br /&gt;
* able to distill &amp;quot;geek gobbledygook&amp;quot; into simple and understandable prose&lt;br /&gt;
* knowledge of and the ability to use various writing tools and schemes (sgml, xml, sphinx, etc)&lt;br /&gt;
* ability to draw simple but meaningful diagrams, and incorporate them into your writing&lt;br /&gt;
* strong ability to work with and use the Linux command-line&lt;br /&gt;
* it would be very beneficial for this role to know how to use git, at least at a basic level&lt;br /&gt;
* a &amp;quot;nice to have&amp;quot; skill would be the ability to read, run, and understand short snippets of python3 and shell code&lt;br /&gt;
* another &amp;quot;nice to have&amp;quot; skill would be the ability to run different Linux distros (e.g. Fedora, openSUSE, Ubuntu) in virtual environments&lt;br /&gt;
* willingness to hang out in the #yocto channel on freenode&#039;s irc server&lt;br /&gt;
&lt;br /&gt;
==Ideas==&lt;br /&gt;
&lt;br /&gt;
===Format Overhaul===&lt;br /&gt;
Currently the project&#039;s documentation is written in docbook, which is a natural choice for a documentation writer, but less so for, say, a developer. To make it as easy as possible for everyone to contribute to the documentation going forward, it would be a good time to convert the raw format of the documentation into a more modern format that is easier to learn. Hopefully this will encourage people who don&#039;t usually write project documentation to submit patches and updates. An experiment was undertaken to evaluate using Sphinx, see https://bugzilla.yoctoproject.org/show_bug.cgi?id=12970. In particular, there is significant potential to improve the way different versions of the manuals for different releases are handled and displayed to users through the website, as what is there today is not working for users.&lt;br /&gt;
&lt;br /&gt;
===One Voice===&lt;br /&gt;
Previously the project&#039;s documentation was written with one voice. Contributors would suggest updates, and Scott would make sure the flow had a certain uniformity; as though it had all been written in one go, by one person. Moving forward, it&#039;s likely the project&#039;s documentation updates will come from many contributors. It would be great to have someone review the current documentation and future updates with an eye towards maintaining one voice. Currently there are no style guidelines for the project; establishing some written guidelines for that &#039;voice&#039; may be part of this too.&lt;br /&gt;
&lt;br /&gt;
===Organization===&lt;br /&gt;
Currently the project&#039;s documentation is spread out in several places and formats. There are a number of manuals, some tutorials, a collection of wiki pages, and more. It would be great to see all this information collected together and organized in such a way as to make it easier for people new or experienced with the project to find exactly what they&#039;re looking for, quickly. Classify all existing documentation according to various attributes to identify areas that have weak or missing documentation. Fill any gaps in the documentation by creating new docs targeting specific users, tasks, or experience levels; or help motivate the right people to help generate the content. Work with the project&#039;s webmaster to present a unified location for all documentation. Perhaps run a survey to poll users on their thoughts regarding the usefulness of the current documentation, and generate an actionable report.&lt;br /&gt;
&lt;br /&gt;
===Tips and Tricks===&lt;br /&gt;
The project started a [[TipsAndTricks]] project which generated a significant amount of ideas and the start of content which it would be great to turn into sections in the manuals and better document some of these topics. Since the manual sections were never generated, the project stalled but could be restarted and the community would be keen to help with content and ideas.&lt;br /&gt;
&lt;br /&gt;
===Update/Release Process===&lt;br /&gt;
Currently the documentation generation and updating process is quite manual. We believe that integration into our CI and release process is desirable and would be the best way to handle this going forward.&lt;br /&gt;
&lt;br /&gt;
===Better Layer Integration===&lt;br /&gt;
The Yocto project is organized as a &amp;quot;core&amp;quot; (which is maintained by The Yocto Project) and &amp;quot;layers&amp;quot; (which are maintained by volunteers). Creating an image for a specific device will often require information for the core and information from individual layer components. There is an opportunity to investigate how to incorporate documentation from various layer projects into a unified whole.&lt;br /&gt;
&lt;br /&gt;
===How-to/Tasks Documentation===&lt;br /&gt;
There was work started to convert some of the manual to a more task oriented/&#039;how-to&#039; approach. https://bugzilla.yoctoproject.org/show_bug.cgi?id=11630 has some details but there is potential to significantly expand the task information. It would be great to see the manuals reach this goal of having a much more complete &amp;quot;how-to&amp;quot; task section.&lt;/div&gt;</summary>
		<author><name>Trevor Woerner</name></author>
	</entry>
	<entry>
		<id>https://wiki.yoctoproject.org/wiki/index.php?title=SeasonOfDocs&amp;diff=73473</id>
		<title>SeasonOfDocs</title>
		<link rel="alternate" type="text/html" href="https://wiki.yoctoproject.org/wiki/index.php?title=SeasonOfDocs&amp;diff=73473"/>
		<updated>2020-04-30T18:36:01Z</updated>

		<summary type="html">&lt;p&gt;Trevor Woerner: /* One Voice */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= Yocto Project Season of Docs =&lt;br /&gt;
&lt;br /&gt;
==About==&lt;br /&gt;
The [http://yoctoproject.org Yocto Project] is an open-source project that delivers a set of tools that create operating system images for embedded Linux systems. The Yocto Project tools are based on the [http://www.openembedded.org/wiki/Main_Page OpenEmbedded] (OE) project, which uses the BitBake build tool, to construct complete Linux images. BitBake and OE are combined to form a reference build host known as Poky which includes the following [[Core Components|core components]]. This [https://www.youtube.com/watch?v=utZpKM7i5Z4 video] will help explain what it&#039;s all about.&lt;br /&gt;
&lt;br /&gt;
Richard Purdie, the Yocto Project&#039;s lead developer and Linux Foundation Fellow, considers documentation to be one of the cornerstones of this project. The quality and breadth of the documentation is one of the aspects of the project which is appreciated by and commented upon by our users. One of the very first members of that team to work on what became the Yocto Project 10 years ago was Scott Rifenbark, the project&#039;s tech writer. Sadly, Scott passed away early this year. The project is therefore at a cross roads with its documentation and with a need of new contributors and with that, the potential for new ideas and direction.&lt;br /&gt;
&lt;br /&gt;
Creating images and GNU/Linux-based distributions takes a wide breadth of knowledge. Even a simple and small image is the combination of dozens of individual software components, each of which has its own quirks and configurations. Each software component is free to choose whatever build system suits its developers, often with little regard for issues concerning cross-compilation. Users who are new to The Yocto Project, and especially new to image creation, are often overwhelmed by its necessary size and scope. Good, comprehensive documentation has always been at the core of The Yocto Project for both new and seasoned users alike.&lt;br /&gt;
&lt;br /&gt;
The Yocto Project hopes it will be successful in its bid for GSoD. But moreover is hoping to find the right person who will stay on with the project for years to come.&lt;br /&gt;
&lt;br /&gt;
==Google Season of Docs==&lt;br /&gt;
The Yocto Project is applying to the 2020 Google Season of Docs campaign. The deadline for the application is May 4th, 2020, and the results will be announced on May 11th, 2020. See https://developers.google.com/season-of-docs for additional information about this project.&lt;br /&gt;
&lt;br /&gt;
The following mailing list was created to discuss about the Season of Docs project: https://lists.yoctoproject.org/g/season-of-docs/.&lt;br /&gt;
&lt;br /&gt;
==Candidate Criteria==&lt;br /&gt;
&lt;br /&gt;
* excellent written command of the English language&lt;br /&gt;
* you have experience as a writer, preferably writing technical documentation&lt;br /&gt;
* able to distill &amp;quot;geek gobbledygook&amp;quot; into simple and understandable prose&lt;br /&gt;
* knowledge of and the ability to use various writing tools and schemes (sgml, xml, sphinx, etc)&lt;br /&gt;
* ability to draw simple but meaningful diagrams, and incorporate them into your writing&lt;br /&gt;
* strong ability to work with and use the Linux command-line&lt;br /&gt;
* it would be very beneficial for this role to know how to use git, at least at a basic level&lt;br /&gt;
* a &amp;quot;nice to have&amp;quot; skill would be the ability to read, run, and understand short snippets of python3 and shell code&lt;br /&gt;
* another &amp;quot;nice to have&amp;quot; skill would be the ability to run different Linux distros (e.g. Fedora, openSUSE, Ubuntu) in virtual environments&lt;br /&gt;
* willingness to hang out in the #yocto channel on freenode&#039;s irc server&lt;br /&gt;
&lt;br /&gt;
==Ideas==&lt;br /&gt;
&lt;br /&gt;
===Format Overhaul===&lt;br /&gt;
Currently the project&#039;s documentation is written in docbook, which is a natural choice for a documentation writer, but less so for, say, a developer. To make it as easy as possible for everyone to contribute to the documentation going forward, it would be a good time to convert the raw format of the documentation into a more modern format that is easier to learn. Hopefully this will encourage people who don&#039;t usually write project documentation to submit patches and updates. An experiment was undertaken to evaluate using Sphinx, see https://bugzilla.yoctoproject.org/show_bug.cgi?id=12970. In particular, there is significant potential to improve the way different versions of the manuals for different releases are handled and displayed to users through the website, as what is there today is not working for users.&lt;br /&gt;
&lt;br /&gt;
===One Voice===&lt;br /&gt;
Previously the project&#039;s documentation was written with one voice. Contributors would suggest updates, and Scott would make sure the flow had a certain uniformity; as though it had all been written in one go, by one person. Moving forward, it&#039;s likely the project&#039;s documentation updates will come from many contributors. It would be great to have someone review the current documentation and future updates with an eye towards maintaining one voice. Currently there are no style guidelines for the project; establishing some written guidelines for that &#039;voice&#039; may be part of this too.&lt;br /&gt;
&lt;br /&gt;
===Organization===&lt;br /&gt;
Currently the project&#039;s documentation is spread out in several places and formats. There are a number of manuals, some tutorials, a collection of wiki pages, and more. It would be great to see all this information collected together and organized in such a way as to make it easier for people new or experienced with the project to find exactly what they&#039;re looking for, quickly. Classify all existing documentation according to various attributes to identify areas that have weak or missing documentation. Fill any gaps in the documentation by creating new docs targeting specific users, tasks, or experience levels; or help motivate the right people to help generate the content. Work with the project&#039;s webmaster to present a unified location for all documentation.&lt;br /&gt;
&lt;br /&gt;
===Tips and Tricks===&lt;br /&gt;
The project started a [[TipsAndTricks]] project which generated a significant amount of ideas and the start of content which it would be great to turn into sections in the manuals and better document some of these topics. Since the manual sections were never generated, the project stalled but could be restarted and the community would be keen to help with content and ideas.&lt;br /&gt;
&lt;br /&gt;
===Update/Release Process===&lt;br /&gt;
Currently the documentation generation and updating process is quite manual. We believe that integration into our CI and release process is desirable and would be the best way to handle this going forward.&lt;br /&gt;
&lt;br /&gt;
===How-to/Tasks Documentation===&lt;br /&gt;
There was work started to convert some of the manual to a more task oriented/&#039;how-to&#039; approach. https://bugzilla.yoctoproject.org/show_bug.cgi?id=11630 has some details but there is potential to significantly expand the task information. It would be great to see the manuals reach this goal of having a much more complete &amp;quot;how-to&amp;quot; task section.&lt;/div&gt;</summary>
		<author><name>Trevor Woerner</name></author>
	</entry>
	<entry>
		<id>https://wiki.yoctoproject.org/wiki/index.php?title=SeasonOfDocs&amp;diff=73472</id>
		<title>SeasonOfDocs</title>
		<link rel="alternate" type="text/html" href="https://wiki.yoctoproject.org/wiki/index.php?title=SeasonOfDocs&amp;diff=73472"/>
		<updated>2020-04-30T18:34:26Z</updated>

		<summary type="html">&lt;p&gt;Trevor Woerner: /* One Voice */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= Yocto Project Season of Docs =&lt;br /&gt;
&lt;br /&gt;
==About==&lt;br /&gt;
The [http://yoctoproject.org Yocto Project] is an open-source project that delivers a set of tools that create operating system images for embedded Linux systems. The Yocto Project tools are based on the [http://www.openembedded.org/wiki/Main_Page OpenEmbedded] (OE) project, which uses the BitBake build tool, to construct complete Linux images. BitBake and OE are combined to form a reference build host known as Poky which includes the following [[Core Components|core components]]. This [https://www.youtube.com/watch?v=utZpKM7i5Z4 video] will help explain what it&#039;s all about.&lt;br /&gt;
&lt;br /&gt;
Richard Purdie, the Yocto Project&#039;s lead developer and Linux Foundation Fellow, considers documentation to be one of the cornerstones of this project. The quality and breadth of the documentation is one of the aspects of the project which is appreciated by and commented upon by our users. One of the very first members of that team to work on what became the Yocto Project 10 years ago was Scott Rifenbark, the project&#039;s tech writer. Sadly, Scott passed away early this year. The project is therefore at a cross roads with its documentation and with a need of new contributors and with that, the potential for new ideas and direction.&lt;br /&gt;
&lt;br /&gt;
Creating images and GNU/Linux-based distributions takes a wide breadth of knowledge. Even a simple and small image is the combination of dozens of individual software components, each of which has its own quirks and configurations. Each software component is free to choose whatever build system suits its developers, often with little regard for issues concerning cross-compilation. Users who are new to The Yocto Project, and especially new to image creation, are often overwhelmed by its necessary size and scope. Good, comprehensive documentation has always been at the core of The Yocto Project for both new and seasoned users alike.&lt;br /&gt;
&lt;br /&gt;
The Yocto Project hopes it will be successful in its bid for GSoD. But moreover is hoping to find the right person who will stay on with the project for years to come.&lt;br /&gt;
&lt;br /&gt;
==Google Season of Docs==&lt;br /&gt;
The Yocto Project is applying to the 2020 Google Season of Docs campaign. The deadline for the application is May 4th, 2020, and the results will be announced on May 11th, 2020. See https://developers.google.com/season-of-docs for additional information about this project.&lt;br /&gt;
&lt;br /&gt;
The following mailing list was created to discuss about the Season of Docs project: https://lists.yoctoproject.org/g/season-of-docs/.&lt;br /&gt;
&lt;br /&gt;
==Candidate Criteria==&lt;br /&gt;
&lt;br /&gt;
* excellent written command of the English language&lt;br /&gt;
* you have experience as a writer, preferably writing technical documentation&lt;br /&gt;
* able to distill &amp;quot;geek gobbledygook&amp;quot; into simple and understandable prose&lt;br /&gt;
* knowledge of and the ability to use various writing tools and schemes (sgml, xml, sphinx, etc)&lt;br /&gt;
* ability to draw simple but meaningful diagrams, and incorporate them into your writing&lt;br /&gt;
* strong ability to work with and use the Linux command-line&lt;br /&gt;
* it would be very beneficial for this role to know how to use git, at least at a basic level&lt;br /&gt;
* a &amp;quot;nice to have&amp;quot; skill would be the ability to read, run, and understand short snippets of python3 and shell code&lt;br /&gt;
* another &amp;quot;nice to have&amp;quot; skill would be the ability to run different Linux distros (e.g. Fedora, openSUSE, Ubuntu) in virtual environments&lt;br /&gt;
* willingness to hang out in the #yocto channel on freenode&#039;s irc server&lt;br /&gt;
&lt;br /&gt;
==Ideas==&lt;br /&gt;
&lt;br /&gt;
===Format Overhaul===&lt;br /&gt;
Currently the project&#039;s documentation is written in docbook, which is a natural choice for a documentation writer, but less so for, say, a developer. To make it as easy as possible for everyone to contribute to the documentation going forward, it would be a good time to convert the raw format of the documentation into a more modern format that is easier to learn. Hopefully this will encourage people who don&#039;t usually write project documentation to submit patches and updates. An experiment was undertaken to evaluate using Sphinx, see https://bugzilla.yoctoproject.org/show_bug.cgi?id=12970. In particular, there is significant potential to improve the way different versions of the manuals for different releases are handled and displayed to users through the website, as what is there today is not working for users.&lt;br /&gt;
&lt;br /&gt;
===One Voice===&lt;br /&gt;
Previously the project&#039;s documentation was written with one voice. Contributors would suggest updates, and Scott would make sure the flow had a certain uniformity; as though it had all been written in one go, by one person. Moving forward, it&#039;s likely the project&#039;s documentation updates will come from many contributors. It would be great to have someone review the current documentation and future updates with an eye towards maintaining one voice. The project has no documentation of the style of the documentation so establishing some written guidelines for that &#039;voice&#039; may be part of this too.&lt;br /&gt;
&lt;br /&gt;
===Organization===&lt;br /&gt;
Currently the project&#039;s documentation is spread out in several places and formats. There are a number of manuals, some tutorials, a collection of wiki pages, and more. It would be great to see all this information collected together and organized in such a way as to make it easier for people new or experienced with the project to find exactly what they&#039;re looking for, quickly. Classify all existing documentation according to various attributes to identify areas that have weak or missing documentation. Fill any gaps in the documentation by creating new docs targeting specific users, tasks, or experience levels; or help motivate the right people to help generate the content. Work with the project&#039;s webmaster to present a unified location for all documentation.&lt;br /&gt;
&lt;br /&gt;
===Tips and Tricks===&lt;br /&gt;
The project started a [[TipsAndTricks]] project which generated a significant amount of ideas and the start of content which it would be great to turn into sections in the manuals and better document some of these topics. Since the manual sections were never generated, the project stalled but could be restarted and the community would be keen to help with content and ideas.&lt;br /&gt;
&lt;br /&gt;
===Update/Release Process===&lt;br /&gt;
Currently the documentation generation and updating process is quite manual. We believe that integration into our CI and release process is desirable and would be the best way to handle this going forward.&lt;br /&gt;
&lt;br /&gt;
===How-to/Tasks Documentation===&lt;br /&gt;
There was work started to convert some of the manual to a more task oriented/&#039;how-to&#039; approach. https://bugzilla.yoctoproject.org/show_bug.cgi?id=11630 has some details but there is potential to significantly expand the task information. It would be great to see the manuals reach this goal of having a much more complete &amp;quot;how-to&amp;quot; task section.&lt;/div&gt;</summary>
		<author><name>Trevor Woerner</name></author>
	</entry>
	<entry>
		<id>https://wiki.yoctoproject.org/wiki/index.php?title=SeasonOfDocs&amp;diff=73471</id>
		<title>SeasonOfDocs</title>
		<link rel="alternate" type="text/html" href="https://wiki.yoctoproject.org/wiki/index.php?title=SeasonOfDocs&amp;diff=73471"/>
		<updated>2020-04-30T18:33:38Z</updated>

		<summary type="html">&lt;p&gt;Trevor Woerner: /* Format Overhaul */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= Yocto Project Season of Docs =&lt;br /&gt;
&lt;br /&gt;
==About==&lt;br /&gt;
The [http://yoctoproject.org Yocto Project] is an open-source project that delivers a set of tools that create operating system images for embedded Linux systems. The Yocto Project tools are based on the [http://www.openembedded.org/wiki/Main_Page OpenEmbedded] (OE) project, which uses the BitBake build tool, to construct complete Linux images. BitBake and OE are combined to form a reference build host known as Poky which includes the following [[Core Components|core components]]. This [https://www.youtube.com/watch?v=utZpKM7i5Z4 video] will help explain what it&#039;s all about.&lt;br /&gt;
&lt;br /&gt;
Richard Purdie, the Yocto Project&#039;s lead developer and Linux Foundation Fellow, considers documentation to be one of the cornerstones of this project. The quality and breadth of the documentation is one of the aspects of the project which is appreciated by and commented upon by our users. One of the very first members of that team to work on what became the Yocto Project 10 years ago was Scott Rifenbark, the project&#039;s tech writer. Sadly, Scott passed away early this year. The project is therefore at a cross roads with its documentation and with a need of new contributors and with that, the potential for new ideas and direction.&lt;br /&gt;
&lt;br /&gt;
Creating images and GNU/Linux-based distributions takes a wide breadth of knowledge. Even a simple and small image is the combination of dozens of individual software components, each of which has its own quirks and configurations. Each software component is free to choose whatever build system suits its developers, often with little regard for issues concerning cross-compilation. Users who are new to The Yocto Project, and especially new to image creation, are often overwhelmed by its necessary size and scope. Good, comprehensive documentation has always been at the core of The Yocto Project for both new and seasoned users alike.&lt;br /&gt;
&lt;br /&gt;
The Yocto Project hopes it will be successful in its bid for GSoD. But moreover is hoping to find the right person who will stay on with the project for years to come.&lt;br /&gt;
&lt;br /&gt;
==Google Season of Docs==&lt;br /&gt;
The Yocto Project is applying to the 2020 Google Season of Docs campaign. The deadline for the application is May 4th, 2020, and the results will be announced on May 11th, 2020. See https://developers.google.com/season-of-docs for additional information about this project.&lt;br /&gt;
&lt;br /&gt;
The following mailing list was created to discuss about the Season of Docs project: https://lists.yoctoproject.org/g/season-of-docs/.&lt;br /&gt;
&lt;br /&gt;
==Candidate Criteria==&lt;br /&gt;
&lt;br /&gt;
* excellent written command of the English language&lt;br /&gt;
* you have experience as a writer, preferably writing technical documentation&lt;br /&gt;
* able to distill &amp;quot;geek gobbledygook&amp;quot; into simple and understandable prose&lt;br /&gt;
* knowledge of and the ability to use various writing tools and schemes (sgml, xml, sphinx, etc)&lt;br /&gt;
* ability to draw simple but meaningful diagrams, and incorporate them into your writing&lt;br /&gt;
* strong ability to work with and use the Linux command-line&lt;br /&gt;
* it would be very beneficial for this role to know how to use git, at least at a basic level&lt;br /&gt;
* a &amp;quot;nice to have&amp;quot; skill would be the ability to read, run, and understand short snippets of python3 and shell code&lt;br /&gt;
* another &amp;quot;nice to have&amp;quot; skill would be the ability to run different Linux distros (e.g. Fedora, openSUSE, Ubuntu) in virtual environments&lt;br /&gt;
* willingness to hang out in the #yocto channel on freenode&#039;s irc server&lt;br /&gt;
&lt;br /&gt;
==Ideas==&lt;br /&gt;
&lt;br /&gt;
===Format Overhaul===&lt;br /&gt;
Currently the project&#039;s documentation is written in docbook, which is a natural choice for a documentation writer, but less so for, say, a developer. To make it as easy as possible for everyone to contribute to the documentation going forward, it would be a good time to convert the raw format of the documentation into a more modern format that is easier to learn. Hopefully this will encourage people who don&#039;t usually write project documentation to submit patches and updates. An experiment was undertaken to evaluate using Sphinx, see https://bugzilla.yoctoproject.org/show_bug.cgi?id=12970. In particular, there is significant potential to improve the way different versions of the manuals for different releases are handled and displayed to users through the website, as what is there today is not working for users.&lt;br /&gt;
&lt;br /&gt;
===One Voice===&lt;br /&gt;
Previously the project&#039;s documentation was written with one voice. Contributors would suggest updates, and Scott would make sure the flow had a certain uniformity; as though it had all been written in one go, by one person. Moving forward, it&#039;s likely the project&#039;s documentation updates will likely come from many contributors. It would be great to have someone review the current documentation and future updates with an eye towards maintaining one voice. The project has no documentation of the style of the documentation so establishing some written guidelines for that &#039;voice&#039; may be part of this too.&lt;br /&gt;
&lt;br /&gt;
===Organization===&lt;br /&gt;
Currently the project&#039;s documentation is spread out in several places and formats. There are a number of manuals, some tutorials, a collection of wiki pages, and more. It would be great to see all this information collected together and organized in such a way as to make it easier for people new or experienced with the project to find exactly what they&#039;re looking for, quickly. Classify all existing documentation according to various attributes to identify areas that have weak or missing documentation. Fill any gaps in the documentation by creating new docs targeting specific users, tasks, or experience levels; or help motivate the right people to help generate the content. Work with the project&#039;s webmaster to present a unified location for all documentation.&lt;br /&gt;
&lt;br /&gt;
===Tips and Tricks===&lt;br /&gt;
The project started a [[TipsAndTricks]] project which generated a significant amount of ideas and the start of content which it would be great to turn into sections in the manuals and better document some of these topics. Since the manual sections were never generated, the project stalled but could be restarted and the community would be keen to help with content and ideas.&lt;br /&gt;
&lt;br /&gt;
===Update/Release Process===&lt;br /&gt;
Currently the documentation generation and updating process is quite manual. We believe that integration into our CI and release process is desirable and would be the best way to handle this going forward.&lt;br /&gt;
&lt;br /&gt;
===How-to/Tasks Documentation===&lt;br /&gt;
There was work started to convert some of the manual to a more task oriented/&#039;how-to&#039; approach. https://bugzilla.yoctoproject.org/show_bug.cgi?id=11630 has some details but there is potential to significantly expand the task information. It would be great to see the manuals reach this goal of having a much more complete &amp;quot;how-to&amp;quot; task section.&lt;/div&gt;</summary>
		<author><name>Trevor Woerner</name></author>
	</entry>
	<entry>
		<id>https://wiki.yoctoproject.org/wiki/index.php?title=SeasonOfDocs&amp;diff=73470</id>
		<title>SeasonOfDocs</title>
		<link rel="alternate" type="text/html" href="https://wiki.yoctoproject.org/wiki/index.php?title=SeasonOfDocs&amp;diff=73470"/>
		<updated>2020-04-30T18:30:55Z</updated>

		<summary type="html">&lt;p&gt;Trevor Woerner: /* Candidate Criteria */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= Yocto Project Season of Docs =&lt;br /&gt;
&lt;br /&gt;
==About==&lt;br /&gt;
The [http://yoctoproject.org Yocto Project] is an open-source project that delivers a set of tools that create operating system images for embedded Linux systems. The Yocto Project tools are based on the [http://www.openembedded.org/wiki/Main_Page OpenEmbedded] (OE) project, which uses the BitBake build tool, to construct complete Linux images. BitBake and OE are combined to form a reference build host known as Poky which includes the following [[Core Components|core components]]. This [https://www.youtube.com/watch?v=utZpKM7i5Z4 video] will help explain what it&#039;s all about.&lt;br /&gt;
&lt;br /&gt;
Richard Purdie, the Yocto Project&#039;s lead developer and Linux Foundation Fellow, considers documentation to be one of the cornerstones of this project. The quality and breadth of the documentation is one of the aspects of the project which is appreciated by and commented upon by our users. One of the very first members of that team to work on what became the Yocto Project 10 years ago was Scott Rifenbark, the project&#039;s tech writer. Sadly, Scott passed away early this year. The project is therefore at a cross roads with its documentation and with a need of new contributors and with that, the potential for new ideas and direction.&lt;br /&gt;
&lt;br /&gt;
Creating images and GNU/Linux-based distributions takes a wide breadth of knowledge. Even a simple and small image is the combination of dozens of individual software components, each of which has its own quirks and configurations. Each software component is free to choose whatever build system suits its developers, often with little regard for issues concerning cross-compilation. Users who are new to The Yocto Project, and especially new to image creation, are often overwhelmed by its necessary size and scope. Good, comprehensive documentation has always been at the core of The Yocto Project for both new and seasoned users alike.&lt;br /&gt;
&lt;br /&gt;
The Yocto Project hopes it will be successful in its bid for GSoD. But moreover is hoping to find the right person who will stay on with the project for years to come.&lt;br /&gt;
&lt;br /&gt;
==Google Season of Docs==&lt;br /&gt;
The Yocto Project is applying to the 2020 Google Season of Docs campaign. The deadline for the application is May 4th, 2020, and the results will be announced on May 11th, 2020. See https://developers.google.com/season-of-docs for additional information about this project.&lt;br /&gt;
&lt;br /&gt;
The following mailing list was created to discuss about the Season of Docs project: https://lists.yoctoproject.org/g/season-of-docs/.&lt;br /&gt;
&lt;br /&gt;
==Candidate Criteria==&lt;br /&gt;
&lt;br /&gt;
* excellent written command of the English language&lt;br /&gt;
* you have experience as a writer, preferably writing technical documentation&lt;br /&gt;
* able to distill &amp;quot;geek gobbledygook&amp;quot; into simple and understandable prose&lt;br /&gt;
* knowledge of and the ability to use various writing tools and schemes (sgml, xml, sphinx, etc)&lt;br /&gt;
* ability to draw simple but meaningful diagrams, and incorporate them into your writing&lt;br /&gt;
* strong ability to work with and use the Linux command-line&lt;br /&gt;
* it would be very beneficial for this role to know how to use git, at least at a basic level&lt;br /&gt;
* a &amp;quot;nice to have&amp;quot; skill would be the ability to read, run, and understand short snippets of python3 and shell code&lt;br /&gt;
* another &amp;quot;nice to have&amp;quot; skill would be the ability to run different Linux distros (e.g. Fedora, openSUSE, Ubuntu) in virtual environments&lt;br /&gt;
* willingness to hang out in the #yocto channel on freenode&#039;s irc server&lt;br /&gt;
&lt;br /&gt;
==Ideas==&lt;br /&gt;
&lt;br /&gt;
===Format Overhaul===&lt;br /&gt;
Currently the project&#039;s documentation is written in docbook, which is a natural choice for a documentation writer, but less so for, say, a developer. To make it as easy as possible for everyone to contribute to the documentation going forward, it would be a good time to convert the raw format of the documentation into a more modern format that is easier to learn. Hopefully this will encourage people who don&#039;t usually write project documentation to submit patches and updates. An experimentation has started to evaluate using Sphinx, see https://bugzilla.yoctoproject.org/show_bug.cgi?id=12970. In particular, there is significant potential to improve the way different versions of the manuals for different releases is handled and displayed to users through the website as what is there today is not working for users.&lt;br /&gt;
&lt;br /&gt;
===One Voice===&lt;br /&gt;
Previously the project&#039;s documentation was written with one voice. Contributors would suggest updates, and Scott would make sure the flow had a certain uniformity; as though it had all been written in one go, by one person. Moving forward, it&#039;s likely the project&#039;s documentation updates will likely come from many contributors. It would be great to have someone review the current documentation and future updates with an eye towards maintaining one voice. The project has no documentation of the style of the documentation so establishing some written guidelines for that &#039;voice&#039; may be part of this too.&lt;br /&gt;
&lt;br /&gt;
===Organization===&lt;br /&gt;
Currently the project&#039;s documentation is spread out in several places and formats. There are a number of manuals, some tutorials, a collection of wiki pages, and more. It would be great to see all this information collected together and organized in such a way as to make it easier for people new or experienced with the project to find exactly what they&#039;re looking for, quickly. Classify all existing documentation according to various attributes to identify areas that have weak or missing documentation. Fill any gaps in the documentation by creating new docs targeting specific users, tasks, or experience levels; or help motivate the right people to help generate the content. Work with the project&#039;s webmaster to present a unified location for all documentation.&lt;br /&gt;
&lt;br /&gt;
===Tips and Tricks===&lt;br /&gt;
The project started a [[TipsAndTricks]] project which generated a significant amount of ideas and the start of content which it would be great to turn into sections in the manuals and better document some of these topics. Since the manual sections were never generated, the project stalled but could be restarted and the community would be keen to help with content and ideas.&lt;br /&gt;
&lt;br /&gt;
===Update/Release Process===&lt;br /&gt;
Currently the documentation generation and updating process is quite manual. We believe that integration into our CI and release process is desirable and would be the best way to handle this going forward.&lt;br /&gt;
&lt;br /&gt;
===How-to/Tasks Documentation===&lt;br /&gt;
There was work started to convert some of the manual to a more task oriented/&#039;how-to&#039; approach. https://bugzilla.yoctoproject.org/show_bug.cgi?id=11630 has some details but there is potential to significantly expand the task information. It would be great to see the manuals reach this goal of having a much more complete &amp;quot;how-to&amp;quot; task section.&lt;/div&gt;</summary>
		<author><name>Trevor Woerner</name></author>
	</entry>
</feed>