https://wiki.yoctoproject.org/wiki/api.php?action=feedcontributions&user=Davest&feedformat=atomYocto Project - User contributions [en]2024-03-29T05:05:26ZUser contributionsMediaWiki 1.39.5https://wiki.yoctoproject.org/wiki/index.php?title=Yocto_Project_Roadmap&diff=10890Yocto Project Roadmap2013-08-13T15:22:44Z<p>Davest: </p>
<hr />
<div>=== Yocto Project future roadmap ===<br />
<br />
At the highest level, the Yocto Project consists of three major components:<br />
<br />
* A '''build system''' - based primarily on the Bitbake project and including other associated projects such as Pseudo<br />
* '''Metadata''' - which includes classes, recipes, files and patches which, when taken together, build a working Linux system<br />
* A '''developer experience''' - methodologies and tools for developing embedded devices, which is mostly based on Eclipse, but also includes Hob and other tools.<br />
<br />
The project will continue to do regular releases to support development and bug fixes in all of these areas.<br />
<br />
For more specifics around what the project community is working on, check out the project bugzilla</div>Davesthttps://wiki.yoctoproject.org/wiki/index.php?title=Working_Draft_of_Compliance_Prop&diff=6085Working Draft of Compliance Prop2012-05-30T22:20:18Z<p>Davest: Reverted edits by Darknighte (talk) to last revision by Davest</p>
<hr />
<div>= YOCTO PROJECT Branding and Compliance =<br />
== Introduction ==<br />
The YOCTO PROJECT adheres to the guidelines set up by the Linux Foundation (add link here). The YOCTO PROJECT compliance program has been established to support and strengthen the YOCTO PROJECT strategic initiatives and promote by use of its branding.<br />
*To encourage the development of and collaboration on the use of a common set of tools, standards and practices to reduce fragmentation in the embedded market.<br />
*To ensure as much as possible that the tooling for these developments is architecturally independent.<br />
*To provide benefits to membership in the YOCTO PROJECT.<br />
<br />
In other words, the compliance program provides the necessary level of standardizations to allow OSVs, ODMs, Tools and Application developers to deliver implementations which contribute to and support the goals of the project and encourage an ecosystem to build around the YOCTO PROJECT.<br />
<br />
Compliance as defined by the YOCTO PROJECT governs the RIGHTS for the usage of the project name, Logo and marks in association with products, marketing materials, and announcements. The YOCTO PROJECT brand guidelines describes how to use these RIGHTS. (Add document link here – document and guidelines are in development)<br />
<br />
As with Linux, COMPLIANCE AFFECTS THE COMMERCIAL USE OF RESULTING PRODUCTS OR PROJECTS CREATED BY THE YOCTO PROJECT. PERSONAL USE CASES ARE NOT COVERED. <br />
<br />
<br />
== Compliance levels, Compliance Recommendations and Terminology ==<br />
The YOCTO PROJECT compliance program defines several steps of compliance to support OSVs, ODMs, Project Contributors, and Application Developers.<br />
<br />
== YOCTO PROJECT Brand Documentation ==<br />
Clear documentation how the brands can be used (palette etc) as well as when they can be used in conjunction with the above are found in the “YOCTO PROJECT Brand Usage Guide.”<br />
<br />
= YOCTO PROJECT Aligned = <br />
<br />
Instructions: To register for use of the YOCTO PROJECT Aligned logo/text:<br />
* Edit the wiki page, <br />
* copy the text below and add a new section for your project / organization<br />
* Send mail to yocto-ab@yoctoproject.org requesting registration<br />
* When you have received email acknowledgement, you may use the logo / text treatment<br />
<br />
== YOCTO PROJECT Aligned Registration Template == <br />
<br />
{| border="1" {{table}} <br />
| '''Organization / Project name''' || (Replace with text) <br />
|-<br />
| '''Contact Name / Email address''' || (Replace with text)<br />
|-<br />
| '''Registration Date''' || (Replace with text)<br />
|-<br />
| '''Compliance version''' || Version 1.0<br />
|}<br />
<br />
{| border="1" {{table}} <br />
| ! scope="col" bgcolor="grey" | '''Criteria''' || ! scope="col" bgcolor="grey" | '''Yes/No''' || ! scope="col" bgcolor="grey" | '''Explanation (if N or N/A)'''<br />
|- <br />
| Working towards and supporting the aims and objectives of the YOCTO PROJECT. These include decreasing the fragmentation of embedded ecosystem and focus around a common shared set of tools, formats and best practices. We want to avoid multiple groups of people repeating the same work and have one set of great tools rather than multiple tools with drawbacks. || Y or N || bgcolor="" | (Delete if "Y")<br />
|- <br />
| Promoting the OpenEmbedded Architecture, layer model and BSP format || Y or N || bgcolor="" | (Delete if "Y")<br />
|- <br />
| Committed to sending to the open source community any patches to OpenEmbedded-Core, BitBake and other YOCTO PROJECT layers || Y or N || bgcolor="" | (Delete if "Y")<br />
|- <br />
| Aim for compatibility and interoperability between different metadata layers. || Y or N || bgcolor="" | (Delete if "Y")<br />
|- <br />
| Be an open source project, non-profit, small business (up to 80 employees). || Y or N || bgcolor="" | (Delete if "Y")<br />
|}<br />
<br />
== YOCTO PROJECT Aligned Registrar ==<br />
<br />
=== OpenSDR (Consultant) ===<br />
<br />
<br />
{| border="1" {{table}} <br />
| '''Organization / Project name''' || OpenSDR (Example) <br />
|-<br />
| '''Contact Name / Email address''' || Philip Balister / philip@balister.org<br />
|-<br />
| '''Registration Date''' || May 20, 2012<br />
|-<br />
| '''Compliance version''' || Version 1.0<br />
|}<br />
<br />
{| border="1" {{table}} <br />
| ! scope="col" bgcolor="grey" | '''Criteria''' || ! scope="col" bgcolor="grey" | '''Yes/No''' || ! scope="col" bgcolor="grey" | '''Explanation (if N or N/A)'''<br />
|- <br />
| Working towards and supporting the aims and objectives of the YOCTO PROJECT. These include decreasing the fragmentation of embedded ecosystem and focus around a common shared set of tools, formats and best practices. We want to avoid multiple groups of people repeating the same work and have one set of great tools rather than multiple tools with drawbacks. || Y || bgcolor="" | <br />
|- <br />
| Promoting the OpenEmbedded Architecture, layer model and BSP format || Y || bgcolor="" | <br />
|- <br />
| Committed to sending to the open source community any patches to OpenEmbedded-Core, BitBake and other YOCTO PROJECT layers || Y || bgcolor="" | <br />
|- <br />
| Aim for compatibility and interoperability between different metadata layers. || Y || bgcolor="" | <br />
|- <br />
| Be an open source project, non-profit, small business (up to 80 employees). || Y || bgcolor="" | <br />
|}<br />
<br />
= YOCTO PROJECT Powered = <br />
<br />
<br />
Instructions: To register for use of the YOCTO PROJECT Powered logo/text:<br />
* Edit the wiki page, <br />
* copy the text below and add a new section for your project / organization<br />
* Send mail to yocto-ab@yoctoproject.org requesting registration<br />
* When you have received email acknowledgement, you may use the logo / text treatment<br />
<br />
<br />
{| border="1" {{table}} <br />
| '''Organization / Project name''' || (Replace with text) <br />
|-<br />
| '''Contact Name / Email address''' || (Replace with text)<br />
|-<br />
| '''Product / Project name''' || (Replace with text)<br />
|-<br />
| '''Release version number''' || (Replace with text)<br />
|-<br />
| '''Registration Date''' || (Replace with text)<br />
|-<br />
| '''Compliance version''' || Version 1.0<br />
|}<br />
<br />
<br />
== YOCTO PROJECT Powered Acceptance Criteria == <br />
{| border="1" {{table}} <br />
| ! scope="col" bgcolor="grey" | '''Criteria''' || ! scope="col" bgcolor="grey" | '''Yes/No''' || ! scope="col" bgcolor="grey" | '''Explanation (if N or N/A)'''<br />
|- <br />
| Working towards and supporting the aims and objectives of the YOCTO PROJECT. These include decreasing the fragmentation of embedded ecosystem and focus around a common shared set of tools, formats and best practices. We want to avoid multiple groups of people repeating the same work and have one set of great tools rather than multiple tools with drawbacks. || Y or N || bgcolor="" | (Delete if "Y")<br />
|- <br />
| Promoting the OpenEmbedded Architecture, layer model and BSP format || Y or N || bgcolor="" | (Delete if "Y")<br />
|- <br />
| Making visible contributions in the OpenEmbedded and component projects of the YOCTO PROJECT || Y or N || bgcolor="" | (Delete if "Y")<br />
|- <br />
| Be an open source project, non-profit or member of the YOCTO PROJECT working group, regardless of organization size || Y or N || bgcolor="" | (Delete if "Y")<br />
|-<br />
| If the project includes build system functionality, are BitBake and OpenEmbedded-Core included as components? || Y or N || bgcolor="" | (Delete if "Y")<br />
|-<br />
| If present, can the directories containing BitBake and OpenEmbedded-Core be clearly identified within the system and only contain those components? || Y or N || bgcolor="" | (Delete if "Y")<br />
|-<br />
| Have all patches applied to BitBake and OpenEmbedded-Core (if present) been submitted to the open source community? || Y or N || bgcolor="" | (Delete if "Y")<br />
|-<br />
| Do all layers contain a README file which details the origin of the layer, its maintainer, where to submit changes, and any dependencies or version requirements? || Y or N || bgcolor="" | (Delete if "Y")<br />
|-<br />
| Do all layers build without errors against OpenEmbedded-Core with only the dependencies/requirements listed in their README file? || Y or N || bgcolor="" | (Delete if "Y")<br />
|-<br />
| '''(For BSPs)''' Does the layer follow the format defined in the [http://www.yoctoproject.org/docs/current/bsp-guide/bsp-guide.html YOCTO PROJECT Board Support Package (BSP) Developers Guide]? || Y or N || bgcolor="" | (Delete if "Y")<br />
|-<br />
| Are hardware support, configuration (distro) policy and recipe metadata separated into different layers which do not depend on each other? || Y or N || bgcolor="" | (Delete if "Y")<br />
|-<br />
| A test report document is included of which combinations of layers, recipes and machines have been tested. || Y or N || bgcolor="" | (Delete if "Y")<br />
|-<br />
| If any item in the "YOCTO PROJECT Powered Compliance Recommendations" list is not true, is this documented in the testing report?|| Y or N || bgcolor="" | (Delete if "Y")<br />
|-<br />
|}<br />
<br />
== YOCTO PROJECT Powered Compliance Recommendations == <br />
{| border="1" {{table}} <br />
| ! scope="col" bgcolor="grey" | '''Criteria''' || ! scope="col" bgcolor="grey" | '''Yes/No''' || ! scope="col" bgcolor="grey" | '''Explanation (if N or N/A)'''<br />
|- <br />
| Linux kernels are either based around LTSI kernel versions or a YOCTO PROJECT kernel version || Y or N || bgcolor="" | (Delete if "Y")<br />
|-<br />
| Everything builds successfully with the standard toolchain from OE-Core where the architecture is one supported by OE-Core as standard? || Y or N || bgcolor="" | (Delete if "Y")<br />
|}<br />
<br />
<br />
== YOCTO PROJECT Powered Registrar == <br />
<br />
=== Mentor Graphics Embedded Linux ===<br />
<br />
{| border="1" {{table}} <br />
| '''Organization / Project name''' || Mentor Graphics, Inc <br />
|-<br />
| '''Contact Name / Email address''' || Sean Hudson, Sean_Hudson@mentor.com<br />
|-<br />
| '''Product / Project name''' || Mentor Embedded Linux<br />
|-<br />
| '''Release version number''' || v3.0<br />
|-<br />
| '''Registration Date''' || May 22, 2012<br />
|-<br />
| '''Compliance version''' || Version 1.0<br />
|}<br />
<br />
<br />
=== Mentor Graphics YOCTO PROJECT Powered Acceptance Criteria === <br />
{| border="1" {{table}} <br />
| ! scope="col" bgcolor="grey" | '''Criteria''' || ! scope="col" bgcolor="grey" | '''Yes/No''' || ! scope="col" bgcolor="grey" | '''Explanation (if N or N/A)'''<br />
|- <br />
| Working towards and supporting the aims and objectives of the YOCTO PROJECT. These include decreasing the fragmentation of embedded ecosystem and focus around a common shared set of tools, formats and best practices. We want to avoid multiple groups of people repeating the same work and have one set of great tools rather than multiple tools with drawbacks. || Y || bgcolor="" | <br />
|- <br />
| Promoting the OpenEmbedded Architecture, layer model and BSP format || Y || bgcolor="" | <br />
|- <br />
| Making visible contributions in the OpenEmbedded and component projects of the YOCTO PROJECT || Y || bgcolor="" | <br />
|- <br />
| Be an open source project, non-profit or member of the YOCTO PROJECT || Y || bgcolor="" | <br />
|-<br />
| If the project includes build system functionality, are BitBake and OpenEmbedded-Core included as components? || Y || bgcolor="" | <br />
|-<br />
| If present, can the directories containing BitBake and OpenEmbedded-Core be clearly identified within the system and only contain those components? || Y || bgcolor="" | <br />
|-<br />
| Have all patches applied to BitBake and OpenEmbedded-Core (if present) been submitted to the open source community? || Y || bgcolor="" | <br />
|-<br />
| Do all layers contain a README file which details the origin of the layer, its maintainer, where to submit changes, and any dependencies or version requirements? || Y || bgcolor="" | <br />
|-<br />
| Do all layers build without errors against OpenEmbedded-Core with only the dependencies/requirements listed in their README file? || Y || bgcolor="" | <br />
|-<br />
| '''(For BSPs)''' Does the layer follow the format defined in the [http://www.yoctoproject.org/docs/current/bsp-guide/bsp-guide.html YOCTO PROJECT Board Support Package (BSP) Developers Guide]? || Y || bgcolor="" | <br />
|-<br />
| Are hardware support, configuration (distro) policy and recipe metadata separated into different layers which do not depend on each other? || Y || bgcolor="" | <br />
|-<br />
| A test report document is included of which combinations of layers, recipes and machines have been tested. || Y || bgcolor="" | <br />
|-<br />
| If any item in the "YOCTO PROJECT Powered Compliance Recommendations" list is not true, is this documented in the testing report?|| Y || bgcolor="" | <br />
|-<br />
|}<br />
<br />
=== Mentor Graphics YOCTO PROJECT Powered Compliance Recommendations === <br />
{| border="1" {{table}} <br />
| ! scope="col" bgcolor="grey" | '''Criteria''' || ! scope="col" bgcolor="grey" | '''Yes/No''' || ! scope="col" bgcolor="grey" | '''Explanation (if N or N/A)'''<br />
|- <br />
| Linux kernels are either based around LTSI kernel versions or a YOCTO PROJECT kernel version || Y || bgcolor="" | Based on YOCTO PROJECT v1.1<br />
|-<br />
| Everything builds successfully with the standard toolchain from OE-Core where the architecture is one supported by OE-Core as standard? || Y || bgcolor="" | <br />
|}</div>Davesthttps://wiki.yoctoproject.org/wiki/index.php?title=Working_Draft_of_Compliance_Prop&diff=6079Working Draft of Compliance Prop2012-05-30T17:06:33Z<p>Davest: /* YOCTO PROJECT Brand Documentation */</p>
<hr />
<div>= YOCTO PROJECT Branding and Compliance =<br />
== Introduction ==<br />
The YOCTO PROJECT adheres to the guidelines set up by the Linux Foundation (add link here). The YOCTO PROJECT compliance program has been established to support and strengthen the YOCTO PROJECT strategic initiatives and promote by use of its branding.<br />
*To encourage the development of and collaboration on the use of a common set of tools, standards and practices to reduce fragmentation in the embedded market.<br />
*To ensure as much as possible that the tooling for these developments is architecturally independent.<br />
*To provide benefits to membership in the YOCTO PROJECT.<br />
<br />
In other words, the compliance program provides the necessary level of standardizations to allow OSVs, ODMs, Tools and Application developers to deliver implementations which contribute to and support the goals of the project and encourage an ecosystem to build around the YOCTO PROJECT.<br />
<br />
Compliance as defined by the YOCTO PROJECT governs the RIGHTS for the usage of the project name, Logo and marks in association with products, marketing materials, and announcements. The YOCTO PROJECT brand guidelines describes how to use these RIGHTS. (Add document link here – document and guidelines are in development)<br />
<br />
As with Linux, COMPLIANCE AFFECTS THE COMMERCIAL USE OF RESULTING PRODUCTS OR PROJECTS CREATED BY THE YOCTO PROJECT. PERSONAL USE CASES ARE NOT COVERED. <br />
<br />
<br />
== Compliance levels, Compliance Recommendations and Terminology ==<br />
The YOCTO PROJECT compliance program defines several steps of compliance to support OSVs, ODMs, Project Contributors, and Application Developers.<br />
<br />
== YOCTO PROJECT Brand Documentation ==<br />
Clear documentation how the brands can be used (palette etc) as well as when they can be used in conjunction with the above are found in the “YOCTO PROJECT Brand Usage Guide.”<br />
<br />
= YOCTO PROJECT Aligned = <br />
<br />
Instructions: To register for use of the YOCTO PROJECT Aligned logo/text:<br />
* Edit the wiki page, <br />
* copy the text below and add a new section for your project / organization<br />
* Send mail to yocto-ab@yoctoproject.org requesting registration<br />
* When you have received email acknowledgement, you may use the logo / text treatment<br />
<br />
== YOCTO PROJECT Aligned Registration Template == <br />
<br />
{| border="1" {{table}} <br />
| '''Organization / Project name''' || (Replace with text) <br />
|-<br />
| '''Contact Name / Email address''' || (Replace with text)<br />
|-<br />
| '''Registration Date''' || (Replace with text)<br />
|-<br />
| '''Compliance version''' || Version 1.0<br />
|}<br />
<br />
{| border="1" {{table}} <br />
| ! scope="col" bgcolor="grey" | '''Criteria''' || ! scope="col" bgcolor="grey" | '''Yes/No''' || ! scope="col" bgcolor="grey" | '''Explanation (if N or N/A)'''<br />
|- <br />
| Working towards and supporting the aims and objectives of the YOCTO PROJECT. These include decreasing the fragmentation of embedded ecosystem and focus around a common shared set of tools, formats and best practices. We want to avoid multiple groups of people repeating the same work and have one set of great tools rather than multiple tools with drawbacks. || Y or N || bgcolor="" | (Delete if "Y")<br />
|- <br />
| Promoting the OpenEmbedded Architecture, layer model and BSP format || Y or N || bgcolor="" | (Delete if "Y")<br />
|- <br />
| Committed to sending to the open source community any patches to OpenEmbedded-Core, BitBake and other YOCTO PROJECT layers || Y or N || bgcolor="" | (Delete if "Y")<br />
|- <br />
| Aim for compatibility and interoperability between different metadata layers. || Y or N || bgcolor="" | (Delete if "Y")<br />
|- <br />
| Be an open source project, non-profit, small business (up to 80 employees). || Y or N || bgcolor="" | (Delete if "Y")<br />
|}<br />
<br />
== YOCTO PROJECT Aligned Registrar ==<br />
<br />
=== OpenSDR (Consultant) ===<br />
<br />
<br />
{| border="1" {{table}} <br />
| '''Organization / Project name''' || OpenSDR (Example) <br />
|-<br />
| '''Contact Name / Email address''' || Philip Balister / philip@balister.org<br />
|-<br />
| '''Registration Date''' || May 20, 2012<br />
|-<br />
| '''Compliance version''' || Version 1.0<br />
|}<br />
<br />
{| border="1" {{table}} <br />
| ! scope="col" bgcolor="grey" | '''Criteria''' || ! scope="col" bgcolor="grey" | '''Yes/No''' || ! scope="col" bgcolor="grey" | '''Explanation (if N or N/A)'''<br />
|- <br />
| Working towards and supporting the aims and objectives of the YOCTO PROJECT. These include decreasing the fragmentation of embedded ecosystem and focus around a common shared set of tools, formats and best practices. We want to avoid multiple groups of people repeating the same work and have one set of great tools rather than multiple tools with drawbacks. || Y || bgcolor="" | <br />
|- <br />
| Promoting the OpenEmbedded Architecture, layer model and BSP format || Y || bgcolor="" | <br />
|- <br />
| Committed to sending to the open source community any patches to OpenEmbedded-Core, BitBake and other YOCTO PROJECT layers || Y || bgcolor="" | <br />
|- <br />
| Aim for compatibility and interoperability between different metadata layers. || Y || bgcolor="" | <br />
|- <br />
| Be an open source project, non-profit, small business (up to 80 employees). || Y || bgcolor="" | <br />
|}<br />
<br />
= YOCTO PROJECT Powered = <br />
<br />
<br />
Instructions: To register for use of the YOCTO PROJECT Powered logo/text:<br />
* Edit the wiki page, <br />
* copy the text below and add a new section for your project / organization<br />
* Send mail to yocto-ab@yoctoproject.org requesting registration<br />
* When you have received email acknowledgement, you may use the logo / text treatment<br />
<br />
<br />
{| border="1" {{table}} <br />
| '''Organization / Project name''' || (Replace with text) <br />
|-<br />
| '''Contact Name / Email address''' || (Replace with text)<br />
|-<br />
| '''Product / Project name''' || (Replace with text)<br />
|-<br />
| '''Release version number''' || (Replace with text)<br />
|-<br />
| '''Registration Date''' || (Replace with text)<br />
|-<br />
| '''Compliance version''' || Version 1.0<br />
|}<br />
<br />
<br />
== YOCTO PROJECT Powered Acceptance Criteria == <br />
{| border="1" {{table}} <br />
| ! scope="col" bgcolor="grey" | '''Criteria''' || ! scope="col" bgcolor="grey" | '''Yes/No''' || ! scope="col" bgcolor="grey" | '''Explanation (if N or N/A)'''<br />
|- <br />
| Working towards and supporting the aims and objectives of the YOCTO PROJECT. These include decreasing the fragmentation of embedded ecosystem and focus around a common shared set of tools, formats and best practices. We want to avoid multiple groups of people repeating the same work and have one set of great tools rather than multiple tools with drawbacks. || Y or N || bgcolor="" | (Delete if "Y")<br />
|- <br />
| Promoting the OpenEmbedded Architecture, layer model and BSP format || Y or N || bgcolor="" | (Delete if "Y")<br />
|- <br />
| Making visible contributions in the OpenEmbedded and component projects of the YOCTO PROJECT || Y or N || bgcolor="" | (Delete if "Y")<br />
|- <br />
| Be an open source project, non-profit or member of the YOCTO PROJECT working group, regardless of organization size || Y or N || bgcolor="" | (Delete if "Y")<br />
|-<br />
| If the project includes build system functionality, are BitBake and OpenEmbedded-Core included as components? || Y or N || bgcolor="" | (Delete if "Y")<br />
|-<br />
| If present, can the directories containing BitBake and OpenEmbedded-Core be clearly identified within the system and only contain those components? || Y or N || bgcolor="" | (Delete if "Y")<br />
|-<br />
| Have all patches applied to BitBake and OpenEmbedded-Core (if present) been submitted to the open source community? || Y or N || bgcolor="" | (Delete if "Y")<br />
|-<br />
| Do all layers contain a README file which details the origin of the layer, its maintainer, where to submit changes, and any dependencies or version requirements? || Y or N || bgcolor="" | (Delete if "Y")<br />
|-<br />
| Do all layers build without errors against OpenEmbedded-Core with only the dependencies/requirements listed in their README file? || Y or N || bgcolor="" | (Delete if "Y")<br />
|-<br />
| '''(For BSPs)''' Does the layer follow the format defined in the [http://www.yoctoproject.org/docs/current/bsp-guide/bsp-guide.html YOCTO PROJECT Board Support Package (BSP) Developers Guide]? || Y or N || bgcolor="" | (Delete if "Y")<br />
|-<br />
| Are hardware support, configuration (distro) policy and recipe metadata separated into different layers which do not depend on each other? || Y or N || bgcolor="" | (Delete if "Y")<br />
|-<br />
| A test report document is included of which combinations of layers, recipes and machines have been tested. || Y or N || bgcolor="" | (Delete if "Y")<br />
|-<br />
| If any item in the "YOCTO PROJECT Powered Compliance Recommendations" list is not true, is this documented in the testing report?|| Y or N || bgcolor="" | (Delete if "Y")<br />
|-<br />
|}<br />
<br />
== YOCTO PROJECT Powered Compliance Recommendations == <br />
{| border="1" {{table}} <br />
| ! scope="col" bgcolor="grey" | '''Criteria''' || ! scope="col" bgcolor="grey" | '''Yes/No''' || ! scope="col" bgcolor="grey" | '''Explanation (if N or N/A)'''<br />
|- <br />
| Linux kernels are either based around LTSI kernel versions or a YOCTO PROJECT kernel version || Y or N || bgcolor="" | (Delete if "Y")<br />
|-<br />
| Everything builds successfully with the standard toolchain from OE-Core where the architecture is one supported by OE-Core as standard? || Y or N || bgcolor="" | (Delete if "Y")<br />
|}<br />
<br />
<br />
== YOCTO PROJECT Powered Registrar == <br />
<br />
=== Mentor Graphics Embedded Linux ===<br />
<br />
{| border="1" {{table}} <br />
| '''Organization / Project name''' || Mentor Graphics, Inc <br />
|-<br />
| '''Contact Name / Email address''' || Sean Hudson, Sean_Hudson@mentor.com<br />
|-<br />
| '''Product / Project name''' || Mentor Embedded Linux<br />
|-<br />
| '''Release version number''' || v3.0<br />
|-<br />
| '''Registration Date''' || May 22, 2012<br />
|-<br />
| '''Compliance version''' || Version 1.0<br />
|}<br />
<br />
<br />
=== Mentor Graphics YOCTO PROJECT Powered Acceptance Criteria === <br />
{| border="1" {{table}} <br />
| ! scope="col" bgcolor="grey" | '''Criteria''' || ! scope="col" bgcolor="grey" | '''Yes/No''' || ! scope="col" bgcolor="grey" | '''Explanation (if N or N/A)'''<br />
|- <br />
| Working towards and supporting the aims and objectives of the YOCTO PROJECT. These include decreasing the fragmentation of embedded ecosystem and focus around a common shared set of tools, formats and best practices. We want to avoid multiple groups of people repeating the same work and have one set of great tools rather than multiple tools with drawbacks. || Y || bgcolor="" | <br />
|- <br />
| Promoting the OpenEmbedded Architecture, layer model and BSP format || Y || bgcolor="" | <br />
|- <br />
| Making visible contributions in the OpenEmbedded and component projects of the YOCTO PROJECT || Y || bgcolor="" | <br />
|- <br />
| Be an open source project, non-profit or member of the YOCTO PROJECT || Y || bgcolor="" | <br />
|-<br />
| If the project includes build system functionality, are BitBake and OpenEmbedded-Core included as components? || Y || bgcolor="" | <br />
|-<br />
| If present, can the directories containing BitBake and OpenEmbedded-Core be clearly identified within the system and only contain those components? || Y || bgcolor="" | <br />
|-<br />
| Have all patches applied to BitBake and OpenEmbedded-Core (if present) been submitted to the open source community? || Y || bgcolor="" | <br />
|-<br />
| Do all layers contain a README file which details the origin of the layer, its maintainer, where to submit changes, and any dependencies or version requirements? || Y || bgcolor="" | <br />
|-<br />
| Do all layers build without errors against OpenEmbedded-Core with only the dependencies/requirements listed in their README file? || Y || bgcolor="" | <br />
|-<br />
| '''(For BSPs)''' Does the layer follow the format defined in the [http://www.yoctoproject.org/docs/current/bsp-guide/bsp-guide.html YOCTO PROJECT Board Support Package (BSP) Developers Guide]? || Y || bgcolor="" | <br />
|-<br />
| Are hardware support, configuration (distro) policy and recipe metadata separated into different layers which do not depend on each other? || Y || bgcolor="" | <br />
|-<br />
| A test report document is included of which combinations of layers, recipes and machines have been tested. || Y || bgcolor="" | <br />
|-<br />
| If any item in the "YOCTO PROJECT Powered Compliance Recommendations" list is not true, is this documented in the testing report?|| Y || bgcolor="" | <br />
|-<br />
|}<br />
<br />
=== Mentor Graphics YOCTO PROJECT Powered Compliance Recommendations === <br />
{| border="1" {{table}} <br />
| ! scope="col" bgcolor="grey" | '''Criteria''' || ! scope="col" bgcolor="grey" | '''Yes/No''' || ! scope="col" bgcolor="grey" | '''Explanation (if N or N/A)'''<br />
|- <br />
| Linux kernels are either based around LTSI kernel versions or a YOCTO PROJECT kernel version || Y || bgcolor="" | Based on YOCTO PROJECT v1.1<br />
|-<br />
| Everything builds successfully with the standard toolchain from OE-Core where the architecture is one supported by OE-Core as standard? || Y || bgcolor="" | <br />
|}</div>Davesthttps://wiki.yoctoproject.org/wiki/index.php?title=Working_Draft_of_Compliance_Prop&diff=6078Working Draft of Compliance Prop2012-05-30T17:04:51Z<p>Davest: /* YOCTO PROJECT Powered */</p>
<hr />
<div>= YOCTO PROJECT Branding and Compliance =<br />
== Introduction ==<br />
The YOCTO PROJECT adheres to the guidelines set up by the Linux Foundation (add link here). The YOCTO PROJECT compliance program has been established to support and strengthen the YOCTO PROJECT strategic initiatives and promote by use of its branding.<br />
*To encourage the development of and collaboration on the use of a common set of tools, standards and practices to reduce fragmentation in the embedded market.<br />
*To ensure as much as possible that the tooling for these developments is architecturally independent.<br />
*To provide benefits to membership in the YOCTO PROJECT.<br />
<br />
In other words, the compliance program provides the necessary level of standardizations to allow OSVs, ODMs, Tools and Application developers to deliver implementations which contribute to and support the goals of the project and encourage an ecosystem to build around the YOCTO PROJECT.<br />
<br />
Compliance as defined by the YOCTO PROJECT governs the RIGHTS for the usage of the project name, Logo and marks in association with products, marketing materials, and announcements. The YOCTO PROJECT brand guidelines describes how to use these RIGHTS. (Add document link here – document and guidelines are in development)<br />
<br />
As with Linux, COMPLIANCE AFFECTS THE COMMERCIAL USE OF RESULTING PRODUCTS OR PROJECTS CREATED BY THE YOCTO PROJECT. PERSONAL USE CASES ARE NOT COVERED. <br />
<br />
<br />
== Compliance levels, Compliance Recommendations and Terminology ==<br />
The YOCTO PROJECT compliance program defines several steps of compliance to support OSVs, ODMs, Project Contributors, and Application Developers.<br />
<br />
== YOCTO PROJECT Brand Documentation ==<br />
Clearly document how the brands can be used (palette etc) as well as when they can be used in conjunction with the above. (in progress)<br />
<br />
= YOCTO PROJECT Aligned = <br />
<br />
Instructions: To register for use of the YOCTO PROJECT Aligned logo/text:<br />
* Edit the wiki page, <br />
* copy the text below and add a new section for your project / organization<br />
* Send mail to yocto-ab@yoctoproject.org requesting registration<br />
* When you have received email acknowledgement, you may use the logo / text treatment<br />
<br />
== YOCTO PROJECT Aligned Registration Template == <br />
<br />
{| border="1" {{table}} <br />
| '''Organization / Project name''' || (Replace with text) <br />
|-<br />
| '''Contact Name / Email address''' || (Replace with text)<br />
|-<br />
| '''Registration Date''' || (Replace with text)<br />
|-<br />
| '''Compliance version''' || Version 1.0<br />
|}<br />
<br />
{| border="1" {{table}} <br />
| ! scope="col" bgcolor="grey" | '''Criteria''' || ! scope="col" bgcolor="grey" | '''Yes/No''' || ! scope="col" bgcolor="grey" | '''Explanation (if N or N/A)'''<br />
|- <br />
| Working towards and supporting the aims and objectives of the YOCTO PROJECT. These include decreasing the fragmentation of embedded ecosystem and focus around a common shared set of tools, formats and best practices. We want to avoid multiple groups of people repeating the same work and have one set of great tools rather than multiple tools with drawbacks. || Y or N || bgcolor="" | (Delete if "Y")<br />
|- <br />
| Promoting the OpenEmbedded Architecture, layer model and BSP format || Y or N || bgcolor="" | (Delete if "Y")<br />
|- <br />
| Committed to sending to the open source community any patches to OpenEmbedded-Core, BitBake and other YOCTO PROJECT layers || Y or N || bgcolor="" | (Delete if "Y")<br />
|- <br />
| Aim for compatibility and interoperability between different metadata layers. || Y or N || bgcolor="" | (Delete if "Y")<br />
|- <br />
| Be an open source project, non-profit, small business (up to 80 employees). || Y or N || bgcolor="" | (Delete if "Y")<br />
|}<br />
<br />
== YOCTO PROJECT Aligned Registrar ==<br />
<br />
=== OpenSDR (Consultant) ===<br />
<br />
<br />
{| border="1" {{table}} <br />
| '''Organization / Project name''' || OpenSDR (Example) <br />
|-<br />
| '''Contact Name / Email address''' || Philip Balister / philip@balister.org<br />
|-<br />
| '''Registration Date''' || May 20, 2012<br />
|-<br />
| '''Compliance version''' || Version 1.0<br />
|}<br />
<br />
{| border="1" {{table}} <br />
| ! scope="col" bgcolor="grey" | '''Criteria''' || ! scope="col" bgcolor="grey" | '''Yes/No''' || ! scope="col" bgcolor="grey" | '''Explanation (if N or N/A)'''<br />
|- <br />
| Working towards and supporting the aims and objectives of the YOCTO PROJECT. These include decreasing the fragmentation of embedded ecosystem and focus around a common shared set of tools, formats and best practices. We want to avoid multiple groups of people repeating the same work and have one set of great tools rather than multiple tools with drawbacks. || Y || bgcolor="" | <br />
|- <br />
| Promoting the OpenEmbedded Architecture, layer model and BSP format || Y || bgcolor="" | <br />
|- <br />
| Committed to sending to the open source community any patches to OpenEmbedded-Core, BitBake and other YOCTO PROJECT layers || Y || bgcolor="" | <br />
|- <br />
| Aim for compatibility and interoperability between different metadata layers. || Y || bgcolor="" | <br />
|- <br />
| Be an open source project, non-profit, small business (up to 80 employees). || Y || bgcolor="" | <br />
|}<br />
<br />
= YOCTO PROJECT Powered = <br />
<br />
<br />
Instructions: To register for use of the YOCTO PROJECT Powered logo/text:<br />
* Edit the wiki page, <br />
* copy the text below and add a new section for your project / organization<br />
* Send mail to yocto-ab@yoctoproject.org requesting registration<br />
* When you have received email acknowledgement, you may use the logo / text treatment<br />
<br />
<br />
{| border="1" {{table}} <br />
| '''Organization / Project name''' || (Replace with text) <br />
|-<br />
| '''Contact Name / Email address''' || (Replace with text)<br />
|-<br />
| '''Product / Project name''' || (Replace with text)<br />
|-<br />
| '''Release version number''' || (Replace with text)<br />
|-<br />
| '''Registration Date''' || (Replace with text)<br />
|-<br />
| '''Compliance version''' || Version 1.0<br />
|}<br />
<br />
<br />
== YOCTO PROJECT Powered Acceptance Criteria == <br />
{| border="1" {{table}} <br />
| ! scope="col" bgcolor="grey" | '''Criteria''' || ! scope="col" bgcolor="grey" | '''Yes/No''' || ! scope="col" bgcolor="grey" | '''Explanation (if N or N/A)'''<br />
|- <br />
| Working towards and supporting the aims and objectives of the YOCTO PROJECT. These include decreasing the fragmentation of embedded ecosystem and focus around a common shared set of tools, formats and best practices. We want to avoid multiple groups of people repeating the same work and have one set of great tools rather than multiple tools with drawbacks. || Y or N || bgcolor="" | (Delete if "Y")<br />
|- <br />
| Promoting the OpenEmbedded Architecture, layer model and BSP format || Y or N || bgcolor="" | (Delete if "Y")<br />
|- <br />
| Making visible contributions in the OpenEmbedded and component projects of the YOCTO PROJECT || Y or N || bgcolor="" | (Delete if "Y")<br />
|- <br />
| Be an open source project, non-profit or member of the YOCTO PROJECT working group, regardless of organization size || Y or N || bgcolor="" | (Delete if "Y")<br />
|-<br />
| If the project includes build system functionality, are BitBake and OpenEmbedded-Core included as components? || Y or N || bgcolor="" | (Delete if "Y")<br />
|-<br />
| If present, can the directories containing BitBake and OpenEmbedded-Core be clearly identified within the system and only contain those components? || Y or N || bgcolor="" | (Delete if "Y")<br />
|-<br />
| Have all patches applied to BitBake and OpenEmbedded-Core (if present) been submitted to the open source community? || Y or N || bgcolor="" | (Delete if "Y")<br />
|-<br />
| Do all layers contain a README file which details the origin of the layer, its maintainer, where to submit changes, and any dependencies or version requirements? || Y or N || bgcolor="" | (Delete if "Y")<br />
|-<br />
| Do all layers build without errors against OpenEmbedded-Core with only the dependencies/requirements listed in their README file? || Y or N || bgcolor="" | (Delete if "Y")<br />
|-<br />
| '''(For BSPs)''' Does the layer follow the format defined in the [http://www.yoctoproject.org/docs/current/bsp-guide/bsp-guide.html YOCTO PROJECT Board Support Package (BSP) Developers Guide]? || Y or N || bgcolor="" | (Delete if "Y")<br />
|-<br />
| Are hardware support, configuration (distro) policy and recipe metadata separated into different layers which do not depend on each other? || Y or N || bgcolor="" | (Delete if "Y")<br />
|-<br />
| A test report document is included of which combinations of layers, recipes and machines have been tested. || Y or N || bgcolor="" | (Delete if "Y")<br />
|-<br />
| If any item in the "YOCTO PROJECT Powered Compliance Recommendations" list is not true, is this documented in the testing report?|| Y or N || bgcolor="" | (Delete if "Y")<br />
|-<br />
|}<br />
<br />
== YOCTO PROJECT Powered Compliance Recommendations == <br />
{| border="1" {{table}} <br />
| ! scope="col" bgcolor="grey" | '''Criteria''' || ! scope="col" bgcolor="grey" | '''Yes/No''' || ! scope="col" bgcolor="grey" | '''Explanation (if N or N/A)'''<br />
|- <br />
| Linux kernels are either based around LTSI kernel versions or a YOCTO PROJECT kernel version || Y or N || bgcolor="" | (Delete if "Y")<br />
|-<br />
| Everything builds successfully with the standard toolchain from OE-Core where the architecture is one supported by OE-Core as standard? || Y or N || bgcolor="" | (Delete if "Y")<br />
|}<br />
<br />
<br />
== YOCTO PROJECT Powered Registrar == <br />
<br />
=== Mentor Graphics Embedded Linux ===<br />
<br />
{| border="1" {{table}} <br />
| '''Organization / Project name''' || Mentor Graphics, Inc <br />
|-<br />
| '''Contact Name / Email address''' || Sean Hudson, Sean_Hudson@mentor.com<br />
|-<br />
| '''Product / Project name''' || Mentor Embedded Linux<br />
|-<br />
| '''Release version number''' || v3.0<br />
|-<br />
| '''Registration Date''' || May 22, 2012<br />
|-<br />
| '''Compliance version''' || Version 1.0<br />
|}<br />
<br />
<br />
=== Mentor Graphics YOCTO PROJECT Powered Acceptance Criteria === <br />
{| border="1" {{table}} <br />
| ! scope="col" bgcolor="grey" | '''Criteria''' || ! scope="col" bgcolor="grey" | '''Yes/No''' || ! scope="col" bgcolor="grey" | '''Explanation (if N or N/A)'''<br />
|- <br />
| Working towards and supporting the aims and objectives of the YOCTO PROJECT. These include decreasing the fragmentation of embedded ecosystem and focus around a common shared set of tools, formats and best practices. We want to avoid multiple groups of people repeating the same work and have one set of great tools rather than multiple tools with drawbacks. || Y || bgcolor="" | <br />
|- <br />
| Promoting the OpenEmbedded Architecture, layer model and BSP format || Y || bgcolor="" | <br />
|- <br />
| Making visible contributions in the OpenEmbedded and component projects of the YOCTO PROJECT || Y || bgcolor="" | <br />
|- <br />
| Be an open source project, non-profit or member of the YOCTO PROJECT || Y || bgcolor="" | <br />
|-<br />
| If the project includes build system functionality, are BitBake and OpenEmbedded-Core included as components? || Y || bgcolor="" | <br />
|-<br />
| If present, can the directories containing BitBake and OpenEmbedded-Core be clearly identified within the system and only contain those components? || Y || bgcolor="" | <br />
|-<br />
| Have all patches applied to BitBake and OpenEmbedded-Core (if present) been submitted to the open source community? || Y || bgcolor="" | <br />
|-<br />
| Do all layers contain a README file which details the origin of the layer, its maintainer, where to submit changes, and any dependencies or version requirements? || Y || bgcolor="" | <br />
|-<br />
| Do all layers build without errors against OpenEmbedded-Core with only the dependencies/requirements listed in their README file? || Y || bgcolor="" | <br />
|-<br />
| '''(For BSPs)''' Does the layer follow the format defined in the [http://www.yoctoproject.org/docs/current/bsp-guide/bsp-guide.html YOCTO PROJECT Board Support Package (BSP) Developers Guide]? || Y || bgcolor="" | <br />
|-<br />
| Are hardware support, configuration (distro) policy and recipe metadata separated into different layers which do not depend on each other? || Y || bgcolor="" | <br />
|-<br />
| A test report document is included of which combinations of layers, recipes and machines have been tested. || Y || bgcolor="" | <br />
|-<br />
| If any item in the "YOCTO PROJECT Powered Compliance Recommendations" list is not true, is this documented in the testing report?|| Y || bgcolor="" | <br />
|-<br />
|}<br />
<br />
=== Mentor Graphics YOCTO PROJECT Powered Compliance Recommendations === <br />
{| border="1" {{table}} <br />
| ! scope="col" bgcolor="grey" | '''Criteria''' || ! scope="col" bgcolor="grey" | '''Yes/No''' || ! scope="col" bgcolor="grey" | '''Explanation (if N or N/A)'''<br />
|- <br />
| Linux kernels are either based around LTSI kernel versions or a YOCTO PROJECT kernel version || Y || bgcolor="" | Based on YOCTO PROJECT v1.1<br />
|-<br />
| Everything builds successfully with the standard toolchain from OE-Core where the architecture is one supported by OE-Core as standard? || Y || bgcolor="" | <br />
|}</div>Davesthttps://wiki.yoctoproject.org/wiki/index.php?title=Working_Draft_of_Compliance_Proposal&diff=6045Working Draft of Compliance Proposal2012-05-24T00:42:37Z<p>Davest: Replaced content with "This document has been deprecated - the droids you are looking for are at: [ https://wiki.yoctoproject.org/wiki/Working_Draft_of_Compliance_Prop ]
(This redirect is due to D..."</p>
<hr />
<div>This document has been deprecated - the droids you are looking for are at: [ https://wiki.yoctoproject.org/wiki/Working_Draft_of_Compliance_Prop ]<br />
<br />
(This redirect is due to Dave Stewart's jet-lagged blunder. Apologies to Sean Hudson)</div>Davesthttps://wiki.yoctoproject.org/wiki/index.php?title=Working_Draft_of_Compliance_Prop&diff=6037Working Draft of Compliance Prop2012-05-22T23:45:25Z<p>Davest: </p>
<hr />
<div>= Yocto Project Branding and Compliance =<br />
== Introduction ==<br />
The YOCTO PROJECT adheres to the guidelines set up by the Linux Foundation (add link here). The YOCTO PROJECT compliance program has been established to support and strengthen the YOCTO PROJECT strategic initiatives and promote by use of its branding.<br />
*To encourage the development of and collaboration on the use of a common set of tools, standards and practices to reduce fragmentation in the embedded market.<br />
*To ensure as much as possible that the tooling for these developments is architecturally independent.<br />
*To provide benefits to membership in the YOCTO PROJECT.<br />
<br />
In other words, the compliance program provides the necessary level of standardizations to allow OSVs, ODMs, Tools and Application developers to deliver implementations which contribute to and support the goals of the project and encourage an ecosystem to build around the Yocto Project.<br />
<br />
Compliance as defined by the YOCTO PROJECT governs the use of the project name, Logo and marks in association with products, marketing materials, and announcements. The YOCTO PROJECT brand guidelines call out how those usages must appear. (Add document link here – document and guidelines are in development)<br />
<br />
As with Linux, COMPLIANCE AFFECTS THE COMMERCIAL USE OF RESULTING PRODUCTS OR PROJECTS CREATED BY THE YOCTO PROJECT. PERSONAL USE CASES ARE NOT COVERED. <br />
<br />
<br />
== Compliance levels, Compliance Recommendations and Terminology ==<br />
The Yocto Project compliance program defines several steps of compliance to support OSVs, ODMs, Project Contributors, and Application Developers.<br />
<br />
== Yocto Project Brand Documentation ==<br />
Clearly document how the brands can be used (palette etc) as well as when they can be used in conjunction with the above. (in progress)<br />
<br />
<br />
= Yocto Project Aligned = <br />
<br />
Instructions: To register for use of the Yocto Project Aligned logo/text:<br />
* Edit the wiki page, <br />
* copy the text below and add a new section for your project / organization<br />
* Send mail to yocto-ab@yoctoproject.org requesting registration<br />
* When you have received email acknowledgement, you may use the logo / text treatment<br />
<br />
== Yocto Project Aligned Registration Template == <br />
<br />
{| border="1" {{table}} <br />
| '''Organization / Project name''' || (Replace with text) <br />
|-<br />
| '''Contact Name / Email address''' || (Replace with text)<br />
|-<br />
| '''Registration Date''' || (Replace with text)<br />
|-<br />
| '''Compliance version''' || Version 1.0<br />
|}<br />
<br />
{| border="1" {{table}} <br />
| ! scope="col" bgcolor="grey" | '''Criteria''' || ! scope="col" bgcolor="grey" | '''Yes/No''' || ! scope="col" bgcolor="grey" | '''Explanation (if N or N/A)'''<br />
|- <br />
| Working towards and supporting the aims and objectives of the Yocto Project. These include decreasing the fragmentation of embedded ecosystem and focus around a common shared set of tools, formats and best practices. We want to avoid multiple groups of people repeating the same work and have one set of great tools rather than multiple tools with drawbacks. || Y or N || bgcolor="" | (Delete if "Y")<br />
|- <br />
| Promoting the OpenEmbedded Architecture, layer model and BSP format || Y or N || bgcolor="" | (Delete if "Y")<br />
|- <br />
| Committed to sending to the open source community any patches to OpenEmbedded-Core, BitBake and other Yocto Project layers || Y or N || bgcolor="" | (Delete if "Y")<br />
|- <br />
| Aim for compatibility and interoperability between different metadata layers. || Y or N || bgcolor="" | (Delete if "Y")<br />
|- <br />
| Be an open source project, non-profit, small business (up to 80 employees). || Y or N || bgcolor="" | (Delete if "Y")<br />
|}<br />
<br />
== Yocto Project Aligned Registrar ==<br />
<br />
=== OpenSDR (Consultant) ===<br />
<br />
<br />
{| border="1" {{table}} <br />
| '''Organization / Project name''' || OpenSDR (Example) <br />
|-<br />
| '''Contact Name / Email address''' || Philip Balister / philip@balister.org<br />
|-<br />
| '''Registration Date''' || May 20, 2012<br />
|-<br />
| '''Compliance version''' || Version 1.0<br />
|}<br />
<br />
{| border="1" {{table}} <br />
| ! scope="col" bgcolor="grey" | '''Criteria''' || ! scope="col" bgcolor="grey" | '''Yes/No''' || ! scope="col" bgcolor="grey" | '''Explanation (if N or N/A)'''<br />
|- <br />
| Working towards and supporting the aims and objectives of the Yocto Project. These include decreasing the fragmentation of embedded ecosystem and focus around a common shared set of tools, formats and best practices. We want to avoid multiple groups of people repeating the same work and have one set of great tools rather than multiple tools with drawbacks. || Y || bgcolor="" | <br />
|- <br />
| Promoting the OpenEmbedded Architecture, layer model and BSP format || Y || bgcolor="" | <br />
|- <br />
| Committed to sending to the open source community any patches to OpenEmbedded-Core, BitBake and other Yocto Project layers || Y || bgcolor="" | <br />
|- <br />
| Aim for compatibility and interoperability between different metadata layers. || Y || bgcolor="" | <br />
|- <br />
| Be an open source project, non-profit, small business (up to 80 employees). || Y || bgcolor="" | <br />
|}<br />
<br />
= Yocto Project Powered = <br />
<br />
<br />
Instructions: To register for use of the Yocto Project Aligned logo/text:<br />
* Edit the wiki page, <br />
* copy the text below and add a new section for your project / organization<br />
* Send mail to yocto-ab@yoctoproject.org requesting registration<br />
* When you have received email acknowledgement, you may use the logo / text treatment<br />
<br />
<br />
{| border="1" {{table}} <br />
| '''Organization / Project name''' || (Replace with text) <br />
|-<br />
| '''Contact Name / Email address''' || (Replace with text)<br />
|-<br />
| '''Product / Project name''' || (Replace with text)<br />
|-<br />
| '''Release version number''' || (Replace with text)<br />
|-<br />
| '''Registration Date''' || (Replace with text)<br />
|-<br />
| '''Compliance version''' || Version 1.0<br />
|}<br />
<br />
<br />
== Yocto Project Powered Acceptance Criteria == <br />
{| border="1" {{table}} <br />
| ! scope="col" bgcolor="grey" | '''Criteria''' || ! scope="col" bgcolor="grey" | '''Yes/No''' || ! scope="col" bgcolor="grey" | '''Explanation (if N or N/A)'''<br />
|- <br />
| Working towards and supporting the aims and objectives of the Yocto Project. These include decreasing the fragmentation of embedded ecosystem and focus around a common shared set of tools, formats and best practices. We want to avoid multiple groups of people repeating the same work and have one set of great tools rather than multiple tools with drawbacks. || Y or N || bgcolor="" | (Delete if "Y")<br />
|- <br />
| Promoting the OpenEmbedded Architecture, layer model and BSP format || Y or N || bgcolor="" | (Delete if "Y")<br />
|- <br />
| Making visible contributions in the OpenEmbedded and component projects of the Yocto Project || Y or N || bgcolor="" | (Delete if "Y")<br />
|- <br />
| Be an open source project, non-profit or member of the Yocto Project working group, regardless of organization size || Y or N || bgcolor="" | (Delete if "Y")<br />
|-<br />
| If the project includes build system functionality, are BitBake and OpenEmbedded-Core included as components? || Y or N || bgcolor="" | (Delete if "Y")<br />
|-<br />
| If present, can the directories containing BitBake and OpenEmbedded-Core be clearly identified within the system and only contain those components? || Y or N || bgcolor="" | (Delete if "Y")<br />
|-<br />
| Have all patches applied to BitBake and OpenEmbedded-Core (if present) been submitted to the open source community? || Y or N || bgcolor="" | (Delete if "Y")<br />
|-<br />
| Do all layers contain a README file which details the origin of the layer, its maintainer, where to submit changes, and any dependencies or version requirements? || Y or N || bgcolor="" | (Delete if "Y")<br />
|-<br />
| Do all layers build without errors against OpenEmbedded-Core with only the dependencies/requirements listed in their README file? || Y or N || bgcolor="" | (Delete if "Y")<br />
|-<br />
| '''(For BSPs)''' Does the layer follow the format defined in the [http://www.yoctoproject.org/docs/current/bsp-guide/bsp-guide.html Yocto Project Board Support Package (BSP) Developers Guide]? || Y or N || bgcolor="" | (Delete if "Y")<br />
|-<br />
| Are hardware support, configuration (distro) policy and recipe metadata separated into different layers which do not depend on each other? || Y or N || bgcolor="" | (Delete if "Y")<br />
|-<br />
| A test report document is included of which combinations of layers, recipes and machines have been tested. || Y or N || bgcolor="" | (Delete if "Y")<br />
|-<br />
| If any item in the "Yocto Project Powered Compliance Recommendations" list is not true, is this documented in the testing report?|| Y or N || bgcolor="" | (Delete if "Y")<br />
|-<br />
|}<br />
<br />
== Yocto Project Powered Compliance Recommendations == <br />
{| border="1" {{table}} <br />
| ! scope="col" bgcolor="grey" | '''Criteria''' || ! scope="col" bgcolor="grey" | '''Yes/No''' || ! scope="col" bgcolor="grey" | '''Explanation (if N or N/A)'''<br />
|- <br />
| Linux kernels are either based around LTSI kernel versions or a Yocto Project kernel version || Y or N || bgcolor="" | (Delete if "Y")<br />
|-<br />
| Everything builds successfully with the standard toolchain from OE-Core where the architecture is one supported by OE-Core as standard? || Y or N || bgcolor="" | (Delete if "Y")<br />
|}<br />
<br />
<br />
== Yocto Project Powered Registrar == <br />
<br />
=== Mentor Graphics Embedded Linux ===<br />
<br />
{| border="1" {{table}} <br />
| '''Organization / Project name''' || Mentor Graphics, Inc <br />
|-<br />
| '''Contact Name / Email address''' || Sean Hudson, Sean_Hudson@mentor.com<br />
|-<br />
| '''Product / Project name''' || Mentor Embedded Linux<br />
|-<br />
| '''Release version number''' || v3.0<br />
|-<br />
| '''Registration Date''' || May 22, 2012<br />
|-<br />
| '''Compliance version''' || Version 1.0<br />
|}<br />
<br />
<br />
=== Mentor Graphics Yocto Project Powered Acceptance Criteria === <br />
{| border="1" {{table}} <br />
| ! scope="col" bgcolor="grey" | '''Criteria''' || ! scope="col" bgcolor="grey" | '''Yes/No''' || ! scope="col" bgcolor="grey" | '''Explanation (if N or N/A)'''<br />
|- <br />
| Working towards and supporting the aims and objectives of the Yocto Project. These include decreasing the fragmentation of embedded ecosystem and focus around a common shared set of tools, formats and best practices. We want to avoid multiple groups of people repeating the same work and have one set of great tools rather than multiple tools with drawbacks. || Y || bgcolor="" | <br />
|- <br />
| Promoting the OpenEmbedded Architecture, layer model and BSP format || Y || bgcolor="" | <br />
|- <br />
| Making visible contributions in the OpenEmbedded and component projects of the Yocto Project || Y || bgcolor="" | <br />
|- <br />
| Be an open source project, non-profit or member of the Yocto Project || Y || bgcolor="" | <br />
|-<br />
| If the project includes build system functionality, are BitBake and OpenEmbedded-Core included as components? || Y || bgcolor="" | <br />
|-<br />
| If present, can the directories containing BitBake and OpenEmbedded-Core be clearly identified within the system and only contain those components? || Y || bgcolor="" | <br />
|-<br />
| Have all patches applied to BitBake and OpenEmbedded-Core (if present) been submitted to the open source community? || Y || bgcolor="" | <br />
|-<br />
| Do all layers contain a README file which details the origin of the layer, its maintainer, where to submit changes, and any dependencies or version requirements? || Y || bgcolor="" | <br />
|-<br />
| Do all layers build without errors against OpenEmbedded-Core with only the dependencies/requirements listed in their README file? || Y || bgcolor="" | <br />
|-<br />
| '''(For BSPs)''' Does the layer follow the format defined in the [http://www.yoctoproject.org/docs/current/bsp-guide/bsp-guide.html Yocto Project Board Support Package (BSP) Developers Guide]? || Y || bgcolor="" | <br />
|-<br />
| Are hardware support, configuration (distro) policy and recipe metadata separated into different layers which do not depend on each other? || Y || bgcolor="" | <br />
|-<br />
| A test report document is included of which combinations of layers, recipes and machines have been tested. || Y || bgcolor="" | <br />
|-<br />
| If any item in the "Yocto Project Powered Compliance Recommendations" list is not true, is this documented in the testing report?|| Y || bgcolor="" | <br />
|-<br />
|}<br />
<br />
=== Mentor Graphics Yocto Project Powered Compliance Recommendations === <br />
{| border="1" {{table}} <br />
| ! scope="col" bgcolor="grey" | '''Criteria''' || ! scope="col" bgcolor="grey" | '''Yes/No''' || ! scope="col" bgcolor="grey" | '''Explanation (if N or N/A)'''<br />
|- <br />
| Linux kernels are either based around LTSI kernel versions or a Yocto Project kernel version || Y || bgcolor="" | Based on Yocto Project v1.1<br />
|-<br />
| Everything builds successfully with the standard toolchain from OE-Core where the architecture is one supported by OE-Core as standard? || Y || bgcolor="" | <br />
|}</div>Davesthttps://wiki.yoctoproject.org/wiki/index.php?title=Working_Draft_of_Compliance_Prop&diff=6036Working Draft of Compliance Prop2012-05-22T23:12:26Z<p>Davest: Created page with "= Yocto Project Branding and Compliance = == Introduction == The YOCTO PROJECT adheres to the guidelines set up by the Linux Foundation (add link here). The YOCTO PROJECT compli..."</p>
<hr />
<div>= Yocto Project Branding and Compliance =<br />
== Introduction ==<br />
The YOCTO PROJECT adheres to the guidelines set up by the Linux Foundation (add link here). The YOCTO PROJECT compliance program has been established to support and strengthen the YOCTO PROJECT strategic initiatives and promote by use of its branding.<br />
*To encourage the development of and collaboration on the use of a common set of tools, standards and practices to reduce fragmentation in the embedded market.<br />
*To ensure as much as possible that the tooling for these developments is architecturally independent.<br />
*To provide benefits to membership in the YOCTO PROJECT.<br />
<br />
In other words, the compliance program provides the necessary level of standardizations to allow OSVs, ODMs, Tools and Application developers to deliver implementations which contribute to and support the goals of the project.<br />
<br />
Compliance as defined by the YOCTO PROJECT governs the use of the project name, Logo and marks in association with products, marketing materials, and announcements. Use of the YOCTO PROJECT name, logo and marks is governed by the YOCTO PROJECT brand guidelines. (Add document link here – document and guidelines are in development)<br />
<br />
As with Linux, COMPLIANCE AFFECTS THE COMMERCIAL USE OF THE RESULTING DISTRIBUTIONS CREATED BY THE YOCTO PROJECT. PERSONAL USE CASES ARE NOT COVERED. <br />
<br />
<br />
== Compliance levels, Compliance Recommendations and Terminology ==<br />
The Yocto Project compliance program defines several steps of compliance to support OSVs, ODMs, Project Contributors, and Application Developers.<br />
<br />
== Yocto Project Brand Documentation ==<br />
Clearly document how the brands can be used (palette etc) as well as when they can be used in conjunction with the above. (in progress)<br />
<br />
<br />
= Yocto Project Aligned = <br />
<br />
Instructions: To register for use of the Yocto Project Aligned logo/text:<br />
* Edit the wiki page, <br />
* copy the text below and add a new section for your project / organization<br />
* Send mail to yocto-ab@yoctoproject.org requesting registration<br />
* When you have received email acknowledgement, you may use the logo / text treatment<br />
<br />
== Yocto Project Aligned Registration Template == <br />
<br />
{| border="1" {{table}} <br />
| '''Organization / Project name''' || (Replace with text) <br />
|-<br />
| '''Contact Name / Email address''' || (Replace with text)<br />
|-<br />
| '''Registration Date''' || (Replace with text)<br />
|-<br />
| '''Compliance version''' || Version 1.0<br />
|}<br />
<br />
{| border="1" {{table}} <br />
| ! scope="col" bgcolor="grey" | '''Criteria''' || ! scope="col" bgcolor="grey" | '''Yes/No''' || ! scope="col" bgcolor="grey" | '''Explanation (if N or N/A)'''<br />
|- <br />
| Working towards and supporting the aims and objectives of the Yocto Project. These include decreasing the fragmentation of embedded ecosystem and focus around a common shared set of tools, formats and best practices. We want to avoid multiple groups of people repeating the same work and have one set of great tools rather than multiple tools with drawbacks. || Y or N || bgcolor="" | (Delete if "Y")<br />
|- <br />
| Promoting the OpenEmbedded Architecture, layer model and BSP format || Y or N || bgcolor="" | (Delete if "Y")<br />
|- <br />
| Committed to sending to the open source community any patches to OpenEmbedded-Core, BitBake and other Yocto Project layers || Y or N || bgcolor="" | (Delete if "Y")<br />
|- <br />
| Aim for compatibility and interoperability between different metadata layers. || Y or N || bgcolor="" | (Delete if "Y")<br />
|- <br />
| Be an open source project, non-profit, small business (up to 80 employees). || Y or N || bgcolor="" | (Delete if "Y")<br />
|}<br />
<br />
== Yocto Project Aligned Registrar ==<br />
<br />
=== OpenSDR (Consultant) ===<br />
<br />
<br />
{| border="1" {{table}} <br />
| '''Organization / Project name''' || OpenSDR (Example) <br />
|-<br />
| '''Contact Name / Email address''' || Philip Balister / philip@balister.org<br />
|-<br />
| '''Registration Date''' || May 20, 2012<br />
|-<br />
| '''Compliance version''' || Version 1.0<br />
|}<br />
<br />
{| border="1" {{table}} <br />
| ! scope="col" bgcolor="grey" | '''Criteria''' || ! scope="col" bgcolor="grey" | '''Yes/No''' || ! scope="col" bgcolor="grey" | '''Explanation (if N or N/A)'''<br />
|- <br />
| Working towards and supporting the aims and objectives of the Yocto Project. These include decreasing the fragmentation of embedded ecosystem and focus around a common shared set of tools, formats and best practices. We want to avoid multiple groups of people repeating the same work and have one set of great tools rather than multiple tools with drawbacks. || Y || bgcolor="" | <br />
|- <br />
| Promoting the OpenEmbedded Architecture, layer model and BSP format || Y || bgcolor="" | <br />
|- <br />
| Committed to sending to the open source community any patches to OpenEmbedded-Core, BitBake and other Yocto Project layers || Y || bgcolor="" | <br />
|- <br />
| Aim for compatibility and interoperability between different metadata layers. || Y || bgcolor="" | <br />
|- <br />
| Be an open source project, non-profit, small business (up to 80 employees). || Y || bgcolor="" | <br />
|}<br />
<br />
= Yocto Project Powered = <br />
<br />
<br />
Instructions: To register for use of the Yocto Project Aligned logo/text:<br />
* Edit the wiki page, <br />
* copy the text below and add a new section for your project / organization<br />
* Send mail to yocto-ab@yoctoproject.org requesting registration<br />
* When you have received email acknowledgement, you may use the logo / text treatment<br />
<br />
<br />
{| border="1" {{table}} <br />
| '''Organization / Project name''' || (Replace with text) <br />
|-<br />
| '''Contact Name / Email address''' || (Replace with text)<br />
|-<br />
| '''Product / Project name''' || (Replace with text)<br />
|-<br />
| '''Release version number''' || (Replace with text)<br />
|-<br />
| '''Registration Date''' || (Replace with text)<br />
|-<br />
| '''Compliance version''' || Version 1.0<br />
|}<br />
<br />
<br />
== Yocto Project Powered Acceptance Criteria == <br />
{| border="1" {{table}} <br />
| ! scope="col" bgcolor="grey" | '''Criteria''' || ! scope="col" bgcolor="grey" | '''Yes/No''' || ! scope="col" bgcolor="grey" | '''Explanation (if N or N/A)'''<br />
|- <br />
| Working towards and supporting the aims and objectives of the Yocto Project. These include decreasing the fragmentation of embedded ecosystem and focus around a common shared set of tools, formats and best practices. We want to avoid multiple groups of people repeating the same work and have one set of great tools rather than multiple tools with drawbacks. || Y or N || bgcolor="" | (Delete if "Y")<br />
|- <br />
| Promoting the OpenEmbedded Architecture, layer model and BSP format || Y or N || bgcolor="" | (Delete if "Y")<br />
|- <br />
| Making visible contributions in the OpenEmbedded and component projects of the Yocto Project || Y or N || bgcolor="" | (Delete if "Y")<br />
|- <br />
| Be an open source project, non-profit or member of the Yocto Project || Y or N || bgcolor="" | (Delete if "Y")<br />
|-<br />
| If the project includes build system functionality, are BitBake and OpenEmbedded-Core included as components? || Y or N || bgcolor="" | (Delete if "Y")<br />
|-<br />
| If present, can the directories containing BitBake and OpenEmbedded-Core be clearly identified within the system and only contain those components? || Y or N || bgcolor="" | (Delete if "Y")<br />
|-<br />
| Have all patches applied to BitBake and OpenEmbedded-Core (if present) been submitted to the open source community? || Y or N || bgcolor="" | (Delete if "Y")<br />
|-<br />
| Do all layers contain a README file which details the origin of the layer, its maintainer, where to submit changes, and any dependencies or version requirements? || Y or N || bgcolor="" | (Delete if "Y")<br />
|-<br />
| Do all layers build without errors against OpenEmbedded-Core with only the dependencies/requirements listed in their README file? || Y or N || bgcolor="" | (Delete if "Y")<br />
|-<br />
| '''(For BSPs)''' Does the layer follow the format defined in the [http://www.yoctoproject.org/docs/current/bsp-guide/bsp-guide.html Yocto Project Board Support Package (BSP) Developers Guide]? || Y or N || bgcolor="" | (Delete if "Y")<br />
|-<br />
| Are hardware support, configuration (distro) policy and recipe metadata separated into different layers which do not depend on each other? || Y or N || bgcolor="" | (Delete if "Y")<br />
|-<br />
| A test report document is included of which combinations of layers, recipes and machines have been tested. || Y or N || bgcolor="" | (Delete if "Y")<br />
|-<br />
| If any item in the "Yocto Project Powered Compliance Recommendations" list is not true, is this documented in the testing report?|| Y or N || bgcolor="" | (Delete if "Y")<br />
|-<br />
|}<br />
<br />
== Yocto Project Powered Compliance Recommendations == <br />
{| border="1" {{table}} <br />
| ! scope="col" bgcolor="grey" | '''Criteria''' || ! scope="col" bgcolor="grey" | '''Yes/No''' || ! scope="col" bgcolor="grey" | '''Explanation (if N or N/A)'''<br />
|- <br />
| Linux kernels are either based around LTSI kernel versions or a Yocto Project kernel version || Y or N || bgcolor="" | (Delete if "Y")<br />
|-<br />
| Everything builds successfully with the standard toolchain from OE-Core where the architecture is one supported by OE-Core as standard? || Y or N || bgcolor="" | (Delete if "Y")<br />
|}<br />
<br />
<br />
== Yocto Project Powered Registrar == <br />
<br />
=== Mentor Graphics Embedded Linux ===<br />
<br />
{| border="1" {{table}} <br />
| '''Organization / Project name''' || Mentor Graphics, Inc <br />
|-<br />
| '''Contact Name / Email address''' || Sean Hudson, Sean_Hudson@mentor.com<br />
|-<br />
| '''Product / Project name''' || Mentor Embedded Linux<br />
|-<br />
| '''Release version number''' || v3.0<br />
|-<br />
| '''Registration Date''' || May 22, 2012<br />
|-<br />
| '''Compliance version''' || Version 1.0<br />
|}<br />
<br />
<br />
=== Mentor Graphics Yocto Project Powered Acceptance Criteria === <br />
{| border="1" {{table}} <br />
| ! scope="col" bgcolor="grey" | '''Criteria''' || ! scope="col" bgcolor="grey" | '''Yes/No''' || ! scope="col" bgcolor="grey" | '''Explanation (if N or N/A)'''<br />
|- <br />
| Working towards and supporting the aims and objectives of the Yocto Project. These include decreasing the fragmentation of embedded ecosystem and focus around a common shared set of tools, formats and best practices. We want to avoid multiple groups of people repeating the same work and have one set of great tools rather than multiple tools with drawbacks. || Y || bgcolor="" | <br />
|- <br />
| Promoting the OpenEmbedded Architecture, layer model and BSP format || Y || bgcolor="" | <br />
|- <br />
| Making visible contributions in the OpenEmbedded and component projects of the Yocto Project || Y || bgcolor="" | <br />
|- <br />
| Be an open source project, non-profit or member of the Yocto Project || Y || bgcolor="" | <br />
|-<br />
| If the project includes build system functionality, are BitBake and OpenEmbedded-Core included as components? || Y || bgcolor="" | <br />
|-<br />
| If present, can the directories containing BitBake and OpenEmbedded-Core be clearly identified within the system and only contain those components? || Y || bgcolor="" | <br />
|-<br />
| Have all patches applied to BitBake and OpenEmbedded-Core (if present) been submitted to the open source community? || Y || bgcolor="" | <br />
|-<br />
| Do all layers contain a README file which details the origin of the layer, its maintainer, where to submit changes, and any dependencies or version requirements? || Y || bgcolor="" | <br />
|-<br />
| Do all layers build without errors against OpenEmbedded-Core with only the dependencies/requirements listed in their README file? || Y || bgcolor="" | <br />
|-<br />
| '''(For BSPs)''' Does the layer follow the format defined in the [http://www.yoctoproject.org/docs/current/bsp-guide/bsp-guide.html Yocto Project Board Support Package (BSP) Developers Guide]? || Y || bgcolor="" | <br />
|-<br />
| Are hardware support, configuration (distro) policy and recipe metadata separated into different layers which do not depend on each other? || Y || bgcolor="" | <br />
|-<br />
| A test report document is included of which combinations of layers, recipes and machines have been tested. || Y || bgcolor="" | <br />
|-<br />
| If any item in the "Yocto Project Powered Compliance Recommendations" list is not true, is this documented in the testing report?|| Y || bgcolor="" | <br />
|-<br />
|}<br />
<br />
=== Mentor Graphics Yocto Project Powered Compliance Recommendations === <br />
{| border="1" {{table}} <br />
| ! scope="col" bgcolor="grey" | '''Criteria''' || ! scope="col" bgcolor="grey" | '''Yes/No''' || ! scope="col" bgcolor="grey" | '''Explanation (if N or N/A)'''<br />
|- <br />
| Linux kernels are either based around LTSI kernel versions or a Yocto Project kernel version || Y || bgcolor="" | Based on Yocto Project v1.1<br />
|-<br />
| Everything builds successfully with the standard toolchain from OE-Core where the architecture is one supported by OE-Core as standard? || Y || bgcolor="" | <br />
|}</div>Davesthttps://wiki.yoctoproject.org/wiki/index.php?title=Yocto_1.2_Features&diff=3555Yocto 1.2 Features2011-09-30T15:52:03Z<p>Davest: This needs a good scrub - in particular, need a scrub of the test framework items</p>
<hr />
<div>== Potential Yocto Project 1.2 Features ==<br />
Yocto Project 1.2 - Target release = April 2012<br />
<br />
== Yocto Project 1.2 Themes ==<br />
The topics below are the themes that some members of the team have started brainstorming for Yocto Project v1.2. These will be improved with community input.<br />
<br />
=== Yocto Project 1.2 Objectives ===<br />
The objectives of the Yocto 1.2 release are to increase adoption of the Yocto Project.<br />
<br />
=== Yocto Project 1.2 Theme List ===<br />
The Yocto Project 1.2 Themes towards the Objectives listed above are:<br />
<br />
* Improved usability of the build system for new experienced users, new novice users and existing users.<br />
*<br />
<br />
== Process for Entering New Feature Requests ==<br />
<br />
* Create a new entry in the appropriate feature table below (Poky, SDK, Hardware)<br />
** Suggestion: start by copying an existing request as a template<br />
* Give the feature a short, descriptive name<br />
* Provide a one or two sentence brief description of the feature<br />
* Set the priority as appropriate (see the legend below)<br />
* Set the Status to "Review"<br />
* In the Source field, enter your name along with the origination of the request (e.g. OSV, OEM, Community) if applicable; provide as much detail here as you can<br />
* In the Comments / Bugzilla field, provide any additional information for the request, such as a link to a bugzilla entry<br />
* Preview your Entry to make sure it looks ok and then save it<br />
<br />
''Legend''<br />
<br />
'''Priority:''' 1 = Must Have, 2 = Nice to Have, 3 = Optional<br />
<br />
'''Status:''' Accept = Engineering agreement to include in release, Review = Under Review for Inclusion in this release, Reject = Will not be included in this release<br />
== Sample Table ==<br />
<br />
This is a sample table to show how to submit features.<br />
<br />
{| border="1"<br />
||'''Feature Name''' ||'''Description''' ||'''Priority''' ||'''Status''' ||'''Source''' ||'''Comments / Bugzilla Links'''<br />
|-<br />
||Placeholder feature name || Placeholder description of the feature || 1, 2, or 3 || Review|| name|| Comment<br />
|}<br />
<br />
== Usability ==<br />
{| border="1"<br />
| align="center" style="background:#f0f0f0;"|'''Feature Name'''<br />
| align="center" style="background:#f0f0f0;"|'''Description'''<br />
| align="center" style="background:#f0f0f0;"|'''Priority'''<br />
| align="center" style="background:#f0f0f0;"|'''Status'''<br />
| align="center" style="background:#f0f0f0;"|'''Source'''<br />
| align="center" style="background:#f0f0f0;"|'''Owner'''<br />
| align="center" style="background:#f0f0f0;"|'''Comments / Bugzilla Links'''<br />
|-<br />
| build appliance||Intended for developers to very easily "Check it out" and do a Yocto Project build with minimal pain. Should be a virtual image of a desktop OS which will boot into HOB and offer a terminal or an app to deploy resulting images to media or to run QEMU.||1||Review||davest/tracey/RP||TBD||See here for [[Build Appliance Design]]<br />
|-<br />
| Visual Hob ||Massively update interface for Hob, perhaps similar to SuSE Studio. This is for both local (non-network) builds as well as network.||1||Review||davest/tracey/RP||TBD||xx<br />
|-<br />
| Hob improvements||Update Hob with performance improvements and improvements to package disabling||1||Review||davest/tracey/RP||TBD||xx<br />
|-<br />
| Support for non-developers||Create clear instructions for how a Windows user can take an example image from the YP web site and deploy it to a board. Assume no Linux knowledge. These instructions should be applicable in example images in BSPs ||1||Review||davest/tracey/RP||TBD||xx<br />
|-<br />
| Firewall / Proxy handling in git||Develop a git plugin which will fall back to tunneling through HTTP if the git:// interface will not work because it is blocked by a firewall and the correct proxy is not set up. ||2||Review||davest/tracey/RP||TBD||same for svn,hg,ftp,etc? -dvhart<br />
|-<br />
| Build Yocto behind firewall - implementation||||2||Dev||Dave||Darren/Joshua||Yocto 1.2, from 1.1, the above one seems to be part of this.<br />
|}<br />
<br />
== Core/Bitbake ==<br />
{| border="1"<br />
| align="center" style="background:#f0f0f0;"|'''Feature Name'''<br />
| align="center" style="background:#f0f0f0;"|'''Description'''<br />
| align="center" style="background:#f0f0f0;"|'''Priority'''<br />
| align="center" style="background:#f0f0f0;"|'''Status'''<br />
| align="center" style="background:#f0f0f0;"|'''Source'''<br />
| align="center" style="background:#f0f0f0;"|'''Owner'''<br />
| align="center" style="background:#f0f0f0;"|'''Due'''<br />
| align="center" style="background:#f0f0f0;"|'''Comments / Bugzilla Links'''<br />
|-<br />
| Recipe-specific sysroot||||3||Review||from 1.0||Saul (Dongxiao)||1.2||Yocto 1.2 (1 month task)<br />
|-<br />
| Handle old versions in WORKDIR||||3||Review||from 1.0||||1.2||Yocto 1.2<br />
|-<br />
| Executable images||Create images that are executable - for example a pre-installed Ubuntu image with YP installed||3||Review||LCS||||1.2||Yocto 1.2<br />
|-<br />
| Yocto OOPS-type messages||add the equivalent of kernel OOPS to Yocto||2.5||Review||LCS||||1.2||Yocto 1.2<br />
|-<br />
| Ability to archive work dir||Add the ability to archive the work directory to handle the GPL compliance issue.||3||Review||LCS||||1.2||Yocto 1.2, On Janitor\'s list<br />
|}<br />
<br />
== QA Items ==<br />
{| border="1"<br />
| align="center" style="background:#f0f0f0;"|'''Feature Name'''<br />
| align="center" style="background:#f0f0f0;"|'''Description'''<br />
| align="center" style="background:#f0f0f0;"|'''Priority'''<br />
| align="center" style="background:#f0f0f0;"|'''Status'''<br />
| align="center" style="background:#f0f0f0;"|'''Source'''<br />
| align="center" style="background:#f0f0f0;"|'''Owner'''<br />
| align="center" style="background:#f0f0f0;"|'''Due'''<br />
| align="center" style="background:#f0f0f0;"|'''Comments / Bugzilla Links'''<br />
|-<br />
| Patch Test System||Create a machine where developers can upload/test patches before submitting them to master to ensure builds won\'t break when patches are added. (developer autobuilders? Fuzz builds?)||2||Review||Team||Jiajun||1.2||This should work already for the pokycontrib tree<br />
|-<br />
| Open Source Test Cases||Perform technical, legal, and QA steps necessary to move test cases into open source.||3||Review||QA||||1.2||Yocto 1.2<br />
|-<br />
| Start a framework for automated BSP testing||Build-testing is only half the job of BSP testing, and new BSP development is and will be ramping up even more rapidly soon. We need to start building a framework to make as much of this as automated as possible. Phase I, what we can complete for 1.2, should be the ability to load an image from the autobuilder and make it ready for booting, or actually boot it, on a given target. It would be good to use systems running Yocto images as much as possible for this.||2||Review||Tom||||1.2||Maybe use CATS?<br />
|-<br />
| Test framework||this is a test framework that we can include in the distribution||3||Review||RP Notes||||1.2||Yocto 1.2 - Is it the TI’s test framework we discussed before? A: Not necessarily, we\'re still waiting for someone to step up and really take ownership of this area but it needs some resource commitment as its not a simple task. <br />
|-<br />
| Package History||Write out data about the size of packages, their contents, dependencies, build time and so on allowing changes to be detected. One idea is we could do this in the form of a git repository||1||Review||RP||||1.2||Yocto 1.2<br />
|-<br />
| Package History Analysis Tool||Take the above data, highlight significant deltas and allow the user to confirm or red flag changes. Why did the package double in size? Why did some dependencies go missing? ||1||Review||RP||||1.2||Yocto 1.2<br />
|-<br />
| Extend current QA Tests||Automate some of the existing QA tests such as LSB, posix and rt tests||1||Review||RP||||1.2||Yocto 1.2<br />
|}<br />
<br />
== Meta Data ==<br />
{| border="1"<br />
| align="center" style="background:#f0f0f0;"|'''Feature Name'''<br />
| align="center" style="background:#f0f0f0;"|'''Description'''<br />
| align="center" style="background:#f0f0f0;"|'''Priority'''<br />
| align="center" style="background:#f0f0f0;"|'''Status'''<br />
| align="center" style="background:#f0f0f0;"|'''Source'''<br />
| align="center" style="background:#f0f0f0;"|'''Owner'''<br />
| align="center" style="background:#f0f0f0;"|'''Due'''<br />
| align="center" style="background:#f0f0f0;"|'''Comments / Bugzilla Links'''<br />
|-<br />
| Replacement for video/audio players currently in Yocto||Codec…||3||Review||Meta-data||||1.2||Yocto 1.2<br />
|-<br />
| Investigate New UI||For demos, we would like need a reference UI that is not Sato. Investigate possibilities that the Yocto team won\'t need to maintain. OpenBox? Gnome-desktop? GP? LXDE? KDE Mobile?||3||Review||Meta-data||||1.2||Yocto 1.2<br />
|-<br />
| Qemugl upstreaming||Opengl ES Support||3||Review||Meta-data||||1.2||Yocto 1.2<br />
|-<br />
| selinux patch integration||add SE Linux patches in a similar way to PAM||3||Review||Meta-data||||1.2||Yocto 1.2<br />
|-<br />
| build statistics reporting||As someone interested in how long it takes to build different images on different hardware configurations and other assorted build metrics, I would like a web based service, that takes output generated by an extended buildstats.bbclass and stores it, to compare against different machines. The end result should be a way to visualize the collected data. See: https://wiki.yoctoproject.org/wiki/Yocto_Buildbot_Autobuilder_Discussions||2||M3, Sprint A||eflanagan/Jay7/ka6sox||Beth/Jay||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| Framework to support multiple library versions co-existing||similar to recipe specific sysroot; needs documentation||3||Review||Team||Saul (Dongxiao?)||1.2||Yocto 1.2 - we just need to document how to use multiple versions of a library using clutter as the example<br />
|-<br />
| Embedded java environment or even JDK support||||3||Review||Team||||1.2||Yocto 1.2<br />
|-<br />
| Target module build||Allow for building kernel modules on the target device||2||Review||RP Notes||Darren||1.2||Yocto 1.2, On Janitor\'s list<br />
|-<br />
| gtk+ sato filechooser patch||||3||Review||RP Notes||||1.2||Yocto 1.2<br />
|-<br />
| sato refresh||||3||Review||RP Notes||||1.2||Yocto 1.2<br />
|-<br />
| Sanity checks on per recipe basis||||2||Accept||RP Notes Bug#405||Saul (Scott G)||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| perf scripting\' integration||Make it easy and convenient for the user to write and execute \'perf scripts\' from the IDE. We should be able to leverage and build on the Systemtap integration for this.||2||Dev||Tom||Jessica/Tom||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| Add Directfb(license LGPL) function||Directfb is more appropriate embedded device than other graphic software||3||Moved from M1||Meta-data||WR Distro team||1.2||Yocto 1.2, from 1.1<br />
|}<br />
<br />
== Autobuilder ==<br />
{| border="1"<br />
| align="center" style="background:#f0f0f0;"|'''Feature Name'''<br />
| align="center" style="background:#f0f0f0;"|'''Description'''<br />
| align="center" style="background:#f0f0f0;"|'''Priority'''<br />
| align="center" style="background:#f0f0f0;"|'''Status'''<br />
| align="center" style="background:#f0f0f0;"|'''Source'''<br />
| align="center" style="background:#f0f0f0;"|'''Owner'''<br />
| align="center" style="background:#f0f0f0;"|'''Due'''<br />
| align="center" style="background:#f0f0f0;"|'''Comments / Bugzilla Links'''<br />
|-<br />
| autobuilder layer support||||2||||Beth||Beth||1.2||2 weeks<br />
|-<br />
| autobuilder split of nightly (really an M4 task) few days license.bbclass refactor||||2||||Beth||Beth||1.2||1 week<br />
|-<br />
| buildstats memory measurements||||2||||Beth||Beth||1.2||1 week and half<br />
|-<br />
| license manifest||||2||||Beth||Beth||1.2||1 week<br />
|-<br />
| autobuilder release checkbox (running a yocto release right from the autobuilder)||||2||||Beth||Beth||1.2||2 weeks<br />
|}<br />
<br />
== BSPs ==<br />
{| border="1"<br />
| align="center" style="background:#f0f0f0;"|'''Feature Name'''<br />
| align="center" style="background:#f0f0f0;"|'''Description'''<br />
| align="center" style="background:#f0f0f0;"|'''Priority'''<br />
| align="center" style="background:#f0f0f0;"|'''Status'''<br />
| align="center" style="background:#f0f0f0;"|'''Source'''<br />
| align="center" style="background:#f0f0f0;"|'''Owner'''<br />
| align="center" style="background:#f0f0f0;"|'''Due'''<br />
| align="center" style="background:#f0f0f0;"|'''Comments / Bugzilla Links'''<br />
|-<br />
| AMT driver integration||incorporate Linux AMT into the Yocto BSPs||||||||||1.2||Intel<br />
|-<br />
| Zaurusd++ (devmand?)||I keep seeing changes to toggle certain features for various boards (audio on the beagleboard, N450 and spring to mind), rather than writing lots of recipes for this perhaps we could resurrect zaurusd and evolve it to reflect the projects original goals as devmand; a daemon to handle hardware quirks across a range of boards and devices. ||||||||||1.2||Joshua<br />
|-<br />
| BSP update/intro||determine and integrate / create arch reference BSPs (e500, Cortex, ARM, MIPs)||2||Dev||Bruce/Richard/team||Bruce||1.2||Yocto 1.2, from 1.1<br />
|- <br />
|Drop Grub for Syslinux || Grub is considerably more complicated than we need for any of our current BSPs. Syslinux can be used in place of every known usage of Grub. For upcoming EFI BSPs, we can look to Efilinux. This will reduce our bootloader maintenance burden and simplify our images. || 2 || Review || Darren || Darren || 1.2 ||<br />
|-<br />
|Integrate alsa-state || Remove all the BSP specific $MACHINE-audio recipes in favor of the more generic alsa-state mechanism in use by OE already. || 1 || Review || Darren || || 1.2 || This possibly conflicts with the item to refresh zaurusd.<br />
|-<br />
|Upgrade to EFI ||Where possible, update our existing BSPs to boot using EFI. This will support development of efilinux as well as help us prepare for the newer boards which will be EFI only. || 2 || Review || Darren || Darren || 1.2 ||<br />
|-<br />
|BSP/kernel wrappers/wizards || Create some simple scripts or 'wizards' that make it easy for users to start writing a new BSP and/or easily make simple kernel modifications to a BSP. Ideally, users shouldn't need to know anything low-level about the kernel, git, or the mechanics of appending config items to recipes in order to get a BSP up and running or to make the simple modifications needed to tweak or maintain it. || 2 || Review || tomz || tomz || 1.2 ||<br />
|}<br />
<br />
== ADT == <br />
{| border="1"<br />
| align="center" style="background:#f0f0f0;"|'''Feature Name'''<br />
| align="center" style="background:#f0f0f0;"|'''Description'''<br />
| align="center" style="background:#f0f0f0;"|'''Priority'''<br />
| align="center" style="background:#f0f0f0;"|'''Status'''<br />
| align="center" style="background:#f0f0f0;"|'''Source'''<br />
| align="center" style="background:#f0f0f0;"|'''Owner'''<br />
| align="center" style="background:#f0f0f0;"|'''Due'''<br />
| align="center" style="background:#f0f0f0;"|'''Comments / Bugzilla Links'''<br />
|-<br />
| Enhance the deploy part in remote debug||ADT is currently using org.eclipse.cdt.remote.launch for remote debug. One limitation in this plug-in is that it can only deploy one single file to the target during the debug. Though it is ok for debugging static linked program, debugging dynamic linked program might require deploying multiple files(including executables and libraries) to the target.||2||Review||Lianhao||Jessica||1.2||<br />
|-<br />
| Secure login||||2||Review||ADT Team||Jessica||1.2||Yocto 1.2<br />
|-<br />
| Linux tools upstream integration||There're some activities within the Eclipse Linux Tools community for various tools remote invocation improvement, we need to sync up with the community for their latest deliveries and make some contribution if possible ||2||Review||ADT Team||Jessica||1.2||Yocto 1.2<br />
|-<br />
| Add recipe supporting autoconf-nativesdk and automake-nativesdk ||The new libtool m4 macros(supporting --with-libtool-sysroot) resides in the directory where host aclocal can not find it by default. This requires the user to manually add that directory using -I options. Adding automake(autoconf)-nativesdk into meta-toolchain would help this. ||2||Review||Lianhao||||1.2||Yocto 1.2<br />
|-<br />
| Prebuit SDK integration||speedup target image generation by reusing prebuilt tools from SDK native and target binaries. See: http://wiki.secretlab.ca/Yocto_prebuilt_SDK_integration||2||Reject||Adrian||Jessica||1.2||Yocto 1.2 - This functionality looks to have been provided by sstate packages?<br />
|-<br />
|Eclipse BSP/Kernel Plugin || Provide an Eclipse plugin to facilitate configuring new BSPs and streamlining the linuix-yocto development workflow. || 2 || Review || Darren || || 1.2 ||<br />
<br />
|}<br />
<br />
== Documentation ==<br />
{| border="1"<br />
| align="center" style="background:#f0f0f0;"|'''Feature Name'''<br />
| align="center" style="background:#f0f0f0;"|'''Description'''<br />
| align="center" style="background:#f0f0f0;"|'''Priority'''<br />
| align="center" style="background:#f0f0f0;"|'''Status'''<br />
| align="center" style="background:#f0f0f0;"|'''Source'''<br />
| align="center" style="background:#f0f0f0;"|'''Owner'''<br />
| align="center" style="background:#f0f0f0;"|'''Due'''<br />
| align="center" style="background:#f0f0f0;"|'''Comments / Bugzilla Links'''<br />
|-<br />
| Various Demo Videos||The idea here is to create screen-capture type tutorials similar to what exists for the ADT Eclipse Plug-in. However, we want to contract out some help for professional voice-over talent to be used with the images. These don\'t have to be limited to screen-capture material but could include well-done PPT decks - similar to how other business units in Intel create various training modules. For 1.1 it would be good to capture the script for the existing ADT Eclipse Plug-in module and have it voiced over. Also, for 1.1 it would be good to create a similar module for the Image Creator application.||2||Not Started||From ADT module and scratch||ScottR||1.2||Q3 at the earliest<br />
|}<br />
<br />
== Performance & usability ==<br />
{| border="1"<br />
| align="center" style="background:#f0f0f0;"|'''Feature Name'''<br />
| align="center" style="background:#f0f0f0;"|'''Description'''<br />
| align="center" style="background:#f0f0f0;"|'''Priority'''<br />
| align="center" style="background:#f0f0f0;"|'''Status'''<br />
| align="center" style="background:#f0f0f0;"|'''Source'''<br />
| align="center" style="background:#f0f0f0;"|'''Owner'''<br />
| align="center" style="background:#f0f0f0;"|'''Due'''<br />
| align="center" style="background:#f0f0f0;"|'''Comments / Bugzilla Links'''<br />
|-<br />
| POSIX support||address POSIX failures found in 1.1||2||Review||Team||||1.2||Yocto 1.2, On Janitor\'s list<br />
|}<br />
<br />
<br />
== Kernel ==<br />
{| border="1"<br />
| align="center" style="background:#f0f0f0;"|'''Feature Name'''<br />
| align="center" style="background:#f0f0f0;"|'''Description'''<br />
| align="center" style="background:#f0f0f0;"|'''Priority'''<br />
| align="center" style="background:#f0f0f0;"|'''Status'''<br />
| align="center" style="background:#f0f0f0;"|'''Source'''<br />
| align="center" style="background:#f0f0f0;"|'''Owner'''<br />
| align="center" style="background:#f0f0f0;"|'''Due'''<br />
| align="center" style="background:#f0f0f0;"|'''Comments / Bugzilla Links'''<br />
|-<br />
| Minimal Image unique||make minimal image smaller||3||Accept||Team||WR Distro Team||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| Tracing: tuna, oscilloscope recipes||This might be more useful with the increased importance of RT||3||Review||from 1.0||||1.2||Yocto 1.2<br />
|-<br />
| Kernel Tools||Implement plan for kernel tools||2||Dev (20%)||Bruce/Mark||Bruce||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| use cases||BSP config streamlining, building the kernel standalone, yoctoization, meta data sharing||1||Accept||Bruce||Bruce||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| kernel bloat - development||target = boot a minimal image in < 8M - development complete||1||Dev||Darren||Darren||1.2||Yocto 1.2, from 1.1, continuation needed?<br />
|-<br />
| Fast boot time||2 second boot time target||1||Dev||Team||Darren||1.2||Yocto 1.2, from 1.1, continuation needed?<br />
|-<br />
|Upstream config fragments || Work with John Stultz to upstream a Linux kernel config fragment manager and rework the yocto-kernel-tools to use it. This will simplify our tooling and increase our usage/test base. || 1 || Review || Darren || || 1.2 ||<br />
|-<br />
|Real-time process-executed timers || Timers currently run at the priority of the softirq that processes them and they are accounted to whichever task was preempted for them to run. This negatively impacts determinism and accounting accuracy. || 2 || Review || Darren || || 1.2 ||<br />
|-<br />
|Define Kernel policy || We need to clearly document kernel policy and make the config fragments reflect it. This will facilitate a more modular approach to building BSP kernel configs, as well as make it clear what can be expected to be supported when running a "linux-yocto kernel". || 1 || Review || Darren || || 1.2 ||<br />
|}<br />
<br />
== Project-wide Features ==<br />
{| border="1"<br />
| align="center" style="background:#f0f0f0;"|'''Feature Name'''<br />
| align="center" style="background:#f0f0f0;"|'''Description'''<br />
| align="center" style="background:#f0f0f0;"|'''Priority'''<br />
| align="center" style="background:#f0f0f0;"|'''Status'''<br />
| align="center" style="background:#f0f0f0;"|'''Source'''<br />
| align="center" style="background:#f0f0f0;"|'''Owner'''<br />
| align="center" style="background:#f0f0f0;"|'''Due'''<br />
| align="center" style="background:#f0f0f0;"|'''Comments / Bugzilla Links'''<br />
|-<br />
| LayerTooling – remote layer tool||Consider integrating Jeremy Puhlman\'s remote layers patch||2||Community||Paul||1.2||||<br />
|-<br />
| running post installs at rootfs gen time||||2||Review||RP Notes||Saul (Dexuan)||1.2||<br />
|-<br />
| Clean up warning messages||A build that runs correctly to completion still includes a ton of WARNING messages. We need a project to clean these up. Beth will work on License Warnings, team will look at other logfile warnings||2||Review||Dave & RP||Saul||1.2||<br />
|-<br />
| Multi-lib - 11||Directly support multlibs within the toolchain itself [post 1.1] ||2||||RP||Ke||1.2||<br />
|-<br />
| Multi-lib - 8||Add support to RPM packaging backend to turn modified package names into true rpm multilib packages||1||||RP||Mark||1.2||<br />
|-<br />
| Multi-lib - 7||Investigate better TARGET_VENDOR handling for config.sub. Currently we can only have ARCH-VENDOR-linux where VENDOR cannot contain \"-\" but it might be possible to relax that constraint [not high priority]. ||2||Review||RP||Ke||1.2||<br />
|-<br />
| Multi-lib - 6||Create some \"standard\" multilib configurations (x86 32+64 bit)||1||Review||RP||Ke||1.2||<br />
|-<br />
| Patchwork||is it worth the overhead, are there alternatives||3||Review||RP Notes||||1.2||Yocto 1.2<br />
|-<br />
| Bugzilla to Wiki||Create a script which automatically populates and updates the Wiki based on changes in bugzilla.||2.5||Review||Darren||||1.2||Yocto 1.2<br />
|-<br />
| Sync qemugl with MeeGo - Implementation||sync qemugl with MeeGo is complete||2||Dev (70%)||Meta-data||Saul (Edwin)||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| Tracing/profiling HOWTOs||Create a document or extend the current Yocto tracing wiki page to explain in detail how to use all the tracing tools in Yocto. It should detail not only how to use each tool individually, but also how to use them in conjunction with each other, highlighting situations in which each is most useful. There should also be some extensive worked examples of real-life use-cases and how they could be investigated using the Yocto tracing/profiling tools.||2||Accept||Tom||Tom||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| Error handling in bitbake (Implementation): Stage 2||Performance improvement (gather input from community on use cases)||1||Dev||RP Notes||Saul (Scott G)||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| btrfs||Kernel enabling||2||Dev||Meta-data||Saul (Nitin)||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| replace qemuppc||||||||||Bruce||1.2||Come from bug 414<br />
|-<br />
| MeeGo GPLv2 Sync||compare with Yocto, sync any patches||2||Accept||RP Notes||Saul (Ke)||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| Package Documentation Audit: All recipes build||31 recipes were identified as not building during the package documentation audit done in M1, Sprint B. Those all need to build and we need to re-run a new package documentation audit.||2||Accept||Team||Scott G||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| Tracing: Systemtap usability in Yocto||Right now, there are instructions on the wiki on how to configure and use Systemtap with Yocto. While straightforward, they are tedious and unlikely to be useful to most people pressed for time. We need to make it easier to use - in addition to documentation/HOWTO tasks listed elsewhere on this page, we need to make it usable \'out of the box\' (i.e. outside of ADT) e.g. all paths and configuration handled via script or something similar||2||Accept||Tom||Tom||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| Tracing: create separate recipe for perf||Perf is currently built as part of the kernel build. If we want to make use of everything perf has to offer we should get rid of the dependency. For example, the kernel build shouldn\'t depend on libnewt, and x32 shouldn\'t have to deal with embedded Python||2||Review||Tom||Tom||1.2||<br />
|-<br />
| Tracing: perf trace scripting support||Basically this means allowing perf to be built with the Perl and Python bindings, which turned out to be a headache last time.||2||Dev (50%)||from 1.0||Tom||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| Monitor disk availability||Monitor disk availability and warn the user if it is running low. May only focus on a few directories, for example: poky/build and poky/build/downloads, this would solve the multiple mount point problem||2||Review||RP and Robert||WR Distro Team (Robert)||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| Ability to build SRPM||||3||Accept||RP Notes||Jeff Polk/Mark||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| Classes to help install binary packages||It\'s been suggested that it would be a useful feature to be able to easily take an RPM or similar containing a software binary from a 3rd party software vendor and integrate it into an image created by the build system.||2||Review||||||1.2||<br />
|-<br />
| Host intrusion prevention||We have Swabber but it\'s not integrated into our process. I believe this is because there are several recipes which don\'t work when run under strace with parallelisation. We should determine a path for inclusion of swabber into our process and execute on it so that we can be aware of, and fix, any host intrusion issues.||2||Review||||||1.2||<br />
|-<br />
| Security layer||Many of our users are likely to want to use kernel level security mechanisms and so I\'d like to investigate supporting one of the in-kernel LSM (Linux Security Modules), possibly SMACK as used in MeeGo, and adding policy to the oe-core metadata. The LSM, policy and user-space tools could all be enabled via a distro feature. This work may well want to be in a separate layer?||2||Review||Joshua||||1.2||<br />
|-<br />
| Factory reset||Implement a factory reset image feature. We\'ll use one of the union mount technologies (aufs/overlayfs/union mounts) to create an overlay on the file system as the final piece of rootfs creation. The overlaid file-system will be the target of all writes made to the image after the image is generated. A user-space mechanism to disable the overlay, and therefore reset to the state of the image just after it was created, will also be provided. This feature could be further enhanced by integrating with the package manager, and other user-space switches, to create system restore points which can later be rolled back to.||2||Review||Joshua||||1.2||<br />
|-<br />
| Gstreamer||Refactor gstreamer recipes to better support COMMERCIAL_LICENSE and enabling/disabling of various codecs and features||2||Review||||||1.2||http://bugzilla.pokylinux.org/show_bug.cgi?id=923<br />
|-<br />
| Init||Interest in systemd as a replacement for Sys V init is growing but it may not be appropriate for deeply embedded systems. I\'d like to investigate a crop of service based and process monitoring init systems and compare them on a variety of criteria as determined by the community. Furthermore I would like to investigate supporting multiple init systems, the current SysV system, systemd and possibly others. As part of this work, and because increasingly many upstreams support systemd (no doubt thanks to its adoption in Fedora) I would like to investigate implementing some infrastructure which translates from systemd units to the appropriate init format for the supported init systems.||2||Review||||||1.2||<br />
|-<br />
| Enhance Automated QA Tests||Add tests for the RT pieces, consider run-time security checking tools used by Fedora and Gentoo||2||Review||||||1.2||<br />
|-<br />
| Collect data at build time to increase accuracy of estimation (hob)||Collect data at build time to allow hob to: predict the size of the generated image, more accurately reflect the built image contents, etc. This will likely involve generating data on the autobuilder which the UI can fetch and consume (with local caching for offline usage)||2||Review||||||1.2||http://bugzilla.pokylinux.org/show_bug.cgi?id=1316<br />
|-<br />
| Finish and enable PR server||We\'re still seeing people being forced to cleansstate too often, we need to finish up and enable the PR server so the checksummed sstate future can live||2||Review||||||1.2||http://thread.gmane.org/gmane.comp.handhelds.openembedded.core/1272/focus=1357 http://thread.gmane.org/gmane.comp.handhelds.openembedded.core/835/focus=852<br />
|-<br />
| Provide a click through license mechanism||Implement the mechanism described in Section 1.2. BSP \'Click-Through\' Licensing Procedure in the BSP Developer\'s Guide||2||Review||Tom||Tom||1.2||<br />
|-<br />
| Finish Oracle/Sun Hotspot JDK/JRE support||I created an initial hack of a recipe for this for the demo - finish it up (involves licensing issues (click-through license support would be a prerequisite) as well)||2||Review||Tom||Tom||1.2||50% done already<br />
|- <br />
| BSPs or layers for a specific category of devices || This will demonstrate the value of Yocto to developers and help them get up to speed quicker for this category of devices. ||2||Review||Dirk/Dave/Andy||TBD||1.2||<br />
|- <br />
| enhance the bitbake commander eclipse plugin || By having the Eclipse as a frontend UI to bitbake server, eclipse may talk to bitbake server, enable the user to glimpse on the variables' values when editing the recipes, try out building the recipe being edited, etc. ||2||Review||Dongxiao/Lianhao||TBD||TBD|| This requires new features both in eclipse plugin and bitbake server.<br />
|- <br />
| Parallel Locale Generation || Add makefile to allow the locale generation to happen in parallel ||2||Review||RP||||||<br />
|- <br />
| Make BasicHash the default || We'd like to start adding the sstate signature to the stampfiles using the BasicHash signature generator and stop bumping PR values. This will require some additions to the PR server work we previously started||2||Review||RP||||||<br />
|- <br />
| Address git fetcher concerns || The community has raised some git fetcher concerns we should address||2||Review||RP||||||<br />
|}</div>Davesthttps://wiki.yoctoproject.org/wiki/index.php?title=Yocto_1.2_Features&diff=3554Yocto 1.2 Features2011-09-30T15:47:25Z<p>Davest: Removed some duplicates</p>
<hr />
<div>== Potential Yocto Project 1.2 Features ==<br />
Yocto Project 1.2 - Target release = April 2012<br />
<br />
== Yocto Project 1.2 Themes ==<br />
The topics below are the themes that some members of the team have started brainstorming for Yocto Project v1.2. These will be improved with community input.<br />
<br />
=== Yocto Project 1.2 Objectives ===<br />
The objectives of the Yocto 1.2 release are to increase adoption of the Yocto Project.<br />
<br />
=== Yocto Project 1.2 Theme List ===<br />
The Yocto Project 1.2 Themes towards the Objectives listed above are:<br />
<br />
* Improved usability of the build system for new experienced users, new novice users and existing users.<br />
*<br />
<br />
== Process for Entering New Feature Requests ==<br />
<br />
* Create a new entry in the appropriate feature table below (Poky, SDK, Hardware)<br />
** Suggestion: start by copying an existing request as a template<br />
* Give the feature a short, descriptive name<br />
* Provide a one or two sentence brief description of the feature<br />
* Set the priority as appropriate (see the legend below)<br />
* Set the Status to "Review"<br />
* In the Source field, enter your name along with the origination of the request (e.g. OSV, OEM, Community) if applicable; provide as much detail here as you can<br />
* In the Comments / Bugzilla field, provide any additional information for the request, such as a link to a bugzilla entry<br />
* Preview your Entry to make sure it looks ok and then save it<br />
<br />
''Legend''<br />
<br />
'''Priority:''' 1 = Must Have, 2 = Nice to Have, 3 = Optional<br />
<br />
'''Status:''' Accept = Engineering agreement to include in release, Review = Under Review for Inclusion in this release, Reject = Will not be included in this release<br />
== Sample Table ==<br />
<br />
This is a sample table to show how to submit features.<br />
<br />
{| border="1"<br />
||'''Feature Name''' ||'''Description''' ||'''Priority''' ||'''Status''' ||'''Source''' ||'''Comments / Bugzilla Links'''<br />
|-<br />
||Placeholder feature name || Placeholder description of the feature || 1, 2, or 3 || Review|| name|| Comment<br />
|}<br />
<br />
== Usability ==<br />
{| border="1"<br />
| align="center" style="background:#f0f0f0;"|'''Feature Name'''<br />
| align="center" style="background:#f0f0f0;"|'''Description'''<br />
| align="center" style="background:#f0f0f0;"|'''Priority'''<br />
| align="center" style="background:#f0f0f0;"|'''Status'''<br />
| align="center" style="background:#f0f0f0;"|'''Source'''<br />
| align="center" style="background:#f0f0f0;"|'''Owner'''<br />
| align="center" style="background:#f0f0f0;"|'''Comments / Bugzilla Links'''<br />
|-<br />
| build appliance||Intended for developers to very easily "Check it out" and do a Yocto Project build with minimal pain. Should be a virtual image of a desktop OS which will boot into HOB and offer a terminal or an app to deploy resulting images to media or to run QEMU.||1||Review||davest/tracey/RP||TBD||See here for [[Build Appliance Design]]<br />
|-<br />
| Visual Hob ||Massively update interface for Hob, perhaps similar to SuSE Studio. This is for both local (non-network) builds as well as network.||1||Review||davest/tracey/RP||TBD||xx<br />
|-<br />
| Hob improvements||Update Hob with performance improvements and improvements to package disabling||1||Review||davest/tracey/RP||TBD||xx<br />
|-<br />
| Support for non-developers||Create clear instructions for how a Windows user can take an example image from the YP web site and deploy it to a board. Assume no Linux knowledge. These instructions should be applicable in example images in BSPs ||1||Review||davest/tracey/RP||TBD||xx<br />
|-<br />
| Firewall / Proxy handling in git||Develop a git plugin which will fall back to tunneling through HTTP if the git:// interface will not work because it is blocked by a firewall and the correct proxy is not set up. ||2||Review||davest/tracey/RP||TBD||same for svn,hg,ftp,etc? -dvhart<br />
|-<br />
| Build Yocto behind firewall - implementation||||2||Dev||Dave||Darren/Joshua||Yocto 1.2, from 1.1, the above one seems to be part of this.<br />
|}<br />
<br />
== Core/Bitbake ==<br />
{| border="1"<br />
| align="center" style="background:#f0f0f0;"|'''Feature Name'''<br />
| align="center" style="background:#f0f0f0;"|'''Description'''<br />
| align="center" style="background:#f0f0f0;"|'''Priority'''<br />
| align="center" style="background:#f0f0f0;"|'''Status'''<br />
| align="center" style="background:#f0f0f0;"|'''Source'''<br />
| align="center" style="background:#f0f0f0;"|'''Owner'''<br />
| align="center" style="background:#f0f0f0;"|'''Due'''<br />
| align="center" style="background:#f0f0f0;"|'''Comments / Bugzilla Links'''<br />
|-<br />
| Recipe-specific sysroot||||3||Review||from 1.0||Saul (Dongxiao)||1.2||Yocto 1.2 (1 month task)<br />
|-<br />
| Handle old versions in WORKDIR||||3||Review||from 1.0||||1.2||Yocto 1.2<br />
|-<br />
| Executable images||Create images that are executable - for example a pre-installed Ubuntu image with YP installed||3||Review||LCS||||1.2||Yocto 1.2<br />
|-<br />
| Yocto OOPS-type messages||add the equivalent of kernel OOPS to Yocto||2.5||Review||LCS||||1.2||Yocto 1.2<br />
|-<br />
| Ability to archive work dir||Add the ability to archive the work directory to handle the GPL compliance issue.||3||Review||LCS||||1.2||Yocto 1.2, On Janitor\'s list<br />
|}<br />
<br />
== QA Items ==<br />
{| border="1"<br />
| align="center" style="background:#f0f0f0;"|'''Feature Name'''<br />
| align="center" style="background:#f0f0f0;"|'''Description'''<br />
| align="center" style="background:#f0f0f0;"|'''Priority'''<br />
| align="center" style="background:#f0f0f0;"|'''Status'''<br />
| align="center" style="background:#f0f0f0;"|'''Source'''<br />
| align="center" style="background:#f0f0f0;"|'''Owner'''<br />
| align="center" style="background:#f0f0f0;"|'''Due'''<br />
| align="center" style="background:#f0f0f0;"|'''Comments / Bugzilla Links'''<br />
|-<br />
| Patch Test System||Create a machine where developers can upload/test patches before submitting them to master to ensure builds won\'t break when patches are added. (developer autobuilders? Fuzz builds?)||2||Review||Team||Jiajun||1.2||<br />
|-<br />
| Open Source Test Cases||Perform technical, legal, and QA steps necessary to move test cases into open source.||3||Review||QA||||1.2||Yocto 1.2<br />
|-<br />
| Start a framework for automated BSP testing||Build-testing is only half the job of BSP testing, and new BSP development is and will be ramping up even more rapidly soon. We need to start building a framework to make as much of this as automated as possible. Phase I, what we can complete for 1.2, should be the ability to load an image from the autobuilder and make it ready for booting, or actually boot it, on a given target. It would be good to use systems running Yocto images as much as possible for this.||2||Review||Tom||||1.2||<br />
|-<br />
| Test framework||this is a test framework that we can include in the distribution||3||Review||RP Notes||||1.2||Yocto 1.2 - Is it the TI’s test framework we discussed before? A: Not necessarily, we\'re still waiting for someone to step up and really take ownership of this area but it needs some resource commitment as its not a simple task. <br />
|-<br />
| Package History||Write out data about the size of packages, their contents, dependencies, build time and so on allowing changes to be detected. One idea is we could do this in the form of a git repository||1||Review||RP||||1.2||Yocto 1.2<br />
|-<br />
| Package History Analysis Tool||Take the above data, highlight significant deltas and allow the user to confirm or red flag changes. Why did the package double in size? Why did some dependencies go missing? ||1||Review||RP||||1.2||Yocto 1.2<br />
|-<br />
| Extend current QA Tests||Automate some of the existing QA tests such as LSB, posix and rt tests||1||Review||RP||||1.2||Yocto 1.2<br />
|}<br />
<br />
== Meta Data ==<br />
{| border="1"<br />
| align="center" style="background:#f0f0f0;"|'''Feature Name'''<br />
| align="center" style="background:#f0f0f0;"|'''Description'''<br />
| align="center" style="background:#f0f0f0;"|'''Priority'''<br />
| align="center" style="background:#f0f0f0;"|'''Status'''<br />
| align="center" style="background:#f0f0f0;"|'''Source'''<br />
| align="center" style="background:#f0f0f0;"|'''Owner'''<br />
| align="center" style="background:#f0f0f0;"|'''Due'''<br />
| align="center" style="background:#f0f0f0;"|'''Comments / Bugzilla Links'''<br />
|-<br />
| Replacement for video/audio players currently in Yocto||Codec…||3||Review||Meta-data||||1.2||Yocto 1.2<br />
|-<br />
| Investigate New UI||For demos, we would like need a reference UI that is not Sato. Investigate possibilities that the Yocto team won\'t need to maintain. OpenBox? Gnome-desktop? GP? LXDE? KDE Mobile?||3||Review||Meta-data||||1.2||Yocto 1.2<br />
|-<br />
| Qemugl upstreaming||Opengl ES Support||3||Review||Meta-data||||1.2||Yocto 1.2<br />
|-<br />
| selinux patch integration||add SE Linux patches in a similar way to PAM||3||Review||Meta-data||||1.2||Yocto 1.2<br />
|-<br />
| build statistics reporting||As someone interested in how long it takes to build different images on different hardware configurations and other assorted build metrics, I would like a web based service, that takes output generated by an extended buildstats.bbclass and stores it, to compare against different machines. The end result should be a way to visualize the collected data. See: https://wiki.yoctoproject.org/wiki/Yocto_Buildbot_Autobuilder_Discussions||2||M3, Sprint A||eflanagan/Jay7/ka6sox||Beth/Jay||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| Framework to support multiple library versions co-existing||similar to recipe specific sysroot; needs documentation||3||Review||Team||Saul (Dongxiao?)||1.2||Yocto 1.2 - we just need to document how to use multiple versions of a library using clutter as the example<br />
|-<br />
| Embedded java environment or even JDK support||||3||Review||Team||||1.2||Yocto 1.2<br />
|-<br />
| Target module build||Allow for building kernel modules on the target device||2||Review||RP Notes||Darren||1.2||Yocto 1.2, On Janitor\'s list<br />
|-<br />
| gtk+ sato filechooser patch||||3||Review||RP Notes||||1.2||Yocto 1.2<br />
|-<br />
| sato refresh||||3||Review||RP Notes||||1.2||Yocto 1.2<br />
|-<br />
| Sanity checks on per recipe basis||||2||Accept||RP Notes Bug#405||Saul (Scott G)||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| perf scripting\' integration||Make it easy and convenient for the user to write and execute \'perf scripts\' from the IDE. We should be able to leverage and build on the Systemtap integration for this.||2||Dev||Tom||Jessica/Tom||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| Add Directfb(license LGPL) function||Directfb is more appropriate embedded device than other graphic software||3||Moved from M1||Meta-data||WR Distro team||1.2||Yocto 1.2, from 1.1<br />
|}<br />
<br />
== Autobuilder ==<br />
{| border="1"<br />
| align="center" style="background:#f0f0f0;"|'''Feature Name'''<br />
| align="center" style="background:#f0f0f0;"|'''Description'''<br />
| align="center" style="background:#f0f0f0;"|'''Priority'''<br />
| align="center" style="background:#f0f0f0;"|'''Status'''<br />
| align="center" style="background:#f0f0f0;"|'''Source'''<br />
| align="center" style="background:#f0f0f0;"|'''Owner'''<br />
| align="center" style="background:#f0f0f0;"|'''Due'''<br />
| align="center" style="background:#f0f0f0;"|'''Comments / Bugzilla Links'''<br />
|-<br />
| autobuilder layer support||||2||||Beth||Beth||1.2||2 weeks<br />
|-<br />
| autobuilder split of nightly (really an M4 task) few days license.bbclass refactor||||2||||Beth||Beth||1.2||1 week<br />
|-<br />
| buildstats memory measurements||||2||||Beth||Beth||1.2||1 week and half<br />
|-<br />
| license manifest||||2||||Beth||Beth||1.2||1 week<br />
|-<br />
| autobuilder release checkbox (running a yocto release right from the autobuilder)||||2||||Beth||Beth||1.2||2 weeks<br />
|}<br />
<br />
== BSPs ==<br />
{| border="1"<br />
| align="center" style="background:#f0f0f0;"|'''Feature Name'''<br />
| align="center" style="background:#f0f0f0;"|'''Description'''<br />
| align="center" style="background:#f0f0f0;"|'''Priority'''<br />
| align="center" style="background:#f0f0f0;"|'''Status'''<br />
| align="center" style="background:#f0f0f0;"|'''Source'''<br />
| align="center" style="background:#f0f0f0;"|'''Owner'''<br />
| align="center" style="background:#f0f0f0;"|'''Due'''<br />
| align="center" style="background:#f0f0f0;"|'''Comments / Bugzilla Links'''<br />
|-<br />
| AMT driver integration||incorporate Linux AMT into the Yocto BSPs||||||||||1.2||Intel<br />
|-<br />
| Zaurusd++ (devmand?)||I keep seeing changes to toggle certain features for various boards (audio on the beagleboard, N450 and spring to mind), rather than writing lots of recipes for this perhaps we could resurrect zaurusd and evolve it to reflect the projects original goals as devmand; a daemon to handle hardware quirks across a range of boards and devices. ||||||||||1.2||Joshua<br />
|-<br />
| BSP update/intro||determine and integrate / create arch reference BSPs (e500, Cortex, ARM, MIPs)||2||Dev||Bruce/Richard/team||Bruce||1.2||Yocto 1.2, from 1.1<br />
|- <br />
|Drop Grub for Syslinux || Grub is considerably more complicated than we need for any of our current BSPs. Syslinux can be used in place of every known usage of Grub. For upcoming EFI BSPs, we can look to Efilinux. This will reduce our bootloader maintenance burden and simplify our images. || 2 || Review || Darren || Darren || 1.2 ||<br />
|-<br />
|Integrate alsa-state || Remove all the BSP specific $MACHINE-audio recipes in favor of the more generic alsa-state mechanism in use by OE already. || 1 || Review || Darren || || 1.2 || This possibly conflicts with the item to refresh zaurusd.<br />
|-<br />
|Upgrade to EFI ||Where possible, update our existing BSPs to boot using EFI. This will support development of efilinux as well as help us prepare for the newer boards which will be EFI only. || 2 || Review || Darren || Darren || 1.2 ||<br />
|-<br />
|BSP/kernel wrappers/wizards || Create some simple scripts or 'wizards' that make it easy for users to start writing a new BSP and/or easily make simple kernel modifications to a BSP. Ideally, users shouldn't need to know anything low-level about the kernel, git, or the mechanics of appending config items to recipes in order to get a BSP up and running or to make the simple modifications needed to tweak or maintain it. || 2 || Review || tomz || tomz || 1.2 ||<br />
|}<br />
<br />
== ADT == <br />
{| border="1"<br />
| align="center" style="background:#f0f0f0;"|'''Feature Name'''<br />
| align="center" style="background:#f0f0f0;"|'''Description'''<br />
| align="center" style="background:#f0f0f0;"|'''Priority'''<br />
| align="center" style="background:#f0f0f0;"|'''Status'''<br />
| align="center" style="background:#f0f0f0;"|'''Source'''<br />
| align="center" style="background:#f0f0f0;"|'''Owner'''<br />
| align="center" style="background:#f0f0f0;"|'''Due'''<br />
| align="center" style="background:#f0f0f0;"|'''Comments / Bugzilla Links'''<br />
|-<br />
| Enhance the deploy part in remote debug||ADT is currently using org.eclipse.cdt.remote.launch for remote debug. One limitation in this plug-in is that it can only deploy one single file to the target during the debug. Though it is ok for debugging static linked program, debugging dynamic linked program might require deploying multiple files(including executables and libraries) to the target.||2||Review||Lianhao||Jessica||1.2||<br />
|-<br />
| Secure login||||2||Review||ADT Team||Jessica||1.2||Yocto 1.2<br />
|-<br />
| Linux tools upstream integration||There're some activities within the Eclipse Linux Tools community for various tools remote invocation improvement, we need to sync up with the community for their latest deliveries and make some contribution if possible ||2||Review||ADT Team||Jessica||1.2||Yocto 1.2<br />
|-<br />
| Add recipe supporting autoconf-nativesdk and automake-nativesdk ||The new libtool m4 macros(supporting --with-libtool-sysroot) resides in the directory where host aclocal can not find it by default. This requires the user to manually add that directory using -I options. Adding automake(autoconf)-nativesdk into meta-toolchain would help this. ||2||Review||Lianhao||||1.2||Yocto 1.2<br />
|-<br />
| Prebuit SDK integration||speedup target image generation by reusing prebuilt tools from SDK native and target binaries. See: http://wiki.secretlab.ca/Yocto_prebuilt_SDK_integration||2||Reject||Adrian||Jessica||1.2||Yocto 1.2 - This functionality looks to have been provided by sstate packages?<br />
|-<br />
|Eclipse BSP/Kernel Plugin || Provide an Eclipse plugin to facilitate configuring new BSPs and streamlining the linuix-yocto development workflow. || 2 || Review || Darren || || 1.2 ||<br />
<br />
|}<br />
<br />
== Documentation ==<br />
{| border="1"<br />
| align="center" style="background:#f0f0f0;"|'''Feature Name'''<br />
| align="center" style="background:#f0f0f0;"|'''Description'''<br />
| align="center" style="background:#f0f0f0;"|'''Priority'''<br />
| align="center" style="background:#f0f0f0;"|'''Status'''<br />
| align="center" style="background:#f0f0f0;"|'''Source'''<br />
| align="center" style="background:#f0f0f0;"|'''Owner'''<br />
| align="center" style="background:#f0f0f0;"|'''Due'''<br />
| align="center" style="background:#f0f0f0;"|'''Comments / Bugzilla Links'''<br />
|-<br />
| Various Demo Videos||The idea here is to create screen-capture type tutorials similar to what exists for the ADT Eclipse Plug-in. However, we want to contract out some help for professional voice-over talent to be used with the images. These don\'t have to be limited to screen-capture material but could include well-done PPT decks - similar to how other business units in Intel create various training modules. For 1.1 it would be good to capture the script for the existing ADT Eclipse Plug-in module and have it voiced over. Also, for 1.1 it would be good to create a similar module for the Image Creator application.||2||Not Started||From ADT module and scratch||ScottR||1.2||Q3 at the earliest<br />
|}<br />
<br />
== Performance & usability ==<br />
{| border="1"<br />
| align="center" style="background:#f0f0f0;"|'''Feature Name'''<br />
| align="center" style="background:#f0f0f0;"|'''Description'''<br />
| align="center" style="background:#f0f0f0;"|'''Priority'''<br />
| align="center" style="background:#f0f0f0;"|'''Status'''<br />
| align="center" style="background:#f0f0f0;"|'''Source'''<br />
| align="center" style="background:#f0f0f0;"|'''Owner'''<br />
| align="center" style="background:#f0f0f0;"|'''Due'''<br />
| align="center" style="background:#f0f0f0;"|'''Comments / Bugzilla Links'''<br />
|-<br />
| POSIX support||address POSIX failures found in 1.1||2||Review||Team||||1.2||Yocto 1.2, On Janitor\'s list<br />
|}<br />
<br />
<br />
== Kernel ==<br />
{| border="1"<br />
| align="center" style="background:#f0f0f0;"|'''Feature Name'''<br />
| align="center" style="background:#f0f0f0;"|'''Description'''<br />
| align="center" style="background:#f0f0f0;"|'''Priority'''<br />
| align="center" style="background:#f0f0f0;"|'''Status'''<br />
| align="center" style="background:#f0f0f0;"|'''Source'''<br />
| align="center" style="background:#f0f0f0;"|'''Owner'''<br />
| align="center" style="background:#f0f0f0;"|'''Due'''<br />
| align="center" style="background:#f0f0f0;"|'''Comments / Bugzilla Links'''<br />
|-<br />
| Minimal Image unique||make minimal image smaller||3||Accept||Team||WR Distro Team||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| Tracing: tuna, oscilloscope recipes||This might be more useful with the increased importance of RT||3||Review||from 1.0||||1.2||Yocto 1.2<br />
|-<br />
| Kernel Tools||Implement plan for kernel tools||2||Dev (20%)||Bruce/Mark||Bruce||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| use cases||BSP config streamlining, building the kernel standalone, yoctoization, meta data sharing||1||Accept||Bruce||Bruce||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| kernel bloat - development||target = boot a minimal image in < 8M - development complete||1||Dev||Darren||Darren||1.2||Yocto 1.2, from 1.1, continuation needed?<br />
|-<br />
| Fast boot time||2 second boot time target||1||Dev||Team||Darren||1.2||Yocto 1.2, from 1.1, continuation needed?<br />
|-<br />
|Upstream config fragments || Work with John Stultz to upstream a Linux kernel config fragment manager and rework the yocto-kernel-tools to use it. This will simplify our tooling and increase our usage/test base. || 1 || Review || Darren || || 1.2 ||<br />
|-<br />
|Real-time process-executed timers || Timers currently run at the priority of the softirq that processes them and they are accounted to whichever task was preempted for them to run. This negatively impacts determinism and accounting accuracy. || 2 || Review || Darren || || 1.2 ||<br />
|-<br />
|Define Kernel policy || We need to clearly document kernel policy and make the config fragments reflect it. This will facilitate a more modular approach to building BSP kernel configs, as well as make it clear what can be expected to be supported when running a "linux-yocto kernel". || 1 || Review || Darren || || 1.2 ||<br />
|}<br />
<br />
== Project-wide Features ==<br />
{| border="1"<br />
| align="center" style="background:#f0f0f0;"|'''Feature Name'''<br />
| align="center" style="background:#f0f0f0;"|'''Description'''<br />
| align="center" style="background:#f0f0f0;"|'''Priority'''<br />
| align="center" style="background:#f0f0f0;"|'''Status'''<br />
| align="center" style="background:#f0f0f0;"|'''Source'''<br />
| align="center" style="background:#f0f0f0;"|'''Owner'''<br />
| align="center" style="background:#f0f0f0;"|'''Due'''<br />
| align="center" style="background:#f0f0f0;"|'''Comments / Bugzilla Links'''<br />
|-<br />
| LayerTooling – remote layer tool||Consider integrating Jeremy Puhlman\'s remote layers patch||2||Community||Paul||1.2||||<br />
|-<br />
| running post installs at rootfs gen time||||2||Review||RP Notes||Saul (Dexuan)||1.2||<br />
|-<br />
| Clean up warning messages||A build that runs correctly to completion still includes a ton of WARNING messages. We need a project to clean these up. Beth will work on License Warnings, team will look at other logfile warnings||2||Review||Dave & RP||Saul||1.2||<br />
|-<br />
| Multi-lib - 11||Directly support multlibs within the toolchain itself [post 1.1] ||2||||RP||Ke||1.2||<br />
|-<br />
| Multi-lib - 8||Add support to RPM packaging backend to turn modified package names into true rpm multilib packages||1||||RP||Mark||1.2||<br />
|-<br />
| Multi-lib - 7||Investigate better TARGET_VENDOR handling for config.sub. Currently we can only have ARCH-VENDOR-linux where VENDOR cannot contain \"-\" but it might be possible to relax that constraint [not high priority]. ||2||Review||RP||Ke||1.2||<br />
|-<br />
| Multi-lib - 6||Create some \"standard\" multilib configurations (x86 32+64 bit)||1||Review||RP||Ke||1.2||<br />
|-<br />
| Patchwork||is it worth the overhead, are there alternatives||3||Review||RP Notes||||1.2||Yocto 1.2<br />
|-<br />
| Bugzilla to Wiki||Create a script which automatically populates and updates the Wiki based on changes in bugzilla.||2.5||Review||Darren||||1.2||Yocto 1.2<br />
|-<br />
| Sync qemugl with MeeGo - Implementation||sync qemugl with MeeGo is complete||2||Dev (70%)||Meta-data||Saul (Edwin)||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| Tracing/profiling HOWTOs||Create a document or extend the current Yocto tracing wiki page to explain in detail how to use all the tracing tools in Yocto. It should detail not only how to use each tool individually, but also how to use them in conjunction with each other, highlighting situations in which each is most useful. There should also be some extensive worked examples of real-life use-cases and how they could be investigated using the Yocto tracing/profiling tools.||2||Accept||Tom||Tom||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| Error handling in bitbake (Implementation): Stage 2||Performance improvement (gather input from community on use cases)||1||Dev||RP Notes||Saul (Scott G)||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| btrfs||Kernel enabling||2||Dev||Meta-data||Saul (Nitin)||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| replace qemuppc||||||||||Bruce||1.2||Come from bug 414<br />
|-<br />
| MeeGo GPLv2 Sync||compare with Yocto, sync any patches||2||Accept||RP Notes||Saul (Ke)||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| Package Documentation Audit: All recipes build||31 recipes were identified as not building during the package documentation audit done in M1, Sprint B. Those all need to build and we need to re-run a new package documentation audit.||2||Accept||Team||Scott G||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| Tracing: Systemtap usability in Yocto||Right now, there are instructions on the wiki on how to configure and use Systemtap with Yocto. While straightforward, they are tedious and unlikely to be useful to most people pressed for time. We need to make it easier to use - in addition to documentation/HOWTO tasks listed elsewhere on this page, we need to make it usable \'out of the box\' (i.e. outside of ADT) e.g. all paths and configuration handled via script or something similar||2||Accept||Tom||Tom||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| Tracing: create separate recipe for perf||Perf is currently built as part of the kernel build. If we want to make use of everything perf has to offer we should get rid of the dependency. For example, the kernel build shouldn\'t depend on libnewt, and x32 shouldn\'t have to deal with embedded Python||2||Review||Tom||Tom||1.2||<br />
|-<br />
| Tracing: perf trace scripting support||Basically this means allowing perf to be built with the Perl and Python bindings, which turned out to be a headache last time.||2||Dev (50%)||from 1.0||Tom||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| Monitor disk availability||Monitor disk availability and warn the user if it is running low. May only focus on a few directories, for example: poky/build and poky/build/downloads, this would solve the multiple mount point problem||2||Review||RP and Robert||WR Distro Team (Robert)||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| Ability to build SRPM||||3||Accept||RP Notes||Jeff Polk/Mark||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| Classes to help install binary packages||It\'s been suggested that it would be a useful feature to be able to easily take an RPM or similar containing a software binary from a 3rd party software vendor and integrate it into an image created by the build system.||2||Review||||||1.2||<br />
|-<br />
| Host intrusion prevention||We have Swabber but it\'s not integrated into our process. I believe this is because there are several recipes which don\'t work when run under strace with parallelisation. We should determine a path for inclusion of swabber into our process and execute on it so that we can be aware of, and fix, any host intrusion issues.||2||Review||||||1.2||<br />
|-<br />
| Security layer||Many of our users are likely to want to use kernel level security mechanisms and so I\'d like to investigate supporting one of the in-kernel LSM (Linux Security Modules), possibly SMACK as used in MeeGo, and adding policy to the oe-core metadata. The LSM, policy and user-space tools could all be enabled via a distro feature. This work may well want to be in a separate layer?||2||Review||Joshua||||1.2||<br />
|-<br />
| Factory reset||Implement a factory reset image feature. We\'ll use one of the union mount technologies (aufs/overlayfs/union mounts) to create an overlay on the file system as the final piece of rootfs creation. The overlaid file-system will be the target of all writes made to the image after the image is generated. A user-space mechanism to disable the overlay, and therefore reset to the state of the image just after it was created, will also be provided. This feature could be further enhanced by integrating with the package manager, and other user-space switches, to create system restore points which can later be rolled back to.||2||Review||Joshua||||1.2||<br />
|-<br />
| Gstreamer||Refactor gstreamer recipes to better support COMMERCIAL_LICENSE and enabling/disabling of various codecs and features||2||Review||||||1.2||http://bugzilla.pokylinux.org/show_bug.cgi?id=923<br />
|-<br />
| Init||Interest in systemd as a replacement for Sys V init is growing but it may not be appropriate for deeply embedded systems. I\'d like to investigate a crop of service based and process monitoring init systems and compare them on a variety of criteria as determined by the community. Furthermore I would like to investigate supporting multiple init systems, the current SysV system, systemd and possibly others. As part of this work, and because increasingly many upstreams support systemd (no doubt thanks to its adoption in Fedora) I would like to investigate implementing some infrastructure which translates from systemd units to the appropriate init format for the supported init systems.||2||Review||||||1.2||<br />
|-<br />
| Enhance Automated QA Tests||Add tests for the RT pieces, consider run-time security checking tools used by Fedora and Gentoo||2||Review||||||1.2||<br />
|-<br />
| Collect data at build time to increase accuracy of estimation (hob)||Collect data at build time to allow hob to: predict the size of the generated image, more accurately reflect the built image contents, etc. This will likely involve generating data on the autobuilder which the UI can fetch and consume (with local caching for offline usage)||2||Review||||||1.2||http://bugzilla.pokylinux.org/show_bug.cgi?id=1316<br />
|-<br />
| Finish and enable PR server||We\'re still seeing people being forced to cleansstate too often, we need to finish up and enable the PR server so the checksummed sstate future can live||2||Review||||||1.2||http://thread.gmane.org/gmane.comp.handhelds.openembedded.core/1272/focus=1357 http://thread.gmane.org/gmane.comp.handhelds.openembedded.core/835/focus=852<br />
|-<br />
| Provide a click through license mechanism||Implement the mechanism described in Section 1.2. BSP \'Click-Through\' Licensing Procedure in the BSP Developer\'s Guide||2||Review||Tom||Tom||1.2||<br />
|-<br />
| Finish Oracle/Sun Hotspot JDK/JRE support||I created an initial hack of a recipe for this for the demo - finish it up (involves licensing issues (click-through license support would be a prerequisite) as well)||2||Review||Tom||Tom||1.2||50% done already<br />
|- <br />
| BSPs or layers for a specific category of devices || This will demonstrate the value of Yocto to developers and help them get up to speed quicker for this category of devices. ||2||Review||Dirk/Dave/Andy||TBD||1.2||<br />
|- <br />
| enhance the bitbake commander eclipse plugin || By having the Eclipse as a frontend UI to bitbake server, eclipse may talk to bitbake server, enable the user to glimpse on the variables' values when editing the recipes, try out building the recipe being edited, etc. ||2||Review||Dongxiao/Lianhao||TBD||TBD|| This requires new features both in eclipse plugin and bitbake server.<br />
|- <br />
| Parallel Locale Generation || Add makefile to allow the locale generation to happen in parallel ||2||Review||RP||||||<br />
|- <br />
| Make BasicHash the default || We'd like to start adding the sstate signature to the stampfiles using the BasicHash signature generator and stop bumping PR values. This will require some additions to the PR server work we previously started||2||Review||RP||||||<br />
|- <br />
| Address git fetcher concerns || The community has raised some git fetcher concerns we should address||2||Review||RP||||||<br />
|}</div>Davesthttps://wiki.yoctoproject.org/wiki/index.php?title=Yocto_1.2_Features&diff=3553Yocto 1.2 Features2011-09-30T15:39:44Z<p>Davest: /* Usability */</p>
<hr />
<div>== Potential Yocto Project 1.2 Features ==<br />
Yocto Project 1.2 - Target release = April 2012<br />
<br />
== Yocto Project 1.2 Themes ==<br />
The topics below are the themes that some members of the team have started brainstorming for Yocto Project v1.2. These will be improved with community input.<br />
<br />
=== Yocto Project 1.2 Objectives ===<br />
The objectives of the Yocto 1.2 release are to increase adoption of the Yocto Project.<br />
<br />
=== Yocto Project 1.2 Theme List ===<br />
The Yocto Project 1.2 Themes towards the Objectives listed above are:<br />
<br />
* Improved usability of the build system for new experienced users, new novice users and existing users.<br />
*<br />
<br />
== Process for Entering New Feature Requests ==<br />
<br />
* Create a new entry in the appropriate feature table below (Poky, SDK, Hardware)<br />
** Suggestion: start by copying an existing request as a template<br />
* Give the feature a short, descriptive name<br />
* Provide a one or two sentence brief description of the feature<br />
* Set the priority as appropriate (see the legend below)<br />
* Set the Status to "Review"<br />
* In the Source field, enter your name along with the origination of the request (e.g. OSV, OEM, Community) if applicable; provide as much detail here as you can<br />
* In the Comments / Bugzilla field, provide any additional information for the request, such as a link to a bugzilla entry<br />
* Preview your Entry to make sure it looks ok and then save it<br />
<br />
''Legend''<br />
<br />
'''Priority:''' 1 = Must Have, 2 = Nice to Have, 3 = Optional<br />
<br />
'''Status:''' Accept = Engineering agreement to include in release, Review = Under Review for Inclusion in this release, Reject = Will not be included in this release<br />
== Sample Table ==<br />
<br />
This is a sample table to show how to submit features.<br />
<br />
{| border="1"<br />
||'''Feature Name''' ||'''Description''' ||'''Priority''' ||'''Status''' ||'''Source''' ||'''Comments / Bugzilla Links'''<br />
|-<br />
||Placeholder feature name || Placeholder description of the feature || 1, 2, or 3 || Review|| name|| Comment<br />
|}<br />
<br />
== Usability ==<br />
{| border="1"<br />
| align="center" style="background:#f0f0f0;"|'''Feature Name'''<br />
| align="center" style="background:#f0f0f0;"|'''Description'''<br />
| align="center" style="background:#f0f0f0;"|'''Priority'''<br />
| align="center" style="background:#f0f0f0;"|'''Status'''<br />
| align="center" style="background:#f0f0f0;"|'''Source'''<br />
| align="center" style="background:#f0f0f0;"|'''Owner'''<br />
| align="center" style="background:#f0f0f0;"|'''Comments / Bugzilla Links'''<br />
|-<br />
| build appliance||Intended for developers to very easily "Check it out" and do a Yocto Project build with minimal pain. Should be a virtual image of a desktop OS which will boot into HOB and offer a terminal or an app to deploy resulting images to media or to run QEMU.||1||Review||davest/tracey/RP||TBD||See here for [[Build Appliance Design]]<br />
|-<br />
| Visual Hob ||Massively update interface for Hob, perhaps similar to SuSE Studio. This is for both local (non-network) builds as well as network.||1||Review||davest/tracey/RP||TBD||xx<br />
|-<br />
| Hob improvements||Update Hob with performance improvements and improvements to package disabling||1||Review||davest/tracey/RP||TBD||xx<br />
|-<br />
| Support for non-developers||Create clear instructions for how a Windows user can take an example image from the YP web site and deploy it to a board. Assume no Linux knowledge. These instructions should be applicable in example images in BSPs ||1||Review||davest/tracey/RP||TBD||xx<br />
|-<br />
| Firewall / Proxy handling in git||Develop a git plugin which will fall back to tunneling through HTTP if the git:// interface will not work because it is blocked by a firewall and the correct proxy is not set up. ||2||Review||davest/tracey/RP||TBD||same for svn,hg,ftp,etc? -dvhart<br />
|-<br />
| Build Yocto behind firewall - implementation||||2||Dev||Dave||Darren/Joshua||Yocto 1.2, from 1.1, the above one seems to be part of this.<br />
|}<br />
<br />
== Core/Bitbake ==<br />
{| border="1"<br />
| align="center" style="background:#f0f0f0;"|'''Feature Name'''<br />
| align="center" style="background:#f0f0f0;"|'''Description'''<br />
| align="center" style="background:#f0f0f0;"|'''Priority'''<br />
| align="center" style="background:#f0f0f0;"|'''Status'''<br />
| align="center" style="background:#f0f0f0;"|'''Source'''<br />
| align="center" style="background:#f0f0f0;"|'''Owner'''<br />
| align="center" style="background:#f0f0f0;"|'''Due'''<br />
| align="center" style="background:#f0f0f0;"|'''Comments / Bugzilla Links'''<br />
|-<br />
| Web-based Image Creator||Create a web-based interface that does what the Image Creator does.||2.5||Review||LCS||Jason Kridner?||1.2||Yocto 1.2 - depends on Image Creator completing<br />
|-<br />
| Recipe-specific sysroot||||3||Review||from 1.0||Saul (Dongxiao)||1.2||Yocto 1.2 (1 month task)<br />
|-<br />
| Handle old versions in WORKDIR||||3||Review||from 1.0||||1.2||Yocto 1.2<br />
|-<br />
| Executable images||Create images that are executable - for example a pre-installed Ubuntu image with YP installed||3||Review||LCS||||1.2||Yocto 1.2<br />
|-<br />
| Self-hosting image||Create customizable chroot; Build an image that would be self-hosting||2.5||Review||LCS||||1.2||Yocto 1.2<br />
|-<br />
| Yocto OOPS-type messages||add the equivalent of kernel OOPS to Yocto||2.5||Review||LCS||||1.2||Yocto 1.2<br />
|-<br />
| Reduced depth revision history||Decrease the depth of the revision history||3||Review||LCS||||1.2||Yocto 1.2<br />
|-<br />
| Ability to archive work dir||Add the ability to archive the work directory to handle the GPL compliance issue.||3||Review||LCS||||1.2||Yocto 1.2, On Janitor\'s list<br />
|}<br />
<br />
== QA Items ==<br />
{| border="1"<br />
| align="center" style="background:#f0f0f0;"|'''Feature Name'''<br />
| align="center" style="background:#f0f0f0;"|'''Description'''<br />
| align="center" style="background:#f0f0f0;"|'''Priority'''<br />
| align="center" style="background:#f0f0f0;"|'''Status'''<br />
| align="center" style="background:#f0f0f0;"|'''Source'''<br />
| align="center" style="background:#f0f0f0;"|'''Owner'''<br />
| align="center" style="background:#f0f0f0;"|'''Due'''<br />
| align="center" style="background:#f0f0f0;"|'''Comments / Bugzilla Links'''<br />
|-<br />
| Patch Test System||Create a machine where developers can upload/test patches before submitting them to master to ensure builds won\'t break when patches are added. (developer autobuilders? Fuzz builds?)||2||Review||Team||Jiajun||1.2||<br />
|-<br />
| Open Source Test Cases||Perform technical, legal, and QA steps necessary to move test cases into open source.||3||Review||QA||||1.2||Yocto 1.2<br />
|-<br />
| Start a framework for automated BSP testing||Build-testing is only half the job of BSP testing, and new BSP development is and will be ramping up even more rapidly soon. We need to start building a framework to make as much of this as automated as possible. Phase I, what we can complete for 1.2, should be the ability to load an image from the autobuilder and make it ready for booting, or actually boot it, on a given target. It would be good to use systems running Yocto images as much as possible for this.||2||Review||Tom||||1.2||<br />
|-<br />
| Test framework||this is a test framework that we can include in the distribution||3||Review||RP Notes||||1.2||Yocto 1.2 - Is it the TI’s test framework we discussed before? A: Not necessarily, we\'re still waiting for someone to step up and really take ownership of this area but it needs some resource commitment as its not a simple task. <br />
|-<br />
| Package History||Write out data about the size of packages, their contents, dependencies, build time and so on allowing changes to be detected. One idea is we could do this in the form of a git repository||1||Review||RP||||1.2||Yocto 1.2<br />
|-<br />
| Package History Analysis Tool||Take the above data, highlight significant deltas and allow the user to confirm or red flag changes. Why did the package double in size? Why did some dependencies go missing? ||1||Review||RP||||1.2||Yocto 1.2<br />
|-<br />
| Extend current QA Tests||Automate some of the existing QA tests such as LSB, posix and rt tests||1||Review||RP||||1.2||Yocto 1.2<br />
|}<br />
<br />
== Meta Data ==<br />
{| border="1"<br />
| align="center" style="background:#f0f0f0;"|'''Feature Name'''<br />
| align="center" style="background:#f0f0f0;"|'''Description'''<br />
| align="center" style="background:#f0f0f0;"|'''Priority'''<br />
| align="center" style="background:#f0f0f0;"|'''Status'''<br />
| align="center" style="background:#f0f0f0;"|'''Source'''<br />
| align="center" style="background:#f0f0f0;"|'''Owner'''<br />
| align="center" style="background:#f0f0f0;"|'''Due'''<br />
| align="center" style="background:#f0f0f0;"|'''Comments / Bugzilla Links'''<br />
|-<br />
| Replacement for video/audio players currently in Yocto||Codec…||3||Review||Meta-data||||1.2||Yocto 1.2<br />
|-<br />
| Investigate New UI||For demos, we would like need a reference UI that is not Sato. Investigate possibilities that the Yocto team won\'t need to maintain. OpenBox? Gnome-desktop? GP? LXDE? KDE Mobile?||3||Review||Meta-data||||1.2||Yocto 1.2<br />
|-<br />
| Qemugl upstreaming||Opengl ES Support||3||Review||Meta-data||||1.2||Yocto 1.2<br />
|-<br />
| selinux patch integration||add SE Linux patches in a similar way to PAM||3||Review||Meta-data||||1.2||Yocto 1.2<br />
|-<br />
| build statistics reporting||As someone interested in how long it takes to build different images on different hardware configurations and other assorted build metrics, I would like a web based service, that takes output generated by an extended buildstats.bbclass and stores it, to compare against different machines. The end result should be a way to visualize the collected data. See: https://wiki.yoctoproject.org/wiki/Yocto_Buildbot_Autobuilder_Discussions||2||M3, Sprint A||eflanagan/Jay7/ka6sox||Beth/Jay||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| Framework to support multiple library versions co-existing||similar to recipe specific sysroot; needs documentation||3||Review||Team||Saul (Dongxiao?)||1.2||Yocto 1.2 - we just need to document how to use multiple versions of a library using clutter as the example<br />
|-<br />
| Embedded java environment or even JDK support||||3||Review||Team||||1.2||Yocto 1.2<br />
|-<br />
| Target module build||Allow for building kernel modules on the target device||2||Review||RP Notes||Darren||1.2||Yocto 1.2, On Janitor\'s list<br />
|-<br />
| gtk+ sato filechooser patch||||3||Review||RP Notes||||1.2||Yocto 1.2<br />
|-<br />
| sato refresh||||3||Review||RP Notes||||1.2||Yocto 1.2<br />
|-<br />
| Sanity checks on per recipe basis||||2||Accept||RP Notes Bug#405||Saul (Scott G)||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| perf scripting\' integration||Make it easy and convenient for the user to write and execute \'perf scripts\' from the IDE. We should be able to leverage and build on the Systemtap integration for this.||2||Dev||Tom||Jessica/Tom||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| Add Directfb(license LGPL) function||Directfb is more appropriate embedded device than other graphic software||3||Moved from M1||Meta-data||WR Distro team||1.2||Yocto 1.2, from 1.1<br />
|}<br />
<br />
== Autobuilder ==<br />
{| border="1"<br />
| align="center" style="background:#f0f0f0;"|'''Feature Name'''<br />
| align="center" style="background:#f0f0f0;"|'''Description'''<br />
| align="center" style="background:#f0f0f0;"|'''Priority'''<br />
| align="center" style="background:#f0f0f0;"|'''Status'''<br />
| align="center" style="background:#f0f0f0;"|'''Source'''<br />
| align="center" style="background:#f0f0f0;"|'''Owner'''<br />
| align="center" style="background:#f0f0f0;"|'''Due'''<br />
| align="center" style="background:#f0f0f0;"|'''Comments / Bugzilla Links'''<br />
|-<br />
| autobuilder layer support||||2||||Beth||Beth||1.2||2 weeks<br />
|-<br />
| autobuilder split of nightly (really an M4 task) few days license.bbclass refactor||||2||||Beth||Beth||1.2||1 week<br />
|-<br />
| buildstats memory measurements||||2||||Beth||Beth||1.2||1 week and half<br />
|-<br />
| license manifest||||2||||Beth||Beth||1.2||1 week<br />
|-<br />
| autobuilder release checkbox (running a yocto release right from the autobuilder)||||2||||Beth||Beth||1.2||2 weeks<br />
|}<br />
<br />
== BSPs ==<br />
{| border="1"<br />
| align="center" style="background:#f0f0f0;"|'''Feature Name'''<br />
| align="center" style="background:#f0f0f0;"|'''Description'''<br />
| align="center" style="background:#f0f0f0;"|'''Priority'''<br />
| align="center" style="background:#f0f0f0;"|'''Status'''<br />
| align="center" style="background:#f0f0f0;"|'''Source'''<br />
| align="center" style="background:#f0f0f0;"|'''Owner'''<br />
| align="center" style="background:#f0f0f0;"|'''Due'''<br />
| align="center" style="background:#f0f0f0;"|'''Comments / Bugzilla Links'''<br />
|-<br />
| AMT driver integration||incorporate Linux AMT into the Yocto BSPs||||||||||1.2||Intel<br />
|-<br />
| Zaurusd++ (devmand?)||I keep seeing changes to toggle certain features for various boards (audio on the beagleboard, N450 and spring to mind), rather than writing lots of recipes for this perhaps we could resurrect zaurusd and evolve it to reflect the projects original goals as devmand; a daemon to handle hardware quirks across a range of boards and devices. ||||||||||1.2||Joshua<br />
|-<br />
| BSP update/intro||determine and integrate / create arch reference BSPs (e500, Cortex, ARM, MIPs)||2||Dev||Bruce/Richard/team||Bruce||1.2||Yocto 1.2, from 1.1<br />
|- <br />
|Drop Grub for Syslinux || Grub is considerably more complicated than we need for any of our current BSPs. Syslinux can be used in place of every known usage of Grub. For upcoming EFI BSPs, we can look to Efilinux. This will reduce our bootloader maintenance burden and simplify our images. || 2 || Review || Darren || Darren || 1.2 ||<br />
|-<br />
|Integrate alsa-state || Remove all the BSP specific $MACHINE-audio recipes in favor of the more generic alsa-state mechanism in use by OE already. || 1 || Review || Darren || || 1.2 || This possibly conflicts with the item to refresh zaurusd.<br />
|-<br />
|Upgrade to EFI ||Where possible, update our existing BSPs to boot using EFI. This will support development of efilinux as well as help us prepare for the newer boards which will be EFI only. || 2 || Review || Darren || Darren || 1.2 ||<br />
|-<br />
|BSP/kernel wrappers/wizards || Create some simple scripts or 'wizards' that make it easy for users to start writing a new BSP and/or easily make simple kernel modifications to a BSP. Ideally, users shouldn't need to know anything low-level about the kernel, git, or the mechanics of appending config items to recipes in order to get a BSP up and running or to make the simple modifications needed to tweak or maintain it. || 2 || Review || tomz || tomz || 1.2 ||<br />
|}<br />
<br />
== ADT == <br />
{| border="1"<br />
| align="center" style="background:#f0f0f0;"|'''Feature Name'''<br />
| align="center" style="background:#f0f0f0;"|'''Description'''<br />
| align="center" style="background:#f0f0f0;"|'''Priority'''<br />
| align="center" style="background:#f0f0f0;"|'''Status'''<br />
| align="center" style="background:#f0f0f0;"|'''Source'''<br />
| align="center" style="background:#f0f0f0;"|'''Owner'''<br />
| align="center" style="background:#f0f0f0;"|'''Due'''<br />
| align="center" style="background:#f0f0f0;"|'''Comments / Bugzilla Links'''<br />
|-<br />
| Enhance the deploy part in remote debug||ADT is currently using org.eclipse.cdt.remote.launch for remote debug. One limitation in this plug-in is that it can only deploy one single file to the target during the debug. Though it is ok for debugging static linked program, debugging dynamic linked program might require deploying multiple files(including executables and libraries) to the target.||2||Review||Lianhao||Jessica||1.2||<br />
|-<br />
| Secure login||||2||Review||ADT Team||Jessica||1.2||Yocto 1.2<br />
|-<br />
| Linux tools upstream integration||There're some activities within the Eclipse Linux Tools community for various tools remote invocation improvement, we need to sync up with the community for their latest deliveries and make some contribution if possible ||2||Review||ADT Team||Jessica||1.2||Yocto 1.2<br />
|-<br />
| Add recipe supporting autoconf-nativesdk and automake-nativesdk ||The new libtool m4 macros(supporting --with-libtool-sysroot) resides in the directory where host aclocal can not find it by default. This requires the user to manually add that directory using -I options. Adding automake(autoconf)-nativesdk into meta-toolchain would help this. ||2||Review||Lianhao||||1.2||Yocto 1.2<br />
|-<br />
| Prebuit SDK integration||speedup target image generation by reusing prebuilt tools from SDK native and target binaries. See: http://wiki.secretlab.ca/Yocto_prebuilt_SDK_integration||2||Reject||Adrian||Jessica||1.2||Yocto 1.2 - This functionality looks to have been provided by sstate packages?<br />
|-<br />
|Eclipse BSP/Kernel Plugin || Provide an Eclipse plugin to facilitate configuring new BSPs and streamlining the linuix-yocto development workflow. || 2 || Review || Darren || || 1.2 ||<br />
<br />
|}<br />
<br />
== Documentation ==<br />
{| border="1"<br />
| align="center" style="background:#f0f0f0;"|'''Feature Name'''<br />
| align="center" style="background:#f0f0f0;"|'''Description'''<br />
| align="center" style="background:#f0f0f0;"|'''Priority'''<br />
| align="center" style="background:#f0f0f0;"|'''Status'''<br />
| align="center" style="background:#f0f0f0;"|'''Source'''<br />
| align="center" style="background:#f0f0f0;"|'''Owner'''<br />
| align="center" style="background:#f0f0f0;"|'''Due'''<br />
| align="center" style="background:#f0f0f0;"|'''Comments / Bugzilla Links'''<br />
|-<br />
| Various Demo Videos||The idea here is to create screen-capture type tutorials similar to what exists for the ADT Eclipse Plug-in. However, we want to contract out some help for professional voice-over talent to be used with the images. These don\'t have to be limited to screen-capture material but could include well-done PPT decks - similar to how other business units in Intel create various training modules. For 1.1 it would be good to capture the script for the existing ADT Eclipse Plug-in module and have it voiced over. Also, for 1.1 it would be good to create a similar module for the Image Creator application.||2||Not Started||From ADT module and scratch||ScottR||1.2||Q3 at the earliest<br />
|}<br />
<br />
== Performance & usability ==<br />
{| border="1"<br />
| align="center" style="background:#f0f0f0;"|'''Feature Name'''<br />
| align="center" style="background:#f0f0f0;"|'''Description'''<br />
| align="center" style="background:#f0f0f0;"|'''Priority'''<br />
| align="center" style="background:#f0f0f0;"|'''Status'''<br />
| align="center" style="background:#f0f0f0;"|'''Source'''<br />
| align="center" style="background:#f0f0f0;"|'''Owner'''<br />
| align="center" style="background:#f0f0f0;"|'''Due'''<br />
| align="center" style="background:#f0f0f0;"|'''Comments / Bugzilla Links'''<br />
|-<br />
| POSIX support||address POSIX failures found in 1.1||2||Review||Team||||1.2||Yocto 1.2, On Janitor\'s list<br />
|}<br />
<br />
<br />
== Kernel ==<br />
{| border="1"<br />
| align="center" style="background:#f0f0f0;"|'''Feature Name'''<br />
| align="center" style="background:#f0f0f0;"|'''Description'''<br />
| align="center" style="background:#f0f0f0;"|'''Priority'''<br />
| align="center" style="background:#f0f0f0;"|'''Status'''<br />
| align="center" style="background:#f0f0f0;"|'''Source'''<br />
| align="center" style="background:#f0f0f0;"|'''Owner'''<br />
| align="center" style="background:#f0f0f0;"|'''Due'''<br />
| align="center" style="background:#f0f0f0;"|'''Comments / Bugzilla Links'''<br />
|-<br />
| Minimal Image unique||make minimal image smaller||3||Accept||Team||WR Distro Team||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| Tracing: tuna, oscilloscope recipes||This might be more useful with the increased importance of RT||3||Review||from 1.0||||1.2||Yocto 1.2<br />
|-<br />
| Kernel Tools||Implement plan for kernel tools||2||Dev (20%)||Bruce/Mark||Bruce||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| use cases||BSP config streamlining, building the kernel standalone, yoctoization, meta data sharing||1||Accept||Bruce||Bruce||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| kernel bloat - development||target = boot a minimal image in < 8M - development complete||1||Dev||Darren||Darren||1.2||Yocto 1.2, from 1.1, continuation needed?<br />
|-<br />
| Fast boot time||2 second boot time target||1||Dev||Team||Darren||1.2||Yocto 1.2, from 1.1, continuation needed?<br />
|-<br />
|Upstream config fragments || Work with John Stultz to upstream a Linux kernel config fragment manager and rework the yocto-kernel-tools to use it. This will simplify our tooling and increase our usage/test base. || 1 || Review || Darren || || 1.2 ||<br />
|-<br />
|Real-time process-executed timers || Timers currently run at the priority of the softirq that processes them and they are accounted to whichever task was preempted for them to run. This negatively impacts determinism and accounting accuracy. || 2 || Review || Darren || || 1.2 ||<br />
|-<br />
|Define Kernel policy || We need to clearly document kernel policy and make the config fragments reflect it. This will facilitate a more modular approach to building BSP kernel configs, as well as make it clear what can be expected to be supported when running a "linux-yocto kernel". || 1 || Review || Darren || || 1.2 ||<br />
|}<br />
<br />
== Project-wide Features ==<br />
{| border="1"<br />
| align="center" style="background:#f0f0f0;"|'''Feature Name'''<br />
| align="center" style="background:#f0f0f0;"|'''Description'''<br />
| align="center" style="background:#f0f0f0;"|'''Priority'''<br />
| align="center" style="background:#f0f0f0;"|'''Status'''<br />
| align="center" style="background:#f0f0f0;"|'''Source'''<br />
| align="center" style="background:#f0f0f0;"|'''Owner'''<br />
| align="center" style="background:#f0f0f0;"|'''Due'''<br />
| align="center" style="background:#f0f0f0;"|'''Comments / Bugzilla Links'''<br />
|-<br />
| LayerTooling – remote layer tool||Consider integrating Jeremy Puhlman\'s remote layers patch||2||Community||Paul||1.2||||<br />
|-<br />
| running post installs at rootfs gen time||||2||Review||RP Notes||Saul (Dexuan)||1.2||<br />
|-<br />
| Clean up warning messages||A build that runs correctly to completion still includes a ton of WARNING messages. We need a project to clean these up. Beth will work on License Warnings, team will look at other logfile warnings||2||Review||Dave & RP||Saul||1.2||<br />
|-<br />
| Multi-lib - 11||Directly support multlibs within the toolchain itself [post 1.1] ||2||||RP||Ke||1.2||<br />
|-<br />
| Multi-lib - 8||Add support to RPM packaging backend to turn modified package names into true rpm multilib packages||1||||RP||Mark||1.2||<br />
|-<br />
| Multi-lib - 7||Investigate better TARGET_VENDOR handling for config.sub. Currently we can only have ARCH-VENDOR-linux where VENDOR cannot contain \"-\" but it might be possible to relax that constraint [not high priority]. ||2||Review||RP||Ke||1.2||<br />
|-<br />
| Multi-lib - 6||Create some \"standard\" multilib configurations (x86 32+64 bit)||1||Review||RP||Ke||1.2||<br />
|-<br />
| Patchwork||is it worth the overhead, are there alternatives||3||Review||RP Notes||||1.2||Yocto 1.2<br />
|-<br />
| Bugzilla to Wiki||Create a script which automatically populates and updates the Wiki based on changes in bugzilla.||2.5||Review||Darren||||1.2||Yocto 1.2<br />
|-<br />
| Sync qemugl with MeeGo - Implementation||sync qemugl with MeeGo is complete||2||Dev (70%)||Meta-data||Saul (Edwin)||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| Tracing/profiling HOWTOs||Create a document or extend the current Yocto tracing wiki page to explain in detail how to use all the tracing tools in Yocto. It should detail not only how to use each tool individually, but also how to use them in conjunction with each other, highlighting situations in which each is most useful. There should also be some extensive worked examples of real-life use-cases and how they could be investigated using the Yocto tracing/profiling tools.||2||Accept||Tom||Tom||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| Error handling in bitbake (Implementation): Stage 2||Performance improvement (gather input from community on use cases)||1||Dev||RP Notes||Saul (Scott G)||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| btrfs||Kernel enabling||2||Dev||Meta-data||Saul (Nitin)||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| replace qemuppc||||||||||Bruce||1.2||Come from bug 414<br />
|-<br />
| MeeGo GPLv2 Sync||compare with Yocto, sync any patches||2||Accept||RP Notes||Saul (Ke)||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| Package Documentation Audit: All recipes build||31 recipes were identified as not building during the package documentation audit done in M1, Sprint B. Those all need to build and we need to re-run a new package documentation audit.||2||Accept||Team||Scott G||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| Tracing: Systemtap usability in Yocto||Right now, there are instructions on the wiki on how to configure and use Systemtap with Yocto. While straightforward, they are tedious and unlikely to be useful to most people pressed for time. We need to make it easier to use - in addition to documentation/HOWTO tasks listed elsewhere on this page, we need to make it usable \'out of the box\' (i.e. outside of ADT) e.g. all paths and configuration handled via script or something similar||2||Accept||Tom||Tom||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| Tracing: create separate recipe for perf||Perf is currently built as part of the kernel build. If we want to make use of everything perf has to offer we should get rid of the dependency. For example, the kernel build shouldn\'t depend on libnewt, and x32 shouldn\'t have to deal with embedded Python||2||Review||Tom||Tom||1.2||<br />
|-<br />
| Tracing: perf trace scripting support||Basically this means allowing perf to be built with the Perl and Python bindings, which turned out to be a headache last time.||2||Dev (50%)||from 1.0||Tom||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| Monitor disk availability||Monitor disk availability and warn the user if it is running low. May only focus on a few directories, for example: poky/build and poky/build/downloads, this would solve the multiple mount point problem||2||Review||RP and Robert||WR Distro Team (Robert)||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| Ability to build SRPM||||3||Accept||RP Notes||Jeff Polk/Mark||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| Classes to help install binary packages||It\'s been suggested that it would be a useful feature to be able to easily take an RPM or similar containing a software binary from a 3rd party software vendor and integrate it into an image created by the build system.||2||Review||||||1.2||<br />
|-<br />
| Host intrusion prevention||We have Swabber but it\'s not integrated into our process. I believe this is because there are several recipes which don\'t work when run under strace with parallelisation. We should determine a path for inclusion of swabber into our process and execute on it so that we can be aware of, and fix, any host intrusion issues.||2||Review||||||1.2||<br />
|-<br />
| Security layer||Many of our users are likely to want to use kernel level security mechanisms and so I\'d like to investigate supporting one of the in-kernel LSM (Linux Security Modules), possibly SMACK as used in MeeGo, and adding policy to the oe-core metadata. The LSM, policy and user-space tools could all be enabled via a distro feature. This work may well want to be in a separate layer?||2||Review||Joshua||||1.2||<br />
|-<br />
| Factory reset||Implement a factory reset image feature. We\'ll use one of the union mount technologies (aufs/overlayfs/union mounts) to create an overlay on the file system as the final piece of rootfs creation. The overlaid file-system will be the target of all writes made to the image after the image is generated. A user-space mechanism to disable the overlay, and therefore reset to the state of the image just after it was created, will also be provided. This feature could be further enhanced by integrating with the package manager, and other user-space switches, to create system restore points which can later be rolled back to.||2||Review||Joshua||||1.2||<br />
|-<br />
| Gstreamer||Refactor gstreamer recipes to better support COMMERCIAL_LICENSE and enabling/disabling of various codecs and features||2||Review||||||1.2||http://bugzilla.pokylinux.org/show_bug.cgi?id=923<br />
|-<br />
| Init||Interest in systemd as a replacement for Sys V init is growing but it may not be appropriate for deeply embedded systems. I\'d like to investigate a crop of service based and process monitoring init systems and compare them on a variety of criteria as determined by the community. Furthermore I would like to investigate supporting multiple init systems, the current SysV system, systemd and possibly others. As part of this work, and because increasingly many upstreams support systemd (no doubt thanks to its adoption in Fedora) I would like to investigate implementing some infrastructure which translates from systemd units to the appropriate init format for the supported init systems.||2||Review||||||1.2||<br />
|-<br />
| Enhance Automated QA Tests||Add tests for the RT pieces, consider run-time security checking tools used by Fedora and Gentoo||2||Review||||||1.2||<br />
|-<br />
| Collect data at build time to increase accuracy of estimation (hob)||Collect data at build time to allow hob to: predict the size of the generated image, more accurately reflect the built image contents, etc. This will likely involve generating data on the autobuilder which the UI can fetch and consume (with local caching for offline usage)||2||Review||||||1.2||http://bugzilla.pokylinux.org/show_bug.cgi?id=1316<br />
|-<br />
| Finish and enable PR server||We\'re still seeing people being forced to cleansstate too often, we need to finish up and enable the PR server so the checksummed sstate future can live||2||Review||||||1.2||http://thread.gmane.org/gmane.comp.handhelds.openembedded.core/1272/focus=1357 http://thread.gmane.org/gmane.comp.handhelds.openembedded.core/835/focus=852<br />
|-<br />
| Provide a click through license mechanism||Implement the mechanism described in Section 1.2. BSP \'Click-Through\' Licensing Procedure in the BSP Developer\'s Guide||2||Review||Tom||Tom||1.2||<br />
|-<br />
| Finish Oracle/Sun Hotspot JDK/JRE support||I created an initial hack of a recipe for this for the demo - finish it up (involves licensing issues (click-through license support would be a prerequisite) as well)||2||Review||Tom||Tom||1.2||50% done already<br />
|- <br />
| BSPs or layers for a specific category of devices || This will demonstrate the value of Yocto to developers and help them get up to speed quicker for this category of devices. ||2||Review||Dirk/Dave/Andy||TBD||1.2||<br />
|- <br />
| enhance the bitbake commander eclipse plugin || By having the Eclipse as a frontend UI to bitbake server, eclipse may talk to bitbake server, enable the user to glimpse on the variables' values when editing the recipes, try out building the recipe being edited, etc. ||2||Review||Dongxiao/Lianhao||TBD||TBD|| This requires new features both in eclipse plugin and bitbake server.<br />
|- <br />
| Parallel Locale Generation || Add makefile to allow the locale generation to happen in parallel ||2||Review||RP||||||<br />
|- <br />
| Make BasicHash the default || We'd like to start adding the sstate signature to the stampfiles using the BasicHash signature generator and stop bumping PR values. This will require some additions to the PR server work we previously started||2||Review||RP||||||<br />
|- <br />
| Address git fetcher concerns || The community has raised some git fetcher concerns we should address||2||Review||RP||||||<br />
|}</div>Davesthttps://wiki.yoctoproject.org/wiki/index.php?title=Yocto_1.2_Features&diff=3552Yocto 1.2 Features2011-09-30T15:31:33Z<p>Davest: /* Usability */</p>
<hr />
<div>== Potential Yocto Project 1.2 Features ==<br />
Yocto Project 1.2 - Target release = April 2012<br />
<br />
== Yocto Project 1.2 Themes ==<br />
The topics below are the themes that some members of the team have started brainstorming for Yocto Project v1.2. These will be improved with community input.<br />
<br />
=== Yocto Project 1.2 Objectives ===<br />
The objectives of the Yocto 1.2 release are to increase adoption of the Yocto Project.<br />
<br />
=== Yocto Project 1.2 Theme List ===<br />
The Yocto Project 1.2 Themes towards the Objectives listed above are:<br />
<br />
* Improved usability of the build system for new experienced users, new novice users and existing users.<br />
*<br />
<br />
== Process for Entering New Feature Requests ==<br />
<br />
* Create a new entry in the appropriate feature table below (Poky, SDK, Hardware)<br />
** Suggestion: start by copying an existing request as a template<br />
* Give the feature a short, descriptive name<br />
* Provide a one or two sentence brief description of the feature<br />
* Set the priority as appropriate (see the legend below)<br />
* Set the Status to "Review"<br />
* In the Source field, enter your name along with the origination of the request (e.g. OSV, OEM, Community) if applicable; provide as much detail here as you can<br />
* In the Comments / Bugzilla field, provide any additional information for the request, such as a link to a bugzilla entry<br />
* Preview your Entry to make sure it looks ok and then save it<br />
<br />
''Legend''<br />
<br />
'''Priority:''' 1 = Must Have, 2 = Nice to Have, 3 = Optional<br />
<br />
'''Status:''' Accept = Engineering agreement to include in release, Review = Under Review for Inclusion in this release, Reject = Will not be included in this release<br />
== Sample Table ==<br />
<br />
This is a sample table to show how to submit features.<br />
<br />
{| border="1"<br />
||'''Feature Name''' ||'''Description''' ||'''Priority''' ||'''Status''' ||'''Source''' ||'''Comments / Bugzilla Links'''<br />
|-<br />
||Placeholder feature name || Placeholder description of the feature || 1, 2, or 3 || Review|| name|| Comment<br />
|}<br />
<br />
== Usability ==<br />
{| border="1"<br />
| align="center" style="background:#f0f0f0;"|'''Feature Name'''<br />
| align="center" style="background:#f0f0f0;"|'''Description'''<br />
| align="center" style="background:#f0f0f0;"|'''Priority'''<br />
| align="center" style="background:#f0f0f0;"|'''Status'''<br />
| align="center" style="background:#f0f0f0;"|'''Source'''<br />
| align="center" style="background:#f0f0f0;"|'''Owner'''<br />
| align="center" style="background:#f0f0f0;"|'''Comments / Bugzilla Links'''<br />
|-<br />
| build appliance||Intended for developers to very easily "Check it out" and do a Yocto Project build with minimal pain. Should be a virtual image of a desktop OS which will boot into HOB and offer a terminal or an app to deploy resulting images to media or to run QEMU.||1||Review||davest/tracey/RP||TBD||See here for [[Build Appliance Design]]<br />
|-<br />
| Visual Hob ||Massively update interface for Hob, perhaps similar to SuSE Studio. This is for both local (non-network) builds as well as network.||1||Review||davest/tracey/RP||TBD||xx<br />
|-<br />
| Hob improvements||Update Hob with performance improvements and improvements to package disabling||1||Review||davest/tracey/RP||TBD||xx<br />
|-<br />
| Support for non-developers||Create clear instructions for how a Windows user can take an example image from the YP web site and deploy it to a board. Assume no Linux knowledge. These instructions should be applicable in example images in BSPs ||1||Review||davest/tracey/RP||TBD||xx<br />
|-<br />
| Firewall / Proxy handling in git||Develop a git plugin which will fall back to tunneling through HTTP if the git:// interface will not work because it is blocked by a firewall and the correct proxy is not set up. ||1||Review||davest/tracey/RP||TBD||same for svn,hg,ftp,etc? -dvhart<br />
|-<br />
| Build Yocto behind firewall - implementation||||2||Dev||Dave||Darren/Joshua||Yocto 1.2, from 1.1, the above one seems to be part of this.<br />
|}<br />
<br />
== Core/Bitbake ==<br />
{| border="1"<br />
| align="center" style="background:#f0f0f0;"|'''Feature Name'''<br />
| align="center" style="background:#f0f0f0;"|'''Description'''<br />
| align="center" style="background:#f0f0f0;"|'''Priority'''<br />
| align="center" style="background:#f0f0f0;"|'''Status'''<br />
| align="center" style="background:#f0f0f0;"|'''Source'''<br />
| align="center" style="background:#f0f0f0;"|'''Owner'''<br />
| align="center" style="background:#f0f0f0;"|'''Due'''<br />
| align="center" style="background:#f0f0f0;"|'''Comments / Bugzilla Links'''<br />
|-<br />
| Web-based Image Creator||Create a web-based interface that does what the Image Creator does.||2.5||Review||LCS||Jason Kridner?||1.2||Yocto 1.2 - depends on Image Creator completing<br />
|-<br />
| Recipe-specific sysroot||||3||Review||from 1.0||Saul (Dongxiao)||1.2||Yocto 1.2 (1 month task)<br />
|-<br />
| Handle old versions in WORKDIR||||3||Review||from 1.0||||1.2||Yocto 1.2<br />
|-<br />
| Executable images||Create images that are executable - for example a pre-installed Ubuntu image with YP installed||3||Review||LCS||||1.2||Yocto 1.2<br />
|-<br />
| Self-hosting image||Create customizable chroot; Build an image that would be self-hosting||2.5||Review||LCS||||1.2||Yocto 1.2<br />
|-<br />
| Yocto OOPS-type messages||add the equivalent of kernel OOPS to Yocto||2.5||Review||LCS||||1.2||Yocto 1.2<br />
|-<br />
| Reduced depth revision history||Decrease the depth of the revision history||3||Review||LCS||||1.2||Yocto 1.2<br />
|-<br />
| Ability to archive work dir||Add the ability to archive the work directory to handle the GPL compliance issue.||3||Review||LCS||||1.2||Yocto 1.2, On Janitor\'s list<br />
|}<br />
<br />
== QA Items ==<br />
{| border="1"<br />
| align="center" style="background:#f0f0f0;"|'''Feature Name'''<br />
| align="center" style="background:#f0f0f0;"|'''Description'''<br />
| align="center" style="background:#f0f0f0;"|'''Priority'''<br />
| align="center" style="background:#f0f0f0;"|'''Status'''<br />
| align="center" style="background:#f0f0f0;"|'''Source'''<br />
| align="center" style="background:#f0f0f0;"|'''Owner'''<br />
| align="center" style="background:#f0f0f0;"|'''Due'''<br />
| align="center" style="background:#f0f0f0;"|'''Comments / Bugzilla Links'''<br />
|-<br />
| Patch Test System||Create a machine where developers can upload/test patches before submitting them to master to ensure builds won\'t break when patches are added. (developer autobuilders? Fuzz builds?)||2||Review||Team||Jiajun||1.2||<br />
|-<br />
| Open Source Test Cases||Perform technical, legal, and QA steps necessary to move test cases into open source.||3||Review||QA||||1.2||Yocto 1.2<br />
|-<br />
| Start a framework for automated BSP testing||Build-testing is only half the job of BSP testing, and new BSP development is and will be ramping up even more rapidly soon. We need to start building a framework to make as much of this as automated as possible. Phase I, what we can complete for 1.2, should be the ability to load an image from the autobuilder and make it ready for booting, or actually boot it, on a given target. It would be good to use systems running Yocto images as much as possible for this.||2||Review||Tom||||1.2||<br />
|-<br />
| Test framework||this is a test framework that we can include in the distribution||3||Review||RP Notes||||1.2||Yocto 1.2 - Is it the TI’s test framework we discussed before? A: Not necessarily, we\'re still waiting for someone to step up and really take ownership of this area but it needs some resource commitment as its not a simple task. <br />
|-<br />
| Package History||Write out data about the size of packages, their contents, dependencies, build time and so on allowing changes to be detected. One idea is we could do this in the form of a git repository||1||Review||RP||||1.2||Yocto 1.2<br />
|-<br />
| Package History Analysis Tool||Take the above data, highlight significant deltas and allow the user to confirm or red flag changes. Why did the package double in size? Why did some dependencies go missing? ||1||Review||RP||||1.2||Yocto 1.2<br />
|-<br />
| Extend current QA Tests||Automate some of the existing QA tests such as LSB, posix and rt tests||1||Review||RP||||1.2||Yocto 1.2<br />
|}<br />
<br />
== Meta Data ==<br />
{| border="1"<br />
| align="center" style="background:#f0f0f0;"|'''Feature Name'''<br />
| align="center" style="background:#f0f0f0;"|'''Description'''<br />
| align="center" style="background:#f0f0f0;"|'''Priority'''<br />
| align="center" style="background:#f0f0f0;"|'''Status'''<br />
| align="center" style="background:#f0f0f0;"|'''Source'''<br />
| align="center" style="background:#f0f0f0;"|'''Owner'''<br />
| align="center" style="background:#f0f0f0;"|'''Due'''<br />
| align="center" style="background:#f0f0f0;"|'''Comments / Bugzilla Links'''<br />
|-<br />
| Replacement for video/audio players currently in Yocto||Codec…||3||Review||Meta-data||||1.2||Yocto 1.2<br />
|-<br />
| Investigate New UI||For demos, we would like need a reference UI that is not Sato. Investigate possibilities that the Yocto team won\'t need to maintain. OpenBox? Gnome-desktop? GP? LXDE? KDE Mobile?||3||Review||Meta-data||||1.2||Yocto 1.2<br />
|-<br />
| Qemugl upstreaming||Opengl ES Support||3||Review||Meta-data||||1.2||Yocto 1.2<br />
|-<br />
| selinux patch integration||add SE Linux patches in a similar way to PAM||3||Review||Meta-data||||1.2||Yocto 1.2<br />
|-<br />
| build statistics reporting||As someone interested in how long it takes to build different images on different hardware configurations and other assorted build metrics, I would like a web based service, that takes output generated by an extended buildstats.bbclass and stores it, to compare against different machines. The end result should be a way to visualize the collected data. See: https://wiki.yoctoproject.org/wiki/Yocto_Buildbot_Autobuilder_Discussions||2||M3, Sprint A||eflanagan/Jay7/ka6sox||Beth/Jay||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| Framework to support multiple library versions co-existing||similar to recipe specific sysroot; needs documentation||3||Review||Team||Saul (Dongxiao?)||1.2||Yocto 1.2 - we just need to document how to use multiple versions of a library using clutter as the example<br />
|-<br />
| Embedded java environment or even JDK support||||3||Review||Team||||1.2||Yocto 1.2<br />
|-<br />
| Target module build||Allow for building kernel modules on the target device||2||Review||RP Notes||Darren||1.2||Yocto 1.2, On Janitor\'s list<br />
|-<br />
| gtk+ sato filechooser patch||||3||Review||RP Notes||||1.2||Yocto 1.2<br />
|-<br />
| sato refresh||||3||Review||RP Notes||||1.2||Yocto 1.2<br />
|-<br />
| Sanity checks on per recipe basis||||2||Accept||RP Notes Bug#405||Saul (Scott G)||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| perf scripting\' integration||Make it easy and convenient for the user to write and execute \'perf scripts\' from the IDE. We should be able to leverage and build on the Systemtap integration for this.||2||Dev||Tom||Jessica/Tom||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| Add Directfb(license LGPL) function||Directfb is more appropriate embedded device than other graphic software||3||Moved from M1||Meta-data||WR Distro team||1.2||Yocto 1.2, from 1.1<br />
|}<br />
<br />
== Autobuilder ==<br />
{| border="1"<br />
| align="center" style="background:#f0f0f0;"|'''Feature Name'''<br />
| align="center" style="background:#f0f0f0;"|'''Description'''<br />
| align="center" style="background:#f0f0f0;"|'''Priority'''<br />
| align="center" style="background:#f0f0f0;"|'''Status'''<br />
| align="center" style="background:#f0f0f0;"|'''Source'''<br />
| align="center" style="background:#f0f0f0;"|'''Owner'''<br />
| align="center" style="background:#f0f0f0;"|'''Due'''<br />
| align="center" style="background:#f0f0f0;"|'''Comments / Bugzilla Links'''<br />
|-<br />
| autobuilder layer support||||2||||Beth||Beth||1.2||2 weeks<br />
|-<br />
| autobuilder split of nightly (really an M4 task) few days license.bbclass refactor||||2||||Beth||Beth||1.2||1 week<br />
|-<br />
| buildstats memory measurements||||2||||Beth||Beth||1.2||1 week and half<br />
|-<br />
| license manifest||||2||||Beth||Beth||1.2||1 week<br />
|-<br />
| autobuilder release checkbox (running a yocto release right from the autobuilder)||||2||||Beth||Beth||1.2||2 weeks<br />
|}<br />
<br />
== BSPs ==<br />
{| border="1"<br />
| align="center" style="background:#f0f0f0;"|'''Feature Name'''<br />
| align="center" style="background:#f0f0f0;"|'''Description'''<br />
| align="center" style="background:#f0f0f0;"|'''Priority'''<br />
| align="center" style="background:#f0f0f0;"|'''Status'''<br />
| align="center" style="background:#f0f0f0;"|'''Source'''<br />
| align="center" style="background:#f0f0f0;"|'''Owner'''<br />
| align="center" style="background:#f0f0f0;"|'''Due'''<br />
| align="center" style="background:#f0f0f0;"|'''Comments / Bugzilla Links'''<br />
|-<br />
| AMT driver integration||incorporate Linux AMT into the Yocto BSPs||||||||||1.2||Intel<br />
|-<br />
| Zaurusd++ (devmand?)||I keep seeing changes to toggle certain features for various boards (audio on the beagleboard, N450 and spring to mind), rather than writing lots of recipes for this perhaps we could resurrect zaurusd and evolve it to reflect the projects original goals as devmand; a daemon to handle hardware quirks across a range of boards and devices. ||||||||||1.2||Joshua<br />
|-<br />
| BSP update/intro||determine and integrate / create arch reference BSPs (e500, Cortex, ARM, MIPs)||2||Dev||Bruce/Richard/team||Bruce||1.2||Yocto 1.2, from 1.1<br />
|- <br />
|Drop Grub for Syslinux || Grub is considerably more complicated than we need for any of our current BSPs. Syslinux can be used in place of every known usage of Grub. For upcoming EFI BSPs, we can look to Efilinux. This will reduce our bootloader maintenance burden and simplify our images. || 2 || Review || Darren || Darren || 1.2 ||<br />
|-<br />
|Integrate alsa-state || Remove all the BSP specific $MACHINE-audio recipes in favor of the more generic alsa-state mechanism in use by OE already. || 1 || Review || Darren || || 1.2 || This possibly conflicts with the item to refresh zaurusd.<br />
|-<br />
|Upgrade to EFI ||Where possible, update our existing BSPs to boot using EFI. This will support development of efilinux as well as help us prepare for the newer boards which will be EFI only. || 2 || Review || Darren || Darren || 1.2 ||<br />
|-<br />
|BSP/kernel wrappers/wizards || Create some simple scripts or 'wizards' that make it easy for users to start writing a new BSP and/or easily make simple kernel modifications to a BSP. Ideally, users shouldn't need to know anything low-level about the kernel, git, or the mechanics of appending config items to recipes in order to get a BSP up and running or to make the simple modifications needed to tweak or maintain it. || 2 || Review || tomz || tomz || 1.2 ||<br />
|}<br />
<br />
== ADT == <br />
{| border="1"<br />
| align="center" style="background:#f0f0f0;"|'''Feature Name'''<br />
| align="center" style="background:#f0f0f0;"|'''Description'''<br />
| align="center" style="background:#f0f0f0;"|'''Priority'''<br />
| align="center" style="background:#f0f0f0;"|'''Status'''<br />
| align="center" style="background:#f0f0f0;"|'''Source'''<br />
| align="center" style="background:#f0f0f0;"|'''Owner'''<br />
| align="center" style="background:#f0f0f0;"|'''Due'''<br />
| align="center" style="background:#f0f0f0;"|'''Comments / Bugzilla Links'''<br />
|-<br />
| Enhance the deploy part in remote debug||ADT is currently using org.eclipse.cdt.remote.launch for remote debug. One limitation in this plug-in is that it can only deploy one single file to the target during the debug. Though it is ok for debugging static linked program, debugging dynamic linked program might require deploying multiple files(including executables and libraries) to the target.||2||Review||Lianhao||Jessica||1.2||<br />
|-<br />
| Secure login||||2||Review||ADT Team||Jessica||1.2||Yocto 1.2<br />
|-<br />
| Linux tools upstream integration||There're some activities within the Eclipse Linux Tools community for various tools remote invocation improvement, we need to sync up with the community for their latest deliveries and make some contribution if possible ||2||Review||ADT Team||Jessica||1.2||Yocto 1.2<br />
|-<br />
| Add recipe supporting autoconf-nativesdk and automake-nativesdk ||The new libtool m4 macros(supporting --with-libtool-sysroot) resides in the directory where host aclocal can not find it by default. This requires the user to manually add that directory using -I options. Adding automake(autoconf)-nativesdk into meta-toolchain would help this. ||2||Review||Lianhao||||1.2||Yocto 1.2<br />
|-<br />
| Prebuit SDK integration||speedup target image generation by reusing prebuilt tools from SDK native and target binaries. See: http://wiki.secretlab.ca/Yocto_prebuilt_SDK_integration||2||Reject||Adrian||Jessica||1.2||Yocto 1.2 - This functionality looks to have been provided by sstate packages?<br />
|-<br />
|Eclipse BSP/Kernel Plugin || Provide an Eclipse plugin to facilitate configuring new BSPs and streamlining the linuix-yocto development workflow. || 2 || Review || Darren || || 1.2 ||<br />
<br />
|}<br />
<br />
== Documentation ==<br />
{| border="1"<br />
| align="center" style="background:#f0f0f0;"|'''Feature Name'''<br />
| align="center" style="background:#f0f0f0;"|'''Description'''<br />
| align="center" style="background:#f0f0f0;"|'''Priority'''<br />
| align="center" style="background:#f0f0f0;"|'''Status'''<br />
| align="center" style="background:#f0f0f0;"|'''Source'''<br />
| align="center" style="background:#f0f0f0;"|'''Owner'''<br />
| align="center" style="background:#f0f0f0;"|'''Due'''<br />
| align="center" style="background:#f0f0f0;"|'''Comments / Bugzilla Links'''<br />
|-<br />
| Various Demo Videos||The idea here is to create screen-capture type tutorials similar to what exists for the ADT Eclipse Plug-in. However, we want to contract out some help for professional voice-over talent to be used with the images. These don\'t have to be limited to screen-capture material but could include well-done PPT decks - similar to how other business units in Intel create various training modules. For 1.1 it would be good to capture the script for the existing ADT Eclipse Plug-in module and have it voiced over. Also, for 1.1 it would be good to create a similar module for the Image Creator application.||2||Not Started||From ADT module and scratch||ScottR||1.2||Q3 at the earliest<br />
|}<br />
<br />
== Performance & usability ==<br />
{| border="1"<br />
| align="center" style="background:#f0f0f0;"|'''Feature Name'''<br />
| align="center" style="background:#f0f0f0;"|'''Description'''<br />
| align="center" style="background:#f0f0f0;"|'''Priority'''<br />
| align="center" style="background:#f0f0f0;"|'''Status'''<br />
| align="center" style="background:#f0f0f0;"|'''Source'''<br />
| align="center" style="background:#f0f0f0;"|'''Owner'''<br />
| align="center" style="background:#f0f0f0;"|'''Due'''<br />
| align="center" style="background:#f0f0f0;"|'''Comments / Bugzilla Links'''<br />
|-<br />
| POSIX support||address POSIX failures found in 1.1||2||Review||Team||||1.2||Yocto 1.2, On Janitor\'s list<br />
|}<br />
<br />
<br />
== Kernel ==<br />
{| border="1"<br />
| align="center" style="background:#f0f0f0;"|'''Feature Name'''<br />
| align="center" style="background:#f0f0f0;"|'''Description'''<br />
| align="center" style="background:#f0f0f0;"|'''Priority'''<br />
| align="center" style="background:#f0f0f0;"|'''Status'''<br />
| align="center" style="background:#f0f0f0;"|'''Source'''<br />
| align="center" style="background:#f0f0f0;"|'''Owner'''<br />
| align="center" style="background:#f0f0f0;"|'''Due'''<br />
| align="center" style="background:#f0f0f0;"|'''Comments / Bugzilla Links'''<br />
|-<br />
| Minimal Image unique||make minimal image smaller||3||Accept||Team||WR Distro Team||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| Tracing: tuna, oscilloscope recipes||This might be more useful with the increased importance of RT||3||Review||from 1.0||||1.2||Yocto 1.2<br />
|-<br />
| Kernel Tools||Implement plan for kernel tools||2||Dev (20%)||Bruce/Mark||Bruce||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| use cases||BSP config streamlining, building the kernel standalone, yoctoization, meta data sharing||1||Accept||Bruce||Bruce||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| kernel bloat - development||target = boot a minimal image in < 8M - development complete||1||Dev||Darren||Darren||1.2||Yocto 1.2, from 1.1, continuation needed?<br />
|-<br />
| Fast boot time||2 second boot time target||1||Dev||Team||Darren||1.2||Yocto 1.2, from 1.1, continuation needed?<br />
|-<br />
|Upstream config fragments || Work with John Stultz to upstream a Linux kernel config fragment manager and rework the yocto-kernel-tools to use it. This will simplify our tooling and increase our usage/test base. || 1 || Review || Darren || || 1.2 ||<br />
|-<br />
|Real-time process-executed timers || Timers currently run at the priority of the softirq that processes them and they are accounted to whichever task was preempted for them to run. This negatively impacts determinism and accounting accuracy. || 2 || Review || Darren || || 1.2 ||<br />
|-<br />
|Define Kernel policy || We need to clearly document kernel policy and make the config fragments reflect it. This will facilitate a more modular approach to building BSP kernel configs, as well as make it clear what can be expected to be supported when running a "linux-yocto kernel". || 1 || Review || Darren || || 1.2 ||<br />
|}<br />
<br />
== Project-wide Features ==<br />
{| border="1"<br />
| align="center" style="background:#f0f0f0;"|'''Feature Name'''<br />
| align="center" style="background:#f0f0f0;"|'''Description'''<br />
| align="center" style="background:#f0f0f0;"|'''Priority'''<br />
| align="center" style="background:#f0f0f0;"|'''Status'''<br />
| align="center" style="background:#f0f0f0;"|'''Source'''<br />
| align="center" style="background:#f0f0f0;"|'''Owner'''<br />
| align="center" style="background:#f0f0f0;"|'''Due'''<br />
| align="center" style="background:#f0f0f0;"|'''Comments / Bugzilla Links'''<br />
|-<br />
| LayerTooling – remote layer tool||Consider integrating Jeremy Puhlman\'s remote layers patch||2||Community||Paul||1.2||||<br />
|-<br />
| running post installs at rootfs gen time||||2||Review||RP Notes||Saul (Dexuan)||1.2||<br />
|-<br />
| Clean up warning messages||A build that runs correctly to completion still includes a ton of WARNING messages. We need a project to clean these up. Beth will work on License Warnings, team will look at other logfile warnings||2||Review||Dave & RP||Saul||1.2||<br />
|-<br />
| Multi-lib - 11||Directly support multlibs within the toolchain itself [post 1.1] ||2||||RP||Ke||1.2||<br />
|-<br />
| Multi-lib - 8||Add support to RPM packaging backend to turn modified package names into true rpm multilib packages||1||||RP||Mark||1.2||<br />
|-<br />
| Multi-lib - 7||Investigate better TARGET_VENDOR handling for config.sub. Currently we can only have ARCH-VENDOR-linux where VENDOR cannot contain \"-\" but it might be possible to relax that constraint [not high priority]. ||2||Review||RP||Ke||1.2||<br />
|-<br />
| Multi-lib - 6||Create some \"standard\" multilib configurations (x86 32+64 bit)||1||Review||RP||Ke||1.2||<br />
|-<br />
| Patchwork||is it worth the overhead, are there alternatives||3||Review||RP Notes||||1.2||Yocto 1.2<br />
|-<br />
| Bugzilla to Wiki||Create a script which automatically populates and updates the Wiki based on changes in bugzilla.||2.5||Review||Darren||||1.2||Yocto 1.2<br />
|-<br />
| Sync qemugl with MeeGo - Implementation||sync qemugl with MeeGo is complete||2||Dev (70%)||Meta-data||Saul (Edwin)||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| Tracing/profiling HOWTOs||Create a document or extend the current Yocto tracing wiki page to explain in detail how to use all the tracing tools in Yocto. It should detail not only how to use each tool individually, but also how to use them in conjunction with each other, highlighting situations in which each is most useful. There should also be some extensive worked examples of real-life use-cases and how they could be investigated using the Yocto tracing/profiling tools.||2||Accept||Tom||Tom||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| Error handling in bitbake (Implementation): Stage 2||Performance improvement (gather input from community on use cases)||1||Dev||RP Notes||Saul (Scott G)||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| btrfs||Kernel enabling||2||Dev||Meta-data||Saul (Nitin)||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| replace qemuppc||||||||||Bruce||1.2||Come from bug 414<br />
|-<br />
| MeeGo GPLv2 Sync||compare with Yocto, sync any patches||2||Accept||RP Notes||Saul (Ke)||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| Package Documentation Audit: All recipes build||31 recipes were identified as not building during the package documentation audit done in M1, Sprint B. Those all need to build and we need to re-run a new package documentation audit.||2||Accept||Team||Scott G||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| Tracing: Systemtap usability in Yocto||Right now, there are instructions on the wiki on how to configure and use Systemtap with Yocto. While straightforward, they are tedious and unlikely to be useful to most people pressed for time. We need to make it easier to use - in addition to documentation/HOWTO tasks listed elsewhere on this page, we need to make it usable \'out of the box\' (i.e. outside of ADT) e.g. all paths and configuration handled via script or something similar||2||Accept||Tom||Tom||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| Tracing: create separate recipe for perf||Perf is currently built as part of the kernel build. If we want to make use of everything perf has to offer we should get rid of the dependency. For example, the kernel build shouldn\'t depend on libnewt, and x32 shouldn\'t have to deal with embedded Python||2||Review||Tom||Tom||1.2||<br />
|-<br />
| Tracing: perf trace scripting support||Basically this means allowing perf to be built with the Perl and Python bindings, which turned out to be a headache last time.||2||Dev (50%)||from 1.0||Tom||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| Monitor disk availability||Monitor disk availability and warn the user if it is running low. May only focus on a few directories, for example: poky/build and poky/build/downloads, this would solve the multiple mount point problem||2||Review||RP and Robert||WR Distro Team (Robert)||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| Ability to build SRPM||||3||Accept||RP Notes||Jeff Polk/Mark||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| Classes to help install binary packages||It\'s been suggested that it would be a useful feature to be able to easily take an RPM or similar containing a software binary from a 3rd party software vendor and integrate it into an image created by the build system.||2||Review||||||1.2||<br />
|-<br />
| Host intrusion prevention||We have Swabber but it\'s not integrated into our process. I believe this is because there are several recipes which don\'t work when run under strace with parallelisation. We should determine a path for inclusion of swabber into our process and execute on it so that we can be aware of, and fix, any host intrusion issues.||2||Review||||||1.2||<br />
|-<br />
| Security layer||Many of our users are likely to want to use kernel level security mechanisms and so I\'d like to investigate supporting one of the in-kernel LSM (Linux Security Modules), possibly SMACK as used in MeeGo, and adding policy to the oe-core metadata. The LSM, policy and user-space tools could all be enabled via a distro feature. This work may well want to be in a separate layer?||2||Review||Joshua||||1.2||<br />
|-<br />
| Factory reset||Implement a factory reset image feature. We\'ll use one of the union mount technologies (aufs/overlayfs/union mounts) to create an overlay on the file system as the final piece of rootfs creation. The overlaid file-system will be the target of all writes made to the image after the image is generated. A user-space mechanism to disable the overlay, and therefore reset to the state of the image just after it was created, will also be provided. This feature could be further enhanced by integrating with the package manager, and other user-space switches, to create system restore points which can later be rolled back to.||2||Review||Joshua||||1.2||<br />
|-<br />
| Gstreamer||Refactor gstreamer recipes to better support COMMERCIAL_LICENSE and enabling/disabling of various codecs and features||2||Review||||||1.2||http://bugzilla.pokylinux.org/show_bug.cgi?id=923<br />
|-<br />
| Init||Interest in systemd as a replacement for Sys V init is growing but it may not be appropriate for deeply embedded systems. I\'d like to investigate a crop of service based and process monitoring init systems and compare them on a variety of criteria as determined by the community. Furthermore I would like to investigate supporting multiple init systems, the current SysV system, systemd and possibly others. As part of this work, and because increasingly many upstreams support systemd (no doubt thanks to its adoption in Fedora) I would like to investigate implementing some infrastructure which translates from systemd units to the appropriate init format for the supported init systems.||2||Review||||||1.2||<br />
|-<br />
| Enhance Automated QA Tests||Add tests for the RT pieces, consider run-time security checking tools used by Fedora and Gentoo||2||Review||||||1.2||<br />
|-<br />
| Collect data at build time to increase accuracy of estimation (hob)||Collect data at build time to allow hob to: predict the size of the generated image, more accurately reflect the built image contents, etc. This will likely involve generating data on the autobuilder which the UI can fetch and consume (with local caching for offline usage)||2||Review||||||1.2||http://bugzilla.pokylinux.org/show_bug.cgi?id=1316<br />
|-<br />
| Finish and enable PR server||We\'re still seeing people being forced to cleansstate too often, we need to finish up and enable the PR server so the checksummed sstate future can live||2||Review||||||1.2||http://thread.gmane.org/gmane.comp.handhelds.openembedded.core/1272/focus=1357 http://thread.gmane.org/gmane.comp.handhelds.openembedded.core/835/focus=852<br />
|-<br />
| Provide a click through license mechanism||Implement the mechanism described in Section 1.2. BSP \'Click-Through\' Licensing Procedure in the BSP Developer\'s Guide||2||Review||Tom||Tom||1.2||<br />
|-<br />
| Finish Oracle/Sun Hotspot JDK/JRE support||I created an initial hack of a recipe for this for the demo - finish it up (involves licensing issues (click-through license support would be a prerequisite) as well)||2||Review||Tom||Tom||1.2||50% done already<br />
|- <br />
| BSPs or layers for a specific category of devices || This will demonstrate the value of Yocto to developers and help them get up to speed quicker for this category of devices. ||2||Review||Dirk/Dave/Andy||TBD||1.2||<br />
|- <br />
| enhance the bitbake commander eclipse plugin || By having the Eclipse as a frontend UI to bitbake server, eclipse may talk to bitbake server, enable the user to glimpse on the variables' values when editing the recipes, try out building the recipe being edited, etc. ||2||Review||Dongxiao/Lianhao||TBD||TBD|| This requires new features both in eclipse plugin and bitbake server.<br />
|- <br />
| Parallel Locale Generation || Add makefile to allow the locale generation to happen in parallel ||2||Review||RP||||||<br />
|- <br />
| Make BasicHash the default || We'd like to start adding the sstate signature to the stampfiles using the BasicHash signature generator and stop bumping PR values. This will require some additions to the PR server work we previously started||2||Review||RP||||||<br />
|- <br />
| Address git fetcher concerns || The community has raised some git fetcher concerns we should address||2||Review||RP||||||<br />
|}</div>Davesthttps://wiki.yoctoproject.org/wiki/index.php?title=Yocto_1.2_Features&diff=3551Yocto 1.2 Features2011-09-30T14:57:25Z<p>Davest: /* Yocto Project 1.2 Theme List */</p>
<hr />
<div>== Potential Yocto Project 1.2 Features ==<br />
Yocto Project 1.2 - Target release = April 2012<br />
<br />
== Yocto Project 1.2 Themes ==<br />
The topics below are the themes that some members of the team have started brainstorming for Yocto Project v1.2. These will be improved with community input.<br />
<br />
=== Yocto Project 1.2 Objectives ===<br />
The objectives of the Yocto 1.2 release are to increase adoption of the Yocto Project.<br />
<br />
=== Yocto Project 1.2 Theme List ===<br />
The Yocto Project 1.2 Themes towards the Objectives listed above are:<br />
<br />
* Improved usability of the build system for new experienced users, new novice users and existing users.<br />
*<br />
<br />
== Process for Entering New Feature Requests ==<br />
<br />
* Create a new entry in the appropriate feature table below (Poky, SDK, Hardware)<br />
** Suggestion: start by copying an existing request as a template<br />
* Give the feature a short, descriptive name<br />
* Provide a one or two sentence brief description of the feature<br />
* Set the priority as appropriate (see the legend below)<br />
* Set the Status to "Review"<br />
* In the Source field, enter your name along with the origination of the request (e.g. OSV, OEM, Community) if applicable; provide as much detail here as you can<br />
* In the Comments / Bugzilla field, provide any additional information for the request, such as a link to a bugzilla entry<br />
* Preview your Entry to make sure it looks ok and then save it<br />
<br />
''Legend''<br />
<br />
'''Priority:''' 1 = Must Have, 2 = Nice to Have, 3 = Optional<br />
<br />
'''Status:''' Accept = Engineering agreement to include in release, Review = Under Review for Inclusion in this release, Reject = Will not be included in this release<br />
== Sample Table ==<br />
<br />
This is a sample table to show how to submit features.<br />
<br />
{| border="1"<br />
||'''Feature Name''' ||'''Description''' ||'''Priority''' ||'''Status''' ||'''Source''' ||'''Comments / Bugzilla Links'''<br />
|-<br />
||Placeholder feature name || Placeholder description of the feature || 1, 2, or 3 || Review|| name|| Comment<br />
|}<br />
<br />
== Usability ==<br />
{| border="1"<br />
| align="center" style="background:#f0f0f0;"|'''Feature Name'''<br />
| align="center" style="background:#f0f0f0;"|'''Description'''<br />
| align="center" style="background:#f0f0f0;"|'''Priority'''<br />
| align="center" style="background:#f0f0f0;"|'''Status'''<br />
| align="center" style="background:#f0f0f0;"|'''Source'''<br />
| align="center" style="background:#f0f0f0;"|'''Owner'''<br />
| align="center" style="background:#f0f0f0;"|'''Comments / Bugzilla Links'''<br />
|-<br />
| build appliance||Intended for developers to very easily "Check it out" and do a Yocto Project build with minimal pain. Should be a virtual image of a desktop OS which will boot into HOB and offer a terminal or an app to deploy resulting images to media or to run QEMU.||1||Review||davest/tracey/RP||TBD||See here for [[Build Appliance Design]]<br />
|-<br />
| Web Hob||Add a web interface for Hob, perhaps similar to SuSE Studio. This is for both local (non-network) builds as well as network. Would require us to have a web server package installed of course for local builds.||1||Review||davest/tracey/RP||TBD||xx<br />
|-<br />
| Hob improvements||Update Hob with performance improvements and improvements to package disabling||1||Review||davest/tracey/RP||TBD||xx<br />
|-<br />
| Support for non-developers||Create clear instructions for how a Windows user can take an example image from the YP web site and deploy it to a board. Assume no Linux knowledge. These instructions should be applicable in example images in BSPs ||1||Review||davest/tracey/RP||TBD||xx<br />
|-<br />
| Firewall / Proxy handling in git||Develop a git plugin which will fall back to tunneling through HTTP if the git:// interface will not work because it is blocked by a firewall and the correct proxy is not set up. ||1||Review||davest/tracey/RP||TBD||same for svn,hg,ftp,etc? -dvhart<br />
|-<br />
| Build Yocto behind firewall - implementation||||2||Dev||Dave||Darren/Joshua||Yocto 1.2, from 1.1, the above one seems to be part of this.<br />
|}<br />
<br />
== Core/Bitbake ==<br />
{| border="1"<br />
| align="center" style="background:#f0f0f0;"|'''Feature Name'''<br />
| align="center" style="background:#f0f0f0;"|'''Description'''<br />
| align="center" style="background:#f0f0f0;"|'''Priority'''<br />
| align="center" style="background:#f0f0f0;"|'''Status'''<br />
| align="center" style="background:#f0f0f0;"|'''Source'''<br />
| align="center" style="background:#f0f0f0;"|'''Owner'''<br />
| align="center" style="background:#f0f0f0;"|'''Due'''<br />
| align="center" style="background:#f0f0f0;"|'''Comments / Bugzilla Links'''<br />
|-<br />
| Web-based Image Creator||Create a web-based interface that does what the Image Creator does.||2.5||Review||LCS||Jason Kridner?||1.2||Yocto 1.2 - depends on Image Creator completing<br />
|-<br />
| Recipe-specific sysroot||||3||Review||from 1.0||Saul (Dongxiao)||1.2||Yocto 1.2 (1 month task)<br />
|-<br />
| Handle old versions in WORKDIR||||3||Review||from 1.0||||1.2||Yocto 1.2<br />
|-<br />
| Executable images||Create images that are executable - for example a pre-installed Ubuntu image with YP installed||3||Review||LCS||||1.2||Yocto 1.2<br />
|-<br />
| Self-hosting image||Create customizable chroot; Build an image that would be self-hosting||2.5||Review||LCS||||1.2||Yocto 1.2<br />
|-<br />
| Yocto OOPS-type messages||add the equivalent of kernel OOPS to Yocto||2.5||Review||LCS||||1.2||Yocto 1.2<br />
|-<br />
| Reduced depth revision history||Decrease the depth of the revision history||3||Review||LCS||||1.2||Yocto 1.2<br />
|-<br />
| Ability to archive work dir||Add the ability to archive the work directory to handle the GPL compliance issue.||3||Review||LCS||||1.2||Yocto 1.2, On Janitor\'s list<br />
|}<br />
<br />
== QA Items ==<br />
{| border="1"<br />
| align="center" style="background:#f0f0f0;"|'''Feature Name'''<br />
| align="center" style="background:#f0f0f0;"|'''Description'''<br />
| align="center" style="background:#f0f0f0;"|'''Priority'''<br />
| align="center" style="background:#f0f0f0;"|'''Status'''<br />
| align="center" style="background:#f0f0f0;"|'''Source'''<br />
| align="center" style="background:#f0f0f0;"|'''Owner'''<br />
| align="center" style="background:#f0f0f0;"|'''Due'''<br />
| align="center" style="background:#f0f0f0;"|'''Comments / Bugzilla Links'''<br />
|-<br />
| Patch Test System||Create a machine where developers can upload/test patches before submitting them to master to ensure builds won\'t break when patches are added. (developer autobuilders? Fuzz builds?)||2||Review||Team||Jiajun||1.2||<br />
|-<br />
| Open Source Test Cases||Perform technical, legal, and QA steps necessary to move test cases into open source.||3||Review||QA||||1.2||Yocto 1.2<br />
|-<br />
| Start a framework for automated BSP testing||Build-testing is only half the job of BSP testing, and new BSP development is and will be ramping up even more rapidly soon. We need to start building a framework to make as much of this as automated as possible. Phase I, what we can complete for 1.2, should be the ability to load an image from the autobuilder and make it ready for booting, or actually boot it, on a given target. It would be good to use systems running Yocto images as much as possible for this.||2||Review||Tom||||1.2||<br />
|-<br />
| Test framework||this is a test framework that we can include in the distribution||3||Review||RP Notes||||1.2||Yocto 1.2 - Is it the TI’s test framework we discussed before? A: Not necessarily, we\'re still waiting for someone to step up and really take ownership of this area but it needs some resource commitment as its not a simple task. <br />
|-<br />
| Package History||Write out data about the size of packages, their contents, dependencies, build time and so on allowing changes to be detected. One idea is we could do this in the form of a git repository||1||Review||RP||||1.2||Yocto 1.2<br />
|-<br />
| Package History Analysis Tool||Take the above data, highlight significant deltas and allow the user to confirm or red flag changes. Why did the package double in size? Why did some dependencies go missing? ||1||Review||RP||||1.2||Yocto 1.2<br />
|-<br />
| Extend current QA Tests||Automate some of the existing QA tests such as LSB, posix and rt tests||1||Review||RP||||1.2||Yocto 1.2<br />
|}<br />
<br />
== Meta Data ==<br />
{| border="1"<br />
| align="center" style="background:#f0f0f0;"|'''Feature Name'''<br />
| align="center" style="background:#f0f0f0;"|'''Description'''<br />
| align="center" style="background:#f0f0f0;"|'''Priority'''<br />
| align="center" style="background:#f0f0f0;"|'''Status'''<br />
| align="center" style="background:#f0f0f0;"|'''Source'''<br />
| align="center" style="background:#f0f0f0;"|'''Owner'''<br />
| align="center" style="background:#f0f0f0;"|'''Due'''<br />
| align="center" style="background:#f0f0f0;"|'''Comments / Bugzilla Links'''<br />
|-<br />
| Replacement for video/audio players currently in Yocto||Codec…||3||Review||Meta-data||||1.2||Yocto 1.2<br />
|-<br />
| Investigate New UI||For demos, we would like need a reference UI that is not Sato. Investigate possibilities that the Yocto team won\'t need to maintain. OpenBox? Gnome-desktop? GP? LXDE? KDE Mobile?||3||Review||Meta-data||||1.2||Yocto 1.2<br />
|-<br />
| Qemugl upstreaming||Opengl ES Support||3||Review||Meta-data||||1.2||Yocto 1.2<br />
|-<br />
| selinux patch integration||add SE Linux patches in a similar way to PAM||3||Review||Meta-data||||1.2||Yocto 1.2<br />
|-<br />
| build statistics reporting||As someone interested in how long it takes to build different images on different hardware configurations and other assorted build metrics, I would like a web based service, that takes output generated by an extended buildstats.bbclass and stores it, to compare against different machines. The end result should be a way to visualize the collected data. See: https://wiki.yoctoproject.org/wiki/Yocto_Buildbot_Autobuilder_Discussions||2||M3, Sprint A||eflanagan/Jay7/ka6sox||Beth/Jay||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| Framework to support multiple library versions co-existing||similar to recipe specific sysroot; needs documentation||3||Review||Team||Saul (Dongxiao?)||1.2||Yocto 1.2 - we just need to document how to use multiple versions of a library using clutter as the example<br />
|-<br />
| Embedded java environment or even JDK support||||3||Review||Team||||1.2||Yocto 1.2<br />
|-<br />
| Target module build||Allow for building kernel modules on the target device||2||Review||RP Notes||Darren||1.2||Yocto 1.2, On Janitor\'s list<br />
|-<br />
| gtk+ sato filechooser patch||||3||Review||RP Notes||||1.2||Yocto 1.2<br />
|-<br />
| sato refresh||||3||Review||RP Notes||||1.2||Yocto 1.2<br />
|-<br />
| Sanity checks on per recipe basis||||2||Accept||RP Notes Bug#405||Saul (Scott G)||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| perf scripting\' integration||Make it easy and convenient for the user to write and execute \'perf scripts\' from the IDE. We should be able to leverage and build on the Systemtap integration for this.||2||Dev||Tom||Jessica/Tom||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| Add Directfb(license LGPL) function||Directfb is more appropriate embedded device than other graphic software||3||Moved from M1||Meta-data||WR Distro team||1.2||Yocto 1.2, from 1.1<br />
|}<br />
<br />
== Autobuilder ==<br />
{| border="1"<br />
| align="center" style="background:#f0f0f0;"|'''Feature Name'''<br />
| align="center" style="background:#f0f0f0;"|'''Description'''<br />
| align="center" style="background:#f0f0f0;"|'''Priority'''<br />
| align="center" style="background:#f0f0f0;"|'''Status'''<br />
| align="center" style="background:#f0f0f0;"|'''Source'''<br />
| align="center" style="background:#f0f0f0;"|'''Owner'''<br />
| align="center" style="background:#f0f0f0;"|'''Due'''<br />
| align="center" style="background:#f0f0f0;"|'''Comments / Bugzilla Links'''<br />
|-<br />
| autobuilder layer support||||2||||Beth||Beth||1.2||2 weeks<br />
|-<br />
| autobuilder split of nightly (really an M4 task) few days license.bbclass refactor||||2||||Beth||Beth||1.2||1 week<br />
|-<br />
| buildstats memory measurements||||2||||Beth||Beth||1.2||1 week and half<br />
|-<br />
| license manifest||||2||||Beth||Beth||1.2||1 week<br />
|-<br />
| autobuilder release checkbox (running a yocto release right from the autobuilder)||||2||||Beth||Beth||1.2||2 weeks<br />
|}<br />
<br />
== BSPs ==<br />
{| border="1"<br />
| align="center" style="background:#f0f0f0;"|'''Feature Name'''<br />
| align="center" style="background:#f0f0f0;"|'''Description'''<br />
| align="center" style="background:#f0f0f0;"|'''Priority'''<br />
| align="center" style="background:#f0f0f0;"|'''Status'''<br />
| align="center" style="background:#f0f0f0;"|'''Source'''<br />
| align="center" style="background:#f0f0f0;"|'''Owner'''<br />
| align="center" style="background:#f0f0f0;"|'''Due'''<br />
| align="center" style="background:#f0f0f0;"|'''Comments / Bugzilla Links'''<br />
|-<br />
| AMT driver integration||incorporate Linux AMT into the Yocto BSPs||||||||||1.2||Intel<br />
|-<br />
| Zaurusd++ (devmand?)||I keep seeing changes to toggle certain features for various boards (audio on the beagleboard, N450 and spring to mind), rather than writing lots of recipes for this perhaps we could resurrect zaurusd and evolve it to reflect the projects original goals as devmand; a daemon to handle hardware quirks across a range of boards and devices. ||||||||||1.2||Joshua<br />
|-<br />
| BSP update/intro||determine and integrate / create arch reference BSPs (e500, Cortex, ARM, MIPs)||2||Dev||Bruce/Richard/team||Bruce||1.2||Yocto 1.2, from 1.1<br />
|- <br />
|Drop Grub for Syslinux || Grub is considerably more complicated than we need for any of our current BSPs. Syslinux can be used in place of every known usage of Grub. For upcoming EFI BSPs, we can look to Efilinux. This will reduce our bootloader maintenance burden and simplify our images. || 2 || Review || Darren || Darren || 1.2 ||<br />
|-<br />
|Integrate alsa-state || Remove all the BSP specific $MACHINE-audio recipes in favor of the more generic alsa-state mechanism in use by OE already. || 1 || Review || Darren || || 1.2 || This possibly conflicts with the item to refresh zaurusd.<br />
|-<br />
|Upgrade to EFI ||Where possible, update our existing BSPs to boot using EFI. This will support development of efilinux as well as help us prepare for the newer boards which will be EFI only. || 2 || Review || Darren || Darren || 1.2 ||<br />
|-<br />
|BSP/kernel wrappers/wizards || Create some simple scripts or 'wizards' that make it easy for users to start writing a new BSP and/or easily make simple kernel modifications to a BSP. Ideally, users shouldn't need to know anything low-level about the kernel, git, or the mechanics of appending config items to recipes in order to get a BSP up and running or to make the simple modifications needed to tweak or maintain it. || 2 || Review || tomz || tomz || 1.2 ||<br />
|}<br />
<br />
== ADT == <br />
{| border="1"<br />
| align="center" style="background:#f0f0f0;"|'''Feature Name'''<br />
| align="center" style="background:#f0f0f0;"|'''Description'''<br />
| align="center" style="background:#f0f0f0;"|'''Priority'''<br />
| align="center" style="background:#f0f0f0;"|'''Status'''<br />
| align="center" style="background:#f0f0f0;"|'''Source'''<br />
| align="center" style="background:#f0f0f0;"|'''Owner'''<br />
| align="center" style="background:#f0f0f0;"|'''Due'''<br />
| align="center" style="background:#f0f0f0;"|'''Comments / Bugzilla Links'''<br />
|-<br />
| Enhance the deploy part in remote debug||ADT is currently using org.eclipse.cdt.remote.launch for remote debug. One limitation in this plug-in is that it can only deploy one single file to the target during the debug. Though it is ok for debugging static linked program, debugging dynamic linked program might require deploying multiple files(including executables and libraries) to the target.||2||Review||Lianhao||Jessica||1.2||<br />
|-<br />
| Secure login||||2||Review||ADT Team||Jessica||1.2||Yocto 1.2<br />
|-<br />
| Linux tools upstream integration||There're some activities within the Eclipse Linux Tools community for various tools remote invocation improvement, we need to sync up with the community for their latest deliveries and make some contribution if possible ||2||Review||ADT Team||Jessica||1.2||Yocto 1.2<br />
|-<br />
| Add recipe supporting autoconf-nativesdk and automake-nativesdk ||The new libtool m4 macros(supporting --with-libtool-sysroot) resides in the directory where host aclocal can not find it by default. This requires the user to manually add that directory using -I options. Adding automake(autoconf)-nativesdk into meta-toolchain would help this. ||2||Review||Lianhao||||1.2||Yocto 1.2<br />
|-<br />
| Prebuit SDK integration||speedup target image generation by reusing prebuilt tools from SDK native and target binaries. See: http://wiki.secretlab.ca/Yocto_prebuilt_SDK_integration||2||Reject||Adrian||Jessica||1.2||Yocto 1.2 - This functionality looks to have been provided by sstate packages?<br />
|-<br />
|Eclipse BSP/Kernel Plugin || Provide an Eclipse plugin to facilitate configuring new BSPs and streamlining the linuix-yocto development workflow. || 2 || Review || Darren || || 1.2 ||<br />
<br />
|}<br />
<br />
== Documentation ==<br />
{| border="1"<br />
| align="center" style="background:#f0f0f0;"|'''Feature Name'''<br />
| align="center" style="background:#f0f0f0;"|'''Description'''<br />
| align="center" style="background:#f0f0f0;"|'''Priority'''<br />
| align="center" style="background:#f0f0f0;"|'''Status'''<br />
| align="center" style="background:#f0f0f0;"|'''Source'''<br />
| align="center" style="background:#f0f0f0;"|'''Owner'''<br />
| align="center" style="background:#f0f0f0;"|'''Due'''<br />
| align="center" style="background:#f0f0f0;"|'''Comments / Bugzilla Links'''<br />
|-<br />
| Various Demo Videos||The idea here is to create screen-capture type tutorials similar to what exists for the ADT Eclipse Plug-in. However, we want to contract out some help for professional voice-over talent to be used with the images. These don\'t have to be limited to screen-capture material but could include well-done PPT decks - similar to how other business units in Intel create various training modules. For 1.1 it would be good to capture the script for the existing ADT Eclipse Plug-in module and have it voiced over. Also, for 1.1 it would be good to create a similar module for the Image Creator application.||2||Not Started||From ADT module and scratch||ScottR||1.2||Q3 at the earliest<br />
|}<br />
<br />
== Performance & usability ==<br />
{| border="1"<br />
| align="center" style="background:#f0f0f0;"|'''Feature Name'''<br />
| align="center" style="background:#f0f0f0;"|'''Description'''<br />
| align="center" style="background:#f0f0f0;"|'''Priority'''<br />
| align="center" style="background:#f0f0f0;"|'''Status'''<br />
| align="center" style="background:#f0f0f0;"|'''Source'''<br />
| align="center" style="background:#f0f0f0;"|'''Owner'''<br />
| align="center" style="background:#f0f0f0;"|'''Due'''<br />
| align="center" style="background:#f0f0f0;"|'''Comments / Bugzilla Links'''<br />
|-<br />
| POSIX support||address POSIX failures found in 1.1||2||Review||Team||||1.2||Yocto 1.2, On Janitor\'s list<br />
|}<br />
<br />
<br />
== Kernel ==<br />
{| border="1"<br />
| align="center" style="background:#f0f0f0;"|'''Feature Name'''<br />
| align="center" style="background:#f0f0f0;"|'''Description'''<br />
| align="center" style="background:#f0f0f0;"|'''Priority'''<br />
| align="center" style="background:#f0f0f0;"|'''Status'''<br />
| align="center" style="background:#f0f0f0;"|'''Source'''<br />
| align="center" style="background:#f0f0f0;"|'''Owner'''<br />
| align="center" style="background:#f0f0f0;"|'''Due'''<br />
| align="center" style="background:#f0f0f0;"|'''Comments / Bugzilla Links'''<br />
|-<br />
| Minimal Image unique||make minimal image smaller||3||Accept||Team||WR Distro Team||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| Tracing: tuna, oscilloscope recipes||This might be more useful with the increased importance of RT||3||Review||from 1.0||||1.2||Yocto 1.2<br />
|-<br />
| Kernel Tools||Implement plan for kernel tools||2||Dev (20%)||Bruce/Mark||Bruce||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| use cases||BSP config streamlining, building the kernel standalone, yoctoization, meta data sharing||1||Accept||Bruce||Bruce||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| kernel bloat - development||target = boot a minimal image in < 8M - development complete||1||Dev||Darren||Darren||1.2||Yocto 1.2, from 1.1, continuation needed?<br />
|-<br />
| Fast boot time||2 second boot time target||1||Dev||Team||Darren||1.2||Yocto 1.2, from 1.1, continuation needed?<br />
|-<br />
|Upstream config fragments || Work with John Stultz to upstream a Linux kernel config fragment manager and rework the yocto-kernel-tools to use it. This will simplify our tooling and increase our usage/test base. || 1 || Review || Darren || || 1.2 ||<br />
|-<br />
|Real-time process-executed timers || Timers currently run at the priority of the softirq that processes them and they are accounted to whichever task was preempted for them to run. This negatively impacts determinism and accounting accuracy. || 2 || Review || Darren || || 1.2 ||<br />
|-<br />
|Define Kernel policy || We need to clearly document kernel policy and make the config fragments reflect it. This will facilitate a more modular approach to building BSP kernel configs, as well as make it clear what can be expected to be supported when running a "linux-yocto kernel". || 1 || Review || Darren || || 1.2 ||<br />
|}<br />
<br />
== Project-wide Features ==<br />
{| border="1"<br />
| align="center" style="background:#f0f0f0;"|'''Feature Name'''<br />
| align="center" style="background:#f0f0f0;"|'''Description'''<br />
| align="center" style="background:#f0f0f0;"|'''Priority'''<br />
| align="center" style="background:#f0f0f0;"|'''Status'''<br />
| align="center" style="background:#f0f0f0;"|'''Source'''<br />
| align="center" style="background:#f0f0f0;"|'''Owner'''<br />
| align="center" style="background:#f0f0f0;"|'''Due'''<br />
| align="center" style="background:#f0f0f0;"|'''Comments / Bugzilla Links'''<br />
|-<br />
| LayerTooling – remote layer tool||Consider integrating Jeremy Puhlman\'s remote layers patch||2||Community||Paul||1.2||||<br />
|-<br />
| running post installs at rootfs gen time||||2||Review||RP Notes||Saul (Dexuan)||1.2||<br />
|-<br />
| Clean up warning messages||A build that runs correctly to completion still includes a ton of WARNING messages. We need a project to clean these up. Beth will work on License Warnings, team will look at other logfile warnings||2||Review||Dave & RP||Saul||1.2||<br />
|-<br />
| Multi-lib - 11||Directly support multlibs within the toolchain itself [post 1.1] ||2||||RP||Ke||1.2||<br />
|-<br />
| Multi-lib - 8||Add support to RPM packaging backend to turn modified package names into true rpm multilib packages||1||||RP||Mark||1.2||<br />
|-<br />
| Multi-lib - 7||Investigate better TARGET_VENDOR handling for config.sub. Currently we can only have ARCH-VENDOR-linux where VENDOR cannot contain \"-\" but it might be possible to relax that constraint [not high priority]. ||2||Review||RP||Ke||1.2||<br />
|-<br />
| Multi-lib - 6||Create some \"standard\" multilib configurations (x86 32+64 bit)||1||Review||RP||Ke||1.2||<br />
|-<br />
| Patchwork||is it worth the overhead, are there alternatives||3||Review||RP Notes||||1.2||Yocto 1.2<br />
|-<br />
| Bugzilla to Wiki||Create a script which automatically populates and updates the Wiki based on changes in bugzilla.||2.5||Review||Darren||||1.2||Yocto 1.2<br />
|-<br />
| Sync qemugl with MeeGo - Implementation||sync qemugl with MeeGo is complete||2||Dev (70%)||Meta-data||Saul (Edwin)||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| Tracing/profiling HOWTOs||Create a document or extend the current Yocto tracing wiki page to explain in detail how to use all the tracing tools in Yocto. It should detail not only how to use each tool individually, but also how to use them in conjunction with each other, highlighting situations in which each is most useful. There should also be some extensive worked examples of real-life use-cases and how they could be investigated using the Yocto tracing/profiling tools.||2||Accept||Tom||Tom||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| Error handling in bitbake (Implementation): Stage 2||Performance improvement (gather input from community on use cases)||1||Dev||RP Notes||Saul (Scott G)||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| btrfs||Kernel enabling||2||Dev||Meta-data||Saul (Nitin)||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| replace qemuppc||||||||||Bruce||1.2||Come from bug 414<br />
|-<br />
| MeeGo GPLv2 Sync||compare with Yocto, sync any patches||2||Accept||RP Notes||Saul (Ke)||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| Package Documentation Audit: All recipes build||31 recipes were identified as not building during the package documentation audit done in M1, Sprint B. Those all need to build and we need to re-run a new package documentation audit.||2||Accept||Team||Scott G||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| Tracing: Systemtap usability in Yocto||Right now, there are instructions on the wiki on how to configure and use Systemtap with Yocto. While straightforward, they are tedious and unlikely to be useful to most people pressed for time. We need to make it easier to use - in addition to documentation/HOWTO tasks listed elsewhere on this page, we need to make it usable \'out of the box\' (i.e. outside of ADT) e.g. all paths and configuration handled via script or something similar||2||Accept||Tom||Tom||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| Tracing: create separate recipe for perf||Perf is currently built as part of the kernel build. If we want to make use of everything perf has to offer we should get rid of the dependency. For example, the kernel build shouldn\'t depend on libnewt, and x32 shouldn\'t have to deal with embedded Python||2||Review||Tom||Tom||1.2||<br />
|-<br />
| Tracing: perf trace scripting support||Basically this means allowing perf to be built with the Perl and Python bindings, which turned out to be a headache last time.||2||Dev (50%)||from 1.0||Tom||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| Monitor disk availability||Monitor disk availability and warn the user if it is running low. May only focus on a few directories, for example: poky/build and poky/build/downloads, this would solve the multiple mount point problem||2||Review||RP and Robert||WR Distro Team (Robert)||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| Ability to build SRPM||||3||Accept||RP Notes||Jeff Polk/Mark||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| Classes to help install binary packages||It\'s been suggested that it would be a useful feature to be able to easily take an RPM or similar containing a software binary from a 3rd party software vendor and integrate it into an image created by the build system.||2||Review||||||1.2||<br />
|-<br />
| Host intrusion prevention||We have Swabber but it\'s not integrated into our process. I believe this is because there are several recipes which don\'t work when run under strace with parallelisation. We should determine a path for inclusion of swabber into our process and execute on it so that we can be aware of, and fix, any host intrusion issues.||2||Review||||||1.2||<br />
|-<br />
| Security layer||Many of our users are likely to want to use kernel level security mechanisms and so I\'d like to investigate supporting one of the in-kernel LSM (Linux Security Modules), possibly SMACK as used in MeeGo, and adding policy to the oe-core metadata. The LSM, policy and user-space tools could all be enabled via a distro feature. This work may well want to be in a separate layer?||2||Review||Joshua||||1.2||<br />
|-<br />
| Factory reset||Implement a factory reset image feature. We\'ll use one of the union mount technologies (aufs/overlayfs/union mounts) to create an overlay on the file system as the final piece of rootfs creation. The overlaid file-system will be the target of all writes made to the image after the image is generated. A user-space mechanism to disable the overlay, and therefore reset to the state of the image just after it was created, will also be provided. This feature could be further enhanced by integrating with the package manager, and other user-space switches, to create system restore points which can later be rolled back to.||2||Review||Joshua||||1.2||<br />
|-<br />
| Gstreamer||Refactor gstreamer recipes to better support COMMERCIAL_LICENSE and enabling/disabling of various codecs and features||2||Review||||||1.2||http://bugzilla.pokylinux.org/show_bug.cgi?id=923<br />
|-<br />
| Init||Interest in systemd as a replacement for Sys V init is growing but it may not be appropriate for deeply embedded systems. I\'d like to investigate a crop of service based and process monitoring init systems and compare them on a variety of criteria as determined by the community. Furthermore I would like to investigate supporting multiple init systems, the current SysV system, systemd and possibly others. As part of this work, and because increasingly many upstreams support systemd (no doubt thanks to its adoption in Fedora) I would like to investigate implementing some infrastructure which translates from systemd units to the appropriate init format for the supported init systems.||2||Review||||||1.2||<br />
|-<br />
| Enhance Automated QA Tests||Add tests for the RT pieces, consider run-time security checking tools used by Fedora and Gentoo||2||Review||||||1.2||<br />
|-<br />
| Collect data at build time to increase accuracy of estimation (hob)||Collect data at build time to allow hob to: predict the size of the generated image, more accurately reflect the built image contents, etc. This will likely involve generating data on the autobuilder which the UI can fetch and consume (with local caching for offline usage)||2||Review||||||1.2||http://bugzilla.pokylinux.org/show_bug.cgi?id=1316<br />
|-<br />
| Finish and enable PR server||We\'re still seeing people being forced to cleansstate too often, we need to finish up and enable the PR server so the checksummed sstate future can live||2||Review||||||1.2||http://thread.gmane.org/gmane.comp.handhelds.openembedded.core/1272/focus=1357 http://thread.gmane.org/gmane.comp.handhelds.openembedded.core/835/focus=852<br />
|-<br />
| Provide a click through license mechanism||Implement the mechanism described in Section 1.2. BSP \'Click-Through\' Licensing Procedure in the BSP Developer\'s Guide||2||Review||Tom||Tom||1.2||<br />
|-<br />
| Finish Oracle/Sun Hotspot JDK/JRE support||I created an initial hack of a recipe for this for the demo - finish it up (involves licensing issues (click-through license support would be a prerequisite) as well)||2||Review||Tom||Tom||1.2||50% done already<br />
|- <br />
| BSPs or layers for a specific category of devices || This will demonstrate the value of Yocto to developers and help them get up to speed quicker for this category of devices. ||2||Review||Dirk/Dave/Andy||TBD||1.2||<br />
|- <br />
| enhance the bitbake commander eclipse plugin || By having the Eclipse as a frontend UI to bitbake server, eclipse may talk to bitbake server, enable the user to glimpse on the variables' values when editing the recipes, try out building the recipe being edited, etc. ||2||Review||Dongxiao/Lianhao||TBD||TBD|| This requires new features both in eclipse plugin and bitbake server.<br />
|- <br />
| Parallel Locale Generation || Add makefile to allow the locale generation to happen in parallel ||2||Review||RP||||||<br />
|- <br />
| Make BasicHash the default || We'd like to start adding the sstate signature to the stampfiles using the BasicHash signature generator and stop bumping PR values. This will require some additions to the PR server work we previously started||2||Review||RP||||||<br />
|- <br />
| Address git fetcher concerns || The community has raised some git fetcher concerns we should address||2||Review||RP||||||<br />
|}</div>Davesthttps://wiki.yoctoproject.org/wiki/index.php?title=Yocto_1.2_Features&diff=3550Yocto 1.2 Features2011-09-30T14:49:18Z<p>Davest: /* Yocto Project 1.2 Objectives */</p>
<hr />
<div>== Potential Yocto Project 1.2 Features ==<br />
Yocto Project 1.2 - Target release = April 2012<br />
<br />
== Yocto Project 1.2 Themes ==<br />
The topics below are the themes that some members of the team have started brainstorming for Yocto Project v1.2. These will be improved with community input.<br />
<br />
=== Yocto Project 1.2 Objectives ===<br />
The objectives of the Yocto 1.2 release are to increase adoption of the Yocto Project.<br />
<br />
=== Yocto Project 1.2 Theme List ===<br />
The Yocto Project 1.2 Themes towards the Objectives listed above are:<br />
<br />
* Theme 1<br />
* Theme 2<br />
* Theme 3<br />
<br />
== Process for Entering New Feature Requests ==<br />
<br />
* Create a new entry in the appropriate feature table below (Poky, SDK, Hardware)<br />
** Suggestion: start by copying an existing request as a template<br />
* Give the feature a short, descriptive name<br />
* Provide a one or two sentence brief description of the feature<br />
* Set the priority as appropriate (see the legend below)<br />
* Set the Status to "Review"<br />
* In the Source field, enter your name along with the origination of the request (e.g. OSV, OEM, Community) if applicable; provide as much detail here as you can<br />
* In the Comments / Bugzilla field, provide any additional information for the request, such as a link to a bugzilla entry<br />
* Preview your Entry to make sure it looks ok and then save it<br />
<br />
''Legend''<br />
<br />
'''Priority:''' 1 = Must Have, 2 = Nice to Have, 3 = Optional<br />
<br />
'''Status:''' Accept = Engineering agreement to include in release, Review = Under Review for Inclusion in this release, Reject = Will not be included in this release<br />
== Sample Table ==<br />
<br />
This is a sample table to show how to submit features.<br />
<br />
{| border="1"<br />
||'''Feature Name''' ||'''Description''' ||'''Priority''' ||'''Status''' ||'''Source''' ||'''Comments / Bugzilla Links'''<br />
|-<br />
||Placeholder feature name || Placeholder description of the feature || 1, 2, or 3 || Review|| name|| Comment<br />
|}<br />
<br />
== Usability ==<br />
{| border="1"<br />
| align="center" style="background:#f0f0f0;"|'''Feature Name'''<br />
| align="center" style="background:#f0f0f0;"|'''Description'''<br />
| align="center" style="background:#f0f0f0;"|'''Priority'''<br />
| align="center" style="background:#f0f0f0;"|'''Status'''<br />
| align="center" style="background:#f0f0f0;"|'''Source'''<br />
| align="center" style="background:#f0f0f0;"|'''Owner'''<br />
| align="center" style="background:#f0f0f0;"|'''Comments / Bugzilla Links'''<br />
|-<br />
| build appliance||Intended for developers to very easily "Check it out" and do a Yocto Project build with minimal pain. Should be a virtual image of a desktop OS which will boot into HOB and offer a terminal or an app to deploy resulting images to media or to run QEMU.||1||Review||davest/tracey/RP||TBD||See here for [[Build Appliance Design]]<br />
|-<br />
| Web Hob||Add a web interface for Hob, perhaps similar to SuSE Studio. This is for both local (non-network) builds as well as network. Would require us to have a web server package installed of course for local builds.||1||Review||davest/tracey/RP||TBD||xx<br />
|-<br />
| Hob improvements||Update Hob with performance improvements and improvements to package disabling||1||Review||davest/tracey/RP||TBD||xx<br />
|-<br />
| Support for non-developers||Create clear instructions for how a Windows user can take an example image from the YP web site and deploy it to a board. Assume no Linux knowledge. These instructions should be applicable in example images in BSPs ||1||Review||davest/tracey/RP||TBD||xx<br />
|-<br />
| Firewall / Proxy handling in git||Develop a git plugin which will fall back to tunneling through HTTP if the git:// interface will not work because it is blocked by a firewall and the correct proxy is not set up. ||1||Review||davest/tracey/RP||TBD||same for svn,hg,ftp,etc? -dvhart<br />
|-<br />
| Build Yocto behind firewall - implementation||||2||Dev||Dave||Darren/Joshua||Yocto 1.2, from 1.1, the above one seems to be part of this.<br />
|}<br />
<br />
== Core/Bitbake ==<br />
{| border="1"<br />
| align="center" style="background:#f0f0f0;"|'''Feature Name'''<br />
| align="center" style="background:#f0f0f0;"|'''Description'''<br />
| align="center" style="background:#f0f0f0;"|'''Priority'''<br />
| align="center" style="background:#f0f0f0;"|'''Status'''<br />
| align="center" style="background:#f0f0f0;"|'''Source'''<br />
| align="center" style="background:#f0f0f0;"|'''Owner'''<br />
| align="center" style="background:#f0f0f0;"|'''Due'''<br />
| align="center" style="background:#f0f0f0;"|'''Comments / Bugzilla Links'''<br />
|-<br />
| Web-based Image Creator||Create a web-based interface that does what the Image Creator does.||2.5||Review||LCS||Jason Kridner?||1.2||Yocto 1.2 - depends on Image Creator completing<br />
|-<br />
| Recipe-specific sysroot||||3||Review||from 1.0||Saul (Dongxiao)||1.2||Yocto 1.2 (1 month task)<br />
|-<br />
| Handle old versions in WORKDIR||||3||Review||from 1.0||||1.2||Yocto 1.2<br />
|-<br />
| Executable images||Create images that are executable - for example a pre-installed Ubuntu image with YP installed||3||Review||LCS||||1.2||Yocto 1.2<br />
|-<br />
| Self-hosting image||Create customizable chroot; Build an image that would be self-hosting||2.5||Review||LCS||||1.2||Yocto 1.2<br />
|-<br />
| Yocto OOPS-type messages||add the equivalent of kernel OOPS to Yocto||2.5||Review||LCS||||1.2||Yocto 1.2<br />
|-<br />
| Reduced depth revision history||Decrease the depth of the revision history||3||Review||LCS||||1.2||Yocto 1.2<br />
|-<br />
| Ability to archive work dir||Add the ability to archive the work directory to handle the GPL compliance issue.||3||Review||LCS||||1.2||Yocto 1.2, On Janitor\'s list<br />
|}<br />
<br />
== QA Items ==<br />
{| border="1"<br />
| align="center" style="background:#f0f0f0;"|'''Feature Name'''<br />
| align="center" style="background:#f0f0f0;"|'''Description'''<br />
| align="center" style="background:#f0f0f0;"|'''Priority'''<br />
| align="center" style="background:#f0f0f0;"|'''Status'''<br />
| align="center" style="background:#f0f0f0;"|'''Source'''<br />
| align="center" style="background:#f0f0f0;"|'''Owner'''<br />
| align="center" style="background:#f0f0f0;"|'''Due'''<br />
| align="center" style="background:#f0f0f0;"|'''Comments / Bugzilla Links'''<br />
|-<br />
| Patch Test System||Create a machine where developers can upload/test patches before submitting them to master to ensure builds won\'t break when patches are added. (developer autobuilders? Fuzz builds?)||2||Review||Team||Jiajun||1.2||<br />
|-<br />
| Open Source Test Cases||Perform technical, legal, and QA steps necessary to move test cases into open source.||3||Review||QA||||1.2||Yocto 1.2<br />
|-<br />
| Start a framework for automated BSP testing||Build-testing is only half the job of BSP testing, and new BSP development is and will be ramping up even more rapidly soon. We need to start building a framework to make as much of this as automated as possible. Phase I, what we can complete for 1.2, should be the ability to load an image from the autobuilder and make it ready for booting, or actually boot it, on a given target. It would be good to use systems running Yocto images as much as possible for this.||2||Review||Tom||||1.2||<br />
|-<br />
| Test framework||this is a test framework that we can include in the distribution||3||Review||RP Notes||||1.2||Yocto 1.2 - Is it the TI’s test framework we discussed before? A: Not necessarily, we\'re still waiting for someone to step up and really take ownership of this area but it needs some resource commitment as its not a simple task. <br />
|-<br />
| Package History||Write out data about the size of packages, their contents, dependencies, build time and so on allowing changes to be detected. One idea is we could do this in the form of a git repository||1||Review||RP||||1.2||Yocto 1.2<br />
|-<br />
| Package History Analysis Tool||Take the above data, highlight significant deltas and allow the user to confirm or red flag changes. Why did the package double in size? Why did some dependencies go missing? ||1||Review||RP||||1.2||Yocto 1.2<br />
|-<br />
| Extend current QA Tests||Automate some of the existing QA tests such as LSB, posix and rt tests||1||Review||RP||||1.2||Yocto 1.2<br />
|}<br />
<br />
== Meta Data ==<br />
{| border="1"<br />
| align="center" style="background:#f0f0f0;"|'''Feature Name'''<br />
| align="center" style="background:#f0f0f0;"|'''Description'''<br />
| align="center" style="background:#f0f0f0;"|'''Priority'''<br />
| align="center" style="background:#f0f0f0;"|'''Status'''<br />
| align="center" style="background:#f0f0f0;"|'''Source'''<br />
| align="center" style="background:#f0f0f0;"|'''Owner'''<br />
| align="center" style="background:#f0f0f0;"|'''Due'''<br />
| align="center" style="background:#f0f0f0;"|'''Comments / Bugzilla Links'''<br />
|-<br />
| Replacement for video/audio players currently in Yocto||Codec…||3||Review||Meta-data||||1.2||Yocto 1.2<br />
|-<br />
| Investigate New UI||For demos, we would like need a reference UI that is not Sato. Investigate possibilities that the Yocto team won\'t need to maintain. OpenBox? Gnome-desktop? GP? LXDE? KDE Mobile?||3||Review||Meta-data||||1.2||Yocto 1.2<br />
|-<br />
| Qemugl upstreaming||Opengl ES Support||3||Review||Meta-data||||1.2||Yocto 1.2<br />
|-<br />
| selinux patch integration||add SE Linux patches in a similar way to PAM||3||Review||Meta-data||||1.2||Yocto 1.2<br />
|-<br />
| build statistics reporting||As someone interested in how long it takes to build different images on different hardware configurations and other assorted build metrics, I would like a web based service, that takes output generated by an extended buildstats.bbclass and stores it, to compare against different machines. The end result should be a way to visualize the collected data. See: https://wiki.yoctoproject.org/wiki/Yocto_Buildbot_Autobuilder_Discussions||2||M3, Sprint A||eflanagan/Jay7/ka6sox||Beth/Jay||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| Framework to support multiple library versions co-existing||similar to recipe specific sysroot; needs documentation||3||Review||Team||Saul (Dongxiao?)||1.2||Yocto 1.2 - we just need to document how to use multiple versions of a library using clutter as the example<br />
|-<br />
| Embedded java environment or even JDK support||||3||Review||Team||||1.2||Yocto 1.2<br />
|-<br />
| Target module build||Allow for building kernel modules on the target device||2||Review||RP Notes||Darren||1.2||Yocto 1.2, On Janitor\'s list<br />
|-<br />
| gtk+ sato filechooser patch||||3||Review||RP Notes||||1.2||Yocto 1.2<br />
|-<br />
| sato refresh||||3||Review||RP Notes||||1.2||Yocto 1.2<br />
|-<br />
| Sanity checks on per recipe basis||||2||Accept||RP Notes Bug#405||Saul (Scott G)||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| perf scripting\' integration||Make it easy and convenient for the user to write and execute \'perf scripts\' from the IDE. We should be able to leverage and build on the Systemtap integration for this.||2||Dev||Tom||Jessica/Tom||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| Add Directfb(license LGPL) function||Directfb is more appropriate embedded device than other graphic software||3||Moved from M1||Meta-data||WR Distro team||1.2||Yocto 1.2, from 1.1<br />
|}<br />
<br />
== Autobuilder ==<br />
{| border="1"<br />
| align="center" style="background:#f0f0f0;"|'''Feature Name'''<br />
| align="center" style="background:#f0f0f0;"|'''Description'''<br />
| align="center" style="background:#f0f0f0;"|'''Priority'''<br />
| align="center" style="background:#f0f0f0;"|'''Status'''<br />
| align="center" style="background:#f0f0f0;"|'''Source'''<br />
| align="center" style="background:#f0f0f0;"|'''Owner'''<br />
| align="center" style="background:#f0f0f0;"|'''Due'''<br />
| align="center" style="background:#f0f0f0;"|'''Comments / Bugzilla Links'''<br />
|-<br />
| autobuilder layer support||||2||||Beth||Beth||1.2||2 weeks<br />
|-<br />
| autobuilder split of nightly (really an M4 task) few days license.bbclass refactor||||2||||Beth||Beth||1.2||1 week<br />
|-<br />
| buildstats memory measurements||||2||||Beth||Beth||1.2||1 week and half<br />
|-<br />
| license manifest||||2||||Beth||Beth||1.2||1 week<br />
|-<br />
| autobuilder release checkbox (running a yocto release right from the autobuilder)||||2||||Beth||Beth||1.2||2 weeks<br />
|}<br />
<br />
== BSPs ==<br />
{| border="1"<br />
| align="center" style="background:#f0f0f0;"|'''Feature Name'''<br />
| align="center" style="background:#f0f0f0;"|'''Description'''<br />
| align="center" style="background:#f0f0f0;"|'''Priority'''<br />
| align="center" style="background:#f0f0f0;"|'''Status'''<br />
| align="center" style="background:#f0f0f0;"|'''Source'''<br />
| align="center" style="background:#f0f0f0;"|'''Owner'''<br />
| align="center" style="background:#f0f0f0;"|'''Due'''<br />
| align="center" style="background:#f0f0f0;"|'''Comments / Bugzilla Links'''<br />
|-<br />
| AMT driver integration||incorporate Linux AMT into the Yocto BSPs||||||||||1.2||Intel<br />
|-<br />
| Zaurusd++ (devmand?)||I keep seeing changes to toggle certain features for various boards (audio on the beagleboard, N450 and spring to mind), rather than writing lots of recipes for this perhaps we could resurrect zaurusd and evolve it to reflect the projects original goals as devmand; a daemon to handle hardware quirks across a range of boards and devices. ||||||||||1.2||Joshua<br />
|-<br />
| BSP update/intro||determine and integrate / create arch reference BSPs (e500, Cortex, ARM, MIPs)||2||Dev||Bruce/Richard/team||Bruce||1.2||Yocto 1.2, from 1.1<br />
|- <br />
|Drop Grub for Syslinux || Grub is considerably more complicated than we need for any of our current BSPs. Syslinux can be used in place of every known usage of Grub. For upcoming EFI BSPs, we can look to Efilinux. This will reduce our bootloader maintenance burden and simplify our images. || 2 || Review || Darren || Darren || 1.2 ||<br />
|-<br />
|Integrate alsa-state || Remove all the BSP specific $MACHINE-audio recipes in favor of the more generic alsa-state mechanism in use by OE already. || 1 || Review || Darren || || 1.2 || This possibly conflicts with the item to refresh zaurusd.<br />
|-<br />
|Upgrade to EFI ||Where possible, update our existing BSPs to boot using EFI. This will support development of efilinux as well as help us prepare for the newer boards which will be EFI only. || 2 || Review || Darren || Darren || 1.2 ||<br />
|-<br />
|BSP/kernel wrappers/wizards || Create some simple scripts or 'wizards' that make it easy for users to start writing a new BSP and/or easily make simple kernel modifications to a BSP. Ideally, users shouldn't need to know anything low-level about the kernel, git, or the mechanics of appending config items to recipes in order to get a BSP up and running or to make the simple modifications needed to tweak or maintain it. || 2 || Review || tomz || tomz || 1.2 ||<br />
|}<br />
<br />
== ADT == <br />
{| border="1"<br />
| align="center" style="background:#f0f0f0;"|'''Feature Name'''<br />
| align="center" style="background:#f0f0f0;"|'''Description'''<br />
| align="center" style="background:#f0f0f0;"|'''Priority'''<br />
| align="center" style="background:#f0f0f0;"|'''Status'''<br />
| align="center" style="background:#f0f0f0;"|'''Source'''<br />
| align="center" style="background:#f0f0f0;"|'''Owner'''<br />
| align="center" style="background:#f0f0f0;"|'''Due'''<br />
| align="center" style="background:#f0f0f0;"|'''Comments / Bugzilla Links'''<br />
|-<br />
| Enhance the deploy part in remote debug||ADT is currently using org.eclipse.cdt.remote.launch for remote debug. One limitation in this plug-in is that it can only deploy one single file to the target during the debug. Though it is ok for debugging static linked program, debugging dynamic linked program might require deploying multiple files(including executables and libraries) to the target.||2||Review||Lianhao||Jessica||1.2||<br />
|-<br />
| Secure login||||2||Review||ADT Team||Jessica||1.2||Yocto 1.2<br />
|-<br />
| Linux tools upstream integration||There're some activities within the Eclipse Linux Tools community for various tools remote invocation improvement, we need to sync up with the community for their latest deliveries and make some contribution if possible ||2||Review||ADT Team||Jessica||1.2||Yocto 1.2<br />
|-<br />
| Add recipe supporting autoconf-nativesdk and automake-nativesdk ||The new libtool m4 macros(supporting --with-libtool-sysroot) resides in the directory where host aclocal can not find it by default. This requires the user to manually add that directory using -I options. Adding automake(autoconf)-nativesdk into meta-toolchain would help this. ||2||Review||Lianhao||||1.2||Yocto 1.2<br />
|-<br />
| Prebuit SDK integration||speedup target image generation by reusing prebuilt tools from SDK native and target binaries. See: http://wiki.secretlab.ca/Yocto_prebuilt_SDK_integration||2||Reject||Adrian||Jessica||1.2||Yocto 1.2 - This functionality looks to have been provided by sstate packages?<br />
|-<br />
|Eclipse BSP/Kernel Plugin || Provide an Eclipse plugin to facilitate configuring new BSPs and streamlining the linuix-yocto development workflow. || 2 || Review || Darren || || 1.2 ||<br />
<br />
|}<br />
<br />
== Documentation ==<br />
{| border="1"<br />
| align="center" style="background:#f0f0f0;"|'''Feature Name'''<br />
| align="center" style="background:#f0f0f0;"|'''Description'''<br />
| align="center" style="background:#f0f0f0;"|'''Priority'''<br />
| align="center" style="background:#f0f0f0;"|'''Status'''<br />
| align="center" style="background:#f0f0f0;"|'''Source'''<br />
| align="center" style="background:#f0f0f0;"|'''Owner'''<br />
| align="center" style="background:#f0f0f0;"|'''Due'''<br />
| align="center" style="background:#f0f0f0;"|'''Comments / Bugzilla Links'''<br />
|-<br />
| Various Demo Videos||The idea here is to create screen-capture type tutorials similar to what exists for the ADT Eclipse Plug-in. However, we want to contract out some help for professional voice-over talent to be used with the images. These don\'t have to be limited to screen-capture material but could include well-done PPT decks - similar to how other business units in Intel create various training modules. For 1.1 it would be good to capture the script for the existing ADT Eclipse Plug-in module and have it voiced over. Also, for 1.1 it would be good to create a similar module for the Image Creator application.||2||Not Started||From ADT module and scratch||ScottR||1.2||Q3 at the earliest<br />
|}<br />
<br />
== Performance & usability ==<br />
{| border="1"<br />
| align="center" style="background:#f0f0f0;"|'''Feature Name'''<br />
| align="center" style="background:#f0f0f0;"|'''Description'''<br />
| align="center" style="background:#f0f0f0;"|'''Priority'''<br />
| align="center" style="background:#f0f0f0;"|'''Status'''<br />
| align="center" style="background:#f0f0f0;"|'''Source'''<br />
| align="center" style="background:#f0f0f0;"|'''Owner'''<br />
| align="center" style="background:#f0f0f0;"|'''Due'''<br />
| align="center" style="background:#f0f0f0;"|'''Comments / Bugzilla Links'''<br />
|-<br />
| POSIX support||address POSIX failures found in 1.1||2||Review||Team||||1.2||Yocto 1.2, On Janitor\'s list<br />
|}<br />
<br />
<br />
== Kernel ==<br />
{| border="1"<br />
| align="center" style="background:#f0f0f0;"|'''Feature Name'''<br />
| align="center" style="background:#f0f0f0;"|'''Description'''<br />
| align="center" style="background:#f0f0f0;"|'''Priority'''<br />
| align="center" style="background:#f0f0f0;"|'''Status'''<br />
| align="center" style="background:#f0f0f0;"|'''Source'''<br />
| align="center" style="background:#f0f0f0;"|'''Owner'''<br />
| align="center" style="background:#f0f0f0;"|'''Due'''<br />
| align="center" style="background:#f0f0f0;"|'''Comments / Bugzilla Links'''<br />
|-<br />
| Minimal Image unique||make minimal image smaller||3||Accept||Team||WR Distro Team||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| Tracing: tuna, oscilloscope recipes||This might be more useful with the increased importance of RT||3||Review||from 1.0||||1.2||Yocto 1.2<br />
|-<br />
| Kernel Tools||Implement plan for kernel tools||2||Dev (20%)||Bruce/Mark||Bruce||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| use cases||BSP config streamlining, building the kernel standalone, yoctoization, meta data sharing||1||Accept||Bruce||Bruce||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| kernel bloat - development||target = boot a minimal image in < 8M - development complete||1||Dev||Darren||Darren||1.2||Yocto 1.2, from 1.1, continuation needed?<br />
|-<br />
| Fast boot time||2 second boot time target||1||Dev||Team||Darren||1.2||Yocto 1.2, from 1.1, continuation needed?<br />
|-<br />
|Upstream config fragments || Work with John Stultz to upstream a Linux kernel config fragment manager and rework the yocto-kernel-tools to use it. This will simplify our tooling and increase our usage/test base. || 1 || Review || Darren || || 1.2 ||<br />
|-<br />
|Real-time process-executed timers || Timers currently run at the priority of the softirq that processes them and they are accounted to whichever task was preempted for them to run. This negatively impacts determinism and accounting accuracy. || 2 || Review || Darren || || 1.2 ||<br />
|-<br />
|Define Kernel policy || We need to clearly document kernel policy and make the config fragments reflect it. This will facilitate a more modular approach to building BSP kernel configs, as well as make it clear what can be expected to be supported when running a "linux-yocto kernel". || 1 || Review || Darren || || 1.2 ||<br />
|}<br />
<br />
== Project-wide Features ==<br />
{| border="1"<br />
| align="center" style="background:#f0f0f0;"|'''Feature Name'''<br />
| align="center" style="background:#f0f0f0;"|'''Description'''<br />
| align="center" style="background:#f0f0f0;"|'''Priority'''<br />
| align="center" style="background:#f0f0f0;"|'''Status'''<br />
| align="center" style="background:#f0f0f0;"|'''Source'''<br />
| align="center" style="background:#f0f0f0;"|'''Owner'''<br />
| align="center" style="background:#f0f0f0;"|'''Due'''<br />
| align="center" style="background:#f0f0f0;"|'''Comments / Bugzilla Links'''<br />
|-<br />
| LayerTooling – remote layer tool||Consider integrating Jeremy Puhlman\'s remote layers patch||2||Community||Paul||1.2||||<br />
|-<br />
| running post installs at rootfs gen time||||2||Review||RP Notes||Saul (Dexuan)||1.2||<br />
|-<br />
| Clean up warning messages||A build that runs correctly to completion still includes a ton of WARNING messages. We need a project to clean these up. Beth will work on License Warnings, team will look at other logfile warnings||2||Review||Dave & RP||Saul||1.2||<br />
|-<br />
| Multi-lib - 11||Directly support multlibs within the toolchain itself [post 1.1] ||2||||RP||Ke||1.2||<br />
|-<br />
| Multi-lib - 8||Add support to RPM packaging backend to turn modified package names into true rpm multilib packages||1||||RP||Mark||1.2||<br />
|-<br />
| Multi-lib - 7||Investigate better TARGET_VENDOR handling for config.sub. Currently we can only have ARCH-VENDOR-linux where VENDOR cannot contain \"-\" but it might be possible to relax that constraint [not high priority]. ||2||Review||RP||Ke||1.2||<br />
|-<br />
| Multi-lib - 6||Create some \"standard\" multilib configurations (x86 32+64 bit)||1||Review||RP||Ke||1.2||<br />
|-<br />
| Patchwork||is it worth the overhead, are there alternatives||3||Review||RP Notes||||1.2||Yocto 1.2<br />
|-<br />
| Bugzilla to Wiki||Create a script which automatically populates and updates the Wiki based on changes in bugzilla.||2.5||Review||Darren||||1.2||Yocto 1.2<br />
|-<br />
| Sync qemugl with MeeGo - Implementation||sync qemugl with MeeGo is complete||2||Dev (70%)||Meta-data||Saul (Edwin)||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| Tracing/profiling HOWTOs||Create a document or extend the current Yocto tracing wiki page to explain in detail how to use all the tracing tools in Yocto. It should detail not only how to use each tool individually, but also how to use them in conjunction with each other, highlighting situations in which each is most useful. There should also be some extensive worked examples of real-life use-cases and how they could be investigated using the Yocto tracing/profiling tools.||2||Accept||Tom||Tom||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| Error handling in bitbake (Implementation): Stage 2||Performance improvement (gather input from community on use cases)||1||Dev||RP Notes||Saul (Scott G)||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| btrfs||Kernel enabling||2||Dev||Meta-data||Saul (Nitin)||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| replace qemuppc||||||||||Bruce||1.2||Come from bug 414<br />
|-<br />
| MeeGo GPLv2 Sync||compare with Yocto, sync any patches||2||Accept||RP Notes||Saul (Ke)||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| Package Documentation Audit: All recipes build||31 recipes were identified as not building during the package documentation audit done in M1, Sprint B. Those all need to build and we need to re-run a new package documentation audit.||2||Accept||Team||Scott G||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| Tracing: Systemtap usability in Yocto||Right now, there are instructions on the wiki on how to configure and use Systemtap with Yocto. While straightforward, they are tedious and unlikely to be useful to most people pressed for time. We need to make it easier to use - in addition to documentation/HOWTO tasks listed elsewhere on this page, we need to make it usable \'out of the box\' (i.e. outside of ADT) e.g. all paths and configuration handled via script or something similar||2||Accept||Tom||Tom||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| Tracing: create separate recipe for perf||Perf is currently built as part of the kernel build. If we want to make use of everything perf has to offer we should get rid of the dependency. For example, the kernel build shouldn\'t depend on libnewt, and x32 shouldn\'t have to deal with embedded Python||2||Review||Tom||Tom||1.2||<br />
|-<br />
| Tracing: perf trace scripting support||Basically this means allowing perf to be built with the Perl and Python bindings, which turned out to be a headache last time.||2||Dev (50%)||from 1.0||Tom||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| Monitor disk availability||Monitor disk availability and warn the user if it is running low. May only focus on a few directories, for example: poky/build and poky/build/downloads, this would solve the multiple mount point problem||2||Review||RP and Robert||WR Distro Team (Robert)||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| Ability to build SRPM||||3||Accept||RP Notes||Jeff Polk/Mark||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| Classes to help install binary packages||It\'s been suggested that it would be a useful feature to be able to easily take an RPM or similar containing a software binary from a 3rd party software vendor and integrate it into an image created by the build system.||2||Review||||||1.2||<br />
|-<br />
| Host intrusion prevention||We have Swabber but it\'s not integrated into our process. I believe this is because there are several recipes which don\'t work when run under strace with parallelisation. We should determine a path for inclusion of swabber into our process and execute on it so that we can be aware of, and fix, any host intrusion issues.||2||Review||||||1.2||<br />
|-<br />
| Security layer||Many of our users are likely to want to use kernel level security mechanisms and so I\'d like to investigate supporting one of the in-kernel LSM (Linux Security Modules), possibly SMACK as used in MeeGo, and adding policy to the oe-core metadata. The LSM, policy and user-space tools could all be enabled via a distro feature. This work may well want to be in a separate layer?||2||Review||Joshua||||1.2||<br />
|-<br />
| Factory reset||Implement a factory reset image feature. We\'ll use one of the union mount technologies (aufs/overlayfs/union mounts) to create an overlay on the file system as the final piece of rootfs creation. The overlaid file-system will be the target of all writes made to the image after the image is generated. A user-space mechanism to disable the overlay, and therefore reset to the state of the image just after it was created, will also be provided. This feature could be further enhanced by integrating with the package manager, and other user-space switches, to create system restore points which can later be rolled back to.||2||Review||Joshua||||1.2||<br />
|-<br />
| Gstreamer||Refactor gstreamer recipes to better support COMMERCIAL_LICENSE and enabling/disabling of various codecs and features||2||Review||||||1.2||http://bugzilla.pokylinux.org/show_bug.cgi?id=923<br />
|-<br />
| Init||Interest in systemd as a replacement for Sys V init is growing but it may not be appropriate for deeply embedded systems. I\'d like to investigate a crop of service based and process monitoring init systems and compare them on a variety of criteria as determined by the community. Furthermore I would like to investigate supporting multiple init systems, the current SysV system, systemd and possibly others. As part of this work, and because increasingly many upstreams support systemd (no doubt thanks to its adoption in Fedora) I would like to investigate implementing some infrastructure which translates from systemd units to the appropriate init format for the supported init systems.||2||Review||||||1.2||<br />
|-<br />
| Enhance Automated QA Tests||Add tests for the RT pieces, consider run-time security checking tools used by Fedora and Gentoo||2||Review||||||1.2||<br />
|-<br />
| Collect data at build time to increase accuracy of estimation (hob)||Collect data at build time to allow hob to: predict the size of the generated image, more accurately reflect the built image contents, etc. This will likely involve generating data on the autobuilder which the UI can fetch and consume (with local caching for offline usage)||2||Review||||||1.2||http://bugzilla.pokylinux.org/show_bug.cgi?id=1316<br />
|-<br />
| Finish and enable PR server||We\'re still seeing people being forced to cleansstate too often, we need to finish up and enable the PR server so the checksummed sstate future can live||2||Review||||||1.2||http://thread.gmane.org/gmane.comp.handhelds.openembedded.core/1272/focus=1357 http://thread.gmane.org/gmane.comp.handhelds.openembedded.core/835/focus=852<br />
|-<br />
| Provide a click through license mechanism||Implement the mechanism described in Section 1.2. BSP \'Click-Through\' Licensing Procedure in the BSP Developer\'s Guide||2||Review||Tom||Tom||1.2||<br />
|-<br />
| Finish Oracle/Sun Hotspot JDK/JRE support||I created an initial hack of a recipe for this for the demo - finish it up (involves licensing issues (click-through license support would be a prerequisite) as well)||2||Review||Tom||Tom||1.2||50% done already<br />
|- <br />
| BSPs or layers for a specific category of devices || This will demonstrate the value of Yocto to developers and help them get up to speed quicker for this category of devices. ||2||Review||Dirk/Dave/Andy||TBD||1.2||<br />
|- <br />
| enhance the bitbake commander eclipse plugin || By having the Eclipse as a frontend UI to bitbake server, eclipse may talk to bitbake server, enable the user to glimpse on the variables' values when editing the recipes, try out building the recipe being edited, etc. ||2||Review||Dongxiao/Lianhao||TBD||TBD|| This requires new features both in eclipse plugin and bitbake server.<br />
|- <br />
| Parallel Locale Generation || Add makefile to allow the locale generation to happen in parallel ||2||Review||RP||||||<br />
|- <br />
| Make BasicHash the default || We'd like to start adding the sstate signature to the stampfiles using the BasicHash signature generator and stop bumping PR values. This will require some additions to the PR server work we previously started||2||Review||RP||||||<br />
|- <br />
| Address git fetcher concerns || The community has raised some git fetcher concerns we should address||2||Review||RP||||||<br />
|}</div>Davesthttps://wiki.yoctoproject.org/wiki/index.php?title=Yocto_1.2_Features&diff=3549Yocto 1.2 Features2011-09-30T14:47:37Z<p>Davest: /* Yocto Project 1.2 Objectives */</p>
<hr />
<div>== Potential Yocto Project 1.2 Features ==<br />
Yocto Project 1.2 - Target release = April 2012<br />
<br />
== Yocto Project 1.2 Themes ==<br />
The topics below are the themes that some members of the team have started brainstorming for Yocto Project v1.2. These will be improved with community input.<br />
<br />
=== Yocto Project 1.2 Objectives ===<br />
The objectives of the Yocto 1.2 release are to<br />
<br />
=== Yocto Project 1.2 Theme List ===<br />
The Yocto Project 1.2 Themes towards the Objectives listed above are:<br />
<br />
* Theme 1<br />
* Theme 2<br />
* Theme 3<br />
<br />
== Process for Entering New Feature Requests ==<br />
<br />
* Create a new entry in the appropriate feature table below (Poky, SDK, Hardware)<br />
** Suggestion: start by copying an existing request as a template<br />
* Give the feature a short, descriptive name<br />
* Provide a one or two sentence brief description of the feature<br />
* Set the priority as appropriate (see the legend below)<br />
* Set the Status to "Review"<br />
* In the Source field, enter your name along with the origination of the request (e.g. OSV, OEM, Community) if applicable; provide as much detail here as you can<br />
* In the Comments / Bugzilla field, provide any additional information for the request, such as a link to a bugzilla entry<br />
* Preview your Entry to make sure it looks ok and then save it<br />
<br />
''Legend''<br />
<br />
'''Priority:''' 1 = Must Have, 2 = Nice to Have, 3 = Optional<br />
<br />
'''Status:''' Accept = Engineering agreement to include in release, Review = Under Review for Inclusion in this release, Reject = Will not be included in this release<br />
== Sample Table ==<br />
<br />
This is a sample table to show how to submit features.<br />
<br />
{| border="1"<br />
||'''Feature Name''' ||'''Description''' ||'''Priority''' ||'''Status''' ||'''Source''' ||'''Comments / Bugzilla Links'''<br />
|-<br />
||Placeholder feature name || Placeholder description of the feature || 1, 2, or 3 || Review|| name|| Comment<br />
|}<br />
<br />
== Usability ==<br />
{| border="1"<br />
| align="center" style="background:#f0f0f0;"|'''Feature Name'''<br />
| align="center" style="background:#f0f0f0;"|'''Description'''<br />
| align="center" style="background:#f0f0f0;"|'''Priority'''<br />
| align="center" style="background:#f0f0f0;"|'''Status'''<br />
| align="center" style="background:#f0f0f0;"|'''Source'''<br />
| align="center" style="background:#f0f0f0;"|'''Owner'''<br />
| align="center" style="background:#f0f0f0;"|'''Comments / Bugzilla Links'''<br />
|-<br />
| build appliance||Intended for developers to very easily "Check it out" and do a Yocto Project build with minimal pain. Should be a virtual image of a desktop OS which will boot into HOB and offer a terminal or an app to deploy resulting images to media or to run QEMU.||1||Review||davest/tracey/RP||TBD||See here for [[Build Appliance Design]]<br />
|-<br />
| Web Hob||Add a web interface for Hob, perhaps similar to SuSE Studio. This is for both local (non-network) builds as well as network. Would require us to have a web server package installed of course for local builds.||1||Review||davest/tracey/RP||TBD||xx<br />
|-<br />
| Hob improvements||Update Hob with performance improvements and improvements to package disabling||1||Review||davest/tracey/RP||TBD||xx<br />
|-<br />
| Support for non-developers||Create clear instructions for how a Windows user can take an example image from the YP web site and deploy it to a board. Assume no Linux knowledge. These instructions should be applicable in example images in BSPs ||1||Review||davest/tracey/RP||TBD||xx<br />
|-<br />
| Firewall / Proxy handling in git||Develop a git plugin which will fall back to tunneling through HTTP if the git:// interface will not work because it is blocked by a firewall and the correct proxy is not set up. ||1||Review||davest/tracey/RP||TBD||same for svn,hg,ftp,etc? -dvhart<br />
|-<br />
| Build Yocto behind firewall - implementation||||2||Dev||Dave||Darren/Joshua||Yocto 1.2, from 1.1, the above one seems to be part of this.<br />
|}<br />
<br />
== Core/Bitbake ==<br />
{| border="1"<br />
| align="center" style="background:#f0f0f0;"|'''Feature Name'''<br />
| align="center" style="background:#f0f0f0;"|'''Description'''<br />
| align="center" style="background:#f0f0f0;"|'''Priority'''<br />
| align="center" style="background:#f0f0f0;"|'''Status'''<br />
| align="center" style="background:#f0f0f0;"|'''Source'''<br />
| align="center" style="background:#f0f0f0;"|'''Owner'''<br />
| align="center" style="background:#f0f0f0;"|'''Due'''<br />
| align="center" style="background:#f0f0f0;"|'''Comments / Bugzilla Links'''<br />
|-<br />
| Web-based Image Creator||Create a web-based interface that does what the Image Creator does.||2.5||Review||LCS||Jason Kridner?||1.2||Yocto 1.2 - depends on Image Creator completing<br />
|-<br />
| Recipe-specific sysroot||||3||Review||from 1.0||Saul (Dongxiao)||1.2||Yocto 1.2 (1 month task)<br />
|-<br />
| Handle old versions in WORKDIR||||3||Review||from 1.0||||1.2||Yocto 1.2<br />
|-<br />
| Executable images||Create images that are executable - for example a pre-installed Ubuntu image with YP installed||3||Review||LCS||||1.2||Yocto 1.2<br />
|-<br />
| Self-hosting image||Create customizable chroot; Build an image that would be self-hosting||2.5||Review||LCS||||1.2||Yocto 1.2<br />
|-<br />
| Yocto OOPS-type messages||add the equivalent of kernel OOPS to Yocto||2.5||Review||LCS||||1.2||Yocto 1.2<br />
|-<br />
| Reduced depth revision history||Decrease the depth of the revision history||3||Review||LCS||||1.2||Yocto 1.2<br />
|-<br />
| Ability to archive work dir||Add the ability to archive the work directory to handle the GPL compliance issue.||3||Review||LCS||||1.2||Yocto 1.2, On Janitor\'s list<br />
|}<br />
<br />
== QA Items ==<br />
{| border="1"<br />
| align="center" style="background:#f0f0f0;"|'''Feature Name'''<br />
| align="center" style="background:#f0f0f0;"|'''Description'''<br />
| align="center" style="background:#f0f0f0;"|'''Priority'''<br />
| align="center" style="background:#f0f0f0;"|'''Status'''<br />
| align="center" style="background:#f0f0f0;"|'''Source'''<br />
| align="center" style="background:#f0f0f0;"|'''Owner'''<br />
| align="center" style="background:#f0f0f0;"|'''Due'''<br />
| align="center" style="background:#f0f0f0;"|'''Comments / Bugzilla Links'''<br />
|-<br />
| Patch Test System||Create a machine where developers can upload/test patches before submitting them to master to ensure builds won\'t break when patches are added. (developer autobuilders? Fuzz builds?)||2||Review||Team||Jiajun||1.2||<br />
|-<br />
| Open Source Test Cases||Perform technical, legal, and QA steps necessary to move test cases into open source.||3||Review||QA||||1.2||Yocto 1.2<br />
|-<br />
| Start a framework for automated BSP testing||Build-testing is only half the job of BSP testing, and new BSP development is and will be ramping up even more rapidly soon. We need to start building a framework to make as much of this as automated as possible. Phase I, what we can complete for 1.2, should be the ability to load an image from the autobuilder and make it ready for booting, or actually boot it, on a given target. It would be good to use systems running Yocto images as much as possible for this.||2||Review||Tom||||1.2||<br />
|-<br />
| Test framework||this is a test framework that we can include in the distribution||3||Review||RP Notes||||1.2||Yocto 1.2 - Is it the TI’s test framework we discussed before? A: Not necessarily, we\'re still waiting for someone to step up and really take ownership of this area but it needs some resource commitment as its not a simple task. <br />
|-<br />
| Package History||Write out data about the size of packages, their contents, dependencies, build time and so on allowing changes to be detected. One idea is we could do this in the form of a git repository||1||Review||RP||||1.2||Yocto 1.2<br />
|-<br />
| Package History Analysis Tool||Take the above data, highlight significant deltas and allow the user to confirm or red flag changes. Why did the package double in size? Why did some dependencies go missing? ||1||Review||RP||||1.2||Yocto 1.2<br />
|-<br />
| Extend current QA Tests||Automate some of the existing QA tests such as LSB, posix and rt tests||1||Review||RP||||1.2||Yocto 1.2<br />
|}<br />
<br />
== Meta Data ==<br />
{| border="1"<br />
| align="center" style="background:#f0f0f0;"|'''Feature Name'''<br />
| align="center" style="background:#f0f0f0;"|'''Description'''<br />
| align="center" style="background:#f0f0f0;"|'''Priority'''<br />
| align="center" style="background:#f0f0f0;"|'''Status'''<br />
| align="center" style="background:#f0f0f0;"|'''Source'''<br />
| align="center" style="background:#f0f0f0;"|'''Owner'''<br />
| align="center" style="background:#f0f0f0;"|'''Due'''<br />
| align="center" style="background:#f0f0f0;"|'''Comments / Bugzilla Links'''<br />
|-<br />
| Replacement for video/audio players currently in Yocto||Codec…||3||Review||Meta-data||||1.2||Yocto 1.2<br />
|-<br />
| Investigate New UI||For demos, we would like need a reference UI that is not Sato. Investigate possibilities that the Yocto team won\'t need to maintain. OpenBox? Gnome-desktop? GP? LXDE? KDE Mobile?||3||Review||Meta-data||||1.2||Yocto 1.2<br />
|-<br />
| Qemugl upstreaming||Opengl ES Support||3||Review||Meta-data||||1.2||Yocto 1.2<br />
|-<br />
| selinux patch integration||add SE Linux patches in a similar way to PAM||3||Review||Meta-data||||1.2||Yocto 1.2<br />
|-<br />
| build statistics reporting||As someone interested in how long it takes to build different images on different hardware configurations and other assorted build metrics, I would like a web based service, that takes output generated by an extended buildstats.bbclass and stores it, to compare against different machines. The end result should be a way to visualize the collected data. See: https://wiki.yoctoproject.org/wiki/Yocto_Buildbot_Autobuilder_Discussions||2||M3, Sprint A||eflanagan/Jay7/ka6sox||Beth/Jay||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| Framework to support multiple library versions co-existing||similar to recipe specific sysroot; needs documentation||3||Review||Team||Saul (Dongxiao?)||1.2||Yocto 1.2 - we just need to document how to use multiple versions of a library using clutter as the example<br />
|-<br />
| Embedded java environment or even JDK support||||3||Review||Team||||1.2||Yocto 1.2<br />
|-<br />
| Target module build||Allow for building kernel modules on the target device||2||Review||RP Notes||Darren||1.2||Yocto 1.2, On Janitor\'s list<br />
|-<br />
| gtk+ sato filechooser patch||||3||Review||RP Notes||||1.2||Yocto 1.2<br />
|-<br />
| sato refresh||||3||Review||RP Notes||||1.2||Yocto 1.2<br />
|-<br />
| Sanity checks on per recipe basis||||2||Accept||RP Notes Bug#405||Saul (Scott G)||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| perf scripting\' integration||Make it easy and convenient for the user to write and execute \'perf scripts\' from the IDE. We should be able to leverage and build on the Systemtap integration for this.||2||Dev||Tom||Jessica/Tom||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| Add Directfb(license LGPL) function||Directfb is more appropriate embedded device than other graphic software||3||Moved from M1||Meta-data||WR Distro team||1.2||Yocto 1.2, from 1.1<br />
|}<br />
<br />
== Autobuilder ==<br />
{| border="1"<br />
| align="center" style="background:#f0f0f0;"|'''Feature Name'''<br />
| align="center" style="background:#f0f0f0;"|'''Description'''<br />
| align="center" style="background:#f0f0f0;"|'''Priority'''<br />
| align="center" style="background:#f0f0f0;"|'''Status'''<br />
| align="center" style="background:#f0f0f0;"|'''Source'''<br />
| align="center" style="background:#f0f0f0;"|'''Owner'''<br />
| align="center" style="background:#f0f0f0;"|'''Due'''<br />
| align="center" style="background:#f0f0f0;"|'''Comments / Bugzilla Links'''<br />
|-<br />
| autobuilder layer support||||2||||Beth||Beth||1.2||2 weeks<br />
|-<br />
| autobuilder split of nightly (really an M4 task) few days license.bbclass refactor||||2||||Beth||Beth||1.2||1 week<br />
|-<br />
| buildstats memory measurements||||2||||Beth||Beth||1.2||1 week and half<br />
|-<br />
| license manifest||||2||||Beth||Beth||1.2||1 week<br />
|-<br />
| autobuilder release checkbox (running a yocto release right from the autobuilder)||||2||||Beth||Beth||1.2||2 weeks<br />
|}<br />
<br />
== BSPs ==<br />
{| border="1"<br />
| align="center" style="background:#f0f0f0;"|'''Feature Name'''<br />
| align="center" style="background:#f0f0f0;"|'''Description'''<br />
| align="center" style="background:#f0f0f0;"|'''Priority'''<br />
| align="center" style="background:#f0f0f0;"|'''Status'''<br />
| align="center" style="background:#f0f0f0;"|'''Source'''<br />
| align="center" style="background:#f0f0f0;"|'''Owner'''<br />
| align="center" style="background:#f0f0f0;"|'''Due'''<br />
| align="center" style="background:#f0f0f0;"|'''Comments / Bugzilla Links'''<br />
|-<br />
| AMT driver integration||incorporate Linux AMT into the Yocto BSPs||||||||||1.2||Intel<br />
|-<br />
| Zaurusd++ (devmand?)||I keep seeing changes to toggle certain features for various boards (audio on the beagleboard, N450 and spring to mind), rather than writing lots of recipes for this perhaps we could resurrect zaurusd and evolve it to reflect the projects original goals as devmand; a daemon to handle hardware quirks across a range of boards and devices. ||||||||||1.2||Joshua<br />
|-<br />
| BSP update/intro||determine and integrate / create arch reference BSPs (e500, Cortex, ARM, MIPs)||2||Dev||Bruce/Richard/team||Bruce||1.2||Yocto 1.2, from 1.1<br />
|- <br />
|Drop Grub for Syslinux || Grub is considerably more complicated than we need for any of our current BSPs. Syslinux can be used in place of every known usage of Grub. For upcoming EFI BSPs, we can look to Efilinux. This will reduce our bootloader maintenance burden and simplify our images. || 2 || Review || Darren || Darren || 1.2 ||<br />
|-<br />
|Integrate alsa-state || Remove all the BSP specific $MACHINE-audio recipes in favor of the more generic alsa-state mechanism in use by OE already. || 1 || Review || Darren || || 1.2 || This possibly conflicts with the item to refresh zaurusd.<br />
|-<br />
|Upgrade to EFI ||Where possible, update our existing BSPs to boot using EFI. This will support development of efilinux as well as help us prepare for the newer boards which will be EFI only. || 2 || Review || Darren || Darren || 1.2 ||<br />
|-<br />
|BSP/kernel wrappers/wizards || Create some simple scripts or 'wizards' that make it easy for users to start writing a new BSP and/or easily make simple kernel modifications to a BSP. Ideally, users shouldn't need to know anything low-level about the kernel, git, or the mechanics of appending config items to recipes in order to get a BSP up and running or to make the simple modifications needed to tweak or maintain it. || 2 || Review || tomz || tomz || 1.2 ||<br />
|}<br />
<br />
== ADT == <br />
{| border="1"<br />
| align="center" style="background:#f0f0f0;"|'''Feature Name'''<br />
| align="center" style="background:#f0f0f0;"|'''Description'''<br />
| align="center" style="background:#f0f0f0;"|'''Priority'''<br />
| align="center" style="background:#f0f0f0;"|'''Status'''<br />
| align="center" style="background:#f0f0f0;"|'''Source'''<br />
| align="center" style="background:#f0f0f0;"|'''Owner'''<br />
| align="center" style="background:#f0f0f0;"|'''Due'''<br />
| align="center" style="background:#f0f0f0;"|'''Comments / Bugzilla Links'''<br />
|-<br />
| Enhance the deploy part in remote debug||ADT is currently using org.eclipse.cdt.remote.launch for remote debug. One limitation in this plug-in is that it can only deploy one single file to the target during the debug. Though it is ok for debugging static linked program, debugging dynamic linked program might require deploying multiple files(including executables and libraries) to the target.||2||Review||Lianhao||Jessica||1.2||<br />
|-<br />
| Secure login||||2||Review||ADT Team||Jessica||1.2||Yocto 1.2<br />
|-<br />
| Linux tools upstream integration||There're some activities within the Eclipse Linux Tools community for various tools remote invocation improvement, we need to sync up with the community for their latest deliveries and make some contribution if possible ||2||Review||ADT Team||Jessica||1.2||Yocto 1.2<br />
|-<br />
| Add recipe supporting autoconf-nativesdk and automake-nativesdk ||The new libtool m4 macros(supporting --with-libtool-sysroot) resides in the directory where host aclocal can not find it by default. This requires the user to manually add that directory using -I options. Adding automake(autoconf)-nativesdk into meta-toolchain would help this. ||2||Review||Lianhao||||1.2||Yocto 1.2<br />
|-<br />
| Prebuit SDK integration||speedup target image generation by reusing prebuilt tools from SDK native and target binaries. See: http://wiki.secretlab.ca/Yocto_prebuilt_SDK_integration||2||Reject||Adrian||Jessica||1.2||Yocto 1.2 - This functionality looks to have been provided by sstate packages?<br />
|-<br />
|Eclipse BSP/Kernel Plugin || Provide an Eclipse plugin to facilitate configuring new BSPs and streamlining the linuix-yocto development workflow. || 2 || Review || Darren || || 1.2 ||<br />
<br />
|}<br />
<br />
== Documentation ==<br />
{| border="1"<br />
| align="center" style="background:#f0f0f0;"|'''Feature Name'''<br />
| align="center" style="background:#f0f0f0;"|'''Description'''<br />
| align="center" style="background:#f0f0f0;"|'''Priority'''<br />
| align="center" style="background:#f0f0f0;"|'''Status'''<br />
| align="center" style="background:#f0f0f0;"|'''Source'''<br />
| align="center" style="background:#f0f0f0;"|'''Owner'''<br />
| align="center" style="background:#f0f0f0;"|'''Due'''<br />
| align="center" style="background:#f0f0f0;"|'''Comments / Bugzilla Links'''<br />
|-<br />
| Various Demo Videos||The idea here is to create screen-capture type tutorials similar to what exists for the ADT Eclipse Plug-in. However, we want to contract out some help for professional voice-over talent to be used with the images. These don\'t have to be limited to screen-capture material but could include well-done PPT decks - similar to how other business units in Intel create various training modules. For 1.1 it would be good to capture the script for the existing ADT Eclipse Plug-in module and have it voiced over. Also, for 1.1 it would be good to create a similar module for the Image Creator application.||2||Not Started||From ADT module and scratch||ScottR||1.2||Q3 at the earliest<br />
|}<br />
<br />
== Performance & usability ==<br />
{| border="1"<br />
| align="center" style="background:#f0f0f0;"|'''Feature Name'''<br />
| align="center" style="background:#f0f0f0;"|'''Description'''<br />
| align="center" style="background:#f0f0f0;"|'''Priority'''<br />
| align="center" style="background:#f0f0f0;"|'''Status'''<br />
| align="center" style="background:#f0f0f0;"|'''Source'''<br />
| align="center" style="background:#f0f0f0;"|'''Owner'''<br />
| align="center" style="background:#f0f0f0;"|'''Due'''<br />
| align="center" style="background:#f0f0f0;"|'''Comments / Bugzilla Links'''<br />
|-<br />
| POSIX support||address POSIX failures found in 1.1||2||Review||Team||||1.2||Yocto 1.2, On Janitor\'s list<br />
|}<br />
<br />
<br />
== Kernel ==<br />
{| border="1"<br />
| align="center" style="background:#f0f0f0;"|'''Feature Name'''<br />
| align="center" style="background:#f0f0f0;"|'''Description'''<br />
| align="center" style="background:#f0f0f0;"|'''Priority'''<br />
| align="center" style="background:#f0f0f0;"|'''Status'''<br />
| align="center" style="background:#f0f0f0;"|'''Source'''<br />
| align="center" style="background:#f0f0f0;"|'''Owner'''<br />
| align="center" style="background:#f0f0f0;"|'''Due'''<br />
| align="center" style="background:#f0f0f0;"|'''Comments / Bugzilla Links'''<br />
|-<br />
| Minimal Image unique||make minimal image smaller||3||Accept||Team||WR Distro Team||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| Tracing: tuna, oscilloscope recipes||This might be more useful with the increased importance of RT||3||Review||from 1.0||||1.2||Yocto 1.2<br />
|-<br />
| Kernel Tools||Implement plan for kernel tools||2||Dev (20%)||Bruce/Mark||Bruce||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| use cases||BSP config streamlining, building the kernel standalone, yoctoization, meta data sharing||1||Accept||Bruce||Bruce||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| kernel bloat - development||target = boot a minimal image in < 8M - development complete||1||Dev||Darren||Darren||1.2||Yocto 1.2, from 1.1, continuation needed?<br />
|-<br />
| Fast boot time||2 second boot time target||1||Dev||Team||Darren||1.2||Yocto 1.2, from 1.1, continuation needed?<br />
|-<br />
|Upstream config fragments || Work with John Stultz to upstream a Linux kernel config fragment manager and rework the yocto-kernel-tools to use it. This will simplify our tooling and increase our usage/test base. || 1 || Review || Darren || || 1.2 ||<br />
|-<br />
|Real-time process-executed timers || Timers currently run at the priority of the softirq that processes them and they are accounted to whichever task was preempted for them to run. This negatively impacts determinism and accounting accuracy. || 2 || Review || Darren || || 1.2 ||<br />
|-<br />
|Define Kernel policy || We need to clearly document kernel policy and make the config fragments reflect it. This will facilitate a more modular approach to building BSP kernel configs, as well as make it clear what can be expected to be supported when running a "linux-yocto kernel". || 1 || Review || Darren || || 1.2 ||<br />
|}<br />
<br />
== Project-wide Features ==<br />
{| border="1"<br />
| align="center" style="background:#f0f0f0;"|'''Feature Name'''<br />
| align="center" style="background:#f0f0f0;"|'''Description'''<br />
| align="center" style="background:#f0f0f0;"|'''Priority'''<br />
| align="center" style="background:#f0f0f0;"|'''Status'''<br />
| align="center" style="background:#f0f0f0;"|'''Source'''<br />
| align="center" style="background:#f0f0f0;"|'''Owner'''<br />
| align="center" style="background:#f0f0f0;"|'''Due'''<br />
| align="center" style="background:#f0f0f0;"|'''Comments / Bugzilla Links'''<br />
|-<br />
| LayerTooling – remote layer tool||Consider integrating Jeremy Puhlman\'s remote layers patch||2||Community||Paul||1.2||||<br />
|-<br />
| running post installs at rootfs gen time||||2||Review||RP Notes||Saul (Dexuan)||1.2||<br />
|-<br />
| Clean up warning messages||A build that runs correctly to completion still includes a ton of WARNING messages. We need a project to clean these up. Beth will work on License Warnings, team will look at other logfile warnings||2||Review||Dave & RP||Saul||1.2||<br />
|-<br />
| Multi-lib - 11||Directly support multlibs within the toolchain itself [post 1.1] ||2||||RP||Ke||1.2||<br />
|-<br />
| Multi-lib - 8||Add support to RPM packaging backend to turn modified package names into true rpm multilib packages||1||||RP||Mark||1.2||<br />
|-<br />
| Multi-lib - 7||Investigate better TARGET_VENDOR handling for config.sub. Currently we can only have ARCH-VENDOR-linux where VENDOR cannot contain \"-\" but it might be possible to relax that constraint [not high priority]. ||2||Review||RP||Ke||1.2||<br />
|-<br />
| Multi-lib - 6||Create some \"standard\" multilib configurations (x86 32+64 bit)||1||Review||RP||Ke||1.2||<br />
|-<br />
| Patchwork||is it worth the overhead, are there alternatives||3||Review||RP Notes||||1.2||Yocto 1.2<br />
|-<br />
| Bugzilla to Wiki||Create a script which automatically populates and updates the Wiki based on changes in bugzilla.||2.5||Review||Darren||||1.2||Yocto 1.2<br />
|-<br />
| Sync qemugl with MeeGo - Implementation||sync qemugl with MeeGo is complete||2||Dev (70%)||Meta-data||Saul (Edwin)||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| Tracing/profiling HOWTOs||Create a document or extend the current Yocto tracing wiki page to explain in detail how to use all the tracing tools in Yocto. It should detail not only how to use each tool individually, but also how to use them in conjunction with each other, highlighting situations in which each is most useful. There should also be some extensive worked examples of real-life use-cases and how they could be investigated using the Yocto tracing/profiling tools.||2||Accept||Tom||Tom||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| Error handling in bitbake (Implementation): Stage 2||Performance improvement (gather input from community on use cases)||1||Dev||RP Notes||Saul (Scott G)||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| btrfs||Kernel enabling||2||Dev||Meta-data||Saul (Nitin)||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| replace qemuppc||||||||||Bruce||1.2||Come from bug 414<br />
|-<br />
| MeeGo GPLv2 Sync||compare with Yocto, sync any patches||2||Accept||RP Notes||Saul (Ke)||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| Package Documentation Audit: All recipes build||31 recipes were identified as not building during the package documentation audit done in M1, Sprint B. Those all need to build and we need to re-run a new package documentation audit.||2||Accept||Team||Scott G||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| Tracing: Systemtap usability in Yocto||Right now, there are instructions on the wiki on how to configure and use Systemtap with Yocto. While straightforward, they are tedious and unlikely to be useful to most people pressed for time. We need to make it easier to use - in addition to documentation/HOWTO tasks listed elsewhere on this page, we need to make it usable \'out of the box\' (i.e. outside of ADT) e.g. all paths and configuration handled via script or something similar||2||Accept||Tom||Tom||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| Tracing: create separate recipe for perf||Perf is currently built as part of the kernel build. If we want to make use of everything perf has to offer we should get rid of the dependency. For example, the kernel build shouldn\'t depend on libnewt, and x32 shouldn\'t have to deal with embedded Python||2||Review||Tom||Tom||1.2||<br />
|-<br />
| Tracing: perf trace scripting support||Basically this means allowing perf to be built with the Perl and Python bindings, which turned out to be a headache last time.||2||Dev (50%)||from 1.0||Tom||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| Monitor disk availability||Monitor disk availability and warn the user if it is running low. May only focus on a few directories, for example: poky/build and poky/build/downloads, this would solve the multiple mount point problem||2||Review||RP and Robert||WR Distro Team (Robert)||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| Ability to build SRPM||||3||Accept||RP Notes||Jeff Polk/Mark||1.2||Yocto 1.2, from 1.1<br />
|-<br />
| Classes to help install binary packages||It\'s been suggested that it would be a useful feature to be able to easily take an RPM or similar containing a software binary from a 3rd party software vendor and integrate it into an image created by the build system.||2||Review||||||1.2||<br />
|-<br />
| Host intrusion prevention||We have Swabber but it\'s not integrated into our process. I believe this is because there are several recipes which don\'t work when run under strace with parallelisation. We should determine a path for inclusion of swabber into our process and execute on it so that we can be aware of, and fix, any host intrusion issues.||2||Review||||||1.2||<br />
|-<br />
| Security layer||Many of our users are likely to want to use kernel level security mechanisms and so I\'d like to investigate supporting one of the in-kernel LSM (Linux Security Modules), possibly SMACK as used in MeeGo, and adding policy to the oe-core metadata. The LSM, policy and user-space tools could all be enabled via a distro feature. This work may well want to be in a separate layer?||2||Review||Joshua||||1.2||<br />
|-<br />
| Factory reset||Implement a factory reset image feature. We\'ll use one of the union mount technologies (aufs/overlayfs/union mounts) to create an overlay on the file system as the final piece of rootfs creation. The overlaid file-system will be the target of all writes made to the image after the image is generated. A user-space mechanism to disable the overlay, and therefore reset to the state of the image just after it was created, will also be provided. This feature could be further enhanced by integrating with the package manager, and other user-space switches, to create system restore points which can later be rolled back to.||2||Review||Joshua||||1.2||<br />
|-<br />
| Gstreamer||Refactor gstreamer recipes to better support COMMERCIAL_LICENSE and enabling/disabling of various codecs and features||2||Review||||||1.2||http://bugzilla.pokylinux.org/show_bug.cgi?id=923<br />
|-<br />
| Init||Interest in systemd as a replacement for Sys V init is growing but it may not be appropriate for deeply embedded systems. I\'d like to investigate a crop of service based and process monitoring init systems and compare them on a variety of criteria as determined by the community. Furthermore I would like to investigate supporting multiple init systems, the current SysV system, systemd and possibly others. As part of this work, and because increasingly many upstreams support systemd (no doubt thanks to its adoption in Fedora) I would like to investigate implementing some infrastructure which translates from systemd units to the appropriate init format for the supported init systems.||2||Review||||||1.2||<br />
|-<br />
| Enhance Automated QA Tests||Add tests for the RT pieces, consider run-time security checking tools used by Fedora and Gentoo||2||Review||||||1.2||<br />
|-<br />
| Collect data at build time to increase accuracy of estimation (hob)||Collect data at build time to allow hob to: predict the size of the generated image, more accurately reflect the built image contents, etc. This will likely involve generating data on the autobuilder which the UI can fetch and consume (with local caching for offline usage)||2||Review||||||1.2||http://bugzilla.pokylinux.org/show_bug.cgi?id=1316<br />
|-<br />
| Finish and enable PR server||We\'re still seeing people being forced to cleansstate too often, we need to finish up and enable the PR server so the checksummed sstate future can live||2||Review||||||1.2||http://thread.gmane.org/gmane.comp.handhelds.openembedded.core/1272/focus=1357 http://thread.gmane.org/gmane.comp.handhelds.openembedded.core/835/focus=852<br />
|-<br />
| Provide a click through license mechanism||Implement the mechanism described in Section 1.2. BSP \'Click-Through\' Licensing Procedure in the BSP Developer\'s Guide||2||Review||Tom||Tom||1.2||<br />
|-<br />
| Finish Oracle/Sun Hotspot JDK/JRE support||I created an initial hack of a recipe for this for the demo - finish it up (involves licensing issues (click-through license support would be a prerequisite) as well)||2||Review||Tom||Tom||1.2||50% done already<br />
|- <br />
| BSPs or layers for a specific category of devices || This will demonstrate the value of Yocto to developers and help them get up to speed quicker for this category of devices. ||2||Review||Dirk/Dave/Andy||TBD||1.2||<br />
|- <br />
| enhance the bitbake commander eclipse plugin || By having the Eclipse as a frontend UI to bitbake server, eclipse may talk to bitbake server, enable the user to glimpse on the variables' values when editing the recipes, try out building the recipe being edited, etc. ||2||Review||Dongxiao/Lianhao||TBD||TBD|| This requires new features both in eclipse plugin and bitbake server.<br />
|- <br />
| Parallel Locale Generation || Add makefile to allow the locale generation to happen in parallel ||2||Review||RP||||||<br />
|- <br />
| Make BasicHash the default || We'd like to start adding the sstate signature to the stampfiles using the BasicHash signature generator and stop bumping PR values. This will require some additions to the PR server work we previously started||2||Review||RP||||||<br />
|- <br />
| Address git fetcher concerns || The community has raised some git fetcher concerns we should address||2||Review||RP||||||<br />
|}</div>Davesthttps://wiki.yoctoproject.org/wiki/index.php?title=Build_Appliance_Design&diff=3288Build Appliance Design2011-09-01T22:01:37Z<p>Davest: Created page with "This page holds the design for the Yocto Project build appliance. === Usage Model === This feature is designed to make the Yocto Project much more appealing to the developer wh..."</p>
<hr />
<div>This page holds the design for the Yocto Project build appliance.<br />
<br />
=== Usage Model ===<br />
<br />
This feature is designed to make the Yocto Project much more appealing to the developer who wants to check Yocto out but may not have a recent (and supported) Linux distro installed with all of the proxies set up correctly.<br />
<br />
The developer will download a virtual image and boot it. This image is a Linux OS which will allow the user to do a build, boot the resulting Linux in an emulator. This gives a quick experience with the system without fear of dependencies being missing. (This is needed because of the general difficulty in having something as complex as the Yocto Project be totally compatible with every conceivable Linux system.<br />
<br />
It is a non-goal that a developer would continue to use this appliance for all day-to-day development tasks.<br />
<br />
=== Goals ===<br />
<br />
# Required: Total size of the image must not exceed 100 Mbytes, to make it feasible to download the image.<br />
# Preferred: Have a second, larger image which includes all source and sstate-cache preinstalled, but may be much larger.<br />
# Preferred: VMWare ESX image. VMWare is known to correctly build whereas recent versions of Virtual Box and others are not.<br />
# Required: Must have Linux plus all prerequisite packages installed to make a build work.<br />
# Preferred: Generate the OS in the appliance with Yocto. (Thus, make it a self-hosted build appliance)<br />
# Preferred: When the image boots, it boots up Hob and also has a terminal for launching QEMU or deploying the image<br />
# Preferred: In addition to Hob, there is GUI support for deploying the image on a board and / or boot it into QEMU<br />
<br />
=== Design Notes ===<br />
<br />
(To be filled in with additional design comments)</div>Davesthttps://wiki.yoctoproject.org/wiki/index.php?title=Planning&diff=3025Planning2011-08-02T15:20:21Z<p>Davest: /* Release Cycle and Criteria and Development Methodology */</p>
<hr />
<div>Planning for features and schedule is done as a community. Details on the schedule, features, and development and release process are below. <br />
<br />
=== Roadmaps and Schedules ===<br />
* [[Yocto 1.1 Schedule]] (current)<br />
* [[Yocto 1.0 Schedule]]<br />
* [[Yocto Project Roadmap]]<br />
<br />
=== Features ===<br />
* [[Yocto General Features]] - This page contains general features across all Yocto releases.<br />
* [[Yocto 1.1 Features]] (current)<br />
* [[Yocto Features]] (from v1.0)<br />
* [[Yocto Project Unscheduled Feature List]]<br />
<br />
=== Release Cycle and Criteria and Development Methodology ===<br />
* [[Yocto Project v. 1.0 Release Cycle]]<br />
* [[Development Methodology]] -- This describes what to expect from development effort, planning and execution<br />
* [[Yocto Project v1.1 Release Criteria]] (current)<br />
* [[Yocto Project v1.0.1 Release Criteria]]<br />
* [[Yocto Project v1.0 Release Criteria]]</div>Davesthttps://wiki.yoctoproject.org/wiki/index.php?title=Training&diff=1831Training2011-05-26T23:27:42Z<p>Davest: /* Embedded Linux Conference 2011 */</p>
<hr />
<div>This page collects training materials as contributed by the community.<br />
<br />
== Embedded Linux Conference 2011 ==<br />
Thank you to Free-Electrons.com for the sweet contribution of these videos!<br />
<br />
[http://free-electrons.com/blog/elc-2011-videos/ Link to the Free-Electrons.com web page]<br />
<br />
* [http://elinux.org/images/7/7c/Elc2011_zanussi_wold.odp Building Custom Embedded Images with Yocto (slides)]<br />
* [http://free-electrons.com/pub/video/2011/elc/elc-2011-zanussi-wold-custom-embedded-images-yocto-x450p.webm Building Custom Embedded Images with Yocto (450x800 video)]<br />
* [https://wiki.yoctoproject.org/wiki/images/2/22/Elc11-yocto-kernel-tutorial.pdf Yocto Project: Practical Kernel Development Tutorial (slides)]<br />
* [http://free-electrons.com/pub/video/2011/elc/elc-2011-hart-yocto-kernel-development-x450p.webm Yocto Project: Practical Kernel Development Tutorial (450x800 video)]<br />
* [http://elinux.org/images/e/e6/ELC_Yocto_ADT_2011_davest.odp The Yocto Project and its Application Development Toolkit (ADT) (slides)]<br />
* [http://free-electrons.com/pub/video/2011/elc/elc-2011-stewart-yocto-appdev-toolkit-x450p.webm The Yocto Project and its Application Development Toolkit (ADT) (450x800 video)]<br />
* [http://elinux.org/images/e/ec/Elc2011_flanagan.pdf Delivering Predictability: The Yocto Project Autobuilder, Automated Sanity Testing, License Collection, and Build Statistics Tracking (slides)]<br />
* [http://free-electrons.com/pub/video/2011/elc/elc-2011-flanagan-yocto-autobuilder-x450p.webm Delivering Predictability: The Yocto Project Autobuilder, Automated Sanity Testing, License Collection, and Build Statistics Tracking (450x800 video)]</div>Davesthttps://wiki.yoctoproject.org/wiki/index.php?title=File:Elc11-yocto-kernel-tutorial.pdf&diff=1830File:Elc11-yocto-kernel-tutorial.pdf2011-05-26T23:26:22Z<p>Davest: Talk by Darren Hart on Yocto Kernel Development, presented at the Embedded Linux Conference 2011</p>
<hr />
<div>Talk by Darren Hart on Yocto Kernel Development, presented at the Embedded Linux Conference 2011</div>Davesthttps://wiki.yoctoproject.org/wiki/index.php?title=Training&diff=1829Training2011-05-26T23:23:01Z<p>Davest: Created page with 'This page collects training materials as contributed by the community. == Embedded Linux Conference 2011 == Thank you to Free-Electrons.com for the sweet contribution of these v…'</p>
<hr />
<div>This page collects training materials as contributed by the community.<br />
<br />
== Embedded Linux Conference 2011 ==<br />
Thank you to Free-Electrons.com for the sweet contribution of these videos!<br />
<br />
[http://free-electrons.com/blog/elc-2011-videos/ Link to the Free-Electrons.com web page]<br />
<br />
* [http://elinux.org/images/7/7c/Elc2011_zanussi_wold.odp Building Custom Embedded Images with Yocto (slides)]<br />
* [http://free-electrons.com/pub/video/2011/elc/elc-2011-zanussi-wold-custom-embedded-images-yocto-x450p.webm Building Custom Embedded Images with Yocto (450x800 video)]<br />
* [http://free-electrons.com/pub/video/2011/elc/elc-2011-hart-yocto-kernel-development-x450p.webm Yocto Project: Practical Kernel Development Tutorial (450x800 video)]<br />
* [http://elinux.org/images/e/e6/ELC_Yocto_ADT_2011_davest.odp The Yocto Project and its Application Development Toolkit (ADT) (slides)]<br />
* [http://free-electrons.com/pub/video/2011/elc/elc-2011-stewart-yocto-appdev-toolkit-x450p.webm The Yocto Project and its Application Development Toolkit (ADT) (450x800 video)]<br />
* [http://elinux.org/images/e/ec/Elc2011_flanagan.pdf Delivering Predictability: The Yocto Project Autobuilder, Automated Sanity Testing, License Collection, and Build Statistics Tracking (slides)]<br />
* [http://free-electrons.com/pub/video/2011/elc/elc-2011-flanagan-yocto-autobuilder-x450p.webm Delivering Predictability: The Yocto Project Autobuilder, Automated Sanity Testing, License Collection, and Build Statistics Tracking (450x800 video)]</div>Davesthttps://wiki.yoctoproject.org/wiki/index.php?title=Main_Page&diff=1828Main Page2011-05-26T22:57:29Z<p>Davest: /* Welcome to the Yocto Project Wiki! */</p>
<hr />
<div>== Welcome to the Yocto Project Wiki! ==<br />
* [[Planning and Governance]]<br />
* [[Community Guidelines]]<br />
* [[Processes and Activities]]<br />
* [[Projects]]<br />
* [[Yocto Interest Groups]]<br />
* [[FAQ]]<br />
* [[Contributors]]<br />
* [[Training]]<br />
<br />
== Other resources ==<br />
* [http://yoctoproject.org Yocto Project Front Page]</div>Davesthttps://wiki.yoctoproject.org/wiki/index.php?title=JefroBus&diff=1076JefroBus2011-03-31T01:06:40Z<p>Davest: </p>
<hr />
<div>'''JefroBus Schedule: Collab & ELC 2011<br />
<br />
This is the schedule for the JefroBus. I have a car with room for 4 friendly passengers plus reasonable luggage, or 3 reasonably acquainted passengers plus a lot of luggage, or 2 hostile passengers plus any amount of luggage.. you get the idea. The schedule is posted below. <br />
<br />
If you are arriving at San Jose, Oakland, or San Francisco, and there is room left in the car, feel free to place yourself on the schedule. If you need a trip that is not posted here, send email to [mailto:jefro@jefro.net Jefro] and I'll see what I can arrange.<br />
<br />
For planning purposes, travel times to/from the Kabuki Hotel:<br />
* SJC: approx 1hr<br />
* SFO: approx 25m<br />
* BART/CalTrain: approx 10m<br />
<br />
Tuesday, April 5, 2011<br />
6:00pm - SJC to Kabuki [davest]<br />
<br />
Friday, April 8, 2011<br />
11:00am - Kabuki to SFO [dawn]<br />
4:00pm - Kabuki to SJC [julie, jzhang, tracey]<br />
<br />
Sunday, April 10, 2011<br />
10:30am - SFO to Kabuki [tomr, sgw]<br />
8:30pm - SFO to Kabuki [tracey]<br />
<br />
Monday, April 11, 2011<br />
10:30am - BART or CalTrain to Kabuki [pidge]<br />
<br />
Wednesday, April 13, 2011<br />
4:00pm - Kabuki to SJC (5:55pm Check-in) [dvhart, davest]<br />
7:00pm - Kabuki to SFO [tracey]</div>Davesthttps://wiki.yoctoproject.org/wiki/index.php?title=Yocto_1.1_Features&diff=1044Yocto 1.1 Features2011-03-28T17:18:36Z<p>Davest: /* Poky/Bitbake */</p>
<hr />
<div>== Potential Yocto 1.1 Features ==<br />
Yocto 1.1 - Target release = October 2011<br />
<br />
This page contains a list of Yocto 1.1 features. In early March, the Yocto Architect will issue an official call for Yocto 1.1 features. This list contains reprioritized items from 1.0 or features that came up as a result of discussions among Yocto engineers. If you have a feature you would like to see added, send an email to the Yocto Architect with a description of the feature, its impat on the source code, and whether you are willing to help write the code to implement the feature. The Yocto Architect will add this to the potential Yocto 1.1 Features list. The potential Yocto 1.1 Features list will be turned into the Yocto Features List as described in the [[Program Management Plan]].<br />
<br />
<br />
== Yocto 1.1 Themes ==<br />
The topics below are the themes that some members of the team have started brainstorming for Yocto 1.1. These will grow and change with community input.<br />
<br />
=== Yocto 1.1 Objectives ===<br />
The objectives of the Yocto 1.1 release are to grow participation in Yocto and increase the number of BSPs written for Yocto and partner products based on Yocto.<br />
<br />
=== Yocto 1.1 Theme List ===<br />
The Yocto 1.1 Themes towards the Objectives listed above are:<br />
<br />
* Multilibs & OE-core config - This work, which began in Yocto 1.0, needs to be completed.<br />
* Improve ease of BSP creation - Document the lifecycle and process. Possibly create walkthroughs or tutorials to integrate a new board into the linux-yocto kernel.<br />
* Build performance – Get to the goal of 1 hour build time on a developer machine.<br />
* Upstreaming – Submit patches to upstream projects in order to reduce the 2,000+ patches which are currently part of Yocto Project.<br />
<br />
== Process for Entering New Feature Requests ==<br />
<br />
* Create a new entry in the appropriate feature table below (Poky, SDK, Hardware)<br />
** Suggestion: start by copying an existing request as a template<br />
* Give the feature a short, descriptive name<br />
* Provide a one or two sentence brief description of the feature<br />
* Set the priority as appropriate (see the legend below)<br />
* Set the Status to "Review"<br />
* In the Source field, enter your name along with the origination of the request (e.g. OSV, OEM, Community) if applicable; provide as much detail here as you can<br />
* In the Comments / Bugzilla field, provide any additional information for the request, such as a link to a bugzilla entry<br />
* Preview your Entry to make sure it looks ok and then save it<br />
<br />
''Legend''<br />
<br />
'''Priority:''' 1 = Must Have, 2 = Nice to Have, 3 = Optional<br />
<br />
'''Status:''' Accept = Engineering agreement to include in release, Review = Under Review for Inclusion in this release, Reject = Will not be included in this release<br />
== Sample Table ==<br />
<br />
This is a sample table to show how to submit features.<br />
<br />
{| border="1"<br />
||'''Feature Name''' ||'''Description''' ||'''Priority''' ||'''Status''' ||'''Source''' ||'''Comments / Bugzilla Links'''<br />
|-<br />
||Placeholder feature name || Placeholder description of the feature || 1, 2, or 3 || Review|| name|| Comment<br />
|}<br />
<br />
== Architecture ==<br />
{| border="1"<br />
||'''Feature Name''' ||'''Description''' ||'''Priority''' ||'''Status''' ||'''Source''' ||'''Comments / Bugzilla Links'''<br />
|-<br />
|| Layer Tooling || This includes the architectural work plus implementing the changes. || 1 || Review || Architect || M2; Owner = Richard<br />
|-<br />
|| OE-Core || Restructuring, renaming, rebranding || 1 || Review || RP Notes || M1; Owner = Richard <br />
|}<br />
<br />
== Poky/Bitbake ==<br />
This section contains features for the Poky/Bitbake infastructure.<br />
{| border="1"<br />
||'''Feature Name''' ||'''Description''' ||'''Priority''' ||'''Status''' ||'''Source''' ||'''Comments / Bugzilla Links'''<br />
|-<br />
|| Error handling in bitbake || desc || 1 || Review || RP Notes || M2; Owner = Saul <br />
|-<br />
|| crazygit fetcher || TI issues with fetch2 || 2 || Review || RP Notes || <br />
|-<br />
|| multi-lib || multi-lib support for 32-bit & 64-bit and capable of being installed at the same time || 1 || Review || from 1.0 || M1; Owner = Richard<br />
|-<br />
|| Image Creator || finish the Image Creator to add features pushed out from 1.0 || 1 || Review || from 1.0 || M2; Owner = Josh + someone else (Dave investigating someone on Jessica's team)<br />
|-<br />
|| Recipe-specific sysroot || || 3 || Review || from 1.0 || <br />
|-<br />
|| Handle old versions in WORKDIR || || 3 || Review || from 1.0 || <br />
|-<br />
|| Package config option enhancement || need to plan and then implement || 2 || Review || from 1.0 || <br />
|-<br />
|| Clean up warning messages || A build that runs correctly to completion still includes a ton of WARNING messages. We need a project to clean these up. || 2 || Review || davest and RP || <br />
|}<br />
<br />
== QA Items ==<br />
{| border="1"<br />
||'''Feature Name''' ||'''Description''' ||'''Priority''' ||'''Status''' ||'''Source''' ||'''Comments / Bugzilla Links'''<br />
|-<br />
||QA Framework Enhancements || <br />
* Add test for unfs_qemu bootup in the sanity test framework and give Liping his patch (Jiajun)<br />
* Help to define long-term flexible framework for SDK/meta-toolchain testing.. Under the test folder, we have different groups of test, such as sanity, SDK(tools), meta-toolchain. User could freely select which test cases they want to test. (Control granularity/level group? Or even a single case has a switch) (Jiajun)<br />
* More test-projects into existing manual test part for meta-toolchain. We should help to find the two typical projects, one c and o C++. (Jiajun)<br />
* Transform the meta-toolchain manual testing into the unified test-framework. (Liping)<br />
* Prepare a workable environment for testing all those newly added features. (Liping)<br />
* After sanity test framework is in the upstream, collect data when selecting different kinds of test components. (MeiLei)<br />
|bgcolor="yellow"| ?? || Review|| QA || <br />
|-<br />
|| Open Source Test Cases || Perform technical, legal, and QA steps necessary to move test cases into open source. || 3 || Review|| QA || <br />
|-<br />
|| Automated test infrastructure || Automate the test infrastructure<br />
|| 2 || Review|| QA || <br />
|-<br />
|| Test framework || this is a test framework that we can include in the distribution || 3 || Review || RP Notes || <br />
|-<br />
|| Be prepared for Distro upgrades || Our release is right around the time of the 6monthly distro release dates, we should accommodate for this in our testing plan || 2 || Review || Joshua ||<br />
|}<br />
<br />
== Meta-data ==<br />
{| border="1"<br />
||'''Feature Name''' ||'''Description''' ||'''Priority''' ||'''Status''' ||'''Source''' ||'''Comments / Bugzilla Links'''<br />
|-<br />
|| Upstream our patches || We'll add this as a task in a milestone to give people time to do<br />
|| 1 || Review|| Meta-data|| M2; Owner = Saul<br />
|-<br />
|| 3G || We have an ofono recipe but need some integration work doing || 2 || Review|| Meta-data|| <br />
|-<br />
|| btrfs || || 2 || Review|| Meta-data|| <br />
|-<br />
|| Other components? || Saul will investigate other components. || 2 || Review|| Meta-data|| <br />
|-<br />
|| Replacement for video/audio players currently in Yocto || Codec…<br />
|| 3 || Review|| Meta-data|| <br />
|-<br />
|| Investigate New UI || For demos, we would like need a reference UI that is not Sato. Investigate possibilities that the Yocto team won't need to maintain. OpenBox? Gnome-desktop? GP? LXDE? KDE Mobile? <br />
|| 3 || Review|| Meta-data|| <br />
|-<br />
|| Qemugl upstreaming || Opengl ES Support || 3 || Review|| Meta-data|| <br />
|-<br />
|| Sync qemugl with MeeGo || <br />
|| 2 || Review|| Meta-data|| <br />
|-<br />
|| Package reporting system enhancement|| <br />
|| 2 || Review|| Meta-data|| <br />
|-<br />
|| pam patch integration || add PAM patches throughout the system switchable via the PAM feature (Mark H)<br />
|| 2 || Review|| Meta-data|| <br />
|-<br />
|| selinux patch integration || add SE Linux patches in a similar way to PAM<br />
|| 3 || Review|| Meta-data|| <br />
|-<br />
|| Finish LSB "distribution" work || Merge patches which are pushed during ycoto 1.0. Add packages LSB Test Suite need. Hardware platform x86, x86-64 and ppc32(if qt4 can be supported) can be finished. <br />
|| 2 || Review|| Meta-data|| M2; Owner = Xiaofeng Yan, Jingdong Lu, Kai kang,Xudong Hao<br />
|-<br />
|| OE Comparison || Compare Yocto core set against integration work in OE and other distributions looking for bug fixes, (relevant) feature enhancements, and integration/policy hints.<br />
|| 1 || Review|| Meta-data|| M1; Owner = Mark<br />
|-<br />
|| Framework to support multiple library versions co-existing || similar to recipe specific sysroot; needs documentation<br />
|| 2 || Review|| Team || <br />
|-<br />
|| Embedded java environment or even JDK support || <br />
|| 3 || Review|| Team || <br />
|-<br />
|| Automatically generate package repos || automatically generate package repositories (and be able to "use them" -- to be defined) for both ipk and rpm/zypper combinations; NEEDS MORE DISCUSSION<br />
|| 2|| Review|| Team || <br />
|-<br />
|| MeeGo GPLv2 Sync || compare with Yocto, sync any patches || 2 || Review || RP Notes || <br />
|-<br />
|| Incompatible License || || 2 || Review || Paul || <br />
|-<br />
|| End of package revision || replace with a network service || 2 || Review || RP Notes || Owner = Jessica <br />
|-<br />
|| Target module build || Allow for building kernel modules on the target device || 2 || Review || RP Notes || Owner = Darren <br />
|-<br />
|| Live images || make live images their own image type || 2 || Review || RP Notes || Owner = Saul <br />
|-<br />
|| multiple update-alternatives || fixed? || 3 || Review || RP Notes || <br />
|-<br />
|| init scripts || provide an image/recipe skeleton as a canonical example || 3 || Review || RP Notes || <br />
|-<br />
|| running post installs at rootfs gen time || || 2 || Review || RP Notes || <br />
|-<br />
|| remove gnome-vfs || || 3 || Review || RP Notes || <br />
|-<br />
|| gtk+ sato filechooser patch || || 3 || Review || RP Notes || <br />
|-<br />
|| sato refresh || || 3 || Review || RP Notes || <br />
|-<br />
|| adding eglibc config control || this goes with the package config options || 1.5 || Review || RP Notes || M2; Owner = Mark <br />
|-<br />
|| Sanity checks on per recipe basis || || 2 || Review || RP Notes || <br />
|-<br />
|| x32 || layer to support toolchain, libc, and kernel || 2 || Review || RP Notes || <br />
|-<br />
|| User Creation at postinstall || || 1 || Review || RP Notes || M1; Owner = Mark <br />
|-<br />
|| Directory Ownership || || 1.5 || Review || RP Notes || M2; Owner = Mark <br />
|-<br />
|| Optimise Configure || || 2 || Review || RP Notes || Performance idea <br />
|-<br />
|| Ability to build SRPM || || 3 || Review || RP Notes || <br />
|-<br />
|| Check SRCREV in recipe files || should work, may need dev || 2 || Review || RP Notes || <br />
|-<br />
|| Add Directfb(license LGPL) function || Directfb is more appropriate embedded device than other graphic software|| 3 || Review ||Meta-data || M3;Owner = Xiaofeng Yan if possible<br />
|}<br />
<br />
== BSPs ==<br />
{| border="1"<br />
||'''Feature Name''' ||'''Description''' ||'''Priority''' ||'''Status''' ||'''Source''' ||'''Comments / Bugzilla Links'''<br />
|-<br />
|| Support for AVX as in kernel 2.6.30. - Already in 1.0 || Any toolchain support needed?<br />
|| 1|| Review|| Jay || M1; Owner = Saul<br />
<br />
|}<br />
<br />
== ADT ==<br />
{| border="1"<br />
||'''Feature Name''' ||'''Description''' ||'''Priority''' ||'''Status''' ||'''Source''' ||'''Comments / Bugzilla Links'''<br />
|-<br />
|| More test cases about toolchain in autobuilder || <br />
|| 2 || Review|| ADT Team || Owner = Jessica<br />
|-<br />
|| Eclipse-native tools interface || not using oprofile-UI. More integrated with upstream<br />
|| 2 || Review|| ADT Team || <br />
|-<br />
|| Indigo update || Update to the latest Eclipse release (Indigo) || 2 || Review|| ADT Team || M2; Owner = Jessica<br />
|-<br />
|| Changes for Image Creator || Eclipse changes pending Image Creator || 1 || Review|| ADT Team || M2; Owner = Jessica<br />
|-<br />
|| Secure logging || || 2 || Review|| ADT Team || <br />
|-<br />
|| Prebuit SDK integration || speedup target image generation by reusing prebuilt tools from SDK native and target binaries. See: http://wiki.secretlab.ca/Yocto_prebuilt_SDK_integration|| 2 || Review || Adrian ||<br />
|}<br />
<br />
== Documentation ==<br />
{| border="1"<br />
||'''Feature Name''' ||'''Description''' ||'''Priority''' ||'''Status''' ||'''Source''' ||'''Comments / Bugzilla Links'''<br />
|-<br />
|| Package Documentation Audit || Make changes defined in the package documentation audit from Yocto 1.0<br />
|| 2|| Review|| from 1.0 || Owner = Saul<br />
|-<br />
|| Yocto Project Development Guide || This manual would be an over-arching document that frames the complete development cycle within Yocto Project. The idea here is that the document would be an umbrella document that spawned and referenced subsequent documents. The organization would be the first chapter overviews the major development pieces such as recipe creation, building, debugging, publishing, fail-safing, back-door hook creation, etc. This manual will also include migration information. Scoping would be about two weeks and length would probably be about 40 pages. Overall development time will likely take up to the release given my experience on the creation of the ADT manual (there is no uniterruped time).<br />
|| 1|| Not Started || from scratch || Owner = ScottR <br />
|-<br />
|| Various Demo Videos || The idea here is to create screen-capture type tutorials similar to what exists for the ADT Eclipse Plug-in. However, we want to contract out some help for professional voice-over talent to be used with the images. These don't have to be limited to screen-capture material but could include well-done PPT decks - similar to how other business units in Intel create various training modules. For 1.1 it would be good to capture the script for the existing ADT Eclipse Plug-in module and have it voiced over. Also, for 1.1 it would be good to create a similar module for the Image Creator application.<br />
|| 2|| Not Started || From ADT module and scratch || Owner = ScottR <br />
|-<br />
|| Open-source Newbie Information || This information will be for developers new to open-source. These people do not know what IRC means. Targeted for developers coming from a non-open-source environment. I think the best place for this information would be the website. I haven't looked yet but I suspect information already exists on the web. For Yocto it will be a matter of collecting the best and most useful information, orginizing it and properly referencing/leveraging it.<br />
|| 2|| Not Started || From scratch || Owner = ScottR <br />
|-<br />
|| Tarball Doc process || Right now tarball docs are frozen shortly before a release. The tarball never gets updated beyond that during subsequent documentation development. However, website docs are periodically updated as changes are made during the next development cycle. We need a documentation process where the tarball docs are updated along with the website docs. Perhaps releasing and building a separate documentation tarball is an answer... This whole scheme needs thought about and something implemented.<br />
|| 3|| Not Started || From scratch || Owner = ScottR <br />
|-<br />
|| OOB documentation || Create an out of box guide for giveaway systems built using Yocto. || 1|| Review || Julie || Owner = ScottR<br />
|}<br />
<br />
== Build ==<br />
This section contains requirements related to the build (autobuilder activities, performance, footprint, etc.)<br />
{| border="1"<br />
||'''Feature Name''' ||'''Description''' ||'''Priority''' ||'''Status''' ||'''Source''' ||'''Comments / Bugzilla Links'''<br />
|-<br />
|| Autobuilder maintenance || Bring scripts into configuration or get git repo working for those that can't be brought in. <br />
|bgcolor="yellow"| 1 || Review || Beth || M1; Owner = Beth<br />
|-<br />
|| Meta targets || Part of the challenge of autobuilder is that you have to go into autobuilder, edit script, reconfigure, to change just one build target. This is error prone. What we need is a meta-target where Beth can say she wants to build Poky-image-sato for QEMU x86 and have it just do that. Beth thinks this is done via an override to the web page. (takes ~2 weeks) <br />
|bgcolor="yellow"| 1 || Review || Beth || M2; Owner = Beth<br />
|-<br />
|| License tracking || Get common licenses for all packages. (takes ~3 days) <br />
|bgcolor="yellow"| 1 || Review || Beth || M1; Owner = Beth<br />
|-<br />
|| License history || Build a parser to do license history more gracefully and make sure all recipes are correct. (takes ~2 weeks) <br />
|bgcolor="yellow"| 1 || Review || Beth || M2; Owner = Beth<br />
|-<br />
|| Audotbuilder infrastructure || Bring up additional autobuilders and work with sysadmin to configure.<br />
|bgcolor="yellow"| 1 || Review || Beth || M2; Owner = Beth<br />
|-<br />
|| Overall Project || Host a retrospective to discuss what went well and what can be improved in Yocto 1.0.<br />
|bgcolor="yellow"| 1 || Review || Beth || M1; Owner = Beth<br />
|-<br />
|| Release Scripts || Create Release Scripts for OCT 2011 release.<br />
|bgcolor="yellow"| 1 || Review || Beth || M3; Owner = Beth<br />
|-<br />
|| Enhanced Performance || Also, environmental requirements/suggestions for expected performance; Goal is to build in under 1 hour || 2 || Review || from 1.0 ||<br />
|-<br />
|| Disk Space Reduction || <br />
|| 2 || Review || Team ||<br />
|-<br />
|| Share gcc work directories || <br />
|| 2 || Review || Team ||<br />
|-<br />
|| Patch Test System || Create a machine where developers can upload/test patches before submitting them to master to ensure builds won't break when patches are added.<br />
|| 2 || Review || Team ||<br />
|-<br />
|| build statistics reporting || As someone interested in how long it takes to build different images on different hardware configurations and other assorted build metrics, I would like a web based service, that takes output generated by an extended buildstats.bbclass and stores it, to compare against different machines. The end result should be a way to visualize the collected data. See: https://wiki.yoctoproject.org/wiki/Yocto_Buildbot_Autobuilder_Discussions<br />
|| || Review || eflanagan/Jay7/ka6sox || <br />
|-<br />
|| BSP builds || Autobuilder git fetcher improvements || 2 || Review || from 1.0 || M1; Owner = Beth<br />
|-<br />
|| Implement Continuous Autobuilds || Build constantly instead of daily || 2 || Review || from 1.0 || M1; Owner = Beth<br />
|}<br />
<br />
== Performance and Usability ==<br />
This section contains general Yocto performance as well as usability items.<br />
{| border="1"<br />
||'''Feature Name''' ||'''Description''' ||'''Priority''' ||'''Status''' ||'''Source''' ||'''Comments / Bugzilla Links'''<br />
|-<br />
|| Fast boot time || 2 second boot time target<br />
|| 1|| Review|| Team || M2; Owner = Darren<br />
|-<br />
|| Build Yocto behind firewall || Darren will investigate site.conf and documentation<br />
|| 2 || Review|| Dave|| <br />
|-<br />
|| Minimal Image unique || make minimal image smaller || 3 || Review|| Team || <br />
|-<br />
|| POSIX support || address POSIX failures found in 1.1<br />
|| 2|| Review|| Team || <br />
|}<br />
<br />
== Kernel ==<br />
This section contains items specific to the Yocto kernel.<br />
{| border="1"<br />
||'''Feature Name''' ||'''Description''' ||'''Priority''' ||'''Status''' ||'''Source''' ||'''Comments / Bugzilla Links'''<br />
|-<br />
|| BSP kernel config audit || audit kernel configs for the various BSPS<br />
|| 2|| Review|| Team || <br />
|-<br />
|| Tracing: perf trace scripting support || we think usability is the direction to focus on, we want to improve usability through documentation || 2 || Review || from 1.0 || <br />
|-<br />
|| Tracing: tuna, oscilloscope recipes || catch up with Tom, likely to remove || 3 || Review || from 1.0 || <br />
|}<br />
<br />
== Project-Wide Features ==<br />
This section contains features for the entire project or for the project website or mailing lists.<br />
{| border="1"<br />
||'''Feature Name''' ||'''Description''' ||'''Priority''' ||'''Status''' ||'''Source''' ||'''Comments / Bugzilla Links'''<br />
|-<br />
|| Patchwork || is it worth the overhead, are there alternatives || 3 || Review || RP Notes || <br />
|-<br />
|| Alpha || Begin an alpha program after the stabilization period for M3. || 1 || Review || Team || <br />
|-<br />
|| Bugzilla to Wiki || Create a script which automatically populates and updates the Wiki based on changes in bugzilla. <br />
|bgcolor="yellow"| ? || Review || Darren || <br />
|}</div>Davesthttps://wiki.yoctoproject.org/wiki/index.php?title=Yocto_1.0_Schedule&diff=694Yocto 1.0 Schedule2011-02-01T16:33:46Z<p>Davest: /* Sprint E (closes Jan 28, 11:59pm PDT -- pull request sent, initially reviewed) */</p>
<hr />
<div>= v1.0 (release date: Apr 15, 2011) =<br />
----<br />
The detailed milestone map for v1.0 is as below. During the first week of each subsequent milestone past M1 we will have a demonstration of the previous milestone capabilities as well as a planning and design session for the current milestone.<br><br><br />
<br />
== M2 (Nov 08 to Dec 24 -- Dev Complete Dec 10, Stabilize Complete Dec 17, Release Complete Dec 24) ==<br />
=== Sprint A (closes Nov 12, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links''' <br />
|-<br />
|| Poky Features || Kernel interactive targets || To support incremental kernel development having the ability to run menuconfig (or xconfig, etc) directly is a common request. We'll need to add this for commercialization anyway. i.e. bitbake -c menuconfig. This fuctionality already exists. || 1 || Done || Richard || bruceashfield || Enhancement <br />
|-<br />
|| Distribution / components || Distro Audit: Upgrades Planned (Phase 1) || Complete plan for package upgrades in M2 || 1 || Done || Saul || || Continual Maintenance<br />
|-<br />
|| Validation || Runtime testing || Runtime testing of images as part of the autobuilder || 1 || Done || Jiajun/ScottG || rpurdie || project commitment<br />
|- <br />
|| || Poky Image Creator Wireframe/Interaction Plans Complete || || 1 || Done || Josh || ||<br />
|-<br />
|| || SDK Generator Interaction: Plans Complete || || 1 || Done || Jessica || ||<br />
|-<br />
|| || Tracing/Profiling Planning Complete || This needs to cover where we're at now, what we're missing and also propose the future enhancements that may be needed. M2 targets getting existing tools integrated and documented. F2f discussion n the future enhancements || || Done || Tom || ||<br />
|-<br />
|| || Swabber. (Still needs to be integrated into weekly build by default) || || 1 || Done || Josh || ||<br />
|-<br />
|| Build/Release || Release process documentation || || || Done || Beth || ||<br />
|-<br />
|| Validation || Test plan for v1.0 (to address any deficiencies in coverage from v0.9)|| || 1 || Done || Jiajun || ||<br />
|}<br />
<br />
=== Sprint B (closes Nov 19, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| Distro Audit: World Packages|| Audit world packages making sure it all build, making sure all are packages are required || 2|| Done || Saul|| sgw|| Hygiene<br />
|-<br />
|| Tool Development and SDK Features|| SDK Generator Installer UI|| Look at different ways of Installer UI (GTK+ and ncurses) seems none of them is the right choice, decide to go with script to implement all the functionalities of installer and later add UI part on top of it || 1||Done|| Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Customize sysroot setup || Add and test out "--sysroot" config option to cross compiler within Eclipse IDE || 1|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| SDK Generator Installer design revision|| Close all open questions regarding Yocto SDK Generator Installer function design and come up HLD || 1|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Distribution / components|| kernel version|| keeping 2.6.34 as a -stable kernel is the best option. I've also got a newer -devel tree that can be made available or made the default. || 3|| Done || Bruce|| bruceashfield|| enhancement<br />
|-<br />
|| || assign Yocto Project PM|| acquire and assign a program manager for Yocto Project|| || Done || DaveST|| || <br />
|-<br />
|| || assign Yocto Project Sys Admin|| || || Done || Saul|| || <br />
|-<br />
|| Tool Development and SDK Features|| oprofileUI|| Fixing various bugs of the oprofileUI to make it workable on big endian host.(i.e. ppc, mips) || 2 || Done || Jessica || lianhao.lu || Bug #382 / Bug #493<br />
|-<br />
|| Poky Feature|| SDK Version Control|| If we can expect that yocto SDK has lots of release in the future, we might need to consider SDK version control. Currently, every thing installed under /opt/poky which leads to things be overriden, we need to be able to use a scheme like /opt/poky-1.0, /opt/poky-2.0 to distiguish things. || 2|| Done || Josh|| jzhang|| Enhancement<br />
|-<br />
|| Kernel || Kernel plan complete || Flesh our kernel deliverables and add to Yocto 1.0 schedule || || Done|| Darren || dvhart ||<br />
|}<br />
<br />
=== Sprint C (closes Nov 26, 11:59pm PDT -- pull request sent, initially reviewed) :: NOTE: this is US Thanksgiving week ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| Distro Audit: Licence Checksums|| licence checksums || 1|| Done || Saul|| rpurdie|| Hygiene<br />
|-<br />
|| Poky Features || Performance Analysis Completed|| "I'd like someone to instrument a green release build, see where it spends time (hot/cold parsing time, individual task building time) and then compare this with our 0.9 release build. I'd also like to compare the disk usage between the two. Once we have a blame list we can then set about fixing it. Some things I know will come up: a) pseudo, b) checksums/signature code, c) exec() vs fork for executing tasks, d) task based prebuilds increasing disk usage, e) rpm dependency calculations, f) using rpm vs. ipk but I may be wrong and there may be others. We need numbers. "|| 1|| Done || Saul / Qing, Dongxiao|| rpurdie|| Enhancement<br />
|-<br />
|| Poky Features || environment variables for kernel builds|| switching a branch, or adding a configuration feature (and even changing the kernel repo) is often done during development of a BSP. Having some additional variables that are pass the bitbake environment scrub would be useful. i.e. KBRANCH=foo bitbake -c configure linux-yocto. This goes along with the other BSP bootstrapping suggestions. || 2|| Done || Bruce|| bruceashfield|| Enhancement<br />
|-<br />
|| Supported Targets|| ARM Platform Support|| Replace beagleboard with Beagleboard XM - decision || 2|| Done || Bruce|| alex|| Basic Yocto hardware support <br />
|-<br />
|| Distribution / components|| Security Process|| We need a dedicated person to scan and apply critical security updates to the distro. The MeeGo team already has a similar process with some scripts which may be leveraged. To complete the task, the process should be documented and a first pass over the metadata made to establish the current position on security. Any upgrades needed should be identified and a plan to address them should be in place but doesn't have to be implemented by this point.|| 1|| Done || ScottG|| ktian1|| enhancement<br />
|-<br />
|| Tool Development and SDK Features|| SDK Generator Installer Opkg repo design|| Come up a opkg repo design that will mimic the final Yocto package repo layout to be used by SDK Generator Installer to test against|| 2 || Done || Jessica || jzhang || <br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer tar creaion|| Create a Yocto Installer tar ball which contains Installer script and supported opkg component that will be used for installing other Yocto components|| 2 || Done || Jessica || jzhang || <br />
|-<br />
|| Documentation|| Kernel Framework Paper from WR|| The paper from WR needs to be re-written and then posted somewhere on the Yocto Project site. This will involve examiniation of the text and re-writing and formatting for presentation. Currently it is simply a text document. Completion time assuming uninterrupted time is one week.|| High|| Done || Scott Rifenbark|| 1 Week|| Documentation<br />
|-<br />
|| Documentation|| Poky Reference Manual|| This guide exists in the 0.9 form. The re-write of the text needs to be completed. So far, all the chapters have been rewritten but not re-posted on the site. Only the appendices remain for a text scrub. Time to complete this would be a week of uninterrupted time. Ideally, the manual would be a sub-manual that would be referenced and architected into the Yocto Project Development Guide.|| Medium|| Done|| Scott Rifenbark|| 1 Week|| Documentation<br />
|-<br />
|| Kernel || Initial meta-linaro layer || meta-linaro layer providing a kernel, tool-chain, and uboot loader. This deliverable is primarily to get the infrastructure in place and have a buildable kernel. Toolchain on best effort basis. || || Done || Darren || dvhart || Moderate risk of slippage due to holidays.<br />
|-<br />
|| Kernel || Tracing: blktrace and sysprof recipes || || || Done || Tom || dvhart ||<br />
|}<br />
<br />
=== Sprint D (closes Dec 3, 11:59pm PDT -- pull request sent, initially reviewed) :: NOTE: week of the F2F planning meeting ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Kernel || Kernel git branching structure revamped || || 1 || Done || Bruce || dvhart ||<br />
|-<br />
|| Kernel || Tunnel Creek (Crown Bay) || || 1 || Done || Tom || dvhart ||<br />
|}<br />
<br />
=== Sprint E (closes Dec 9 (THURSDAY), 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| Distro Audit: Upgrades Completed (Phase 1)|| Update to new versions as per the agreed plan for M2 from Sprint A|| 1|| Done || Saul|| rpurdie|| Continual Maintenance<br />
|-<br />
|| Distribution / components|| Distro Audit: Src Checksums|| Make sure all SRC_URI components have checksums too || 1|| Done || Saul|| rpurdie|| Hygiene<br />
|-<br />
|| Poky Features || enable KVM with qemu|| today all new Intel processors support VT, which are enabled on most desktop machines which are most frequently used build machine. with VT support, x86/x86-64 qemu target runs faster which is a good thing for emulation environment. This may require some qemu option tweaks and also poky-qemu script enhancement. || 2|| Done || Saul / Edwin|| ktian1|| Enhancement<br />
|-<br />
|| Kernel || New kernel recipes || dev, -devel, -custom || 3 || Done || Bruce || dvhart ||<br />
|-<br />
|| Swabber || Documentation for swabber || || 1 || Done || Alex || ||<br />
|-<br />
|| CCB || Defect triage process in public documented and implemented || || 1 || Done. Triage process is documented, out for review. || Saul || ||<br />
|}<br />
<br />
== M3 (Dec 20 to Feb 08 -- Dev Complete Feb 04, Stabilize Complete Feb 11, Release Complete Feb 18) ==<br />
=== Sprint A (closes Dec 24, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Kernel || Initial meta-rt layer || PREEMPT_RT kernel and related test-cases and benchmarks || 2 || Done || Darren || dvhart || slipped out from M2<br />
|-<br />
|| Poky Features || Fetcher Overhaul Phase 1 - SRC_REV enhancement||<br />
* a) Add code in FetchData::__init__() which will check if the selected fetcher supports srcrev and the automatically call a function to set the src rev value instead of each fetcher doing this.\n <br />
* e) Break SRCREVINACTION deadlock. To do this, we need to start using a keyword for automatically increasing SRCREV, e.g. SRCREV = "AUTOINC". The actual revision can be injected into PV using SRCPV. If we do this there should no longer be a need of the deadlock; <br />
* k) Ensure that we only set __BB_DONT_CACHE when SRCREV = "AUTOREV". This may need a new method call for fetchers to tell whether they're "floating" or locked down.<br />
|| 1|| Done || Saul / Ke, RP|| rpurdie|| Enhancement, slipped out from M2<br />
|-<br />
|| Distribution / components|| Distro Audit Upgrades Planned (Phase 2)|| Complete plan for package upgrades in M2|| 1|| Done || Saul|| || Continual Maintenance<br />
|-<br />
|| Poky Features || Pseudo Performance || Implement the changes to bitbake based on pseudo's enable/disable switch|| 1|| done || Saul / Qing, Dongxiao || rpurdie|| Enhancement, slipped from M2 due to risk and not having Pseudo's change yet.<br />
|-<br />
|| Tool Development and SDK Features|| Fix the issue user target sysroot is owned by root || The ADT installer will use pseudo to extract user target sysroot which ended up owned by root, this need to be fixed || 1|| done || Jessica|| jzhang|| Cleanup <br />
|-<br />
|| Tool Development and SDK Features|| Eclipse poky tree interfacing (metadata file editor)|| Provide a metadata file editor with some syntax checking and keywords highlight capabilities|| 2|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| IDE Project templates|| Templates for various project types: Clutter GUI, Gtk+ GUI, to help developers get started quickly || 2|| Done || Jessica|| josh|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| push TCF/RSE patches upstream|| work with community to finish up our TCF terminal service, TCF/RSE integration remaining patches taken by upstream. Blocking issues including Eclipse Bug #327865 || 1|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Pseudo || Pseudo enhancement to enable on/off switch || || 1 || done || Mark || ||<br />
|-<br />
|| Pseudo || Bitbake enhancement for pseudo on/off switch || || 1 || done || Richard || ||<br />
|-<br />
|| bugzilla || Complete restructure of bugzilla categories || || 1 || done || Saul || ||<br />
|-<br />
|| Poky Features || Image creator ground work || Nomenclature determined, existing gui's bug fixed and backend work implemented || 1 || Done || Joshua || ||<br />
|-<br />
|| Kernel || Tracing: Initial SystemTap recipe || Works on x86 || 3 || Done || Tom || dvhart ||<br />
|-<br />
|| Distribution / components|| Distro Audit: Package Description/Summary completed|| Ensure DESCRIPTION/SUMMARY fields are all audited|| 2|| Done || Mark|| Mark|| Hygiene, was M2, Sprint B but missed window<br />
|-<br />
|| Distribution / components|| Zypper/RPM|| Small write-up of the problems we're having w/ Zypper and what we plan to do. (i.e. create a roadmap/design) - Includes rootfs generation - Package uprev/install/removal || 1 || Done || Mark/Qing || || was M2, Sprint B<br />
|-<br />
|| Distribution / components|| Distro Audit: Licence Checksums|| Make the licence checksums fatal if not present || 1|| Done || Saul|| rpurdie|| Hygiene, was M2, Sprint C<br />
|-<br />
|| Distribution / components|| push of all relevant Wind River patchs to Yocto (patch comparison)|| Ensure patches present to packages in WRS are also in Poky|| 1|| Done || Mark|| Mark|| was M2, Sprint C<br />
|-<br />
|| Poky Features || Performance Enhancement Completed || Initial changes to reduce disk space (sstate-build-*) || 1|| Done || Saul / Qing, Dongxiao || rpurdie|| Enhancement, was M2, Sprint E<br />
|-<br />
|| Distribution / components|| User specified qemu config support|| We'll provide user an edit box which allows advanced qemu user to specify arbitrary qemu configuration to meet their needs, which the poky-qemu scrip will just append the config list towards the end of the list of parameters to bring up qemu, it also expect the poky-qemu script to do some basic sanity check on the user specifications to catch the obvious mistake || 2|| Done || Saul / criping || criping|| enhancement, was M2, Sprint E<br />
|-<br />
|| Tool Development and SDK Features|| SDK Version Control support in SDK generator installer|| If we can expect that yocto SDK has lots of release in the future, we might need to consider SDK version control. Currently, if we un-tar the sdk, it will override the older version. It's not good for app developers since they might need the old version to do something. And also, maybe a finer installer than untar is preferred. Installer will tied to certain SDK version and the installation will go under /opt/poky-versionNo.|| 1|| Done || Jessica|| criping|| Enhancement-expect planning process by Jessica to handle this task. Was M2, Sprint E.<br />
|}<br />
<br />
=== Sprint B (closes Jan 07, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || Bitbake multi-threaded parsing|| Bitbake recipe parsing is currently single threaded. I want to make this multithreaded as the speedup would be nice. If I can only take a single task for myself for 1.0, I'm nominating this one as I enjoy this kind of thing and I have ideas on how to do it. || 1|| Done || Richard|| rpurdie|| Enhancement<br />
|-<br />
|| Distribution / components|| Lock in Kernel/Toolchain version|| Locked in 2.6.37 and gcc 4.5.1. Pending decision to move to 4.5.2 and Linaro || || Done || || Richard|| || <br />
|-<br />
|| Distribution / components|| License Update|| For each of the licences we support, I'd really like to have a licences directory with a copy of that license contained within. When it comes to deciding what a given LICENSE field means, this would be the reference. It also means we can include the licences a given image includes with the image. This continues to make our license handling world class and ahead of the field. || 2|| Done || Beth|| rpurdie|| Hygiene<br />
|-<br />
|| Tool Development and SDK Features|| Qemu configuration change|| Provice edit box for advanced user to specify qemu configurations|| 2|| Done || Jessica|| criping|| <br />
|-<br />
|| Tool Development and SDK Features|| Lock down Eclipse+CDT+TCF version|| Will use Eclipse Halo 3.6 || 1|| Done || Jessica|| || <br />
|-<br />
|| Demo|| Finalize on demo plans for v1.0 launch || || 1|| Done || Dave || || <br />
|-<br />
|| Release || Release plans for v1.0 launch || Fill out the M4 plan with the necessary release activities and timings || 1|| Done || Beth || || <br />
|-<br />
|| Poky Features || Basic image creator GUI || Functional UI missing some Advanced features || 1 || In replan || Joshua || || <br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer for SDK Generator Installation functions support||Detailed feature request can be found at: http://bugzilla.pokylinux.org/show_bug.cgi?id=589|| 1|| Done || Jessica|| rpurdie|| Enhancement<br />
|-<br />
|| Kernel || Tracing: trace-cmd python binding cleanup || || 3 || Done || Darren || dvhart ||<br />
|}<br />
<br />
=== Sprint C (closes Jan 14, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || kernel development layer|| The (correct) poky behaviour of building known revisions coupled with the fetcher requiring a BSP branch to already be present means that local modifications (and kernel source tree) are required for kernel development. I already have a layer that overrides/modifies the behaviour when added to the bblayers.conf and configured into an environment. This seems useful for more people to use. || 2|| Done || Bruce|| bruceashfield|| Enhancement, was M2, Sprint C<br />
|-<br />
|| Distribution / components|| Zypper/RPM|| RPM Up-rev / Zypper Up-rev [lets get to the latest versions]|| 1|| Done || Mark/Qing|| || was M2, Sprint C<br />
|-<br />
|| Supported Targets|| Intel Platform Support|| JasperForest|| 2|| Basic support in place; DPDK evaluation in process, overall BSP plan still TBD || Tom|| davest|| Basic ECG support (Moved from Sprint A)<br />
|-<br />
|| Tool Development and SDK Features|| Eclipse poky tree interfacing (git support)|| Use Eclipse git capability to install poky tree from git repo and able to interact with git repo at file level within Poky tree || 2|| Done || Jessica|| jzhang|| Enhancement<br />
<br />
|-<br />
|| Poky Features || Poky Image Creator|| A standalone application you can run which asks you to select a distro and machine, then presents a list of packages you can select. Once the selection is made, it goes off and bakes you an image which is then presented to you. Implementation wise, it should use the sstate packages, be a bitbake UI and use the usual poky bbclass files to do the image construction behind the scenes. || 1|| Re-plan || Joshua|| rpurdie|| Enhancement<br />
|-<br />
|| Distribution / components|| LSB Sanity|| execute LSB Test and improve passing rate and document failures with clear understanding|| 2|| Done || MarkH/Saul|| sgw|| Hygiene<br />
|-<br />
|| Tool Development and SDK Features|| Image creator integration with Eclipse || || 2|| replan|| Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Kernel || Tracing: perf trace marker support || This is from feedback to the new trace command. Ingo appears to have this nearly complete already. || 3 || Done || Darren || dvhart ||<br />
|-<br />
|| Cleanup || bitbake user experience error handling validation completed || || 2 || Done || Richard || ||<br />
|-<br />
|| Cleanup || variable scrub - ensure all metadata variables are documented || Script with a histogram of variable use done, identified 50 variables to document; Add task for actual documentation update is low on the list || 2 || Done || Scott/Darren || ||<br />
|-<br />
|| Kernel || Tracing: package kernelshark || || 3 || Done || Darren || dvhart ||<br />
|}<br />
<br />
=== Sprint D (closes Jan 21, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Swabber || Complete review of swabber outputs || Move to M3 Sprint D || 1 || Move to M3 Sprint D || Alex || ||<br />
|-<br />
|| Poky Features || Fetcher Overhaul Phase 2 - API reorg||<br />
* f) Add a generic unpack funciton to __init__.py based on the unpack task in Poky ;<br />
* g) Split go() methods into the following steps: i) download() - do whatever transfer is necessary to get the sources locally ii) build_mirror_data() - generate any data that would be needed to construct a source mirror iii) unpack() - takes a directory as an argument of where to place extracted sources;<br />
The existing go() methods should be replaced with a set of calls to the above sections of functionality as appropriate in the individual fetchers. Some of these categories of function make no sense in certain fetchers, in which case they shouldn't need to implement them. Functions are only executed if the method is present.<br />
* h) Change Poky's unpack to call an unpack method in the fetchers.<br />
* i) Change Poky's fetch task to call a "download" method in the fetcher instead of go().<br />
|| 1|| Done || Saul / Ke, RP|| rpurdie|| Enhancement<br />
|-<br />
|| Poky Features || Fetcher Overhaul Phase 3 - git enhancement||<br />
* j) Optimize git fetcher for the new layout so for a git checkout, we clone the repository in download(), then unpack just does a clone with references to the original repo. <br />
* k) Ensure that we only set __BB_DONT_CACHE when SRCREV = "AUTOREV". This may need a new method call for fetchers to tell whether they're "floating" or locked down. <br />
* l) Add a new "BB_NO_NETWORK" variable which the fetchers check before peforming an operation which hits anything remote. This means adding in error messages about why network access is needed at various points (e.g. SRCREV = "AUTOREV" for a given recipe) <br />
* m) Add multiple branch/srcrev support for git fetcher. These would be of the form: git://somelocation/somerepo.git;name=ref1;branch=foo;name=ref2;branch=bar SRCREV_ref1 = "hash1" SRCREV_ref2 = "hash2" which would ensure both hash1 and hash2 were in the final repo. <br />
* n) Change git fetcher to default to git protocol instead of rsync<br />
|| 1|| On track for Feb 3|| Saul / Ke, RP|| rpurdie|| Enhancement<br />
|-<br />
|| Poky Features || DSO linking changes|| "By the default the gcc linker will automatically link any dependant objects/libraries. ""Inherited"" linkages can cause issues, for example, where a shared object changes its dependencies but a program has come to rely on symbols from an implicitly linked library. Fedora implemented this change in F13, seems like it would be useful to have in Poky too. "|| 2|| Done || Saul / Nitin || josh|| bug#516<br />
|-<br />
|| Distribution / components|| Distro Audit Documentation Output|| Audit package documentation output || 2|| on track for Feb 3 || Saul / ScottG || rpurdie|| Hygiene<br />
|-<br />
|| Distribution / components|| Review & Fix Standards Tests|| Review the results from LTP, POSIX and assess the result, fix as appropriate and clearly document failures.|| 2|| LTP plan is done, a Plan to resolve Posix failures to be sent to the m.l. by Feb 18 || Saul/Kevin || sgw|| Hygiene<br />
|-<br />
|| Poky Features || libtool sysroot option|| libtool 2.4 has a sysroot option. We should try and use it, see how it works and whether we can ditch some of our libtool hacks. || 1|| Done || Saul / ScottG || rpurdie|| Enhancement<br />
|-<br />
|| Distribution / components|| MACHINE or Recipe specific sysroots|| Each machine should have its own sysroot. We'll probably have to split do_populate_sysroot into a two step process, creation of the package and than installtion of the package, which the installation of the package being made machine specific (put ${MACHINE} into ${STAMP} and bitbake should do that). Also allowing this to work per recipe would be desireable|| 1|| Done|| Saul / Dongxiao || rpurdie|| Hygiene<br />
|-<br />
|| Distribution / components|| Toolchain Bootstrap Process|| The toolchain as it bootstraps overwrites files like libc.so and libgcc.so in the sysroot directory which causes issues if you just try and rebuild part of the toolchain. Each step of the bootstrap process should use a separate sysroot. Once this is once, sstate file overwriting detection can be added and enabled. || 1|| Done || Saul / Dexuan || rpurdie|| Hygiene<br />
|-<br />
|| Documentation Features|| Package report system|| move to public server [setup a package report system in an internal machine. We need push it publicly available. The basic features like search and report have been there. But there're still some enhancements in plan, to make it a fit place to feel Yocto metadata comfortably]|| 2|| Feb 11 || Saul (Jon) || ktian1|| enhancement<br />
|-<br />
|| Distribution / components||Add headers and libraries to qemu images ||Since we'll be using qemu images as target sysroot, need to create a set of qemu images for minimal, sato, LSB that contains target header and libraries.|| 2|| Done || Saul ||jzhang|| Enhancement<br />
|-<br />
|| Distribution / components|| push of all relevant Wind River patchs to Yocto (patch comparison)|| Update any additional patches needed since M2.|| 1|| On track for Feb 3 || Mark|| Mark|| <br />
|-<br />
|| Distribution / components|| mklibs|| mklibs is a tool to optimize size of [e]glibc for a perticular root file system image. It is useful to save disk space on small devices. || 2|| On track for Feb 3 || Saul|| Nitin Kamble|| enhancement<br />
|-<br />
|| Poky Features || Performance Enhancement || reduce disk space (hardlink) || 1 || Pending review, on track for Feb 3 || Saul / Qing, Dongxiao || rpurdie || Enhancement<br />
|-<br />
|| Kernel || Tracing: perf trace scripting support || || 3 || Drop for 1.0, move to 1.1 || Tom || dvhart ||<br />
|-<br />
|| Kernel || Tracing: tuna, oscillosope recipes || || 3 || Drop for 1.0, move to 1.1 || Tom || dvhart ||<br />
|- <br />
|| BSP || Beagleboard XM Support || || 3 || Done (our part). Darren to ask the community to finish it up. || Darren || dvhart ||<br />
|-<br />
|| BSP || 2.6.37 Crown Bay Support || On Track for Jan 21 || 2 || || Tom || dvhart || <br />
|-<br />
|| BSP || 2.6.37 Emenlow Support || On track for Jan 21 || 2 || || Tom || dvhart || <br />
|}<br />
<br />
=== Sprint E (closes Jan 28, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| rootless X|| rootless x server has better security than x server launched by root. MeeGo already enable this feature. it would be nice for Yocto to also enable it. || 2|| On track for Feb 11 || Saul / Ke || yuke|| enhancement<br />
|-<br />
|| Distribution / components|| perl upgrade|| perl is the most cross un-friendly recipe pending upgrade. || 2|| Done || Nitin|| Nitin Kamble|| enhancement<br />
|-<br />
|| Supported Targets|| Intel Platform Support|| Sandybridge|| 2|| Accept|| Tom|| davest|| Basic ECG support<br />
|-<br />
|| Distribution / components|| performance indicators|| define some indicators (boot time, footprint, build time, power, component benchmarks, etc.) and then collect them for tracking purpose. The result could be posted on the wiki site, and the initial indicators can be easy ones which can be easily retrieved from autobuilder or weekly qa report). This way we have a clear track about the healthy of the Yocto project, and also identify weak areas. We can include qemu targets and several representational boards as the targets. || 2|| On track for Feb 3 || Beth/Jiajun|| ktian1|| enhancement<br />
|-<br />
|| Tool Development and SDK Features|| SDK user workshop|| Have some developers sit down and use our tools to develop demo software for Yocto. || 2|| End of February|| Jessica|| josh|| Enhancement<br />
|-<br />
|| Kernel || Final linux-yocto_git.bb || With 2.6.37 kernel || 1 || Done || Bruce || dvhart ||<br />
|-<br />
|| Kernel || Final meta-linaro layer || 1 || Darren to test on real hardware, on track for Feb 3 || || Darren || dvhart ||<br />
|-<br />
|| Kernel || Sandy Bridge || || 1 || || Tom || dvhart ||<br />
|}<br />
<br />
=== Sprint F (closes Feb 03 (THURSDAY), 11:59pm PDT -- pull request sent, initially reviewed) :: NOTE: China New Year Holiday ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Documentation|| ADT Reference Guide Draft out for review || Outline complete|| High|| WIP || Scott Rifenbark|| jzhang|| Documentation<br />
|-<br />
|| || || || || || || || <br />
|}<br />
<br />
== M4 (Feb 07 to Apr 15 -- Stabilize Complete Mar 18, Release Complete Apr 01, Contingency to Apr 15) ==<br />
<br />
This sprint is the [[Yocto Project v. 1.0 Release Cycle]].<br />
<br />
During this sprint, we will track the [[Yocto Project v1.0 Release Criteria]].<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Documentation|| Migration chapter in the Poky Reference Manual|| This chapter would cover the four identified use-cases for migrating up to the most recent version of Yocto Project. Additionally, it would cover migration scenarios from other development systems. The chapter does not yet exist. The chapter has not been scoped outside of having a meeting that identified four use-cases that did not include migration from a development system outside of Yocto Project. It will take some more scoping time to cover those areas (a day or two). Again, I have no idea of the length. See earlier entries for standard industry writing estimates for software documentation|| Medium|| Not Started|| Scott Rifenbark|| 3-4 Weeks|| Documentation<br />
|-<br />
|| Documentation|| Yocto Project Development Guide|| This manual would be an over-arching document that frames the complete development cycle within Yocto Project. The idea here is that the document would be an umbrella document that spawned and referenced subsequent documents. The organization would be the first chapter overviewing the major development pieces such as recipe creation, building, debugging, publishing, fail-safing, back-door hook creation, etc. Scoping would be about two weeks and length would probably be about 40 pages. Overall development time would likely be a month of uniterruped time.|| Medium|| Not Started|| Scott Rifenbark|| 3 Weeks|| Documentation<br />
|-<br />
|| Validation|| Boottime/Performance Analysis|| Compare Yocto Project performance to other projects such as MeeGo|| 1|| Initial report on where we are by Feb 9 || Darren|| davest|| project commitment<br />
|-<br />
|| || Multilib Support|| Consider developing post-1.0 branch || 1|| to start in M4 || Richard|| ||<br />
|-<br />
|| Validation|| Alpha testing complete|| 4-5 internal developers unfamiliar with Yocto Project try to do a build and report on the experience and issues encountered|| 1|| Done by Feb 18 || Julie|| davest|| <br />
|-<br />
|| || || || || || || || <br />
|}<br />
<br />
== Features needed and to be put into sprints by assigned owners: ==<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || package config option enhancement|| there're several enhancements we may do here: * allow users setting specific config options (local or global) from external tool, such as poky image creator, instead of changing recipes manually. Need a mechanism to convert from variable assignments into exact config options (e.g. feature_${PN} = ""1"" -> ""--enable-feature""). Consequently dependency chain needs update with option status. * host contamination check. We have swabber to check host contamination, but I'm not sure whether it covers configuration phase. If not, this is one area to improve, as not ususually we see configure script checks host bits for available features * conditional option manipulation. In many recipes we enable/disable one option based on availability of other packages. Now this is done manually and not flexible. this should be made automatically though some new annotation to indicate condition, or just base_contains (not convenient: long line, need define distro features) || 2|| Review|| Richard/MarkH|| ktian1|| Enhancement<br />
|-<br />
|| Media|| Yocto Project Awareness Video|| This 2.5 minute video would introduce and describe the benefits of Yocto Project. The video would use entertaining animations that described concepts and benefits. The result would be suitable for YouTube, conferences, and the website. The production is called an "Epipheo" and will be created by Epipheo Studios. The engagement process has begun and the kick-off meeting will be soon. The PO is in place. Time for development is 10 weeks.|| High|| Kick-off Imminent|| Scott Rifenbark|| 10 Weeks|| Media<br />
|-<br />
|| Documentation|| Yocto Project Debugging Guide|| This would be a guide for the debugging and bug tracking process in Yocto Project. Originally, the thought was that we needed a Bugzilla User's Manual. However, since we don't own Bugzilla it doesn't make sense to produce documentation for it. Rather, we should document the process as it fits into the Yocto Project environment. Ideally, the manual would be a sub-manual that would be referenced and architected into the Yocto Project Development Guide. The manual has not been scoped and would take a week to scope. Again, I have no idea of the length. See the previous item for standard industry writing estimates for software documenation.|| Medium|| Not Started|| Scott Rifenbark|| 3-4 Weeks|| Documentation<br />
|-<br />
|| Website|| Yocto Project Website|| The 0.9 website is in place but needs updates. Items for consideration are the left-panel naviagation scheme, a contributions guidance page, color-scheming and theme (possibly).|| Medium|| Not Started|| Scott Rifenbark|| 1-2 Weeks|| Website<br />
|}<br />
<br />
== Features not believed to be needed in v1.0: ==<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || OpenEmbedded/Bitbake Upstreaming|| "We firstly need to review where we are and where OE is. We then need to make a plan about what we're going to push upstream and what we're not. I'd suggest when we're in PRC, we do a crash course in ""dealing with OE"" and then many dedicate a block of time (a week) where the distro team comes up with a patch set we then propose and get merged into OE. I'd like to find a couple of interested people to monitor OE more regularly and start a workflow of things between Poky/OE where appropriate. The key thing to remember is we need to keep the architectures compatible. The team is now at the point where I'm happy for them to actually try building OpenEmbedded and not worry about it tainting them! "|| 2|| Review|| || rpurdie|| Process<br />
|-<br />
|| Poky Features || Handle old versions in WORKDIR|| an incremental build directory may finally include many old versions WORKDIRS. It'll be good to have those old versions tracked in the cache, which can then either generate a report or allow selectively cleaning up an specific version WORKDIR. Or else it's difficult to figure it out when people want to keep the whole tmp directory but like to cleanup some old bits when disk usage is under pressure. If it's not easy to do in bitbake, perhaps some separate scripts would be also helpful || 3|| Review|| || ktian1|| Enhancement<br />
|-<br />
|| Poky Features || run bitbake w/o rebuilding the cache|| "sometimes it's useful to allow run bitbake w/o re-parsing recipes, if we know nothing metadata is changed. we can just allow reusing existing persistent cache. this is useful when people is debugging WORKDIR w/o metadata change. also sometimes ""bitbake -e"" is used frequently to check poky variable information. with existing cache, several seconds can be saved which are not negligible for a developer daily working on Yocto "|| 2|| Review|| || ktian1|| Enhancement<br />
|-<br />
|| Poky Features || parallel make improvement|| parallel make experience is not good, especially when bb threads and make threads are increased larger than 8. So far we either try to fix package makefile or mark the recipe as no parallel make, when build faiures are reported. But this greatly impacts user experience for a successfully continuous build process. Could we define a safe number we do want to support for 1.0 release? and then have our autobuilder, QA test, and developers cover that number immediately and fix any issues accordingly. Then the safe number can be suggested to the Yocto user || 2|| Review|| || ktian1|| Enhancement<br />
|-<br />
|| Poky Features || Dependency packages rebuild/clean|| It is a mechanism to rebulid or clean a package and all other packages which have build/runtime dependency on it. With this change, we can find potential influences of package upgrade to its related packages, which can make the incremental build more trustable. For example, if we upgrade a package to a new vesion which changes its API, this mechanism can easily find out the incompatibility to other packages which have dependency on it. || 2|| Review|| || dongxiao.xu|| Enhancement, replaced by checksum feature<br />
|-<br />
|| Distribution / components|| FOSSology|| This may be similar to License Update above, but start to use FOSSology to track licenses. || 2|| Review|| || sgw|| Hygiene<br />
|-<br />
|| Distribution / components|| Package Developer Tools|| Create a set of Init scripts template and then review our current init scripts and modify them to confirm to the template. || 2|| Review|| || sgw|| Easy of Use<br />
|-<br />
|| Distribution / components|| Package Website|| Complete the work the intern has started on generating the distro tracking information and get it out on the external site. || 2|| Review|| || sgw|| "Hygiene, duplicate of ""Package report system"""<br />
|-<br />
|| Distribution / components|| Bluetooth UI support|| Currently we have bluez package in poky, and we need to have a workable graphic user interface to connect/configure BT devices. One choice may be gnome-bluetooth-applet. || 3|| Review|| || dongxiao.xu|| enhancement<br />
|-<br />
|| Distribution / components|| Connman-gnome enhancement features|| Enable connman-gnome to support features like, WPA Enterprise connection, hidden SSID, etc. || 3|| Review|| || dongxiao.xu|| enhancement<br />
|-<br />
|| Distribution / components|| Java Running Environment support|| Since most embedded systems support java applications running in it, maybe we'd better consider supporting some kinds of JVMs(Embeded JVM). The JVM may not run by default, but user can launch it if running java applications. Compared with GTK/QT, java user number is not small too. || 3|| Review|| || criping|| enhancement<br />
|-<br />
|| Distribution / components|| create more use cases|| UPnP demo is one really good use case showing how Yocto is utilized to make real functionality. and we could create more to show how Yocto is easily adapted to real use cases. Those use cases can be either maintained as seperate demo layers in yocto repo, or in seperate branches for reference. We can also call for community's contribution on this which would make 1.0 full-fledged. Or else the newbies to Yocto may be in puzzle how our sample profiles can satisfy their requirements. || 2|| Review|| || ktian1|| enhancement<br />
|-<br />
|| Distribution / components|| i18n support || internationalization is an important system wide feature. Many component like font, locale affect the i18n. Yocto alreay has some i18n related package like pango, but so far did not consider i18n systematically. so this is place holder to systematically add i18n support. || 2|| Review|| || yuke/qing|| enhancement<br />
|-<br />
|| Distribution / components|| more demos || demos are a good way to educate, push the envelope, and at the same time tout the strengths of the platform. This item just records a current set of ideas from various sources which could/should be implemented: * face-recognition/face-finding, * robotic control/application of face-finding to 'camera-as-sensor' (hexbug demo), * others [tbd, add here]|| 2|| Review|| || tzanussi|| enhancement <br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer support for image-creator and needed yocto-metadata design||Come up design what need to be created as packages to support using "opkg install" for image-creator and needed yocto-metadata|| 2|| WIP, pending comments from RP regarding how to packaging metadata|| Jessica|| rpurdie|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer image-creator and needed poky-metadata support|| The poky build system will build packages for image-creator and needed poky-metadata, which the Yocto Installer will be able to use "opkg install" to install them|| 2|| Review|| Jessica|| rpurdie|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Provide qemu management UI|| In current eclipse plugin, QEMU settings are put together with project configuration. So we can only have limited settings. If we can have a separate QEMU management UI, the end user could firstly create a QEMU config, such as (env file of arch, image location, unfs or not, sato or lsb, mem size, disk size). And then he can launch a QEMU with a specific config. The dependency between project configuration and QEMU config will be resolved. After all QEMU has nothing to do project configuration. Need to careful review the UI to ensure minimal impact to testing matrix. || 3|| Review|| || criping|| "Enhancement, duplicate of ""Qemu mem/disk size can be adjusted"""<br />
|-<br />
|| Tool Development and SDK Features|| QT plugin For Eclipse|| Integrate QT Ecplise plugin and extend for Yocto Project || 3|| Review|| || jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Profiling/Trace GUI's|| We have a wealth of great tracing and profiling tools but the UI's for them are all extremely minimal and usually quite ugly. Would be great if we could compete with, or even better, Apple's offerings here. We have the technology! || 2|| Review|| || josh|| "Enhancement, duplicate of ""Tracing/Profiling Planning Complete"""<br />
|-<br />
|| Tool Development and SDK Features|| Other profiling tools|| Complete Tom's review of profiling tools and architecture || 2|| Review|| || josh|| "Enhancement, duplicate of ""Tracing/Profiling Planning Complete"""<br />
|-<br />
|| Tool Development and SDK Features|| Design next-gen tracing/profiling tools|| Yocto 1.0 will include all the essential existing tracing/profiling tools expected by users, and Josh has proposed a UI integration of all those tools as far as it's possible to do so. That level of integration, basically a 'plugin-level' integration is necessary and useful, but doesn't go far enough. A next-generation tracing tool would integrate at a much more fundamental level; if done properly, it would provide unmatched levels of power and usability to users, and would allow Yocto to distinguish itself in the embedded tracing/profiling space in a way also unmatched by any other distro/build-tool. The implementation would of course not be available for Yocto 1.0, but a coherent design, including prototypes, that could be taken to the community and implemented in a V 1.5 or 2.0 should be done in that time frame. || 1|| Review|| || tzanussi|| "Enhancement, duplicate of ""Tracing/Profiling Planning Complete"""<br />
|-<br />
|| Documentation Features|| Self Documentation of image contents|| "I'd like to see the -doc packages Poky builds being combined into some kind of large documentation index representing the collective API docs of the target being built. This can then be placed on a webserver and viewed over the web. We'd have a demonstration of this for a ""bitbake world"" target. Part of the idea here is to start making good use of the docs as if developers see this they might start writing better docs too. Aim is to lead the field :). There are a number of places poky packages disable doc generation due to missing tools so we'd need to add these so we can enable the doc generation. Many packages already have many docs though too. "|| 2|| Review|| || rpurdie|| enhancement<br />
|-<br />
|| Validation|| Testing Framework|| Add a framework for doing automated testing in the project|| 1|| Review|| || davest|| project commitment<br />
|-<br />
|| Validation|| more SDK builds on autobuilder|| enable more SDK related tests on autobuilder such as meta-ide-support, etc.|| 2|| Review|| || ktian1|| project commitment, addressed by test plan (?)<br />
|-<br />
|| Validation|| more people should try using SDK|| this may not be a feature, but a requirement. SDK including meta-toolchain is one key factor impacting user experience on Yocto. It's not enough to have only SDK team play with it|| 2|| Review|| || ktian1|| project commitment, addressed by test plan (?)<br />
|-<br />
|| Validation|| Unit Testing Framework|| Add a mechanism to bitbake to parse source packages that have unit tests and then execute them on the target|| 3|| Review|| || sgw|| "project commitment, duplicate of ""Testing Framework"""<br />
|-<br />
|| Validation|| Test Case open source|| Open source Yocto test cases with xml format|| 1|| Review|| || yyou|| "project commitment, duplicate of ""Testing Framework"""<br />
|}</div>Davesthttps://wiki.yoctoproject.org/wiki/index.php?title=Yocto_1.0_Schedule&diff=693Yocto 1.0 Schedule2011-02-01T16:24:33Z<p>Davest: /* Sprint D (closes Jan 21, 11:59pm PDT -- pull request sent, initially reviewed) */</p>
<hr />
<div>= v1.0 (release date: Apr 15, 2011) =<br />
----<br />
The detailed milestone map for v1.0 is as below. During the first week of each subsequent milestone past M1 we will have a demonstration of the previous milestone capabilities as well as a planning and design session for the current milestone.<br><br><br />
<br />
== M2 (Nov 08 to Dec 24 -- Dev Complete Dec 10, Stabilize Complete Dec 17, Release Complete Dec 24) ==<br />
=== Sprint A (closes Nov 12, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links''' <br />
|-<br />
|| Poky Features || Kernel interactive targets || To support incremental kernel development having the ability to run menuconfig (or xconfig, etc) directly is a common request. We'll need to add this for commercialization anyway. i.e. bitbake -c menuconfig. This fuctionality already exists. || 1 || Done || Richard || bruceashfield || Enhancement <br />
|-<br />
|| Distribution / components || Distro Audit: Upgrades Planned (Phase 1) || Complete plan for package upgrades in M2 || 1 || Done || Saul || || Continual Maintenance<br />
|-<br />
|| Validation || Runtime testing || Runtime testing of images as part of the autobuilder || 1 || Done || Jiajun/ScottG || rpurdie || project commitment<br />
|- <br />
|| || Poky Image Creator Wireframe/Interaction Plans Complete || || 1 || Done || Josh || ||<br />
|-<br />
|| || SDK Generator Interaction: Plans Complete || || 1 || Done || Jessica || ||<br />
|-<br />
|| || Tracing/Profiling Planning Complete || This needs to cover where we're at now, what we're missing and also propose the future enhancements that may be needed. M2 targets getting existing tools integrated and documented. F2f discussion n the future enhancements || || Done || Tom || ||<br />
|-<br />
|| || Swabber. (Still needs to be integrated into weekly build by default) || || 1 || Done || Josh || ||<br />
|-<br />
|| Build/Release || Release process documentation || || || Done || Beth || ||<br />
|-<br />
|| Validation || Test plan for v1.0 (to address any deficiencies in coverage from v0.9)|| || 1 || Done || Jiajun || ||<br />
|}<br />
<br />
=== Sprint B (closes Nov 19, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| Distro Audit: World Packages|| Audit world packages making sure it all build, making sure all are packages are required || 2|| Done || Saul|| sgw|| Hygiene<br />
|-<br />
|| Tool Development and SDK Features|| SDK Generator Installer UI|| Look at different ways of Installer UI (GTK+ and ncurses) seems none of them is the right choice, decide to go with script to implement all the functionalities of installer and later add UI part on top of it || 1||Done|| Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Customize sysroot setup || Add and test out "--sysroot" config option to cross compiler within Eclipse IDE || 1|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| SDK Generator Installer design revision|| Close all open questions regarding Yocto SDK Generator Installer function design and come up HLD || 1|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Distribution / components|| kernel version|| keeping 2.6.34 as a -stable kernel is the best option. I've also got a newer -devel tree that can be made available or made the default. || 3|| Done || Bruce|| bruceashfield|| enhancement<br />
|-<br />
|| || assign Yocto Project PM|| acquire and assign a program manager for Yocto Project|| || Done || DaveST|| || <br />
|-<br />
|| || assign Yocto Project Sys Admin|| || || Done || Saul|| || <br />
|-<br />
|| Tool Development and SDK Features|| oprofileUI|| Fixing various bugs of the oprofileUI to make it workable on big endian host.(i.e. ppc, mips) || 2 || Done || Jessica || lianhao.lu || Bug #382 / Bug #493<br />
|-<br />
|| Poky Feature|| SDK Version Control|| If we can expect that yocto SDK has lots of release in the future, we might need to consider SDK version control. Currently, every thing installed under /opt/poky which leads to things be overriden, we need to be able to use a scheme like /opt/poky-1.0, /opt/poky-2.0 to distiguish things. || 2|| Done || Josh|| jzhang|| Enhancement<br />
|-<br />
|| Kernel || Kernel plan complete || Flesh our kernel deliverables and add to Yocto 1.0 schedule || || Done|| Darren || dvhart ||<br />
|}<br />
<br />
=== Sprint C (closes Nov 26, 11:59pm PDT -- pull request sent, initially reviewed) :: NOTE: this is US Thanksgiving week ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| Distro Audit: Licence Checksums|| licence checksums || 1|| Done || Saul|| rpurdie|| Hygiene<br />
|-<br />
|| Poky Features || Performance Analysis Completed|| "I'd like someone to instrument a green release build, see where it spends time (hot/cold parsing time, individual task building time) and then compare this with our 0.9 release build. I'd also like to compare the disk usage between the two. Once we have a blame list we can then set about fixing it. Some things I know will come up: a) pseudo, b) checksums/signature code, c) exec() vs fork for executing tasks, d) task based prebuilds increasing disk usage, e) rpm dependency calculations, f) using rpm vs. ipk but I may be wrong and there may be others. We need numbers. "|| 1|| Done || Saul / Qing, Dongxiao|| rpurdie|| Enhancement<br />
|-<br />
|| Poky Features || environment variables for kernel builds|| switching a branch, or adding a configuration feature (and even changing the kernel repo) is often done during development of a BSP. Having some additional variables that are pass the bitbake environment scrub would be useful. i.e. KBRANCH=foo bitbake -c configure linux-yocto. This goes along with the other BSP bootstrapping suggestions. || 2|| Done || Bruce|| bruceashfield|| Enhancement<br />
|-<br />
|| Supported Targets|| ARM Platform Support|| Replace beagleboard with Beagleboard XM - decision || 2|| Done || Bruce|| alex|| Basic Yocto hardware support <br />
|-<br />
|| Distribution / components|| Security Process|| We need a dedicated person to scan and apply critical security updates to the distro. The MeeGo team already has a similar process with some scripts which may be leveraged. To complete the task, the process should be documented and a first pass over the metadata made to establish the current position on security. Any upgrades needed should be identified and a plan to address them should be in place but doesn't have to be implemented by this point.|| 1|| Done || ScottG|| ktian1|| enhancement<br />
|-<br />
|| Tool Development and SDK Features|| SDK Generator Installer Opkg repo design|| Come up a opkg repo design that will mimic the final Yocto package repo layout to be used by SDK Generator Installer to test against|| 2 || Done || Jessica || jzhang || <br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer tar creaion|| Create a Yocto Installer tar ball which contains Installer script and supported opkg component that will be used for installing other Yocto components|| 2 || Done || Jessica || jzhang || <br />
|-<br />
|| Documentation|| Kernel Framework Paper from WR|| The paper from WR needs to be re-written and then posted somewhere on the Yocto Project site. This will involve examiniation of the text and re-writing and formatting for presentation. Currently it is simply a text document. Completion time assuming uninterrupted time is one week.|| High|| Done || Scott Rifenbark|| 1 Week|| Documentation<br />
|-<br />
|| Documentation|| Poky Reference Manual|| This guide exists in the 0.9 form. The re-write of the text needs to be completed. So far, all the chapters have been rewritten but not re-posted on the site. Only the appendices remain for a text scrub. Time to complete this would be a week of uninterrupted time. Ideally, the manual would be a sub-manual that would be referenced and architected into the Yocto Project Development Guide.|| Medium|| Done|| Scott Rifenbark|| 1 Week|| Documentation<br />
|-<br />
|| Kernel || Initial meta-linaro layer || meta-linaro layer providing a kernel, tool-chain, and uboot loader. This deliverable is primarily to get the infrastructure in place and have a buildable kernel. Toolchain on best effort basis. || || Done || Darren || dvhart || Moderate risk of slippage due to holidays.<br />
|-<br />
|| Kernel || Tracing: blktrace and sysprof recipes || || || Done || Tom || dvhart ||<br />
|}<br />
<br />
=== Sprint D (closes Dec 3, 11:59pm PDT -- pull request sent, initially reviewed) :: NOTE: week of the F2F planning meeting ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Kernel || Kernel git branching structure revamped || || 1 || Done || Bruce || dvhart ||<br />
|-<br />
|| Kernel || Tunnel Creek (Crown Bay) || || 1 || Done || Tom || dvhart ||<br />
|}<br />
<br />
=== Sprint E (closes Dec 9 (THURSDAY), 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| Distro Audit: Upgrades Completed (Phase 1)|| Update to new versions as per the agreed plan for M2 from Sprint A|| 1|| Done || Saul|| rpurdie|| Continual Maintenance<br />
|-<br />
|| Distribution / components|| Distro Audit: Src Checksums|| Make sure all SRC_URI components have checksums too || 1|| Done || Saul|| rpurdie|| Hygiene<br />
|-<br />
|| Poky Features || enable KVM with qemu|| today all new Intel processors support VT, which are enabled on most desktop machines which are most frequently used build machine. with VT support, x86/x86-64 qemu target runs faster which is a good thing for emulation environment. This may require some qemu option tweaks and also poky-qemu script enhancement. || 2|| Done || Saul / Edwin|| ktian1|| Enhancement<br />
|-<br />
|| Kernel || New kernel recipes || dev, -devel, -custom || 3 || Done || Bruce || dvhart ||<br />
|-<br />
|| Swabber || Documentation for swabber || || 1 || Done || Alex || ||<br />
|-<br />
|| CCB || Defect triage process in public documented and implemented || || 1 || Done. Triage process is documented, out for review. || Saul || ||<br />
|}<br />
<br />
== M3 (Dec 20 to Feb 08 -- Dev Complete Feb 04, Stabilize Complete Feb 11, Release Complete Feb 18) ==<br />
=== Sprint A (closes Dec 24, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Kernel || Initial meta-rt layer || PREEMPT_RT kernel and related test-cases and benchmarks || 2 || Done || Darren || dvhart || slipped out from M2<br />
|-<br />
|| Poky Features || Fetcher Overhaul Phase 1 - SRC_REV enhancement||<br />
* a) Add code in FetchData::__init__() which will check if the selected fetcher supports srcrev and the automatically call a function to set the src rev value instead of each fetcher doing this.\n <br />
* e) Break SRCREVINACTION deadlock. To do this, we need to start using a keyword for automatically increasing SRCREV, e.g. SRCREV = "AUTOINC". The actual revision can be injected into PV using SRCPV. If we do this there should no longer be a need of the deadlock; <br />
* k) Ensure that we only set __BB_DONT_CACHE when SRCREV = "AUTOREV". This may need a new method call for fetchers to tell whether they're "floating" or locked down.<br />
|| 1|| Done || Saul / Ke, RP|| rpurdie|| Enhancement, slipped out from M2<br />
|-<br />
|| Distribution / components|| Distro Audit Upgrades Planned (Phase 2)|| Complete plan for package upgrades in M2|| 1|| Done || Saul|| || Continual Maintenance<br />
|-<br />
|| Poky Features || Pseudo Performance || Implement the changes to bitbake based on pseudo's enable/disable switch|| 1|| done || Saul / Qing, Dongxiao || rpurdie|| Enhancement, slipped from M2 due to risk and not having Pseudo's change yet.<br />
|-<br />
|| Tool Development and SDK Features|| Fix the issue user target sysroot is owned by root || The ADT installer will use pseudo to extract user target sysroot which ended up owned by root, this need to be fixed || 1|| done || Jessica|| jzhang|| Cleanup <br />
|-<br />
|| Tool Development and SDK Features|| Eclipse poky tree interfacing (metadata file editor)|| Provide a metadata file editor with some syntax checking and keywords highlight capabilities|| 2|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| IDE Project templates|| Templates for various project types: Clutter GUI, Gtk+ GUI, to help developers get started quickly || 2|| Done || Jessica|| josh|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| push TCF/RSE patches upstream|| work with community to finish up our TCF terminal service, TCF/RSE integration remaining patches taken by upstream. Blocking issues including Eclipse Bug #327865 || 1|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Pseudo || Pseudo enhancement to enable on/off switch || || 1 || done || Mark || ||<br />
|-<br />
|| Pseudo || Bitbake enhancement for pseudo on/off switch || || 1 || done || Richard || ||<br />
|-<br />
|| bugzilla || Complete restructure of bugzilla categories || || 1 || done || Saul || ||<br />
|-<br />
|| Poky Features || Image creator ground work || Nomenclature determined, existing gui's bug fixed and backend work implemented || 1 || Done || Joshua || ||<br />
|-<br />
|| Kernel || Tracing: Initial SystemTap recipe || Works on x86 || 3 || Done || Tom || dvhart ||<br />
|-<br />
|| Distribution / components|| Distro Audit: Package Description/Summary completed|| Ensure DESCRIPTION/SUMMARY fields are all audited|| 2|| Done || Mark|| Mark|| Hygiene, was M2, Sprint B but missed window<br />
|-<br />
|| Distribution / components|| Zypper/RPM|| Small write-up of the problems we're having w/ Zypper and what we plan to do. (i.e. create a roadmap/design) - Includes rootfs generation - Package uprev/install/removal || 1 || Done || Mark/Qing || || was M2, Sprint B<br />
|-<br />
|| Distribution / components|| Distro Audit: Licence Checksums|| Make the licence checksums fatal if not present || 1|| Done || Saul|| rpurdie|| Hygiene, was M2, Sprint C<br />
|-<br />
|| Distribution / components|| push of all relevant Wind River patchs to Yocto (patch comparison)|| Ensure patches present to packages in WRS are also in Poky|| 1|| Done || Mark|| Mark|| was M2, Sprint C<br />
|-<br />
|| Poky Features || Performance Enhancement Completed || Initial changes to reduce disk space (sstate-build-*) || 1|| Done || Saul / Qing, Dongxiao || rpurdie|| Enhancement, was M2, Sprint E<br />
|-<br />
|| Distribution / components|| User specified qemu config support|| We'll provide user an edit box which allows advanced qemu user to specify arbitrary qemu configuration to meet their needs, which the poky-qemu scrip will just append the config list towards the end of the list of parameters to bring up qemu, it also expect the poky-qemu script to do some basic sanity check on the user specifications to catch the obvious mistake || 2|| Done || Saul / criping || criping|| enhancement, was M2, Sprint E<br />
|-<br />
|| Tool Development and SDK Features|| SDK Version Control support in SDK generator installer|| If we can expect that yocto SDK has lots of release in the future, we might need to consider SDK version control. Currently, if we un-tar the sdk, it will override the older version. It's not good for app developers since they might need the old version to do something. And also, maybe a finer installer than untar is preferred. Installer will tied to certain SDK version and the installation will go under /opt/poky-versionNo.|| 1|| Done || Jessica|| criping|| Enhancement-expect planning process by Jessica to handle this task. Was M2, Sprint E.<br />
|}<br />
<br />
=== Sprint B (closes Jan 07, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || Bitbake multi-threaded parsing|| Bitbake recipe parsing is currently single threaded. I want to make this multithreaded as the speedup would be nice. If I can only take a single task for myself for 1.0, I'm nominating this one as I enjoy this kind of thing and I have ideas on how to do it. || 1|| Done || Richard|| rpurdie|| Enhancement<br />
|-<br />
|| Distribution / components|| Lock in Kernel/Toolchain version|| Locked in 2.6.37 and gcc 4.5.1. Pending decision to move to 4.5.2 and Linaro || || Done || || Richard|| || <br />
|-<br />
|| Distribution / components|| License Update|| For each of the licences we support, I'd really like to have a licences directory with a copy of that license contained within. When it comes to deciding what a given LICENSE field means, this would be the reference. It also means we can include the licences a given image includes with the image. This continues to make our license handling world class and ahead of the field. || 2|| Done || Beth|| rpurdie|| Hygiene<br />
|-<br />
|| Tool Development and SDK Features|| Qemu configuration change|| Provice edit box for advanced user to specify qemu configurations|| 2|| Done || Jessica|| criping|| <br />
|-<br />
|| Tool Development and SDK Features|| Lock down Eclipse+CDT+TCF version|| Will use Eclipse Halo 3.6 || 1|| Done || Jessica|| || <br />
|-<br />
|| Demo|| Finalize on demo plans for v1.0 launch || || 1|| Done || Dave || || <br />
|-<br />
|| Release || Release plans for v1.0 launch || Fill out the M4 plan with the necessary release activities and timings || 1|| Done || Beth || || <br />
|-<br />
|| Poky Features || Basic image creator GUI || Functional UI missing some Advanced features || 1 || In replan || Joshua || || <br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer for SDK Generator Installation functions support||Detailed feature request can be found at: http://bugzilla.pokylinux.org/show_bug.cgi?id=589|| 1|| Done || Jessica|| rpurdie|| Enhancement<br />
|-<br />
|| Kernel || Tracing: trace-cmd python binding cleanup || || 3 || Done || Darren || dvhart ||<br />
|}<br />
<br />
=== Sprint C (closes Jan 14, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || kernel development layer|| The (correct) poky behaviour of building known revisions coupled with the fetcher requiring a BSP branch to already be present means that local modifications (and kernel source tree) are required for kernel development. I already have a layer that overrides/modifies the behaviour when added to the bblayers.conf and configured into an environment. This seems useful for more people to use. || 2|| Done || Bruce|| bruceashfield|| Enhancement, was M2, Sprint C<br />
|-<br />
|| Distribution / components|| Zypper/RPM|| RPM Up-rev / Zypper Up-rev [lets get to the latest versions]|| 1|| Done || Mark/Qing|| || was M2, Sprint C<br />
|-<br />
|| Supported Targets|| Intel Platform Support|| JasperForest|| 2|| Basic support in place; DPDK evaluation in process, overall BSP plan still TBD || Tom|| davest|| Basic ECG support (Moved from Sprint A)<br />
|-<br />
|| Tool Development and SDK Features|| Eclipse poky tree interfacing (git support)|| Use Eclipse git capability to install poky tree from git repo and able to interact with git repo at file level within Poky tree || 2|| Done || Jessica|| jzhang|| Enhancement<br />
<br />
|-<br />
|| Poky Features || Poky Image Creator|| A standalone application you can run which asks you to select a distro and machine, then presents a list of packages you can select. Once the selection is made, it goes off and bakes you an image which is then presented to you. Implementation wise, it should use the sstate packages, be a bitbake UI and use the usual poky bbclass files to do the image construction behind the scenes. || 1|| Re-plan || Joshua|| rpurdie|| Enhancement<br />
|-<br />
|| Distribution / components|| LSB Sanity|| execute LSB Test and improve passing rate and document failures with clear understanding|| 2|| Done || MarkH/Saul|| sgw|| Hygiene<br />
|-<br />
|| Tool Development and SDK Features|| Image creator integration with Eclipse || || 2|| replan|| Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Kernel || Tracing: perf trace marker support || This is from feedback to the new trace command. Ingo appears to have this nearly complete already. || 3 || Done || Darren || dvhart ||<br />
|-<br />
|| Cleanup || bitbake user experience error handling validation completed || || 2 || Done || Richard || ||<br />
|-<br />
|| Cleanup || variable scrub - ensure all metadata variables are documented || Script with a histogram of variable use done, identified 50 variables to document; Add task for actual documentation update is low on the list || 2 || Done || Scott/Darren || ||<br />
|-<br />
|| Kernel || Tracing: package kernelshark || || 3 || Done || Darren || dvhart ||<br />
|}<br />
<br />
=== Sprint D (closes Jan 21, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Swabber || Complete review of swabber outputs || Move to M3 Sprint D || 1 || Move to M3 Sprint D || Alex || ||<br />
|-<br />
|| Poky Features || Fetcher Overhaul Phase 2 - API reorg||<br />
* f) Add a generic unpack funciton to __init__.py based on the unpack task in Poky ;<br />
* g) Split go() methods into the following steps: i) download() - do whatever transfer is necessary to get the sources locally ii) build_mirror_data() - generate any data that would be needed to construct a source mirror iii) unpack() - takes a directory as an argument of where to place extracted sources;<br />
The existing go() methods should be replaced with a set of calls to the above sections of functionality as appropriate in the individual fetchers. Some of these categories of function make no sense in certain fetchers, in which case they shouldn't need to implement them. Functions are only executed if the method is present.<br />
* h) Change Poky's unpack to call an unpack method in the fetchers.<br />
* i) Change Poky's fetch task to call a "download" method in the fetcher instead of go().<br />
|| 1|| Done || Saul / Ke, RP|| rpurdie|| Enhancement<br />
|-<br />
|| Poky Features || Fetcher Overhaul Phase 3 - git enhancement||<br />
* j) Optimize git fetcher for the new layout so for a git checkout, we clone the repository in download(), then unpack just does a clone with references to the original repo. <br />
* k) Ensure that we only set __BB_DONT_CACHE when SRCREV = "AUTOREV". This may need a new method call for fetchers to tell whether they're "floating" or locked down. <br />
* l) Add a new "BB_NO_NETWORK" variable which the fetchers check before peforming an operation which hits anything remote. This means adding in error messages about why network access is needed at various points (e.g. SRCREV = "AUTOREV" for a given recipe) <br />
* m) Add multiple branch/srcrev support for git fetcher. These would be of the form: git://somelocation/somerepo.git;name=ref1;branch=foo;name=ref2;branch=bar SRCREV_ref1 = "hash1" SRCREV_ref2 = "hash2" which would ensure both hash1 and hash2 were in the final repo. <br />
* n) Change git fetcher to default to git protocol instead of rsync<br />
|| 1|| On track for Feb 3|| Saul / Ke, RP|| rpurdie|| Enhancement<br />
|-<br />
|| Poky Features || DSO linking changes|| "By the default the gcc linker will automatically link any dependant objects/libraries. ""Inherited"" linkages can cause issues, for example, where a shared object changes its dependencies but a program has come to rely on symbols from an implicitly linked library. Fedora implemented this change in F13, seems like it would be useful to have in Poky too. "|| 2|| Done || Saul / Nitin || josh|| bug#516<br />
|-<br />
|| Distribution / components|| Distro Audit Documentation Output|| Audit package documentation output || 2|| on track for Feb 3 || Saul / ScottG || rpurdie|| Hygiene<br />
|-<br />
|| Distribution / components|| Review & Fix Standards Tests|| Review the results from LTP, POSIX and assess the result, fix as appropriate and clearly document failures.|| 2|| LTP plan is done, a Plan to resolve Posix failures to be sent to the m.l. by Feb 18 || Saul/Kevin || sgw|| Hygiene<br />
|-<br />
|| Poky Features || libtool sysroot option|| libtool 2.4 has a sysroot option. We should try and use it, see how it works and whether we can ditch some of our libtool hacks. || 1|| Done || Saul / ScottG || rpurdie|| Enhancement<br />
|-<br />
|| Distribution / components|| MACHINE or Recipe specific sysroots|| Each machine should have its own sysroot. We'll probably have to split do_populate_sysroot into a two step process, creation of the package and than installtion of the package, which the installation of the package being made machine specific (put ${MACHINE} into ${STAMP} and bitbake should do that). Also allowing this to work per recipe would be desireable|| 1|| Done|| Saul / Dongxiao || rpurdie|| Hygiene<br />
|-<br />
|| Distribution / components|| Toolchain Bootstrap Process|| The toolchain as it bootstraps overwrites files like libc.so and libgcc.so in the sysroot directory which causes issues if you just try and rebuild part of the toolchain. Each step of the bootstrap process should use a separate sysroot. Once this is once, sstate file overwriting detection can be added and enabled. || 1|| Done || Saul / Dexuan || rpurdie|| Hygiene<br />
|-<br />
|| Documentation Features|| Package report system|| move to public server [setup a package report system in an internal machine. We need push it publicly available. The basic features like search and report have been there. But there're still some enhancements in plan, to make it a fit place to feel Yocto metadata comfortably]|| 2|| Feb 11 || Saul (Jon) || ktian1|| enhancement<br />
|-<br />
|| Distribution / components||Add headers and libraries to qemu images ||Since we'll be using qemu images as target sysroot, need to create a set of qemu images for minimal, sato, LSB that contains target header and libraries.|| 2|| Done || Saul ||jzhang|| Enhancement<br />
|-<br />
|| Distribution / components|| push of all relevant Wind River patchs to Yocto (patch comparison)|| Update any additional patches needed since M2.|| 1|| On track for Feb 3 || Mark|| Mark|| <br />
|-<br />
|| Distribution / components|| mklibs|| mklibs is a tool to optimize size of [e]glibc for a perticular root file system image. It is useful to save disk space on small devices. || 2|| On track for Feb 3 || Saul|| Nitin Kamble|| enhancement<br />
|-<br />
|| Poky Features || Performance Enhancement || reduce disk space (hardlink) || 1 || Pending review, on track for Feb 3 || Saul / Qing, Dongxiao || rpurdie || Enhancement<br />
|-<br />
|| Kernel || Tracing: perf trace scripting support || || 3 || Drop for 1.0, move to 1.1 || Tom || dvhart ||<br />
|-<br />
|| Kernel || Tracing: tuna, oscillosope recipes || || 3 || Drop for 1.0, move to 1.1 || Tom || dvhart ||<br />
|- <br />
|| BSP || Beagleboard XM Support || || 3 || Done (our part). Darren to ask the community to finish it up. || Darren || dvhart ||<br />
|-<br />
|| BSP || 2.6.37 Crown Bay Support || On Track for Jan 21 || 2 || || Tom || dvhart || <br />
|-<br />
|| BSP || 2.6.37 Emenlow Support || On track for Jan 21 || 2 || || Tom || dvhart || <br />
|}<br />
<br />
=== Sprint E (closes Jan 28, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| rootless X|| rootless x server has better security than x server launched by root. MeeGo already enable this feature. it would be nice for Yocto to also enable it. || 2|| On track for Jan 28 || Saul / Ke || yuke|| enhancement<br />
|-<br />
|| Documentation Features|| Package report system|| finish major feature development and internal review [setup a package report system in an internal machine. We need push it publicly available. The basic features like search and report have been there. But there're still some enhancements in plan, to make it a fit place to feel Yocto metadata comfortably]|| 2|| Move to Sprint E || Jonathan || ktian1|| enhancement, was M2, Sprint E<br />
|-<br />
|| Distribution / components|| perl upgrade|| perl is the most cross un-friendly recipe pending upgrade. || 2|| Done || Nitin|| Nitin Kamble|| enhancement<br />
|-<br />
|| Supported Targets|| Intel Platform Support|| Sandybridge|| 2|| Accept|| Tom|| davest|| Basic ECG support<br />
|-<br />
|| Distribution / components|| performance indicators|| define some indicators (boot time, footprint, build time, power, component benchmarks, etc.) and then collect them for tracking purpose. The result could be posted on the wiki site, and the initial indicators can be easy ones which can be easily retrieved from autobuilder or weekly qa report). This way we have a clear track about the healthy of the Yocto project, and also identify weak areas. We can include qemu targets and several representational boards as the targets. || 2|| Sprint F || Beth/Jiajun|| ktian1|| enhancement<br />
|-<br />
|| Tool Development and SDK Features|| SDK user workshop|| Have some developers sit down and use our tools to develop demo software for Yocto. || 2|| End of February|| Jessica|| josh|| Enhancement<br />
|-<br />
|| Distribution / components|| Zypper/RPM|| Integration based on design from Sprint B|| 1|| On track for Jan28 || Mark/Qing|| sgw|| Functionality, was M2, Sprint E<br />
|-<br />
|| Kernel || Final linux-yocto_git.bb || With 2.6.37 kernel || 1 || Done || Bruce || dvhart ||<br />
|-<br />
|| Kernel || Final meta-linaro layer || 1 || On track for Jan 28 || || Darren || dvhart ||<br />
|-<br />
|| Kernel || Sandy Bridge || || 1 || || Tom || dvhart ||<br />
|}<br />
<br />
=== Sprint F (closes Feb 03 (THURSDAY), 11:59pm PDT -- pull request sent, initially reviewed) :: NOTE: China New Year Holiday ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Documentation|| ADT Reference Guide Draft out for review || Outline complete|| High|| WIP || Scott Rifenbark|| jzhang|| Documentation<br />
|-<br />
|| || || || || || || || <br />
|}<br />
<br />
== M4 (Feb 07 to Apr 15 -- Stabilize Complete Mar 18, Release Complete Apr 01, Contingency to Apr 15) ==<br />
<br />
This sprint is the [[Yocto Project v. 1.0 Release Cycle]].<br />
<br />
During this sprint, we will track the [[Yocto Project v1.0 Release Criteria]].<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Documentation|| Migration chapter in the Poky Reference Manual|| This chapter would cover the four identified use-cases for migrating up to the most recent version of Yocto Project. Additionally, it would cover migration scenarios from other development systems. The chapter does not yet exist. The chapter has not been scoped outside of having a meeting that identified four use-cases that did not include migration from a development system outside of Yocto Project. It will take some more scoping time to cover those areas (a day or two). Again, I have no idea of the length. See earlier entries for standard industry writing estimates for software documentation|| Medium|| Not Started|| Scott Rifenbark|| 3-4 Weeks|| Documentation<br />
|-<br />
|| Documentation|| Yocto Project Development Guide|| This manual would be an over-arching document that frames the complete development cycle within Yocto Project. The idea here is that the document would be an umbrella document that spawned and referenced subsequent documents. The organization would be the first chapter overviewing the major development pieces such as recipe creation, building, debugging, publishing, fail-safing, back-door hook creation, etc. Scoping would be about two weeks and length would probably be about 40 pages. Overall development time would likely be a month of uniterruped time.|| Medium|| Not Started|| Scott Rifenbark|| 3 Weeks|| Documentation<br />
|-<br />
|| Validation|| Boottime/Performance Analysis|| Compare Yocto Project performance to other projects such as MeeGo|| 1|| Initial report on where we are by Feb 9 || Darren|| davest|| project commitment<br />
|-<br />
|| || Multilib Support|| Consider developing post-1.0 branch || 1|| to start in M4 || Richard|| ||<br />
|-<br />
|| Validation|| Alpha testing complete|| 4-5 internal developers unfamiliar with Yocto Project try to do a build and report on the experience and issues encountered|| 1|| Done by Feb 18 || Julie|| davest|| <br />
|-<br />
|| || || || || || || || <br />
|}<br />
<br />
== Features needed and to be put into sprints by assigned owners: ==<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || package config option enhancement|| there're several enhancements we may do here: * allow users setting specific config options (local or global) from external tool, such as poky image creator, instead of changing recipes manually. Need a mechanism to convert from variable assignments into exact config options (e.g. feature_${PN} = ""1"" -> ""--enable-feature""). Consequently dependency chain needs update with option status. * host contamination check. We have swabber to check host contamination, but I'm not sure whether it covers configuration phase. If not, this is one area to improve, as not ususually we see configure script checks host bits for available features * conditional option manipulation. In many recipes we enable/disable one option based on availability of other packages. Now this is done manually and not flexible. this should be made automatically though some new annotation to indicate condition, or just base_contains (not convenient: long line, need define distro features) || 2|| Review|| Richard/MarkH|| ktian1|| Enhancement<br />
|-<br />
|| Media|| Yocto Project Awareness Video|| This 2.5 minute video would introduce and describe the benefits of Yocto Project. The video would use entertaining animations that described concepts and benefits. The result would be suitable for YouTube, conferences, and the website. The production is called an "Epipheo" and will be created by Epipheo Studios. The engagement process has begun and the kick-off meeting will be soon. The PO is in place. Time for development is 10 weeks.|| High|| Kick-off Imminent|| Scott Rifenbark|| 10 Weeks|| Media<br />
|-<br />
|| Documentation|| Yocto Project Debugging Guide|| This would be a guide for the debugging and bug tracking process in Yocto Project. Originally, the thought was that we needed a Bugzilla User's Manual. However, since we don't own Bugzilla it doesn't make sense to produce documentation for it. Rather, we should document the process as it fits into the Yocto Project environment. Ideally, the manual would be a sub-manual that would be referenced and architected into the Yocto Project Development Guide. The manual has not been scoped and would take a week to scope. Again, I have no idea of the length. See the previous item for standard industry writing estimates for software documenation.|| Medium|| Not Started|| Scott Rifenbark|| 3-4 Weeks|| Documentation<br />
|-<br />
|| Website|| Yocto Project Website|| The 0.9 website is in place but needs updates. Items for consideration are the left-panel naviagation scheme, a contributions guidance page, color-scheming and theme (possibly).|| Medium|| Not Started|| Scott Rifenbark|| 1-2 Weeks|| Website<br />
|}<br />
<br />
== Features not believed to be needed in v1.0: ==<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || OpenEmbedded/Bitbake Upstreaming|| "We firstly need to review where we are and where OE is. We then need to make a plan about what we're going to push upstream and what we're not. I'd suggest when we're in PRC, we do a crash course in ""dealing with OE"" and then many dedicate a block of time (a week) where the distro team comes up with a patch set we then propose and get merged into OE. I'd like to find a couple of interested people to monitor OE more regularly and start a workflow of things between Poky/OE where appropriate. The key thing to remember is we need to keep the architectures compatible. The team is now at the point where I'm happy for them to actually try building OpenEmbedded and not worry about it tainting them! "|| 2|| Review|| || rpurdie|| Process<br />
|-<br />
|| Poky Features || Handle old versions in WORKDIR|| an incremental build directory may finally include many old versions WORKDIRS. It'll be good to have those old versions tracked in the cache, which can then either generate a report or allow selectively cleaning up an specific version WORKDIR. Or else it's difficult to figure it out when people want to keep the whole tmp directory but like to cleanup some old bits when disk usage is under pressure. If it's not easy to do in bitbake, perhaps some separate scripts would be also helpful || 3|| Review|| || ktian1|| Enhancement<br />
|-<br />
|| Poky Features || run bitbake w/o rebuilding the cache|| "sometimes it's useful to allow run bitbake w/o re-parsing recipes, if we know nothing metadata is changed. we can just allow reusing existing persistent cache. this is useful when people is debugging WORKDIR w/o metadata change. also sometimes ""bitbake -e"" is used frequently to check poky variable information. with existing cache, several seconds can be saved which are not negligible for a developer daily working on Yocto "|| 2|| Review|| || ktian1|| Enhancement<br />
|-<br />
|| Poky Features || parallel make improvement|| parallel make experience is not good, especially when bb threads and make threads are increased larger than 8. So far we either try to fix package makefile or mark the recipe as no parallel make, when build faiures are reported. But this greatly impacts user experience for a successfully continuous build process. Could we define a safe number we do want to support for 1.0 release? and then have our autobuilder, QA test, and developers cover that number immediately and fix any issues accordingly. Then the safe number can be suggested to the Yocto user || 2|| Review|| || ktian1|| Enhancement<br />
|-<br />
|| Poky Features || Dependency packages rebuild/clean|| It is a mechanism to rebulid or clean a package and all other packages which have build/runtime dependency on it. With this change, we can find potential influences of package upgrade to its related packages, which can make the incremental build more trustable. For example, if we upgrade a package to a new vesion which changes its API, this mechanism can easily find out the incompatibility to other packages which have dependency on it. || 2|| Review|| || dongxiao.xu|| Enhancement, replaced by checksum feature<br />
|-<br />
|| Distribution / components|| FOSSology|| This may be similar to License Update above, but start to use FOSSology to track licenses. || 2|| Review|| || sgw|| Hygiene<br />
|-<br />
|| Distribution / components|| Package Developer Tools|| Create a set of Init scripts template and then review our current init scripts and modify them to confirm to the template. || 2|| Review|| || sgw|| Easy of Use<br />
|-<br />
|| Distribution / components|| Package Website|| Complete the work the intern has started on generating the distro tracking information and get it out on the external site. || 2|| Review|| || sgw|| "Hygiene, duplicate of ""Package report system"""<br />
|-<br />
|| Distribution / components|| Bluetooth UI support|| Currently we have bluez package in poky, and we need to have a workable graphic user interface to connect/configure BT devices. One choice may be gnome-bluetooth-applet. || 3|| Review|| || dongxiao.xu|| enhancement<br />
|-<br />
|| Distribution / components|| Connman-gnome enhancement features|| Enable connman-gnome to support features like, WPA Enterprise connection, hidden SSID, etc. || 3|| Review|| || dongxiao.xu|| enhancement<br />
|-<br />
|| Distribution / components|| Java Running Environment support|| Since most embedded systems support java applications running in it, maybe we'd better consider supporting some kinds of JVMs(Embeded JVM). The JVM may not run by default, but user can launch it if running java applications. Compared with GTK/QT, java user number is not small too. || 3|| Review|| || criping|| enhancement<br />
|-<br />
|| Distribution / components|| create more use cases|| UPnP demo is one really good use case showing how Yocto is utilized to make real functionality. and we could create more to show how Yocto is easily adapted to real use cases. Those use cases can be either maintained as seperate demo layers in yocto repo, or in seperate branches for reference. We can also call for community's contribution on this which would make 1.0 full-fledged. Or else the newbies to Yocto may be in puzzle how our sample profiles can satisfy their requirements. || 2|| Review|| || ktian1|| enhancement<br />
|-<br />
|| Distribution / components|| i18n support || internationalization is an important system wide feature. Many component like font, locale affect the i18n. Yocto alreay has some i18n related package like pango, but so far did not consider i18n systematically. so this is place holder to systematically add i18n support. || 2|| Review|| || yuke/qing|| enhancement<br />
|-<br />
|| Distribution / components|| more demos || demos are a good way to educate, push the envelope, and at the same time tout the strengths of the platform. This item just records a current set of ideas from various sources which could/should be implemented: * face-recognition/face-finding, * robotic control/application of face-finding to 'camera-as-sensor' (hexbug demo), * others [tbd, add here]|| 2|| Review|| || tzanussi|| enhancement <br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer support for image-creator and needed yocto-metadata design||Come up design what need to be created as packages to support using "opkg install" for image-creator and needed yocto-metadata|| 2|| WIP, pending comments from RP regarding how to packaging metadata|| Jessica|| rpurdie|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer image-creator and needed poky-metadata support|| The poky build system will build packages for image-creator and needed poky-metadata, which the Yocto Installer will be able to use "opkg install" to install them|| 2|| Review|| Jessica|| rpurdie|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Provide qemu management UI|| In current eclipse plugin, QEMU settings are put together with project configuration. So we can only have limited settings. If we can have a separate QEMU management UI, the end user could firstly create a QEMU config, such as (env file of arch, image location, unfs or not, sato or lsb, mem size, disk size). And then he can launch a QEMU with a specific config. The dependency between project configuration and QEMU config will be resolved. After all QEMU has nothing to do project configuration. Need to careful review the UI to ensure minimal impact to testing matrix. || 3|| Review|| || criping|| "Enhancement, duplicate of ""Qemu mem/disk size can be adjusted"""<br />
|-<br />
|| Tool Development and SDK Features|| QT plugin For Eclipse|| Integrate QT Ecplise plugin and extend for Yocto Project || 3|| Review|| || jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Profiling/Trace GUI's|| We have a wealth of great tracing and profiling tools but the UI's for them are all extremely minimal and usually quite ugly. Would be great if we could compete with, or even better, Apple's offerings here. We have the technology! || 2|| Review|| || josh|| "Enhancement, duplicate of ""Tracing/Profiling Planning Complete"""<br />
|-<br />
|| Tool Development and SDK Features|| Other profiling tools|| Complete Tom's review of profiling tools and architecture || 2|| Review|| || josh|| "Enhancement, duplicate of ""Tracing/Profiling Planning Complete"""<br />
|-<br />
|| Tool Development and SDK Features|| Design next-gen tracing/profiling tools|| Yocto 1.0 will include all the essential existing tracing/profiling tools expected by users, and Josh has proposed a UI integration of all those tools as far as it's possible to do so. That level of integration, basically a 'plugin-level' integration is necessary and useful, but doesn't go far enough. A next-generation tracing tool would integrate at a much more fundamental level; if done properly, it would provide unmatched levels of power and usability to users, and would allow Yocto to distinguish itself in the embedded tracing/profiling space in a way also unmatched by any other distro/build-tool. The implementation would of course not be available for Yocto 1.0, but a coherent design, including prototypes, that could be taken to the community and implemented in a V 1.5 or 2.0 should be done in that time frame. || 1|| Review|| || tzanussi|| "Enhancement, duplicate of ""Tracing/Profiling Planning Complete"""<br />
|-<br />
|| Documentation Features|| Self Documentation of image contents|| "I'd like to see the -doc packages Poky builds being combined into some kind of large documentation index representing the collective API docs of the target being built. This can then be placed on a webserver and viewed over the web. We'd have a demonstration of this for a ""bitbake world"" target. Part of the idea here is to start making good use of the docs as if developers see this they might start writing better docs too. Aim is to lead the field :). There are a number of places poky packages disable doc generation due to missing tools so we'd need to add these so we can enable the doc generation. Many packages already have many docs though too. "|| 2|| Review|| || rpurdie|| enhancement<br />
|-<br />
|| Validation|| Testing Framework|| Add a framework for doing automated testing in the project|| 1|| Review|| || davest|| project commitment<br />
|-<br />
|| Validation|| more SDK builds on autobuilder|| enable more SDK related tests on autobuilder such as meta-ide-support, etc.|| 2|| Review|| || ktian1|| project commitment, addressed by test plan (?)<br />
|-<br />
|| Validation|| more people should try using SDK|| this may not be a feature, but a requirement. SDK including meta-toolchain is one key factor impacting user experience on Yocto. It's not enough to have only SDK team play with it|| 2|| Review|| || ktian1|| project commitment, addressed by test plan (?)<br />
|-<br />
|| Validation|| Unit Testing Framework|| Add a mechanism to bitbake to parse source packages that have unit tests and then execute them on the target|| 3|| Review|| || sgw|| "project commitment, duplicate of ""Testing Framework"""<br />
|-<br />
|| Validation|| Test Case open source|| Open source Yocto test cases with xml format|| 1|| Review|| || yyou|| "project commitment, duplicate of ""Testing Framework"""<br />
|}</div>Davesthttps://wiki.yoctoproject.org/wiki/index.php?title=Yocto_1.0_Schedule&diff=692Yocto 1.0 Schedule2011-02-01T16:22:32Z<p>Davest: /* Sprint D (closes Jan 21, 11:59pm PDT -- pull request sent, initially reviewed) */</p>
<hr />
<div>= v1.0 (release date: Apr 15, 2011) =<br />
----<br />
The detailed milestone map for v1.0 is as below. During the first week of each subsequent milestone past M1 we will have a demonstration of the previous milestone capabilities as well as a planning and design session for the current milestone.<br><br><br />
<br />
== M2 (Nov 08 to Dec 24 -- Dev Complete Dec 10, Stabilize Complete Dec 17, Release Complete Dec 24) ==<br />
=== Sprint A (closes Nov 12, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links''' <br />
|-<br />
|| Poky Features || Kernel interactive targets || To support incremental kernel development having the ability to run menuconfig (or xconfig, etc) directly is a common request. We'll need to add this for commercialization anyway. i.e. bitbake -c menuconfig. This fuctionality already exists. || 1 || Done || Richard || bruceashfield || Enhancement <br />
|-<br />
|| Distribution / components || Distro Audit: Upgrades Planned (Phase 1) || Complete plan for package upgrades in M2 || 1 || Done || Saul || || Continual Maintenance<br />
|-<br />
|| Validation || Runtime testing || Runtime testing of images as part of the autobuilder || 1 || Done || Jiajun/ScottG || rpurdie || project commitment<br />
|- <br />
|| || Poky Image Creator Wireframe/Interaction Plans Complete || || 1 || Done || Josh || ||<br />
|-<br />
|| || SDK Generator Interaction: Plans Complete || || 1 || Done || Jessica || ||<br />
|-<br />
|| || Tracing/Profiling Planning Complete || This needs to cover where we're at now, what we're missing and also propose the future enhancements that may be needed. M2 targets getting existing tools integrated and documented. F2f discussion n the future enhancements || || Done || Tom || ||<br />
|-<br />
|| || Swabber. (Still needs to be integrated into weekly build by default) || || 1 || Done || Josh || ||<br />
|-<br />
|| Build/Release || Release process documentation || || || Done || Beth || ||<br />
|-<br />
|| Validation || Test plan for v1.0 (to address any deficiencies in coverage from v0.9)|| || 1 || Done || Jiajun || ||<br />
|}<br />
<br />
=== Sprint B (closes Nov 19, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| Distro Audit: World Packages|| Audit world packages making sure it all build, making sure all are packages are required || 2|| Done || Saul|| sgw|| Hygiene<br />
|-<br />
|| Tool Development and SDK Features|| SDK Generator Installer UI|| Look at different ways of Installer UI (GTK+ and ncurses) seems none of them is the right choice, decide to go with script to implement all the functionalities of installer and later add UI part on top of it || 1||Done|| Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Customize sysroot setup || Add and test out "--sysroot" config option to cross compiler within Eclipse IDE || 1|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| SDK Generator Installer design revision|| Close all open questions regarding Yocto SDK Generator Installer function design and come up HLD || 1|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Distribution / components|| kernel version|| keeping 2.6.34 as a -stable kernel is the best option. I've also got a newer -devel tree that can be made available or made the default. || 3|| Done || Bruce|| bruceashfield|| enhancement<br />
|-<br />
|| || assign Yocto Project PM|| acquire and assign a program manager for Yocto Project|| || Done || DaveST|| || <br />
|-<br />
|| || assign Yocto Project Sys Admin|| || || Done || Saul|| || <br />
|-<br />
|| Tool Development and SDK Features|| oprofileUI|| Fixing various bugs of the oprofileUI to make it workable on big endian host.(i.e. ppc, mips) || 2 || Done || Jessica || lianhao.lu || Bug #382 / Bug #493<br />
|-<br />
|| Poky Feature|| SDK Version Control|| If we can expect that yocto SDK has lots of release in the future, we might need to consider SDK version control. Currently, every thing installed under /opt/poky which leads to things be overriden, we need to be able to use a scheme like /opt/poky-1.0, /opt/poky-2.0 to distiguish things. || 2|| Done || Josh|| jzhang|| Enhancement<br />
|-<br />
|| Kernel || Kernel plan complete || Flesh our kernel deliverables and add to Yocto 1.0 schedule || || Done|| Darren || dvhart ||<br />
|}<br />
<br />
=== Sprint C (closes Nov 26, 11:59pm PDT -- pull request sent, initially reviewed) :: NOTE: this is US Thanksgiving week ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| Distro Audit: Licence Checksums|| licence checksums || 1|| Done || Saul|| rpurdie|| Hygiene<br />
|-<br />
|| Poky Features || Performance Analysis Completed|| "I'd like someone to instrument a green release build, see where it spends time (hot/cold parsing time, individual task building time) and then compare this with our 0.9 release build. I'd also like to compare the disk usage between the two. Once we have a blame list we can then set about fixing it. Some things I know will come up: a) pseudo, b) checksums/signature code, c) exec() vs fork for executing tasks, d) task based prebuilds increasing disk usage, e) rpm dependency calculations, f) using rpm vs. ipk but I may be wrong and there may be others. We need numbers. "|| 1|| Done || Saul / Qing, Dongxiao|| rpurdie|| Enhancement<br />
|-<br />
|| Poky Features || environment variables for kernel builds|| switching a branch, or adding a configuration feature (and even changing the kernel repo) is often done during development of a BSP. Having some additional variables that are pass the bitbake environment scrub would be useful. i.e. KBRANCH=foo bitbake -c configure linux-yocto. This goes along with the other BSP bootstrapping suggestions. || 2|| Done || Bruce|| bruceashfield|| Enhancement<br />
|-<br />
|| Supported Targets|| ARM Platform Support|| Replace beagleboard with Beagleboard XM - decision || 2|| Done || Bruce|| alex|| Basic Yocto hardware support <br />
|-<br />
|| Distribution / components|| Security Process|| We need a dedicated person to scan and apply critical security updates to the distro. The MeeGo team already has a similar process with some scripts which may be leveraged. To complete the task, the process should be documented and a first pass over the metadata made to establish the current position on security. Any upgrades needed should be identified and a plan to address them should be in place but doesn't have to be implemented by this point.|| 1|| Done || ScottG|| ktian1|| enhancement<br />
|-<br />
|| Tool Development and SDK Features|| SDK Generator Installer Opkg repo design|| Come up a opkg repo design that will mimic the final Yocto package repo layout to be used by SDK Generator Installer to test against|| 2 || Done || Jessica || jzhang || <br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer tar creaion|| Create a Yocto Installer tar ball which contains Installer script and supported opkg component that will be used for installing other Yocto components|| 2 || Done || Jessica || jzhang || <br />
|-<br />
|| Documentation|| Kernel Framework Paper from WR|| The paper from WR needs to be re-written and then posted somewhere on the Yocto Project site. This will involve examiniation of the text and re-writing and formatting for presentation. Currently it is simply a text document. Completion time assuming uninterrupted time is one week.|| High|| Done || Scott Rifenbark|| 1 Week|| Documentation<br />
|-<br />
|| Documentation|| Poky Reference Manual|| This guide exists in the 0.9 form. The re-write of the text needs to be completed. So far, all the chapters have been rewritten but not re-posted on the site. Only the appendices remain for a text scrub. Time to complete this would be a week of uninterrupted time. Ideally, the manual would be a sub-manual that would be referenced and architected into the Yocto Project Development Guide.|| Medium|| Done|| Scott Rifenbark|| 1 Week|| Documentation<br />
|-<br />
|| Kernel || Initial meta-linaro layer || meta-linaro layer providing a kernel, tool-chain, and uboot loader. This deliverable is primarily to get the infrastructure in place and have a buildable kernel. Toolchain on best effort basis. || || Done || Darren || dvhart || Moderate risk of slippage due to holidays.<br />
|-<br />
|| Kernel || Tracing: blktrace and sysprof recipes || || || Done || Tom || dvhart ||<br />
|}<br />
<br />
=== Sprint D (closes Dec 3, 11:59pm PDT -- pull request sent, initially reviewed) :: NOTE: week of the F2F planning meeting ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Kernel || Kernel git branching structure revamped || || 1 || Done || Bruce || dvhart ||<br />
|-<br />
|| Kernel || Tunnel Creek (Crown Bay) || || 1 || Done || Tom || dvhart ||<br />
|}<br />
<br />
=== Sprint E (closes Dec 9 (THURSDAY), 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| Distro Audit: Upgrades Completed (Phase 1)|| Update to new versions as per the agreed plan for M2 from Sprint A|| 1|| Done || Saul|| rpurdie|| Continual Maintenance<br />
|-<br />
|| Distribution / components|| Distro Audit: Src Checksums|| Make sure all SRC_URI components have checksums too || 1|| Done || Saul|| rpurdie|| Hygiene<br />
|-<br />
|| Poky Features || enable KVM with qemu|| today all new Intel processors support VT, which are enabled on most desktop machines which are most frequently used build machine. with VT support, x86/x86-64 qemu target runs faster which is a good thing for emulation environment. This may require some qemu option tweaks and also poky-qemu script enhancement. || 2|| Done || Saul / Edwin|| ktian1|| Enhancement<br />
|-<br />
|| Kernel || New kernel recipes || dev, -devel, -custom || 3 || Done || Bruce || dvhart ||<br />
|-<br />
|| Swabber || Documentation for swabber || || 1 || Done || Alex || ||<br />
|-<br />
|| CCB || Defect triage process in public documented and implemented || || 1 || Done. Triage process is documented, out for review. || Saul || ||<br />
|}<br />
<br />
== M3 (Dec 20 to Feb 08 -- Dev Complete Feb 04, Stabilize Complete Feb 11, Release Complete Feb 18) ==<br />
=== Sprint A (closes Dec 24, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Kernel || Initial meta-rt layer || PREEMPT_RT kernel and related test-cases and benchmarks || 2 || Done || Darren || dvhart || slipped out from M2<br />
|-<br />
|| Poky Features || Fetcher Overhaul Phase 1 - SRC_REV enhancement||<br />
* a) Add code in FetchData::__init__() which will check if the selected fetcher supports srcrev and the automatically call a function to set the src rev value instead of each fetcher doing this.\n <br />
* e) Break SRCREVINACTION deadlock. To do this, we need to start using a keyword for automatically increasing SRCREV, e.g. SRCREV = "AUTOINC". The actual revision can be injected into PV using SRCPV. If we do this there should no longer be a need of the deadlock; <br />
* k) Ensure that we only set __BB_DONT_CACHE when SRCREV = "AUTOREV". This may need a new method call for fetchers to tell whether they're "floating" or locked down.<br />
|| 1|| Done || Saul / Ke, RP|| rpurdie|| Enhancement, slipped out from M2<br />
|-<br />
|| Distribution / components|| Distro Audit Upgrades Planned (Phase 2)|| Complete plan for package upgrades in M2|| 1|| Done || Saul|| || Continual Maintenance<br />
|-<br />
|| Poky Features || Pseudo Performance || Implement the changes to bitbake based on pseudo's enable/disable switch|| 1|| done || Saul / Qing, Dongxiao || rpurdie|| Enhancement, slipped from M2 due to risk and not having Pseudo's change yet.<br />
|-<br />
|| Tool Development and SDK Features|| Fix the issue user target sysroot is owned by root || The ADT installer will use pseudo to extract user target sysroot which ended up owned by root, this need to be fixed || 1|| done || Jessica|| jzhang|| Cleanup <br />
|-<br />
|| Tool Development and SDK Features|| Eclipse poky tree interfacing (metadata file editor)|| Provide a metadata file editor with some syntax checking and keywords highlight capabilities|| 2|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| IDE Project templates|| Templates for various project types: Clutter GUI, Gtk+ GUI, to help developers get started quickly || 2|| Done || Jessica|| josh|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| push TCF/RSE patches upstream|| work with community to finish up our TCF terminal service, TCF/RSE integration remaining patches taken by upstream. Blocking issues including Eclipse Bug #327865 || 1|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Pseudo || Pseudo enhancement to enable on/off switch || || 1 || done || Mark || ||<br />
|-<br />
|| Pseudo || Bitbake enhancement for pseudo on/off switch || || 1 || done || Richard || ||<br />
|-<br />
|| bugzilla || Complete restructure of bugzilla categories || || 1 || done || Saul || ||<br />
|-<br />
|| Poky Features || Image creator ground work || Nomenclature determined, existing gui's bug fixed and backend work implemented || 1 || Done || Joshua || ||<br />
|-<br />
|| Kernel || Tracing: Initial SystemTap recipe || Works on x86 || 3 || Done || Tom || dvhart ||<br />
|-<br />
|| Distribution / components|| Distro Audit: Package Description/Summary completed|| Ensure DESCRIPTION/SUMMARY fields are all audited|| 2|| Done || Mark|| Mark|| Hygiene, was M2, Sprint B but missed window<br />
|-<br />
|| Distribution / components|| Zypper/RPM|| Small write-up of the problems we're having w/ Zypper and what we plan to do. (i.e. create a roadmap/design) - Includes rootfs generation - Package uprev/install/removal || 1 || Done || Mark/Qing || || was M2, Sprint B<br />
|-<br />
|| Distribution / components|| Distro Audit: Licence Checksums|| Make the licence checksums fatal if not present || 1|| Done || Saul|| rpurdie|| Hygiene, was M2, Sprint C<br />
|-<br />
|| Distribution / components|| push of all relevant Wind River patchs to Yocto (patch comparison)|| Ensure patches present to packages in WRS are also in Poky|| 1|| Done || Mark|| Mark|| was M2, Sprint C<br />
|-<br />
|| Poky Features || Performance Enhancement Completed || Initial changes to reduce disk space (sstate-build-*) || 1|| Done || Saul / Qing, Dongxiao || rpurdie|| Enhancement, was M2, Sprint E<br />
|-<br />
|| Distribution / components|| User specified qemu config support|| We'll provide user an edit box which allows advanced qemu user to specify arbitrary qemu configuration to meet their needs, which the poky-qemu scrip will just append the config list towards the end of the list of parameters to bring up qemu, it also expect the poky-qemu script to do some basic sanity check on the user specifications to catch the obvious mistake || 2|| Done || Saul / criping || criping|| enhancement, was M2, Sprint E<br />
|-<br />
|| Tool Development and SDK Features|| SDK Version Control support in SDK generator installer|| If we can expect that yocto SDK has lots of release in the future, we might need to consider SDK version control. Currently, if we un-tar the sdk, it will override the older version. It's not good for app developers since they might need the old version to do something. And also, maybe a finer installer than untar is preferred. Installer will tied to certain SDK version and the installation will go under /opt/poky-versionNo.|| 1|| Done || Jessica|| criping|| Enhancement-expect planning process by Jessica to handle this task. Was M2, Sprint E.<br />
|}<br />
<br />
=== Sprint B (closes Jan 07, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || Bitbake multi-threaded parsing|| Bitbake recipe parsing is currently single threaded. I want to make this multithreaded as the speedup would be nice. If I can only take a single task for myself for 1.0, I'm nominating this one as I enjoy this kind of thing and I have ideas on how to do it. || 1|| Done || Richard|| rpurdie|| Enhancement<br />
|-<br />
|| Distribution / components|| Lock in Kernel/Toolchain version|| Locked in 2.6.37 and gcc 4.5.1. Pending decision to move to 4.5.2 and Linaro || || Done || || Richard|| || <br />
|-<br />
|| Distribution / components|| License Update|| For each of the licences we support, I'd really like to have a licences directory with a copy of that license contained within. When it comes to deciding what a given LICENSE field means, this would be the reference. It also means we can include the licences a given image includes with the image. This continues to make our license handling world class and ahead of the field. || 2|| Done || Beth|| rpurdie|| Hygiene<br />
|-<br />
|| Tool Development and SDK Features|| Qemu configuration change|| Provice edit box for advanced user to specify qemu configurations|| 2|| Done || Jessica|| criping|| <br />
|-<br />
|| Tool Development and SDK Features|| Lock down Eclipse+CDT+TCF version|| Will use Eclipse Halo 3.6 || 1|| Done || Jessica|| || <br />
|-<br />
|| Demo|| Finalize on demo plans for v1.0 launch || || 1|| Done || Dave || || <br />
|-<br />
|| Release || Release plans for v1.0 launch || Fill out the M4 plan with the necessary release activities and timings || 1|| Done || Beth || || <br />
|-<br />
|| Poky Features || Basic image creator GUI || Functional UI missing some Advanced features || 1 || In replan || Joshua || || <br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer for SDK Generator Installation functions support||Detailed feature request can be found at: http://bugzilla.pokylinux.org/show_bug.cgi?id=589|| 1|| Done || Jessica|| rpurdie|| Enhancement<br />
|-<br />
|| Kernel || Tracing: trace-cmd python binding cleanup || || 3 || Done || Darren || dvhart ||<br />
|}<br />
<br />
=== Sprint C (closes Jan 14, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || kernel development layer|| The (correct) poky behaviour of building known revisions coupled with the fetcher requiring a BSP branch to already be present means that local modifications (and kernel source tree) are required for kernel development. I already have a layer that overrides/modifies the behaviour when added to the bblayers.conf and configured into an environment. This seems useful for more people to use. || 2|| Done || Bruce|| bruceashfield|| Enhancement, was M2, Sprint C<br />
|-<br />
|| Distribution / components|| Zypper/RPM|| RPM Up-rev / Zypper Up-rev [lets get to the latest versions]|| 1|| Done || Mark/Qing|| || was M2, Sprint C<br />
|-<br />
|| Supported Targets|| Intel Platform Support|| JasperForest|| 2|| Basic support in place; DPDK evaluation in process, overall BSP plan still TBD || Tom|| davest|| Basic ECG support (Moved from Sprint A)<br />
|-<br />
|| Tool Development and SDK Features|| Eclipse poky tree interfacing (git support)|| Use Eclipse git capability to install poky tree from git repo and able to interact with git repo at file level within Poky tree || 2|| Done || Jessica|| jzhang|| Enhancement<br />
<br />
|-<br />
|| Poky Features || Poky Image Creator|| A standalone application you can run which asks you to select a distro and machine, then presents a list of packages you can select. Once the selection is made, it goes off and bakes you an image which is then presented to you. Implementation wise, it should use the sstate packages, be a bitbake UI and use the usual poky bbclass files to do the image construction behind the scenes. || 1|| Re-plan || Joshua|| rpurdie|| Enhancement<br />
|-<br />
|| Distribution / components|| LSB Sanity|| execute LSB Test and improve passing rate and document failures with clear understanding|| 2|| Done || MarkH/Saul|| sgw|| Hygiene<br />
|-<br />
|| Tool Development and SDK Features|| Image creator integration with Eclipse || || 2|| replan|| Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Kernel || Tracing: perf trace marker support || This is from feedback to the new trace command. Ingo appears to have this nearly complete already. || 3 || Done || Darren || dvhart ||<br />
|-<br />
|| Cleanup || bitbake user experience error handling validation completed || || 2 || Done || Richard || ||<br />
|-<br />
|| Cleanup || variable scrub - ensure all metadata variables are documented || Script with a histogram of variable use done, identified 50 variables to document; Add task for actual documentation update is low on the list || 2 || Done || Scott/Darren || ||<br />
|-<br />
|| Kernel || Tracing: package kernelshark || || 3 || Done || Darren || dvhart ||<br />
|}<br />
<br />
=== Sprint D (closes Jan 21, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Swabber || Complete review of swabber outputs || Move to M3 Sprint D || 1 || Move to M3 Sprint D || Alex || ||<br />
|-<br />
|| Poky Features || Fetcher Overhaul Phase 2 - API reorg||<br />
* f) Add a generic unpack funciton to __init__.py based on the unpack task in Poky ;<br />
* g) Split go() methods into the following steps: i) download() - do whatever transfer is necessary to get the sources locally ii) build_mirror_data() - generate any data that would be needed to construct a source mirror iii) unpack() - takes a directory as an argument of where to place extracted sources;<br />
The existing go() methods should be replaced with a set of calls to the above sections of functionality as appropriate in the individual fetchers. Some of these categories of function make no sense in certain fetchers, in which case they shouldn't need to implement them. Functions are only executed if the method is present.<br />
* h) Change Poky's unpack to call an unpack method in the fetchers.<br />
* i) Change Poky's fetch task to call a "download" method in the fetcher instead of go().<br />
|| 1|| Done || Saul / Ke, RP|| rpurdie|| Enhancement<br />
|-<br />
|| Poky Features || Fetcher Overhaul Phase 3 - git enhancement||<br />
* j) Optimize git fetcher for the new layout so for a git checkout, we clone the repository in download(), then unpack just does a clone with references to the original repo. <br />
* k) Ensure that we only set __BB_DONT_CACHE when SRCREV = "AUTOREV". This may need a new method call for fetchers to tell whether they're "floating" or locked down. <br />
* l) Add a new "BB_NO_NETWORK" variable which the fetchers check before peforming an operation which hits anything remote. This means adding in error messages about why network access is needed at various points (e.g. SRCREV = "AUTOREV" for a given recipe) <br />
* m) Add multiple branch/srcrev support for git fetcher. These would be of the form: git://somelocation/somerepo.git;name=ref1;branch=foo;name=ref2;branch=bar SRCREV_ref1 = "hash1" SRCREV_ref2 = "hash2" which would ensure both hash1 and hash2 were in the final repo. <br />
* n) Change git fetcher to default to git protocol instead of rsync<br />
|| 1|| On track for Feb 3|| Saul / Ke, RP|| rpurdie|| Enhancement<br />
|-<br />
|| Poky Features || DSO linking changes|| "By the default the gcc linker will automatically link any dependant objects/libraries. ""Inherited"" linkages can cause issues, for example, where a shared object changes its dependencies but a program has come to rely on symbols from an implicitly linked library. Fedora implemented this change in F13, seems like it would be useful to have in Poky too. "|| 2|| Done || Saul / Nitin || josh|| bug#516<br />
|-<br />
|| Distribution / components|| Distro Audit Documentation Output|| Audit package documentation output || 2|| on track for Feb 3 || Saul / ScottG || rpurdie|| Hygiene<br />
|-<br />
|| Distribution / components|| Review & Fix Standards Tests|| Review the results from LTP, POSIX and assess the result, fix as appropriate and clearly document failures.|| 2|| LTP plan is done, a Plan to resolve Posix failures to be sent to the m.l. by Feb 18 || Saul/Kevin || sgw|| Hygiene<br />
|-<br />
|| Poky Features || libtool sysroot option|| libtool 2.4 has a sysroot option. We should try and use it, see how it works and whether we can ditch some of our libtool hacks. || 1|| Done || Saul / ScottG || rpurdie|| Enhancement<br />
|-<br />
|| Distribution / components|| MACHINE or Recipe specific sysroots|| Each machine should have its own sysroot. We'll probably have to split do_populate_sysroot into a two step process, creation of the package and than installtion of the package, which the installation of the package being made machine specific (put ${MACHINE} into ${STAMP} and bitbake should do that). Also allowing this to work per recipe would be desireable|| 1|| Done|| Saul / Dongxiao || rpurdie|| Hygiene<br />
|-<br />
|| Distribution / components|| Toolchain Bootstrap Process|| The toolchain as it bootstraps overwrites files like libc.so and libgcc.so in the sysroot directory which causes issues if you just try and rebuild part of the toolchain. Each step of the bootstrap process should use a separate sysroot. Once this is once, sstate file overwriting detection can be added and enabled. || 1|| Done || Saul / Dexuan || rpurdie|| Hygiene<br />
|-<br />
|| Documentation Features|| Package report system|| move to public server [setup a package report system in an internal machine. We need push it publicly available. The basic features like search and report have been there. But there're still some enhancements in plan, to make it a fit place to feel Yocto metadata comfortably]|| 2|| Feb 11 || Saul (Jon) || ktian1|| enhancement<br />
|-<br />
|| Distribution / components||Add headers and libraries to qemu images ||Since we'll be using qemu images as target sysroot, need to create a set of qemu images for minimal, sato, LSB that contains target header and libraries.|| 2|| Done || Saul ||jzhang|| Enhancement<br />
|-<br />
|| Distribution / components|| push of all relevant Wind River patchs to Yocto (patch comparison)|| Update any additional patches needed since M2.|| 1|| On track for Feb 3 || Mark|| Mark|| <br />
|-<br />
|| Distribution / components|| mklibs|| mklibs is a tool to optimize size of [e]glibc for a perticular root file system image. It is useful to save disk space on small devices. || 2|| On track for Feb 3 || Saul|| Nitin Kamble|| enhancement<br />
|-<br />
|| Poky Features || Performance Enhancement || reduce disk space (hardlink) || 1 || Pending review, on track for Feb 3 || Saul / Qing, Dongxiao || rpurdie || Enhancement<br />
|-<br />
|| Kernel || Tracing: perf trace scripting support || || 3 || Drop for 1.0, move to 1.1 || Tom || dvhart ||<br />
|-<br />
|| Kernel || Tracing: tuna, oscillosope recipes || || 3 || Drop for 1.0, move to 1.1 || Tom || dvhart ||<br />
|- <br />
|| BSP || Beagleboard XM Support || || 3 || 2.6.34 done, 2.6.37 support works and patches will come out this week || Darren || dvhart ||<br />
|-<br />
|| BSP || 2.6.37 Crown Bay Support || On Track for Jan 21 || 2 || || Tom || dvhart || <br />
|-<br />
|| BSP || 2.6.37 Emenlow Support || On track for Jan 21 || 2 || || Tom || dvhart || <br />
|}<br />
<br />
=== Sprint E (closes Jan 28, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| rootless X|| rootless x server has better security than x server launched by root. MeeGo already enable this feature. it would be nice for Yocto to also enable it. || 2|| On track for Jan 28 || Saul / Ke || yuke|| enhancement<br />
|-<br />
|| Documentation Features|| Package report system|| finish major feature development and internal review [setup a package report system in an internal machine. We need push it publicly available. The basic features like search and report have been there. But there're still some enhancements in plan, to make it a fit place to feel Yocto metadata comfortably]|| 2|| Move to Sprint E || Jonathan || ktian1|| enhancement, was M2, Sprint E<br />
|-<br />
|| Distribution / components|| perl upgrade|| perl is the most cross un-friendly recipe pending upgrade. || 2|| Done || Nitin|| Nitin Kamble|| enhancement<br />
|-<br />
|| Supported Targets|| Intel Platform Support|| Sandybridge|| 2|| Accept|| Tom|| davest|| Basic ECG support<br />
|-<br />
|| Distribution / components|| performance indicators|| define some indicators (boot time, footprint, build time, power, component benchmarks, etc.) and then collect them for tracking purpose. The result could be posted on the wiki site, and the initial indicators can be easy ones which can be easily retrieved from autobuilder or weekly qa report). This way we have a clear track about the healthy of the Yocto project, and also identify weak areas. We can include qemu targets and several representational boards as the targets. || 2|| Sprint F || Beth/Jiajun|| ktian1|| enhancement<br />
|-<br />
|| Tool Development and SDK Features|| SDK user workshop|| Have some developers sit down and use our tools to develop demo software for Yocto. || 2|| End of February|| Jessica|| josh|| Enhancement<br />
|-<br />
|| Distribution / components|| Zypper/RPM|| Integration based on design from Sprint B|| 1|| On track for Jan28 || Mark/Qing|| sgw|| Functionality, was M2, Sprint E<br />
|-<br />
|| Kernel || Final linux-yocto_git.bb || With 2.6.37 kernel || 1 || Done || Bruce || dvhart ||<br />
|-<br />
|| Kernel || Final meta-linaro layer || 1 || On track for Jan 28 || || Darren || dvhart ||<br />
|-<br />
|| Kernel || Sandy Bridge || || 1 || || Tom || dvhart ||<br />
|}<br />
<br />
=== Sprint F (closes Feb 03 (THURSDAY), 11:59pm PDT -- pull request sent, initially reviewed) :: NOTE: China New Year Holiday ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Documentation|| ADT Reference Guide Draft out for review || Outline complete|| High|| WIP || Scott Rifenbark|| jzhang|| Documentation<br />
|-<br />
|| || || || || || || || <br />
|}<br />
<br />
== M4 (Feb 07 to Apr 15 -- Stabilize Complete Mar 18, Release Complete Apr 01, Contingency to Apr 15) ==<br />
<br />
This sprint is the [[Yocto Project v. 1.0 Release Cycle]].<br />
<br />
During this sprint, we will track the [[Yocto Project v1.0 Release Criteria]].<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Documentation|| Migration chapter in the Poky Reference Manual|| This chapter would cover the four identified use-cases for migrating up to the most recent version of Yocto Project. Additionally, it would cover migration scenarios from other development systems. The chapter does not yet exist. The chapter has not been scoped outside of having a meeting that identified four use-cases that did not include migration from a development system outside of Yocto Project. It will take some more scoping time to cover those areas (a day or two). Again, I have no idea of the length. See earlier entries for standard industry writing estimates for software documentation|| Medium|| Not Started|| Scott Rifenbark|| 3-4 Weeks|| Documentation<br />
|-<br />
|| Documentation|| Yocto Project Development Guide|| This manual would be an over-arching document that frames the complete development cycle within Yocto Project. The idea here is that the document would be an umbrella document that spawned and referenced subsequent documents. The organization would be the first chapter overviewing the major development pieces such as recipe creation, building, debugging, publishing, fail-safing, back-door hook creation, etc. Scoping would be about two weeks and length would probably be about 40 pages. Overall development time would likely be a month of uniterruped time.|| Medium|| Not Started|| Scott Rifenbark|| 3 Weeks|| Documentation<br />
|-<br />
|| Validation|| Boottime/Performance Analysis|| Compare Yocto Project performance to other projects such as MeeGo|| 1|| Initial report on where we are by Feb 9 || Darren|| davest|| project commitment<br />
|-<br />
|| || Multilib Support|| Consider developing post-1.0 branch || 1|| to start in M4 || Richard|| ||<br />
|-<br />
|| Validation|| Alpha testing complete|| 4-5 internal developers unfamiliar with Yocto Project try to do a build and report on the experience and issues encountered|| 1|| Done by Feb 18 || Julie|| davest|| <br />
|-<br />
|| || || || || || || || <br />
|}<br />
<br />
== Features needed and to be put into sprints by assigned owners: ==<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || package config option enhancement|| there're several enhancements we may do here: * allow users setting specific config options (local or global) from external tool, such as poky image creator, instead of changing recipes manually. Need a mechanism to convert from variable assignments into exact config options (e.g. feature_${PN} = ""1"" -> ""--enable-feature""). Consequently dependency chain needs update with option status. * host contamination check. We have swabber to check host contamination, but I'm not sure whether it covers configuration phase. If not, this is one area to improve, as not ususually we see configure script checks host bits for available features * conditional option manipulation. In many recipes we enable/disable one option based on availability of other packages. Now this is done manually and not flexible. this should be made automatically though some new annotation to indicate condition, or just base_contains (not convenient: long line, need define distro features) || 2|| Review|| Richard/MarkH|| ktian1|| Enhancement<br />
|-<br />
|| Media|| Yocto Project Awareness Video|| This 2.5 minute video would introduce and describe the benefits of Yocto Project. The video would use entertaining animations that described concepts and benefits. The result would be suitable for YouTube, conferences, and the website. The production is called an "Epipheo" and will be created by Epipheo Studios. The engagement process has begun and the kick-off meeting will be soon. The PO is in place. Time for development is 10 weeks.|| High|| Kick-off Imminent|| Scott Rifenbark|| 10 Weeks|| Media<br />
|-<br />
|| Documentation|| Yocto Project Debugging Guide|| This would be a guide for the debugging and bug tracking process in Yocto Project. Originally, the thought was that we needed a Bugzilla User's Manual. However, since we don't own Bugzilla it doesn't make sense to produce documentation for it. Rather, we should document the process as it fits into the Yocto Project environment. Ideally, the manual would be a sub-manual that would be referenced and architected into the Yocto Project Development Guide. The manual has not been scoped and would take a week to scope. Again, I have no idea of the length. See the previous item for standard industry writing estimates for software documenation.|| Medium|| Not Started|| Scott Rifenbark|| 3-4 Weeks|| Documentation<br />
|-<br />
|| Website|| Yocto Project Website|| The 0.9 website is in place but needs updates. Items for consideration are the left-panel naviagation scheme, a contributions guidance page, color-scheming and theme (possibly).|| Medium|| Not Started|| Scott Rifenbark|| 1-2 Weeks|| Website<br />
|}<br />
<br />
== Features not believed to be needed in v1.0: ==<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || OpenEmbedded/Bitbake Upstreaming|| "We firstly need to review where we are and where OE is. We then need to make a plan about what we're going to push upstream and what we're not. I'd suggest when we're in PRC, we do a crash course in ""dealing with OE"" and then many dedicate a block of time (a week) where the distro team comes up with a patch set we then propose and get merged into OE. I'd like to find a couple of interested people to monitor OE more regularly and start a workflow of things between Poky/OE where appropriate. The key thing to remember is we need to keep the architectures compatible. The team is now at the point where I'm happy for them to actually try building OpenEmbedded and not worry about it tainting them! "|| 2|| Review|| || rpurdie|| Process<br />
|-<br />
|| Poky Features || Handle old versions in WORKDIR|| an incremental build directory may finally include many old versions WORKDIRS. It'll be good to have those old versions tracked in the cache, which can then either generate a report or allow selectively cleaning up an specific version WORKDIR. Or else it's difficult to figure it out when people want to keep the whole tmp directory but like to cleanup some old bits when disk usage is under pressure. If it's not easy to do in bitbake, perhaps some separate scripts would be also helpful || 3|| Review|| || ktian1|| Enhancement<br />
|-<br />
|| Poky Features || run bitbake w/o rebuilding the cache|| "sometimes it's useful to allow run bitbake w/o re-parsing recipes, if we know nothing metadata is changed. we can just allow reusing existing persistent cache. this is useful when people is debugging WORKDIR w/o metadata change. also sometimes ""bitbake -e"" is used frequently to check poky variable information. with existing cache, several seconds can be saved which are not negligible for a developer daily working on Yocto "|| 2|| Review|| || ktian1|| Enhancement<br />
|-<br />
|| Poky Features || parallel make improvement|| parallel make experience is not good, especially when bb threads and make threads are increased larger than 8. So far we either try to fix package makefile or mark the recipe as no parallel make, when build faiures are reported. But this greatly impacts user experience for a successfully continuous build process. Could we define a safe number we do want to support for 1.0 release? and then have our autobuilder, QA test, and developers cover that number immediately and fix any issues accordingly. Then the safe number can be suggested to the Yocto user || 2|| Review|| || ktian1|| Enhancement<br />
|-<br />
|| Poky Features || Dependency packages rebuild/clean|| It is a mechanism to rebulid or clean a package and all other packages which have build/runtime dependency on it. With this change, we can find potential influences of package upgrade to its related packages, which can make the incremental build more trustable. For example, if we upgrade a package to a new vesion which changes its API, this mechanism can easily find out the incompatibility to other packages which have dependency on it. || 2|| Review|| || dongxiao.xu|| Enhancement, replaced by checksum feature<br />
|-<br />
|| Distribution / components|| FOSSology|| This may be similar to License Update above, but start to use FOSSology to track licenses. || 2|| Review|| || sgw|| Hygiene<br />
|-<br />
|| Distribution / components|| Package Developer Tools|| Create a set of Init scripts template and then review our current init scripts and modify them to confirm to the template. || 2|| Review|| || sgw|| Easy of Use<br />
|-<br />
|| Distribution / components|| Package Website|| Complete the work the intern has started on generating the distro tracking information and get it out on the external site. || 2|| Review|| || sgw|| "Hygiene, duplicate of ""Package report system"""<br />
|-<br />
|| Distribution / components|| Bluetooth UI support|| Currently we have bluez package in poky, and we need to have a workable graphic user interface to connect/configure BT devices. One choice may be gnome-bluetooth-applet. || 3|| Review|| || dongxiao.xu|| enhancement<br />
|-<br />
|| Distribution / components|| Connman-gnome enhancement features|| Enable connman-gnome to support features like, WPA Enterprise connection, hidden SSID, etc. || 3|| Review|| || dongxiao.xu|| enhancement<br />
|-<br />
|| Distribution / components|| Java Running Environment support|| Since most embedded systems support java applications running in it, maybe we'd better consider supporting some kinds of JVMs(Embeded JVM). The JVM may not run by default, but user can launch it if running java applications. Compared with GTK/QT, java user number is not small too. || 3|| Review|| || criping|| enhancement<br />
|-<br />
|| Distribution / components|| create more use cases|| UPnP demo is one really good use case showing how Yocto is utilized to make real functionality. and we could create more to show how Yocto is easily adapted to real use cases. Those use cases can be either maintained as seperate demo layers in yocto repo, or in seperate branches for reference. We can also call for community's contribution on this which would make 1.0 full-fledged. Or else the newbies to Yocto may be in puzzle how our sample profiles can satisfy their requirements. || 2|| Review|| || ktian1|| enhancement<br />
|-<br />
|| Distribution / components|| i18n support || internationalization is an important system wide feature. Many component like font, locale affect the i18n. Yocto alreay has some i18n related package like pango, but so far did not consider i18n systematically. so this is place holder to systematically add i18n support. || 2|| Review|| || yuke/qing|| enhancement<br />
|-<br />
|| Distribution / components|| more demos || demos are a good way to educate, push the envelope, and at the same time tout the strengths of the platform. This item just records a current set of ideas from various sources which could/should be implemented: * face-recognition/face-finding, * robotic control/application of face-finding to 'camera-as-sensor' (hexbug demo), * others [tbd, add here]|| 2|| Review|| || tzanussi|| enhancement <br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer support for image-creator and needed yocto-metadata design||Come up design what need to be created as packages to support using "opkg install" for image-creator and needed yocto-metadata|| 2|| WIP, pending comments from RP regarding how to packaging metadata|| Jessica|| rpurdie|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer image-creator and needed poky-metadata support|| The poky build system will build packages for image-creator and needed poky-metadata, which the Yocto Installer will be able to use "opkg install" to install them|| 2|| Review|| Jessica|| rpurdie|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Provide qemu management UI|| In current eclipse plugin, QEMU settings are put together with project configuration. So we can only have limited settings. If we can have a separate QEMU management UI, the end user could firstly create a QEMU config, such as (env file of arch, image location, unfs or not, sato or lsb, mem size, disk size). And then he can launch a QEMU with a specific config. The dependency between project configuration and QEMU config will be resolved. After all QEMU has nothing to do project configuration. Need to careful review the UI to ensure minimal impact to testing matrix. || 3|| Review|| || criping|| "Enhancement, duplicate of ""Qemu mem/disk size can be adjusted"""<br />
|-<br />
|| Tool Development and SDK Features|| QT plugin For Eclipse|| Integrate QT Ecplise plugin and extend for Yocto Project || 3|| Review|| || jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Profiling/Trace GUI's|| We have a wealth of great tracing and profiling tools but the UI's for them are all extremely minimal and usually quite ugly. Would be great if we could compete with, or even better, Apple's offerings here. We have the technology! || 2|| Review|| || josh|| "Enhancement, duplicate of ""Tracing/Profiling Planning Complete"""<br />
|-<br />
|| Tool Development and SDK Features|| Other profiling tools|| Complete Tom's review of profiling tools and architecture || 2|| Review|| || josh|| "Enhancement, duplicate of ""Tracing/Profiling Planning Complete"""<br />
|-<br />
|| Tool Development and SDK Features|| Design next-gen tracing/profiling tools|| Yocto 1.0 will include all the essential existing tracing/profiling tools expected by users, and Josh has proposed a UI integration of all those tools as far as it's possible to do so. That level of integration, basically a 'plugin-level' integration is necessary and useful, but doesn't go far enough. A next-generation tracing tool would integrate at a much more fundamental level; if done properly, it would provide unmatched levels of power and usability to users, and would allow Yocto to distinguish itself in the embedded tracing/profiling space in a way also unmatched by any other distro/build-tool. The implementation would of course not be available for Yocto 1.0, but a coherent design, including prototypes, that could be taken to the community and implemented in a V 1.5 or 2.0 should be done in that time frame. || 1|| Review|| || tzanussi|| "Enhancement, duplicate of ""Tracing/Profiling Planning Complete"""<br />
|-<br />
|| Documentation Features|| Self Documentation of image contents|| "I'd like to see the -doc packages Poky builds being combined into some kind of large documentation index representing the collective API docs of the target being built. This can then be placed on a webserver and viewed over the web. We'd have a demonstration of this for a ""bitbake world"" target. Part of the idea here is to start making good use of the docs as if developers see this they might start writing better docs too. Aim is to lead the field :). There are a number of places poky packages disable doc generation due to missing tools so we'd need to add these so we can enable the doc generation. Many packages already have many docs though too. "|| 2|| Review|| || rpurdie|| enhancement<br />
|-<br />
|| Validation|| Testing Framework|| Add a framework for doing automated testing in the project|| 1|| Review|| || davest|| project commitment<br />
|-<br />
|| Validation|| more SDK builds on autobuilder|| enable more SDK related tests on autobuilder such as meta-ide-support, etc.|| 2|| Review|| || ktian1|| project commitment, addressed by test plan (?)<br />
|-<br />
|| Validation|| more people should try using SDK|| this may not be a feature, but a requirement. SDK including meta-toolchain is one key factor impacting user experience on Yocto. It's not enough to have only SDK team play with it|| 2|| Review|| || ktian1|| project commitment, addressed by test plan (?)<br />
|-<br />
|| Validation|| Unit Testing Framework|| Add a mechanism to bitbake to parse source packages that have unit tests and then execute them on the target|| 3|| Review|| || sgw|| "project commitment, duplicate of ""Testing Framework"""<br />
|-<br />
|| Validation|| Test Case open source|| Open source Yocto test cases with xml format|| 1|| Review|| || yyou|| "project commitment, duplicate of ""Testing Framework"""<br />
|}</div>Davesthttps://wiki.yoctoproject.org/wiki/index.php?title=Yocto_1.0_Schedule&diff=691Yocto 1.0 Schedule2011-02-01T16:04:43Z<p>Davest: /* Sprint C (closes Jan 14, 11:59pm PDT -- pull request sent, initially reviewed) */</p>
<hr />
<div>= v1.0 (release date: Apr 15, 2011) =<br />
----<br />
The detailed milestone map for v1.0 is as below. During the first week of each subsequent milestone past M1 we will have a demonstration of the previous milestone capabilities as well as a planning and design session for the current milestone.<br><br><br />
<br />
== M2 (Nov 08 to Dec 24 -- Dev Complete Dec 10, Stabilize Complete Dec 17, Release Complete Dec 24) ==<br />
=== Sprint A (closes Nov 12, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links''' <br />
|-<br />
|| Poky Features || Kernel interactive targets || To support incremental kernel development having the ability to run menuconfig (or xconfig, etc) directly is a common request. We'll need to add this for commercialization anyway. i.e. bitbake -c menuconfig. This fuctionality already exists. || 1 || Done || Richard || bruceashfield || Enhancement <br />
|-<br />
|| Distribution / components || Distro Audit: Upgrades Planned (Phase 1) || Complete plan for package upgrades in M2 || 1 || Done || Saul || || Continual Maintenance<br />
|-<br />
|| Validation || Runtime testing || Runtime testing of images as part of the autobuilder || 1 || Done || Jiajun/ScottG || rpurdie || project commitment<br />
|- <br />
|| || Poky Image Creator Wireframe/Interaction Plans Complete || || 1 || Done || Josh || ||<br />
|-<br />
|| || SDK Generator Interaction: Plans Complete || || 1 || Done || Jessica || ||<br />
|-<br />
|| || Tracing/Profiling Planning Complete || This needs to cover where we're at now, what we're missing and also propose the future enhancements that may be needed. M2 targets getting existing tools integrated and documented. F2f discussion n the future enhancements || || Done || Tom || ||<br />
|-<br />
|| || Swabber. (Still needs to be integrated into weekly build by default) || || 1 || Done || Josh || ||<br />
|-<br />
|| Build/Release || Release process documentation || || || Done || Beth || ||<br />
|-<br />
|| Validation || Test plan for v1.0 (to address any deficiencies in coverage from v0.9)|| || 1 || Done || Jiajun || ||<br />
|}<br />
<br />
=== Sprint B (closes Nov 19, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| Distro Audit: World Packages|| Audit world packages making sure it all build, making sure all are packages are required || 2|| Done || Saul|| sgw|| Hygiene<br />
|-<br />
|| Tool Development and SDK Features|| SDK Generator Installer UI|| Look at different ways of Installer UI (GTK+ and ncurses) seems none of them is the right choice, decide to go with script to implement all the functionalities of installer and later add UI part on top of it || 1||Done|| Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Customize sysroot setup || Add and test out "--sysroot" config option to cross compiler within Eclipse IDE || 1|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| SDK Generator Installer design revision|| Close all open questions regarding Yocto SDK Generator Installer function design and come up HLD || 1|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Distribution / components|| kernel version|| keeping 2.6.34 as a -stable kernel is the best option. I've also got a newer -devel tree that can be made available or made the default. || 3|| Done || Bruce|| bruceashfield|| enhancement<br />
|-<br />
|| || assign Yocto Project PM|| acquire and assign a program manager for Yocto Project|| || Done || DaveST|| || <br />
|-<br />
|| || assign Yocto Project Sys Admin|| || || Done || Saul|| || <br />
|-<br />
|| Tool Development and SDK Features|| oprofileUI|| Fixing various bugs of the oprofileUI to make it workable on big endian host.(i.e. ppc, mips) || 2 || Done || Jessica || lianhao.lu || Bug #382 / Bug #493<br />
|-<br />
|| Poky Feature|| SDK Version Control|| If we can expect that yocto SDK has lots of release in the future, we might need to consider SDK version control. Currently, every thing installed under /opt/poky which leads to things be overriden, we need to be able to use a scheme like /opt/poky-1.0, /opt/poky-2.0 to distiguish things. || 2|| Done || Josh|| jzhang|| Enhancement<br />
|-<br />
|| Kernel || Kernel plan complete || Flesh our kernel deliverables and add to Yocto 1.0 schedule || || Done|| Darren || dvhart ||<br />
|}<br />
<br />
=== Sprint C (closes Nov 26, 11:59pm PDT -- pull request sent, initially reviewed) :: NOTE: this is US Thanksgiving week ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| Distro Audit: Licence Checksums|| licence checksums || 1|| Done || Saul|| rpurdie|| Hygiene<br />
|-<br />
|| Poky Features || Performance Analysis Completed|| "I'd like someone to instrument a green release build, see where it spends time (hot/cold parsing time, individual task building time) and then compare this with our 0.9 release build. I'd also like to compare the disk usage between the two. Once we have a blame list we can then set about fixing it. Some things I know will come up: a) pseudo, b) checksums/signature code, c) exec() vs fork for executing tasks, d) task based prebuilds increasing disk usage, e) rpm dependency calculations, f) using rpm vs. ipk but I may be wrong and there may be others. We need numbers. "|| 1|| Done || Saul / Qing, Dongxiao|| rpurdie|| Enhancement<br />
|-<br />
|| Poky Features || environment variables for kernel builds|| switching a branch, or adding a configuration feature (and even changing the kernel repo) is often done during development of a BSP. Having some additional variables that are pass the bitbake environment scrub would be useful. i.e. KBRANCH=foo bitbake -c configure linux-yocto. This goes along with the other BSP bootstrapping suggestions. || 2|| Done || Bruce|| bruceashfield|| Enhancement<br />
|-<br />
|| Supported Targets|| ARM Platform Support|| Replace beagleboard with Beagleboard XM - decision || 2|| Done || Bruce|| alex|| Basic Yocto hardware support <br />
|-<br />
|| Distribution / components|| Security Process|| We need a dedicated person to scan and apply critical security updates to the distro. The MeeGo team already has a similar process with some scripts which may be leveraged. To complete the task, the process should be documented and a first pass over the metadata made to establish the current position on security. Any upgrades needed should be identified and a plan to address them should be in place but doesn't have to be implemented by this point.|| 1|| Done || ScottG|| ktian1|| enhancement<br />
|-<br />
|| Tool Development and SDK Features|| SDK Generator Installer Opkg repo design|| Come up a opkg repo design that will mimic the final Yocto package repo layout to be used by SDK Generator Installer to test against|| 2 || Done || Jessica || jzhang || <br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer tar creaion|| Create a Yocto Installer tar ball which contains Installer script and supported opkg component that will be used for installing other Yocto components|| 2 || Done || Jessica || jzhang || <br />
|-<br />
|| Documentation|| Kernel Framework Paper from WR|| The paper from WR needs to be re-written and then posted somewhere on the Yocto Project site. This will involve examiniation of the text and re-writing and formatting for presentation. Currently it is simply a text document. Completion time assuming uninterrupted time is one week.|| High|| Done || Scott Rifenbark|| 1 Week|| Documentation<br />
|-<br />
|| Documentation|| Poky Reference Manual|| This guide exists in the 0.9 form. The re-write of the text needs to be completed. So far, all the chapters have been rewritten but not re-posted on the site. Only the appendices remain for a text scrub. Time to complete this would be a week of uninterrupted time. Ideally, the manual would be a sub-manual that would be referenced and architected into the Yocto Project Development Guide.|| Medium|| Done|| Scott Rifenbark|| 1 Week|| Documentation<br />
|-<br />
|| Kernel || Initial meta-linaro layer || meta-linaro layer providing a kernel, tool-chain, and uboot loader. This deliverable is primarily to get the infrastructure in place and have a buildable kernel. Toolchain on best effort basis. || || Done || Darren || dvhart || Moderate risk of slippage due to holidays.<br />
|-<br />
|| Kernel || Tracing: blktrace and sysprof recipes || || || Done || Tom || dvhart ||<br />
|}<br />
<br />
=== Sprint D (closes Dec 3, 11:59pm PDT -- pull request sent, initially reviewed) :: NOTE: week of the F2F planning meeting ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Kernel || Kernel git branching structure revamped || || 1 || Done || Bruce || dvhart ||<br />
|-<br />
|| Kernel || Tunnel Creek (Crown Bay) || || 1 || Done || Tom || dvhart ||<br />
|}<br />
<br />
=== Sprint E (closes Dec 9 (THURSDAY), 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| Distro Audit: Upgrades Completed (Phase 1)|| Update to new versions as per the agreed plan for M2 from Sprint A|| 1|| Done || Saul|| rpurdie|| Continual Maintenance<br />
|-<br />
|| Distribution / components|| Distro Audit: Src Checksums|| Make sure all SRC_URI components have checksums too || 1|| Done || Saul|| rpurdie|| Hygiene<br />
|-<br />
|| Poky Features || enable KVM with qemu|| today all new Intel processors support VT, which are enabled on most desktop machines which are most frequently used build machine. with VT support, x86/x86-64 qemu target runs faster which is a good thing for emulation environment. This may require some qemu option tweaks and also poky-qemu script enhancement. || 2|| Done || Saul / Edwin|| ktian1|| Enhancement<br />
|-<br />
|| Kernel || New kernel recipes || dev, -devel, -custom || 3 || Done || Bruce || dvhart ||<br />
|-<br />
|| Swabber || Documentation for swabber || || 1 || Done || Alex || ||<br />
|-<br />
|| CCB || Defect triage process in public documented and implemented || || 1 || Done. Triage process is documented, out for review. || Saul || ||<br />
|}<br />
<br />
== M3 (Dec 20 to Feb 08 -- Dev Complete Feb 04, Stabilize Complete Feb 11, Release Complete Feb 18) ==<br />
=== Sprint A (closes Dec 24, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Kernel || Initial meta-rt layer || PREEMPT_RT kernel and related test-cases and benchmarks || 2 || Done || Darren || dvhart || slipped out from M2<br />
|-<br />
|| Poky Features || Fetcher Overhaul Phase 1 - SRC_REV enhancement||<br />
* a) Add code in FetchData::__init__() which will check if the selected fetcher supports srcrev and the automatically call a function to set the src rev value instead of each fetcher doing this.\n <br />
* e) Break SRCREVINACTION deadlock. To do this, we need to start using a keyword for automatically increasing SRCREV, e.g. SRCREV = "AUTOINC". The actual revision can be injected into PV using SRCPV. If we do this there should no longer be a need of the deadlock; <br />
* k) Ensure that we only set __BB_DONT_CACHE when SRCREV = "AUTOREV". This may need a new method call for fetchers to tell whether they're "floating" or locked down.<br />
|| 1|| Done || Saul / Ke, RP|| rpurdie|| Enhancement, slipped out from M2<br />
|-<br />
|| Distribution / components|| Distro Audit Upgrades Planned (Phase 2)|| Complete plan for package upgrades in M2|| 1|| Done || Saul|| || Continual Maintenance<br />
|-<br />
|| Poky Features || Pseudo Performance || Implement the changes to bitbake based on pseudo's enable/disable switch|| 1|| done || Saul / Qing, Dongxiao || rpurdie|| Enhancement, slipped from M2 due to risk and not having Pseudo's change yet.<br />
|-<br />
|| Tool Development and SDK Features|| Fix the issue user target sysroot is owned by root || The ADT installer will use pseudo to extract user target sysroot which ended up owned by root, this need to be fixed || 1|| done || Jessica|| jzhang|| Cleanup <br />
|-<br />
|| Tool Development and SDK Features|| Eclipse poky tree interfacing (metadata file editor)|| Provide a metadata file editor with some syntax checking and keywords highlight capabilities|| 2|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| IDE Project templates|| Templates for various project types: Clutter GUI, Gtk+ GUI, to help developers get started quickly || 2|| Done || Jessica|| josh|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| push TCF/RSE patches upstream|| work with community to finish up our TCF terminal service, TCF/RSE integration remaining patches taken by upstream. Blocking issues including Eclipse Bug #327865 || 1|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Pseudo || Pseudo enhancement to enable on/off switch || || 1 || done || Mark || ||<br />
|-<br />
|| Pseudo || Bitbake enhancement for pseudo on/off switch || || 1 || done || Richard || ||<br />
|-<br />
|| bugzilla || Complete restructure of bugzilla categories || || 1 || done || Saul || ||<br />
|-<br />
|| Poky Features || Image creator ground work || Nomenclature determined, existing gui's bug fixed and backend work implemented || 1 || Done || Joshua || ||<br />
|-<br />
|| Kernel || Tracing: Initial SystemTap recipe || Works on x86 || 3 || Done || Tom || dvhart ||<br />
|-<br />
|| Distribution / components|| Distro Audit: Package Description/Summary completed|| Ensure DESCRIPTION/SUMMARY fields are all audited|| 2|| Done || Mark|| Mark|| Hygiene, was M2, Sprint B but missed window<br />
|-<br />
|| Distribution / components|| Zypper/RPM|| Small write-up of the problems we're having w/ Zypper and what we plan to do. (i.e. create a roadmap/design) - Includes rootfs generation - Package uprev/install/removal || 1 || Done || Mark/Qing || || was M2, Sprint B<br />
|-<br />
|| Distribution / components|| Distro Audit: Licence Checksums|| Make the licence checksums fatal if not present || 1|| Done || Saul|| rpurdie|| Hygiene, was M2, Sprint C<br />
|-<br />
|| Distribution / components|| push of all relevant Wind River patchs to Yocto (patch comparison)|| Ensure patches present to packages in WRS are also in Poky|| 1|| Done || Mark|| Mark|| was M2, Sprint C<br />
|-<br />
|| Poky Features || Performance Enhancement Completed || Initial changes to reduce disk space (sstate-build-*) || 1|| Done || Saul / Qing, Dongxiao || rpurdie|| Enhancement, was M2, Sprint E<br />
|-<br />
|| Distribution / components|| User specified qemu config support|| We'll provide user an edit box which allows advanced qemu user to specify arbitrary qemu configuration to meet their needs, which the poky-qemu scrip will just append the config list towards the end of the list of parameters to bring up qemu, it also expect the poky-qemu script to do some basic sanity check on the user specifications to catch the obvious mistake || 2|| Done || Saul / criping || criping|| enhancement, was M2, Sprint E<br />
|-<br />
|| Tool Development and SDK Features|| SDK Version Control support in SDK generator installer|| If we can expect that yocto SDK has lots of release in the future, we might need to consider SDK version control. Currently, if we un-tar the sdk, it will override the older version. It's not good for app developers since they might need the old version to do something. And also, maybe a finer installer than untar is preferred. Installer will tied to certain SDK version and the installation will go under /opt/poky-versionNo.|| 1|| Done || Jessica|| criping|| Enhancement-expect planning process by Jessica to handle this task. Was M2, Sprint E.<br />
|}<br />
<br />
=== Sprint B (closes Jan 07, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || Bitbake multi-threaded parsing|| Bitbake recipe parsing is currently single threaded. I want to make this multithreaded as the speedup would be nice. If I can only take a single task for myself for 1.0, I'm nominating this one as I enjoy this kind of thing and I have ideas on how to do it. || 1|| Done || Richard|| rpurdie|| Enhancement<br />
|-<br />
|| Distribution / components|| Lock in Kernel/Toolchain version|| Locked in 2.6.37 and gcc 4.5.1. Pending decision to move to 4.5.2 and Linaro || || Done || || Richard|| || <br />
|-<br />
|| Distribution / components|| License Update|| For each of the licences we support, I'd really like to have a licences directory with a copy of that license contained within. When it comes to deciding what a given LICENSE field means, this would be the reference. It also means we can include the licences a given image includes with the image. This continues to make our license handling world class and ahead of the field. || 2|| Done || Beth|| rpurdie|| Hygiene<br />
|-<br />
|| Tool Development and SDK Features|| Qemu configuration change|| Provice edit box for advanced user to specify qemu configurations|| 2|| Done || Jessica|| criping|| <br />
|-<br />
|| Tool Development and SDK Features|| Lock down Eclipse+CDT+TCF version|| Will use Eclipse Halo 3.6 || 1|| Done || Jessica|| || <br />
|-<br />
|| Demo|| Finalize on demo plans for v1.0 launch || || 1|| Done || Dave || || <br />
|-<br />
|| Release || Release plans for v1.0 launch || Fill out the M4 plan with the necessary release activities and timings || 1|| Done || Beth || || <br />
|-<br />
|| Poky Features || Basic image creator GUI || Functional UI missing some Advanced features || 1 || In replan || Joshua || || <br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer for SDK Generator Installation functions support||Detailed feature request can be found at: http://bugzilla.pokylinux.org/show_bug.cgi?id=589|| 1|| Done || Jessica|| rpurdie|| Enhancement<br />
|-<br />
|| Kernel || Tracing: trace-cmd python binding cleanup || || 3 || Done || Darren || dvhart ||<br />
|}<br />
<br />
=== Sprint C (closes Jan 14, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || kernel development layer|| The (correct) poky behaviour of building known revisions coupled with the fetcher requiring a BSP branch to already be present means that local modifications (and kernel source tree) are required for kernel development. I already have a layer that overrides/modifies the behaviour when added to the bblayers.conf and configured into an environment. This seems useful for more people to use. || 2|| Done || Bruce|| bruceashfield|| Enhancement, was M2, Sprint C<br />
|-<br />
|| Distribution / components|| Zypper/RPM|| RPM Up-rev / Zypper Up-rev [lets get to the latest versions]|| 1|| Done || Mark/Qing|| || was M2, Sprint C<br />
|-<br />
|| Supported Targets|| Intel Platform Support|| JasperForest|| 2|| Basic support in place; DPDK evaluation in process, overall BSP plan still TBD || Tom|| davest|| Basic ECG support (Moved from Sprint A)<br />
|-<br />
|| Tool Development and SDK Features|| Eclipse poky tree interfacing (git support)|| Use Eclipse git capability to install poky tree from git repo and able to interact with git repo at file level within Poky tree || 2|| Done || Jessica|| jzhang|| Enhancement<br />
<br />
|-<br />
|| Poky Features || Poky Image Creator|| A standalone application you can run which asks you to select a distro and machine, then presents a list of packages you can select. Once the selection is made, it goes off and bakes you an image which is then presented to you. Implementation wise, it should use the sstate packages, be a bitbake UI and use the usual poky bbclass files to do the image construction behind the scenes. || 1|| Re-plan || Joshua|| rpurdie|| Enhancement<br />
|-<br />
|| Distribution / components|| LSB Sanity|| execute LSB Test and improve passing rate and document failures with clear understanding|| 2|| Done || MarkH/Saul|| sgw|| Hygiene<br />
|-<br />
|| Tool Development and SDK Features|| Image creator integration with Eclipse || || 2|| replan|| Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Kernel || Tracing: perf trace marker support || This is from feedback to the new trace command. Ingo appears to have this nearly complete already. || 3 || Done || Darren || dvhart ||<br />
|-<br />
|| Cleanup || bitbake user experience error handling validation completed || || 2 || Done || Richard || ||<br />
|-<br />
|| Cleanup || variable scrub - ensure all metadata variables are documented || Script with a histogram of variable use done, identified 50 variables to document; Add task for actual documentation update is low on the list || 2 || Done || Scott/Darren || ||<br />
|-<br />
|| Kernel || Tracing: package kernelshark || || 3 || Done || Darren || dvhart ||<br />
|}<br />
<br />
=== Sprint D (closes Jan 21, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Swabber || Complete review of swabber outputs || Move to M3 Sprint D || 1 || Move to M3 Sprint D || Alex || ||<br />
|-<br />
|| Poky Features || Fetcher Overhaul Phase 2 - API reorg||<br />
* f) Add a generic unpack funciton to __init__.py based on the unpack task in Poky ;<br />
* g) Split go() methods into the following steps: i) download() - do whatever transfer is necessary to get the sources locally ii) build_mirror_data() - generate any data that would be needed to construct a source mirror iii) unpack() - takes a directory as an argument of where to place extracted sources;<br />
The existing go() methods should be replaced with a set of calls to the above sections of functionality as appropriate in the individual fetchers. Some of these categories of function make no sense in certain fetchers, in which case they shouldn't need to implement them. Functions are only executed if the method is present.<br />
* h) Change Poky's unpack to call an unpack method in the fetchers.<br />
* i) Change Poky's fetch task to call a "download" method in the fetcher instead of go().<br />
|| 1|| Done || Saul / Ke, RP|| rpurdie|| Enhancement<br />
|-<br />
|| Poky Features || Fetcher Overhaul Phase 3 - git enhancement||<br />
* j) Optimize git fetcher for the new layout so for a git checkout, we clone the repository in download(), then unpack just does a clone with references to the original repo. <br />
* k) Ensure that we only set __BB_DONT_CACHE when SRCREV = "AUTOREV". This may need a new method call for fetchers to tell whether they're "floating" or locked down. <br />
* l) Add a new "BB_NO_NETWORK" variable which the fetchers check before peforming an operation which hits anything remote. This means adding in error messages about why network access is needed at various points (e.g. SRCREV = "AUTOREV" for a given recipe) <br />
* m) Add multiple branch/srcrev support for git fetcher. These would be of the form: git://somelocation/somerepo.git;name=ref1;branch=foo;name=ref2;branch=bar SRCREV_ref1 = "hash1" SRCREV_ref2 = "hash2" which would ensure both hash1 and hash2 were in the final repo. <br />
* n) Change git fetcher to default to git protocol instead of rsync<br />
|| 1|| Slipped to Sprint D || Saul / Ke, RP|| rpurdie|| Enhancement<br />
|-<br />
|| Poky Features || DSO linking changes|| "By the default the gcc linker will automatically link any dependant objects/libraries. ""Inherited"" linkages can cause issues, for example, where a shared object changes its dependencies but a program has come to rely on symbols from an implicitly linked library. Fedora implemented this change in F13, seems like it would be useful to have in Poky too. "|| 2|| Done || Saul / Nitin || josh|| bug#516<br />
|-<br />
|| Distribution / components|| Distro Audit Documentation Output|| Audit package documentation output || 2|| on track for Feb 3 || Saul / ScottG || rpurdie|| Hygiene<br />
|-<br />
|| Distribution / components|| Review & Fix Standards Tests|| Review the results from LTP, POSIX and assess the result, fix as appropriate and clearly document failures.|| 2|| a Plan to resolve final items to be sent to the m.l. by Jan 14 || Saul/Kevin || sgw|| Hygiene<br />
|-<br />
|| Poky Features || libtool sysroot option|| libtool 2.4 has a sysroot option. We should try and use it, see how it works and whether we can ditch some of our libtool hacks. || 1|| Done || Saul / ScottG || rpurdie|| Enhancement<br />
|-<br />
|| Distribution / components|| MACHINE or Recipe specific sysroots|| Each machine should have its own sysroot. We'll probably have to split do_populate_sysroot into a two step process, creation of the package and than installtion of the package, which the installation of the package being made machine specific (put ${MACHINE} into ${STAMP} and bitbake should do that). Also allowing this to work per recipe would be desireable|| 1|| MACHINE-specific are on done; Recipe should be on post 1.0 list with a ? || Saul / Dongxiao || rpurdie|| Hygiene<br />
|-<br />
|| Distribution / components|| Toolchain Bootstrap Process|| The toolchain as it bootstraps overwrites files like libc.so and libgcc.so in the sysroot directory which causes issues if you just try and rebuild part of the toolchain. Each step of the bootstrap process should use a separate sysroot. Once this is once, sstate file overwriting detection can be added and enabled. || 1|| Done || Saul / Dexuan || rpurdie|| Hygiene<br />
|-<br />
|| Documentation Features|| Package report system|| move to public server [setup a package report system in an internal machine. We need push it publicly available. The basic features like search and report have been there. But there're still some enhancements in plan, to make it a fit place to feel Yocto metadata comfortably]|| 2|| Move to Sprint E|| KevinT|| ktian1|| enhancement<br />
|-<br />
|| Distribution / components||Add headers and libraries to qemu images ||Since we'll be using qemu images as target sysroot, need to create a set of qemu images for minimal, sato, LSB that contains target header and libraries.|| 2|| Done || Saul ||jzhang|| Enhancement<br />
|-<br />
|| Distribution / components|| push of all relevant Wind River patchs to Yocto (patch comparison)|| Update any additional patches needed since M2.|| 1|| May be done by Jan 28, pending RPM stuff || Mark|| Mark|| <br />
|-<br />
|| Distribution / components|| mklibs|| mklibs is a tool to optimize size of [e]glibc for a perticular root file system image. It is useful to save disk space on small devices. || 2|| Push to Sprint E || Saul|| Nitin Kamble|| enhancement<br />
|-<br />
|| Poky Features || Performance Enhancement || reduce disk space (hardlink) || 1 || On track for Jan 28, pending RP review || Saul / Qing, Dongxiao || rpurdie || Enhancement<br />
|-<br />
|| Kernel || Tracing: perf trace scripting support || || 3 || Move to Sprint E || Tom || dvhart ||<br />
|-<br />
|| Kernel || Tracing: tuna, oscillosope recipes || || 3 || Tom to discuss plan with Darren et al to see whether we should include these in 1.0 || Tom || dvhart ||<br />
|- <br />
|| BSP || Beagleboard XM Support || || 3 || 2.6.34 done, but 2.6.37 is troublesome, Darren will sync up with RP and Bruce || Darren || dvhart ||<br />
|-<br />
|| BSP || 2.6.37 Crown Bay Support || On Track for Jan 21 || 2 || || Tom || dvhart || <br />
|-<br />
|| BSP || 2.6.37 Emenlow Support || On track for Jan 21 || 2 || || Tom || dvhart || <br />
|}<br />
<br />
=== Sprint E (closes Jan 28, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| rootless X|| rootless x server has better security than x server launched by root. MeeGo already enable this feature. it would be nice for Yocto to also enable it. || 2|| On track for Jan 28 || Saul / Ke || yuke|| enhancement<br />
|-<br />
|| Documentation Features|| Package report system|| finish major feature development and internal review [setup a package report system in an internal machine. We need push it publicly available. The basic features like search and report have been there. But there're still some enhancements in plan, to make it a fit place to feel Yocto metadata comfortably]|| 2|| Move to Sprint E || Jonathan || ktian1|| enhancement, was M2, Sprint E<br />
|-<br />
|| Distribution / components|| perl upgrade|| perl is the most cross un-friendly recipe pending upgrade. || 2|| Done || Nitin|| Nitin Kamble|| enhancement<br />
|-<br />
|| Supported Targets|| Intel Platform Support|| Sandybridge|| 2|| Accept|| Tom|| davest|| Basic ECG support<br />
|-<br />
|| Distribution / components|| performance indicators|| define some indicators (boot time, footprint, build time, power, component benchmarks, etc.) and then collect them for tracking purpose. The result could be posted on the wiki site, and the initial indicators can be easy ones which can be easily retrieved from autobuilder or weekly qa report). This way we have a clear track about the healthy of the Yocto project, and also identify weak areas. We can include qemu targets and several representational boards as the targets. || 2|| Sprint F || Beth/Jiajun|| ktian1|| enhancement<br />
|-<br />
|| Tool Development and SDK Features|| SDK user workshop|| Have some developers sit down and use our tools to develop demo software for Yocto. || 2|| End of February|| Jessica|| josh|| Enhancement<br />
|-<br />
|| Distribution / components|| Zypper/RPM|| Integration based on design from Sprint B|| 1|| On track for Jan28 || Mark/Qing|| sgw|| Functionality, was M2, Sprint E<br />
|-<br />
|| Kernel || Final linux-yocto_git.bb || With 2.6.37 kernel || 1 || Done || Bruce || dvhart ||<br />
|-<br />
|| Kernel || Final meta-linaro layer || 1 || On track for Jan 28 || || Darren || dvhart ||<br />
|-<br />
|| Kernel || Sandy Bridge || || 1 || || Tom || dvhart ||<br />
|}<br />
<br />
=== Sprint F (closes Feb 03 (THURSDAY), 11:59pm PDT -- pull request sent, initially reviewed) :: NOTE: China New Year Holiday ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Documentation|| ADT Reference Guide Draft out for review || Outline complete|| High|| WIP || Scott Rifenbark|| jzhang|| Documentation<br />
|-<br />
|| || || || || || || || <br />
|}<br />
<br />
== M4 (Feb 07 to Apr 15 -- Stabilize Complete Mar 18, Release Complete Apr 01, Contingency to Apr 15) ==<br />
<br />
This sprint is the [[Yocto Project v. 1.0 Release Cycle]].<br />
<br />
During this sprint, we will track the [[Yocto Project v1.0 Release Criteria]].<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Documentation|| Migration chapter in the Poky Reference Manual|| This chapter would cover the four identified use-cases for migrating up to the most recent version of Yocto Project. Additionally, it would cover migration scenarios from other development systems. The chapter does not yet exist. The chapter has not been scoped outside of having a meeting that identified four use-cases that did not include migration from a development system outside of Yocto Project. It will take some more scoping time to cover those areas (a day or two). Again, I have no idea of the length. See earlier entries for standard industry writing estimates for software documentation|| Medium|| Not Started|| Scott Rifenbark|| 3-4 Weeks|| Documentation<br />
|-<br />
|| Documentation|| Yocto Project Development Guide|| This manual would be an over-arching document that frames the complete development cycle within Yocto Project. The idea here is that the document would be an umbrella document that spawned and referenced subsequent documents. The organization would be the first chapter overviewing the major development pieces such as recipe creation, building, debugging, publishing, fail-safing, back-door hook creation, etc. Scoping would be about two weeks and length would probably be about 40 pages. Overall development time would likely be a month of uniterruped time.|| Medium|| Not Started|| Scott Rifenbark|| 3 Weeks|| Documentation<br />
|-<br />
|| Validation|| Boottime/Performance Analysis|| Compare Yocto Project performance to other projects such as MeeGo|| 1|| Initial report on where we are by Feb 9 || Darren|| davest|| project commitment<br />
|-<br />
|| || Multilib Support|| Consider developing post-1.0 branch || 1|| to start in M4 || Richard|| ||<br />
|-<br />
|| Validation|| Alpha testing complete|| 4-5 internal developers unfamiliar with Yocto Project try to do a build and report on the experience and issues encountered|| 1|| Done by Feb 18 || Julie|| davest|| <br />
|-<br />
|| || || || || || || || <br />
|}<br />
<br />
== Features needed and to be put into sprints by assigned owners: ==<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || package config option enhancement|| there're several enhancements we may do here: * allow users setting specific config options (local or global) from external tool, such as poky image creator, instead of changing recipes manually. Need a mechanism to convert from variable assignments into exact config options (e.g. feature_${PN} = ""1"" -> ""--enable-feature""). Consequently dependency chain needs update with option status. * host contamination check. We have swabber to check host contamination, but I'm not sure whether it covers configuration phase. If not, this is one area to improve, as not ususually we see configure script checks host bits for available features * conditional option manipulation. In many recipes we enable/disable one option based on availability of other packages. Now this is done manually and not flexible. this should be made automatically though some new annotation to indicate condition, or just base_contains (not convenient: long line, need define distro features) || 2|| Review|| Richard/MarkH|| ktian1|| Enhancement<br />
|-<br />
|| Media|| Yocto Project Awareness Video|| This 2.5 minute video would introduce and describe the benefits of Yocto Project. The video would use entertaining animations that described concepts and benefits. The result would be suitable for YouTube, conferences, and the website. The production is called an "Epipheo" and will be created by Epipheo Studios. The engagement process has begun and the kick-off meeting will be soon. The PO is in place. Time for development is 10 weeks.|| High|| Kick-off Imminent|| Scott Rifenbark|| 10 Weeks|| Media<br />
|-<br />
|| Documentation|| Yocto Project Debugging Guide|| This would be a guide for the debugging and bug tracking process in Yocto Project. Originally, the thought was that we needed a Bugzilla User's Manual. However, since we don't own Bugzilla it doesn't make sense to produce documentation for it. Rather, we should document the process as it fits into the Yocto Project environment. Ideally, the manual would be a sub-manual that would be referenced and architected into the Yocto Project Development Guide. The manual has not been scoped and would take a week to scope. Again, I have no idea of the length. See the previous item for standard industry writing estimates for software documenation.|| Medium|| Not Started|| Scott Rifenbark|| 3-4 Weeks|| Documentation<br />
|-<br />
|| Website|| Yocto Project Website|| The 0.9 website is in place but needs updates. Items for consideration are the left-panel naviagation scheme, a contributions guidance page, color-scheming and theme (possibly).|| Medium|| Not Started|| Scott Rifenbark|| 1-2 Weeks|| Website<br />
|}<br />
<br />
== Features not believed to be needed in v1.0: ==<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || OpenEmbedded/Bitbake Upstreaming|| "We firstly need to review where we are and where OE is. We then need to make a plan about what we're going to push upstream and what we're not. I'd suggest when we're in PRC, we do a crash course in ""dealing with OE"" and then many dedicate a block of time (a week) where the distro team comes up with a patch set we then propose and get merged into OE. I'd like to find a couple of interested people to monitor OE more regularly and start a workflow of things between Poky/OE where appropriate. The key thing to remember is we need to keep the architectures compatible. The team is now at the point where I'm happy for them to actually try building OpenEmbedded and not worry about it tainting them! "|| 2|| Review|| || rpurdie|| Process<br />
|-<br />
|| Poky Features || Handle old versions in WORKDIR|| an incremental build directory may finally include many old versions WORKDIRS. It'll be good to have those old versions tracked in the cache, which can then either generate a report or allow selectively cleaning up an specific version WORKDIR. Or else it's difficult to figure it out when people want to keep the whole tmp directory but like to cleanup some old bits when disk usage is under pressure. If it's not easy to do in bitbake, perhaps some separate scripts would be also helpful || 3|| Review|| || ktian1|| Enhancement<br />
|-<br />
|| Poky Features || run bitbake w/o rebuilding the cache|| "sometimes it's useful to allow run bitbake w/o re-parsing recipes, if we know nothing metadata is changed. we can just allow reusing existing persistent cache. this is useful when people is debugging WORKDIR w/o metadata change. also sometimes ""bitbake -e"" is used frequently to check poky variable information. with existing cache, several seconds can be saved which are not negligible for a developer daily working on Yocto "|| 2|| Review|| || ktian1|| Enhancement<br />
|-<br />
|| Poky Features || parallel make improvement|| parallel make experience is not good, especially when bb threads and make threads are increased larger than 8. So far we either try to fix package makefile or mark the recipe as no parallel make, when build faiures are reported. But this greatly impacts user experience for a successfully continuous build process. Could we define a safe number we do want to support for 1.0 release? and then have our autobuilder, QA test, and developers cover that number immediately and fix any issues accordingly. Then the safe number can be suggested to the Yocto user || 2|| Review|| || ktian1|| Enhancement<br />
|-<br />
|| Poky Features || Dependency packages rebuild/clean|| It is a mechanism to rebulid or clean a package and all other packages which have build/runtime dependency on it. With this change, we can find potential influences of package upgrade to its related packages, which can make the incremental build more trustable. For example, if we upgrade a package to a new vesion which changes its API, this mechanism can easily find out the incompatibility to other packages which have dependency on it. || 2|| Review|| || dongxiao.xu|| Enhancement, replaced by checksum feature<br />
|-<br />
|| Distribution / components|| FOSSology|| This may be similar to License Update above, but start to use FOSSology to track licenses. || 2|| Review|| || sgw|| Hygiene<br />
|-<br />
|| Distribution / components|| Package Developer Tools|| Create a set of Init scripts template and then review our current init scripts and modify them to confirm to the template. || 2|| Review|| || sgw|| Easy of Use<br />
|-<br />
|| Distribution / components|| Package Website|| Complete the work the intern has started on generating the distro tracking information and get it out on the external site. || 2|| Review|| || sgw|| "Hygiene, duplicate of ""Package report system"""<br />
|-<br />
|| Distribution / components|| Bluetooth UI support|| Currently we have bluez package in poky, and we need to have a workable graphic user interface to connect/configure BT devices. One choice may be gnome-bluetooth-applet. || 3|| Review|| || dongxiao.xu|| enhancement<br />
|-<br />
|| Distribution / components|| Connman-gnome enhancement features|| Enable connman-gnome to support features like, WPA Enterprise connection, hidden SSID, etc. || 3|| Review|| || dongxiao.xu|| enhancement<br />
|-<br />
|| Distribution / components|| Java Running Environment support|| Since most embedded systems support java applications running in it, maybe we'd better consider supporting some kinds of JVMs(Embeded JVM). The JVM may not run by default, but user can launch it if running java applications. Compared with GTK/QT, java user number is not small too. || 3|| Review|| || criping|| enhancement<br />
|-<br />
|| Distribution / components|| create more use cases|| UPnP demo is one really good use case showing how Yocto is utilized to make real functionality. and we could create more to show how Yocto is easily adapted to real use cases. Those use cases can be either maintained as seperate demo layers in yocto repo, or in seperate branches for reference. We can also call for community's contribution on this which would make 1.0 full-fledged. Or else the newbies to Yocto may be in puzzle how our sample profiles can satisfy their requirements. || 2|| Review|| || ktian1|| enhancement<br />
|-<br />
|| Distribution / components|| i18n support || internationalization is an important system wide feature. Many component like font, locale affect the i18n. Yocto alreay has some i18n related package like pango, but so far did not consider i18n systematically. so this is place holder to systematically add i18n support. || 2|| Review|| || yuke/qing|| enhancement<br />
|-<br />
|| Distribution / components|| more demos || demos are a good way to educate, push the envelope, and at the same time tout the strengths of the platform. This item just records a current set of ideas from various sources which could/should be implemented: * face-recognition/face-finding, * robotic control/application of face-finding to 'camera-as-sensor' (hexbug demo), * others [tbd, add here]|| 2|| Review|| || tzanussi|| enhancement <br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer support for image-creator and needed yocto-metadata design||Come up design what need to be created as packages to support using "opkg install" for image-creator and needed yocto-metadata|| 2|| WIP, pending comments from RP regarding how to packaging metadata|| Jessica|| rpurdie|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer image-creator and needed poky-metadata support|| The poky build system will build packages for image-creator and needed poky-metadata, which the Yocto Installer will be able to use "opkg install" to install them|| 2|| Review|| Jessica|| rpurdie|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Provide qemu management UI|| In current eclipse plugin, QEMU settings are put together with project configuration. So we can only have limited settings. If we can have a separate QEMU management UI, the end user could firstly create a QEMU config, such as (env file of arch, image location, unfs or not, sato or lsb, mem size, disk size). And then he can launch a QEMU with a specific config. The dependency between project configuration and QEMU config will be resolved. After all QEMU has nothing to do project configuration. Need to careful review the UI to ensure minimal impact to testing matrix. || 3|| Review|| || criping|| "Enhancement, duplicate of ""Qemu mem/disk size can be adjusted"""<br />
|-<br />
|| Tool Development and SDK Features|| QT plugin For Eclipse|| Integrate QT Ecplise plugin and extend for Yocto Project || 3|| Review|| || jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Profiling/Trace GUI's|| We have a wealth of great tracing and profiling tools but the UI's for them are all extremely minimal and usually quite ugly. Would be great if we could compete with, or even better, Apple's offerings here. We have the technology! || 2|| Review|| || josh|| "Enhancement, duplicate of ""Tracing/Profiling Planning Complete"""<br />
|-<br />
|| Tool Development and SDK Features|| Other profiling tools|| Complete Tom's review of profiling tools and architecture || 2|| Review|| || josh|| "Enhancement, duplicate of ""Tracing/Profiling Planning Complete"""<br />
|-<br />
|| Tool Development and SDK Features|| Design next-gen tracing/profiling tools|| Yocto 1.0 will include all the essential existing tracing/profiling tools expected by users, and Josh has proposed a UI integration of all those tools as far as it's possible to do so. That level of integration, basically a 'plugin-level' integration is necessary and useful, but doesn't go far enough. A next-generation tracing tool would integrate at a much more fundamental level; if done properly, it would provide unmatched levels of power and usability to users, and would allow Yocto to distinguish itself in the embedded tracing/profiling space in a way also unmatched by any other distro/build-tool. The implementation would of course not be available for Yocto 1.0, but a coherent design, including prototypes, that could be taken to the community and implemented in a V 1.5 or 2.0 should be done in that time frame. || 1|| Review|| || tzanussi|| "Enhancement, duplicate of ""Tracing/Profiling Planning Complete"""<br />
|-<br />
|| Documentation Features|| Self Documentation of image contents|| "I'd like to see the -doc packages Poky builds being combined into some kind of large documentation index representing the collective API docs of the target being built. This can then be placed on a webserver and viewed over the web. We'd have a demonstration of this for a ""bitbake world"" target. Part of the idea here is to start making good use of the docs as if developers see this they might start writing better docs too. Aim is to lead the field :). There are a number of places poky packages disable doc generation due to missing tools so we'd need to add these so we can enable the doc generation. Many packages already have many docs though too. "|| 2|| Review|| || rpurdie|| enhancement<br />
|-<br />
|| Validation|| Testing Framework|| Add a framework for doing automated testing in the project|| 1|| Review|| || davest|| project commitment<br />
|-<br />
|| Validation|| more SDK builds on autobuilder|| enable more SDK related tests on autobuilder such as meta-ide-support, etc.|| 2|| Review|| || ktian1|| project commitment, addressed by test plan (?)<br />
|-<br />
|| Validation|| more people should try using SDK|| this may not be a feature, but a requirement. SDK including meta-toolchain is one key factor impacting user experience on Yocto. It's not enough to have only SDK team play with it|| 2|| Review|| || ktian1|| project commitment, addressed by test plan (?)<br />
|-<br />
|| Validation|| Unit Testing Framework|| Add a mechanism to bitbake to parse source packages that have unit tests and then execute them on the target|| 3|| Review|| || sgw|| "project commitment, duplicate of ""Testing Framework"""<br />
|-<br />
|| Validation|| Test Case open source|| Open source Yocto test cases with xml format|| 1|| Review|| || yyou|| "project commitment, duplicate of ""Testing Framework"""<br />
|}</div>Davesthttps://wiki.yoctoproject.org/wiki/index.php?title=Yocto_1.0_Schedule&diff=600Yocto 1.0 Schedule2011-01-25T16:37:24Z<p>Davest: /* Sprint E (closes Jan 28, 11:59pm PDT -- pull request sent, initially reviewed) */</p>
<hr />
<div>= v1.0 (release date: Apr 15, 2011) =<br />
----<br />
The detailed milestone map for v1.0 is as below. During the first week of each subsequent milestone past M1 we will have a demonstration of the previous milestone capabilities as well as a planning and design session for the current milestone.<br><br><br />
<br />
== M2 (Nov 08 to Dec 24 -- Dev Complete Dec 10, Stabilize Complete Dec 17, Release Complete Dec 24) ==<br />
=== Sprint A (closes Nov 12, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links''' <br />
|-<br />
|| Poky Features || Kernel interactive targets || To support incremental kernel development having the ability to run menuconfig (or xconfig, etc) directly is a common request. We'll need to add this for commercialization anyway. i.e. bitbake -c menuconfig. This fuctionality already exists. || 1 || Done || Richard || bruceashfield || Enhancement <br />
|-<br />
|| Distribution / components || Distro Audit: Upgrades Planned (Phase 1) || Complete plan for package upgrades in M2 || 1 || Done || Saul || || Continual Maintenance<br />
|-<br />
|| Validation || Runtime testing || Runtime testing of images as part of the autobuilder || 1 || Done || Jiajun/ScottG || rpurdie || project commitment<br />
|- <br />
|| || Poky Image Creator Wireframe/Interaction Plans Complete || || 1 || Done || Josh || ||<br />
|-<br />
|| || SDK Generator Interaction: Plans Complete || || 1 || Done || Jessica || ||<br />
|-<br />
|| || Tracing/Profiling Planning Complete || This needs to cover where we're at now, what we're missing and also propose the future enhancements that may be needed. M2 targets getting existing tools integrated and documented. F2f discussion n the future enhancements || || Done || Tom || ||<br />
|-<br />
|| || Swabber. (Still needs to be integrated into weekly build by default) || || 1 || Done || Josh || ||<br />
|-<br />
|| Build/Release || Release process documentation || || || Done || Beth || ||<br />
|-<br />
|| Validation || Test plan for v1.0 (to address any deficiencies in coverage from v0.9)|| || 1 || Done || Jiajun || ||<br />
|}<br />
<br />
=== Sprint B (closes Nov 19, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| Distro Audit: World Packages|| Audit world packages making sure it all build, making sure all are packages are required || 2|| Done || Saul|| sgw|| Hygiene<br />
|-<br />
|| Tool Development and SDK Features|| SDK Generator Installer UI|| Look at different ways of Installer UI (GTK+ and ncurses) seems none of them is the right choice, decide to go with script to implement all the functionalities of installer and later add UI part on top of it || 1||Done|| Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Customize sysroot setup || Add and test out "--sysroot" config option to cross compiler within Eclipse IDE || 1|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| SDK Generator Installer design revision|| Close all open questions regarding Yocto SDK Generator Installer function design and come up HLD || 1|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Distribution / components|| kernel version|| keeping 2.6.34 as a -stable kernel is the best option. I've also got a newer -devel tree that can be made available or made the default. || 3|| Done || Bruce|| bruceashfield|| enhancement<br />
|-<br />
|| || assign Yocto Project PM|| acquire and assign a program manager for Yocto Project|| || Done || DaveST|| || <br />
|-<br />
|| || assign Yocto Project Sys Admin|| || || Done || Saul|| || <br />
|-<br />
|| Tool Development and SDK Features|| oprofileUI|| Fixing various bugs of the oprofileUI to make it workable on big endian host.(i.e. ppc, mips) || 2 || Done || Jessica || lianhao.lu || Bug #382 / Bug #493<br />
|-<br />
|| Poky Feature|| SDK Version Control|| If we can expect that yocto SDK has lots of release in the future, we might need to consider SDK version control. Currently, every thing installed under /opt/poky which leads to things be overriden, we need to be able to use a scheme like /opt/poky-1.0, /opt/poky-2.0 to distiguish things. || 2|| Done || Josh|| jzhang|| Enhancement<br />
|-<br />
|| Kernel || Kernel plan complete || Flesh our kernel deliverables and add to Yocto 1.0 schedule || || Done|| Darren || dvhart ||<br />
|}<br />
<br />
=== Sprint C (closes Nov 26, 11:59pm PDT -- pull request sent, initially reviewed) :: NOTE: this is US Thanksgiving week ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| Distro Audit: Licence Checksums|| licence checksums || 1|| Done || Saul|| rpurdie|| Hygiene<br />
|-<br />
|| Poky Features || Performance Analysis Completed|| "I'd like someone to instrument a green release build, see where it spends time (hot/cold parsing time, individual task building time) and then compare this with our 0.9 release build. I'd also like to compare the disk usage between the two. Once we have a blame list we can then set about fixing it. Some things I know will come up: a) pseudo, b) checksums/signature code, c) exec() vs fork for executing tasks, d) task based prebuilds increasing disk usage, e) rpm dependency calculations, f) using rpm vs. ipk but I may be wrong and there may be others. We need numbers. "|| 1|| Done || Saul / Qing, Dongxiao|| rpurdie|| Enhancement<br />
|-<br />
|| Poky Features || environment variables for kernel builds|| switching a branch, or adding a configuration feature (and even changing the kernel repo) is often done during development of a BSP. Having some additional variables that are pass the bitbake environment scrub would be useful. i.e. KBRANCH=foo bitbake -c configure linux-yocto. This goes along with the other BSP bootstrapping suggestions. || 2|| Done || Bruce|| bruceashfield|| Enhancement<br />
|-<br />
|| Supported Targets|| ARM Platform Support|| Replace beagleboard with Beagleboard XM - decision || 2|| Done || Bruce|| alex|| Basic Yocto hardware support <br />
|-<br />
|| Distribution / components|| Security Process|| We need a dedicated person to scan and apply critical security updates to the distro. The MeeGo team already has a similar process with some scripts which may be leveraged. To complete the task, the process should be documented and a first pass over the metadata made to establish the current position on security. Any upgrades needed should be identified and a plan to address them should be in place but doesn't have to be implemented by this point.|| 1|| Done || ScottG|| ktian1|| enhancement<br />
|-<br />
|| Tool Development and SDK Features|| SDK Generator Installer Opkg repo design|| Come up a opkg repo design that will mimic the final Yocto package repo layout to be used by SDK Generator Installer to test against|| 2 || Done || Jessica || jzhang || <br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer tar creaion|| Create a Yocto Installer tar ball which contains Installer script and supported opkg component that will be used for installing other Yocto components|| 2 || Done || Jessica || jzhang || <br />
|-<br />
|| Documentation|| Kernel Framework Paper from WR|| The paper from WR needs to be re-written and then posted somewhere on the Yocto Project site. This will involve examiniation of the text and re-writing and formatting for presentation. Currently it is simply a text document. Completion time assuming uninterrupted time is one week.|| High|| Done || Scott Rifenbark|| 1 Week|| Documentation<br />
|-<br />
|| Documentation|| Poky Reference Manual|| This guide exists in the 0.9 form. The re-write of the text needs to be completed. So far, all the chapters have been rewritten but not re-posted on the site. Only the appendices remain for a text scrub. Time to complete this would be a week of uninterrupted time. Ideally, the manual would be a sub-manual that would be referenced and architected into the Yocto Project Development Guide.|| Medium|| Done|| Scott Rifenbark|| 1 Week|| Documentation<br />
|-<br />
|| Kernel || Initial meta-linaro layer || meta-linaro layer providing a kernel, tool-chain, and uboot loader. This deliverable is primarily to get the infrastructure in place and have a buildable kernel. Toolchain on best effort basis. || || Done || Darren || dvhart || Moderate risk of slippage due to holidays.<br />
|-<br />
|| Kernel || Tracing: blktrace and sysprof recipes || || || Done || Tom || dvhart ||<br />
|}<br />
<br />
=== Sprint D (closes Dec 3, 11:59pm PDT -- pull request sent, initially reviewed) :: NOTE: week of the F2F planning meeting ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Kernel || Kernel git branching structure revamped || || 1 || Done || Bruce || dvhart ||<br />
|-<br />
|| Kernel || Tunnel Creek (Crown Bay) || || 1 || Done || Tom || dvhart ||<br />
|}<br />
<br />
=== Sprint E (closes Dec 9 (THURSDAY), 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| Distro Audit: Upgrades Completed (Phase 1)|| Update to new versions as per the agreed plan for M2 from Sprint A|| 1|| Done || Saul|| rpurdie|| Continual Maintenance<br />
|-<br />
|| Distribution / components|| Distro Audit: Src Checksums|| Make sure all SRC_URI components have checksums too || 1|| Done || Saul|| rpurdie|| Hygiene<br />
|-<br />
|| Poky Features || enable KVM with qemu|| today all new Intel processors support VT, which are enabled on most desktop machines which are most frequently used build machine. with VT support, x86/x86-64 qemu target runs faster which is a good thing for emulation environment. This may require some qemu option tweaks and also poky-qemu script enhancement. || 2|| Done || Saul / Edwin|| ktian1|| Enhancement<br />
|-<br />
|| Kernel || New kernel recipes || dev, -devel, -custom || 3 || Done || Bruce || dvhart ||<br />
|-<br />
|| Swabber || Documentation for swabber || || 1 || Done || Alex || ||<br />
|-<br />
|| CCB || Defect triage process in public documented and implemented || || 1 || Done. Triage process is documented, out for review. || Saul || ||<br />
|}<br />
<br />
== M3 (Dec 20 to Feb 08 -- Dev Complete Feb 04, Stabilize Complete Feb 11, Release Complete Feb 18) ==<br />
=== Sprint A (closes Dec 24, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Kernel || Initial meta-rt layer || PREEMPT_RT kernel and related test-cases and benchmarks || 2 || Done || Darren || dvhart || slipped out from M2<br />
|-<br />
|| Poky Features || Fetcher Overhaul Phase 1 - SRC_REV enhancement||<br />
* a) Add code in FetchData::__init__() which will check if the selected fetcher supports srcrev and the automatically call a function to set the src rev value instead of each fetcher doing this.\n <br />
* e) Break SRCREVINACTION deadlock. To do this, we need to start using a keyword for automatically increasing SRCREV, e.g. SRCREV = "AUTOINC". The actual revision can be injected into PV using SRCPV. If we do this there should no longer be a need of the deadlock; <br />
* k) Ensure that we only set __BB_DONT_CACHE when SRCREV = "AUTOREV". This may need a new method call for fetchers to tell whether they're "floating" or locked down.<br />
|| 1|| Done || Saul / Ke, RP|| rpurdie|| Enhancement, slipped out from M2<br />
|-<br />
|| Distribution / components|| Distro Audit Upgrades Planned (Phase 2)|| Complete plan for package upgrades in M2|| 1|| Done || Saul|| || Continual Maintenance<br />
|-<br />
|| Poky Features || Pseudo Performance || Implement the changes to bitbake based on pseudo's enable/disable switch|| 1|| done || Saul / Qing, Dongxiao || rpurdie|| Enhancement, slipped from M2 due to risk and not having Pseudo's change yet.<br />
|-<br />
|| Tool Development and SDK Features|| Fix the issue user target sysroot is owned by root || The ADT installer will use pseudo to extract user target sysroot which ended up owned by root, this need to be fixed || 1|| done || Jessica|| jzhang|| Cleanup <br />
|-<br />
|| Tool Development and SDK Features|| Eclipse poky tree interfacing (metadata file editor)|| Provide a metadata file editor with some syntax checking and keywords highlight capabilities|| 2|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| IDE Project templates|| Templates for various project types: Clutter GUI, Gtk+ GUI, to help developers get started quickly || 2|| Done || Jessica|| josh|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| push TCF/RSE patches upstream|| work with community to finish up our TCF terminal service, TCF/RSE integration remaining patches taken by upstream. Blocking issues including Eclipse Bug #327865 || 1|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Pseudo || Pseudo enhancement to enable on/off switch || || 1 || done || Mark || ||<br />
|-<br />
|| Pseudo || Bitbake enhancement for pseudo on/off switch || || 1 || done || Richard || ||<br />
|-<br />
|| bugzilla || Complete restructure of bugzilla categories || || 1 || done || Saul || ||<br />
|-<br />
|| Poky Features || Image creator ground work || Nomenclature determined, existing gui's bug fixed and backend work implemented || 1 || Done || Joshua || ||<br />
|-<br />
|| Kernel || Tracing: Initial SystemTap recipe || Works on x86 || 3 || Done || Tom || dvhart ||<br />
|-<br />
|| Distribution / components|| Distro Audit: Package Description/Summary completed|| Ensure DESCRIPTION/SUMMARY fields are all audited|| 2|| Done || Mark|| Mark|| Hygiene, was M2, Sprint B but missed window<br />
|-<br />
|| Distribution / components|| Zypper/RPM|| Small write-up of the problems we're having w/ Zypper and what we plan to do. (i.e. create a roadmap/design) - Includes rootfs generation - Package uprev/install/removal || 1 || Done || Mark/Qing || || was M2, Sprint B<br />
|-<br />
|| Distribution / components|| Distro Audit: Licence Checksums|| Make the licence checksums fatal if not present || 1|| Done || Saul|| rpurdie|| Hygiene, was M2, Sprint C<br />
|-<br />
|| Distribution / components|| push of all relevant Wind River patchs to Yocto (patch comparison)|| Ensure patches present to packages in WRS are also in Poky|| 1|| Done || Mark|| Mark|| was M2, Sprint C<br />
|-<br />
|| Poky Features || Performance Enhancement Completed || Initial changes to reduce disk space (sstate-build-*) || 1|| Done || Saul / Qing, Dongxiao || rpurdie|| Enhancement, was M2, Sprint E<br />
|-<br />
|| Distribution / components|| User specified qemu config support|| We'll provide user an edit box which allows advanced qemu user to specify arbitrary qemu configuration to meet their needs, which the poky-qemu scrip will just append the config list towards the end of the list of parameters to bring up qemu, it also expect the poky-qemu script to do some basic sanity check on the user specifications to catch the obvious mistake || 2|| Done || Saul / criping || criping|| enhancement, was M2, Sprint E<br />
|-<br />
|| Tool Development and SDK Features|| SDK Version Control support in SDK generator installer|| If we can expect that yocto SDK has lots of release in the future, we might need to consider SDK version control. Currently, if we un-tar the sdk, it will override the older version. It's not good for app developers since they might need the old version to do something. And also, maybe a finer installer than untar is preferred. Installer will tied to certain SDK version and the installation will go under /opt/poky-versionNo.|| 1|| Done || Jessica|| criping|| Enhancement-expect planning process by Jessica to handle this task. Was M2, Sprint E.<br />
|}<br />
<br />
=== Sprint B (closes Jan 07, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || Bitbake multi-threaded parsing|| Bitbake recipe parsing is currently single threaded. I want to make this multithreaded as the speedup would be nice. If I can only take a single task for myself for 1.0, I'm nominating this one as I enjoy this kind of thing and I have ideas on how to do it. || 1|| Done || Richard|| rpurdie|| Enhancement<br />
|-<br />
|| Distribution / components|| Lock in Kernel/Toolchain version|| Locked in 2.6.37 and gcc 4.5.1. Pending decision to move to 4.5.2 and Linaro || || Done || || Richard|| || <br />
|-<br />
|| Distribution / components|| License Update|| For each of the licences we support, I'd really like to have a licences directory with a copy of that license contained within. When it comes to deciding what a given LICENSE field means, this would be the reference. It also means we can include the licences a given image includes with the image. This continues to make our license handling world class and ahead of the field. || 2|| Done || Beth|| rpurdie|| Hygiene<br />
|-<br />
|| Tool Development and SDK Features|| Qemu configuration change|| Provice edit box for advanced user to specify qemu configurations|| 2|| Done || Jessica|| criping|| <br />
|-<br />
|| Tool Development and SDK Features|| Lock down Eclipse+CDT+TCF version|| Will use Eclipse Halo 3.6 || 1|| Done || Jessica|| || <br />
|-<br />
|| Demo|| Finalize on demo plans for v1.0 launch || || 1|| Done || Dave || || <br />
|-<br />
|| Release || Release plans for v1.0 launch || Fill out the M4 plan with the necessary release activities and timings || 1|| Done || Beth || || <br />
|-<br />
|| Poky Features || Basic image creator GUI || Functional UI missing some Advanced features || 1 || In replan || Joshua || || <br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer for SDK Generator Installation functions support||Detailed feature request can be found at: http://bugzilla.pokylinux.org/show_bug.cgi?id=589|| 1|| Done || Jessica|| rpurdie|| Enhancement<br />
|-<br />
|| Kernel || Tracing: trace-cmd python binding cleanup || || 3 || Done || Darren || dvhart ||<br />
|}<br />
<br />
=== Sprint C (closes Jan 14, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || kernel development layer|| The (correct) poky behaviour of building known revisions coupled with the fetcher requiring a BSP branch to already be present means that local modifications (and kernel source tree) are required for kernel development. I already have a layer that overrides/modifies the behaviour when added to the bblayers.conf and configured into an environment. This seems useful for more people to use. || 2|| Done || Bruce|| bruceashfield|| Enhancement, was M2, Sprint C<br />
|-<br />
|| Distribution / components|| Zypper/RPM|| RPM Up-rev / Zypper Up-rev [lets get to the latest versions]|| 1|| Feb 4 || Mark/Qing|| || was M2, Sprint C<br />
|-<br />
|| Supported Targets|| Intel Platform Support|| JasperForest|| 2|| Basic support in place; DPDK evaluation in process, overall BSP plan still TBD || Tom|| davest|| Basic ECG support (Moved from Sprint A)<br />
|-<br />
|| Tool Development and SDK Features|| Eclipse poky tree interfacing (git support)|| Use Eclipse git capability to install poky tree from git repo and able to interact with git repo at file level within Poky tree || 2|| Done || Jessica|| jzhang|| Enhancement<br />
<br />
|-<br />
|| Poky Features || Poky Image Creator|| A standalone application you can run which asks you to select a distro and machine, then presents a list of packages you can select. Once the selection is made, it goes off and bakes you an image which is then presented to you. Implementation wise, it should use the sstate packages, be a bitbake UI and use the usual poky bbclass files to do the image construction behind the scenes. || 1|| Re-plan || Joshua|| rpurdie|| Enhancement<br />
|-<br />
|| Distribution / components|| LSB Sanity|| execute LSB Test and improve passing rate and document failures with clear understanding|| 2|| Done || MarkH/Saul|| sgw|| Hygiene<br />
|-<br />
|| Tool Development and SDK Features|| Image creator integration with Eclipse || || 2|| replan|| Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Kernel || Tracing: perf trace marker support || This is from feedback to the new trace command. Ingo appears to have this nearly complete already. || 3 || Done || Darren || dvhart ||<br />
|-<br />
|| Cleanup || bitbake user experience error handling validation completed || || 2 || Done || Richard || ||<br />
|-<br />
|| Cleanup || variable scrub - ensure all metadata variables are documented || Script with a histogram of variable use done, identified 50 variables to document; Add task for actual documentation update is low on the list || 2 || Done || Scott/Darren || ||<br />
|-<br />
|| Kernel || Tracing: package kernelshark || || 3 || Done || Darren || dvhart ||<br />
|}<br />
<br />
=== Sprint D (closes Jan 21, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Swabber || Complete review of swabber outputs || Move to M3 Sprint D || 1 || Move to M3 Sprint D || Alex || ||<br />
|-<br />
|| Poky Features || Fetcher Overhaul Phase 2 - API reorg||<br />
* f) Add a generic unpack funciton to __init__.py based on the unpack task in Poky ;<br />
* g) Split go() methods into the following steps: i) download() - do whatever transfer is necessary to get the sources locally ii) build_mirror_data() - generate any data that would be needed to construct a source mirror iii) unpack() - takes a directory as an argument of where to place extracted sources;<br />
The existing go() methods should be replaced with a set of calls to the above sections of functionality as appropriate in the individual fetchers. Some of these categories of function make no sense in certain fetchers, in which case they shouldn't need to implement them. Functions are only executed if the method is present.<br />
* h) Change Poky's unpack to call an unpack method in the fetchers.<br />
* i) Change Poky's fetch task to call a "download" method in the fetcher instead of go().<br />
|| 1|| Done || Saul / Ke, RP|| rpurdie|| Enhancement<br />
|-<br />
|| Poky Features || Fetcher Overhaul Phase 3 - git enhancement||<br />
* j) Optimize git fetcher for the new layout so for a git checkout, we clone the repository in download(), then unpack just does a clone with references to the original repo. <br />
* k) Ensure that we only set __BB_DONT_CACHE when SRCREV = "AUTOREV". This may need a new method call for fetchers to tell whether they're "floating" or locked down. <br />
* l) Add a new "BB_NO_NETWORK" variable which the fetchers check before peforming an operation which hits anything remote. This means adding in error messages about why network access is needed at various points (e.g. SRCREV = "AUTOREV" for a given recipe) <br />
* m) Add multiple branch/srcrev support for git fetcher. These would be of the form: git://somelocation/somerepo.git;name=ref1;branch=foo;name=ref2;branch=bar SRCREV_ref1 = "hash1" SRCREV_ref2 = "hash2" which would ensure both hash1 and hash2 were in the final repo. <br />
* n) Change git fetcher to default to git protocol instead of rsync<br />
|| 1|| Slipped to Sprint D || Saul / Ke, RP|| rpurdie|| Enhancement<br />
|-<br />
|| Poky Features || DSO linking changes|| "By the default the gcc linker will automatically link any dependant objects/libraries. ""Inherited"" linkages can cause issues, for example, where a shared object changes its dependencies but a program has come to rely on symbols from an implicitly linked library. Fedora implemented this change in F13, seems like it would be useful to have in Poky too. "|| 2|| Done || Saul / Nitin || josh|| bug#516<br />
|-<br />
|| Distribution / components|| Distro Audit Documentation Output|| Audit package documentation output || 2|| on track for Feb 3 || Saul / ScottG || rpurdie|| Hygiene<br />
|-<br />
|| Distribution / components|| Review & Fix Standards Tests|| Review the results from LTP, POSIX and assess the result, fix as appropriate and clearly document failures.|| 2|| a Plan to resolve final items to be sent to the m.l. by Jan 14 || Saul/Kevin || sgw|| Hygiene<br />
|-<br />
|| Poky Features || libtool sysroot option|| libtool 2.4 has a sysroot option. We should try and use it, see how it works and whether we can ditch some of our libtool hacks. || 1|| Done || Saul / ScottG || rpurdie|| Enhancement<br />
|-<br />
|| Distribution / components|| MACHINE or Recipe specific sysroots|| Each machine should have its own sysroot. We'll probably have to split do_populate_sysroot into a two step process, creation of the package and than installtion of the package, which the installation of the package being made machine specific (put ${MACHINE} into ${STAMP} and bitbake should do that). Also allowing this to work per recipe would be desireable|| 1|| MACHINE-specific are on done; Recipe should be on post 1.0 list with a ? || Saul / Dongxiao || rpurdie|| Hygiene<br />
|-<br />
|| Distribution / components|| Toolchain Bootstrap Process|| The toolchain as it bootstraps overwrites files like libc.so and libgcc.so in the sysroot directory which causes issues if you just try and rebuild part of the toolchain. Each step of the bootstrap process should use a separate sysroot. Once this is once, sstate file overwriting detection can be added and enabled. || 1|| Done || Saul / Dexuan || rpurdie|| Hygiene<br />
|-<br />
|| Documentation Features|| Package report system|| move to public server [setup a package report system in an internal machine. We need push it publicly available. The basic features like search and report have been there. But there're still some enhancements in plan, to make it a fit place to feel Yocto metadata comfortably]|| 2|| Move to Sprint E|| KevinT|| ktian1|| enhancement<br />
|-<br />
|| Distribution / components||Add headers and libraries to qemu images ||Since we'll be using qemu images as target sysroot, need to create a set of qemu images for minimal, sato, LSB that contains target header and libraries.|| 2|| Done || Saul ||jzhang|| Enhancement<br />
|-<br />
|| Distribution / components|| push of all relevant Wind River patchs to Yocto (patch comparison)|| Update any additional patches needed since M2.|| 1|| May be done by Jan 28, pending RPM stuff || Mark|| Mark|| <br />
|-<br />
|| Distribution / components|| mklibs|| mklibs is a tool to optimize size of [e]glibc for a perticular root file system image. It is useful to save disk space on small devices. || 2|| Push to Sprint E || Saul|| Nitin Kamble|| enhancement<br />
|-<br />
|| Poky Features || Performance Enhancement || reduce disk space (hardlink) || 1 || On track for Jan 28, pending RP review || Saul / Qing, Dongxiao || rpurdie || Enhancement<br />
|-<br />
|| Kernel || Tracing: perf trace scripting support || || 3 || Move to Sprint E || Tom || dvhart ||<br />
|-<br />
|| Kernel || Tracing: tuna, oscillosope recipes || || 3 || Tom to discuss plan with Darren et al to see whether we should include these in 1.0 || Tom || dvhart ||<br />
|- <br />
|| BSP || Beagleboard XM Support || || 3 || 2.6.34 done, but 2.6.37 is troublesome, Darren will sync up with RP and Bruce || Darren || dvhart ||<br />
|-<br />
|| BSP || 2.6.37 Crown Bay Support || On Track for Jan 21 || 2 || || Tom || dvhart || <br />
|-<br />
|| BSP || 2.6.37 Emenlow Support || On track for Jan 21 || 2 || || Tom || dvhart || <br />
|}<br />
<br />
=== Sprint E (closes Jan 28, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| rootless X|| rootless x server has better security than x server launched by root. MeeGo already enable this feature. it would be nice for Yocto to also enable it. || 2|| On track for Jan 28 || Saul / Ke || yuke|| enhancement<br />
|-<br />
|| Documentation Features|| Package report system|| finish major feature development and internal review [setup a package report system in an internal machine. We need push it publicly available. The basic features like search and report have been there. But there're still some enhancements in plan, to make it a fit place to feel Yocto metadata comfortably]|| 2|| Move to Sprint E || Jonathan || ktian1|| enhancement, was M2, Sprint E<br />
|-<br />
|| Distribution / components|| perl upgrade|| perl is the most cross un-friendly recipe pending upgrade. || 2|| Done || Nitin|| Nitin Kamble|| enhancement<br />
|-<br />
|| Supported Targets|| Intel Platform Support|| Sandybridge|| 2|| Accept|| Tom|| davest|| Basic ECG support<br />
|-<br />
|| Distribution / components|| performance indicators|| define some indicators (boot time, footprint, build time, power, component benchmarks, etc.) and then collect them for tracking purpose. The result could be posted on the wiki site, and the initial indicators can be easy ones which can be easily retrieved from autobuilder or weekly qa report). This way we have a clear track about the healthy of the Yocto project, and also identify weak areas. We can include qemu targets and several representational boards as the targets. || 2|| Sprint F || Beth/Jiajun|| ktian1|| enhancement<br />
|-<br />
|| Tool Development and SDK Features|| SDK user workshop|| Have some developers sit down and use our tools to develop demo software for Yocto. || 2|| End of February|| Jessica|| josh|| Enhancement<br />
|-<br />
|| Distribution / components|| Zypper/RPM|| Integration based on design from Sprint B|| 1|| On track for Jan28 || Mark/Qing|| sgw|| Functionality, was M2, Sprint E<br />
|-<br />
|| Kernel || Final linux-yocto_git.bb || With 2.6.37 kernel || 1 || Done || Bruce || dvhart ||<br />
|-<br />
|| Kernel || Final meta-linaro layer || 1 || On track for Jan 28 || || Darren || dvhart ||<br />
|-<br />
|| Kernel || Sandy Bridge || || 1 || || Tom || dvhart ||<br />
|}<br />
<br />
=== Sprint F (closes Feb 03 (THURSDAY), 11:59pm PDT -- pull request sent, initially reviewed) :: NOTE: China New Year Holiday ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Documentation|| ADT Reference Guide Draft out for review || Outline complete|| High|| WIP || Scott Rifenbark|| jzhang|| Documentation<br />
|-<br />
|| || || || || || || || <br />
|}<br />
<br />
== M4 (Feb 07 to Apr 15 -- Stabilize Complete Mar 18, Release Complete Apr 01, Contingency to Apr 15) ==<br />
<br />
This sprint is the [[Yocto Project v. 1.0 Release Cycle]].<br />
<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Documentation|| Migration chapter in the Poky Reference Manual|| This chapter would cover the four identified use-cases for migrating up to the most recent version of Yocto Project. Additionally, it would cover migration scenarios from other development systems. The chapter does not yet exist. The chapter has not been scoped outside of having a meeting that identified four use-cases that did not include migration from a development system outside of Yocto Project. It will take some more scoping time to cover those areas (a day or two). Again, I have no idea of the length. See earlier entries for standard industry writing estimates for software documentation|| Medium|| Not Started|| Scott Rifenbark|| 3-4 Weeks|| Documentation<br />
|-<br />
|| Documentation|| Yocto Project Development Guide|| This manual would be an over-arching document that frames the complete development cycle within Yocto Project. The idea here is that the document would be an umbrella document that spawned and referenced subsequent documents. The organization would be the first chapter overviewing the major development pieces such as recipe creation, building, debugging, publishing, fail-safing, back-door hook creation, etc. Scoping would be about two weeks and length would probably be about 40 pages. Overall development time would likely be a month of uniterruped time.|| Medium|| Not Started|| Scott Rifenbark|| 3 Weeks|| Documentation<br />
|-<br />
|| Validation|| Boottime/Performance Analysis|| Compare Yocto Project performance to other projects such as MeeGo|| 1|| Initial report on where we are by Feb 9 || Darren|| davest|| project commitment<br />
|-<br />
|| || Multilib Support|| Consider developing post-1.0 branch || 1|| to start in M4 || Richard|| ||<br />
|-<br />
|| Validation|| Alpha testing complete|| 4-5 internal developers unfamiliar with Yocto Project try to do a build and report on the experience and issues encountered|| 1|| Done by Feb 18 || Julie|| davest|| <br />
|-<br />
|| || || || || || || || <br />
|}<br />
<br />
== Features needed and to be put into sprints by assigned owners: ==<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || package config option enhancement|| there're several enhancements we may do here: * allow users setting specific config options (local or global) from external tool, such as poky image creator, instead of changing recipes manually. Need a mechanism to convert from variable assignments into exact config options (e.g. feature_${PN} = ""1"" -> ""--enable-feature""). Consequently dependency chain needs update with option status. * host contamination check. We have swabber to check host contamination, but I'm not sure whether it covers configuration phase. If not, this is one area to improve, as not ususually we see configure script checks host bits for available features * conditional option manipulation. In many recipes we enable/disable one option based on availability of other packages. Now this is done manually and not flexible. this should be made automatically though some new annotation to indicate condition, or just base_contains (not convenient: long line, need define distro features) || 2|| Review|| Richard/MarkH|| ktian1|| Enhancement<br />
|-<br />
|| Media|| Yocto Project Awareness Video|| This 2.5 minute video would introduce and describe the benefits of Yocto Project. The video would use entertaining animations that described concepts and benefits. The result would be suitable for YouTube, conferences, and the website. The production is called an "Epipheo" and will be created by Epipheo Studios. The engagement process has begun and the kick-off meeting will be soon. The PO is in place. Time for development is 10 weeks.|| High|| Kick-off Imminent|| Scott Rifenbark|| 10 Weeks|| Media<br />
|-<br />
|| Documentation|| Yocto Project Debugging Guide|| This would be a guide for the debugging and bug tracking process in Yocto Project. Originally, the thought was that we needed a Bugzilla User's Manual. However, since we don't own Bugzilla it doesn't make sense to produce documentation for it. Rather, we should document the process as it fits into the Yocto Project environment. Ideally, the manual would be a sub-manual that would be referenced and architected into the Yocto Project Development Guide. The manual has not been scoped and would take a week to scope. Again, I have no idea of the length. See the previous item for standard industry writing estimates for software documenation.|| Medium|| Not Started|| Scott Rifenbark|| 3-4 Weeks|| Documentation<br />
|-<br />
|| Website|| Yocto Project Website|| The 0.9 website is in place but needs updates. Items for consideration are the left-panel naviagation scheme, a contributions guidance page, color-scheming and theme (possibly).|| Medium|| Not Started|| Scott Rifenbark|| 1-2 Weeks|| Website<br />
|}<br />
<br />
== Features not believed to be needed in v1.0: ==<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || OpenEmbedded/Bitbake Upstreaming|| "We firstly need to review where we are and where OE is. We then need to make a plan about what we're going to push upstream and what we're not. I'd suggest when we're in PRC, we do a crash course in ""dealing with OE"" and then many dedicate a block of time (a week) where the distro team comes up with a patch set we then propose and get merged into OE. I'd like to find a couple of interested people to monitor OE more regularly and start a workflow of things between Poky/OE where appropriate. The key thing to remember is we need to keep the architectures compatible. The team is now at the point where I'm happy for them to actually try building OpenEmbedded and not worry about it tainting them! "|| 2|| Review|| || rpurdie|| Process<br />
|-<br />
|| Poky Features || Handle old versions in WORKDIR|| an incremental build directory may finally include many old versions WORKDIRS. It'll be good to have those old versions tracked in the cache, which can then either generate a report or allow selectively cleaning up an specific version WORKDIR. Or else it's difficult to figure it out when people want to keep the whole tmp directory but like to cleanup some old bits when disk usage is under pressure. If it's not easy to do in bitbake, perhaps some separate scripts would be also helpful || 3|| Review|| || ktian1|| Enhancement<br />
|-<br />
|| Poky Features || run bitbake w/o rebuilding the cache|| "sometimes it's useful to allow run bitbake w/o re-parsing recipes, if we know nothing metadata is changed. we can just allow reusing existing persistent cache. this is useful when people is debugging WORKDIR w/o metadata change. also sometimes ""bitbake -e"" is used frequently to check poky variable information. with existing cache, several seconds can be saved which are not negligible for a developer daily working on Yocto "|| 2|| Review|| || ktian1|| Enhancement<br />
|-<br />
|| Poky Features || parallel make improvement|| parallel make experience is not good, especially when bb threads and make threads are increased larger than 8. So far we either try to fix package makefile or mark the recipe as no parallel make, when build faiures are reported. But this greatly impacts user experience for a successfully continuous build process. Could we define a safe number we do want to support for 1.0 release? and then have our autobuilder, QA test, and developers cover that number immediately and fix any issues accordingly. Then the safe number can be suggested to the Yocto user || 2|| Review|| || ktian1|| Enhancement<br />
|-<br />
|| Poky Features || Dependency packages rebuild/clean|| It is a mechanism to rebulid or clean a package and all other packages which have build/runtime dependency on it. With this change, we can find potential influences of package upgrade to its related packages, which can make the incremental build more trustable. For example, if we upgrade a package to a new vesion which changes its API, this mechanism can easily find out the incompatibility to other packages which have dependency on it. || 2|| Review|| || dongxiao.xu|| Enhancement, replaced by checksum feature<br />
|-<br />
|| Distribution / components|| FOSSology|| This may be similar to License Update above, but start to use FOSSology to track licenses. || 2|| Review|| || sgw|| Hygiene<br />
|-<br />
|| Distribution / components|| Package Developer Tools|| Create a set of Init scripts template and then review our current init scripts and modify them to confirm to the template. || 2|| Review|| || sgw|| Easy of Use<br />
|-<br />
|| Distribution / components|| Package Website|| Complete the work the intern has started on generating the distro tracking information and get it out on the external site. || 2|| Review|| || sgw|| "Hygiene, duplicate of ""Package report system"""<br />
|-<br />
|| Distribution / components|| Bluetooth UI support|| Currently we have bluez package in poky, and we need to have a workable graphic user interface to connect/configure BT devices. One choice may be gnome-bluetooth-applet. || 3|| Review|| || dongxiao.xu|| enhancement<br />
|-<br />
|| Distribution / components|| Connman-gnome enhancement features|| Enable connman-gnome to support features like, WPA Enterprise connection, hidden SSID, etc. || 3|| Review|| || dongxiao.xu|| enhancement<br />
|-<br />
|| Distribution / components|| Java Running Environment support|| Since most embedded systems support java applications running in it, maybe we'd better consider supporting some kinds of JVMs(Embeded JVM). The JVM may not run by default, but user can launch it if running java applications. Compared with GTK/QT, java user number is not small too. || 3|| Review|| || criping|| enhancement<br />
|-<br />
|| Distribution / components|| create more use cases|| UPnP demo is one really good use case showing how Yocto is utilized to make real functionality. and we could create more to show how Yocto is easily adapted to real use cases. Those use cases can be either maintained as seperate demo layers in yocto repo, or in seperate branches for reference. We can also call for community's contribution on this which would make 1.0 full-fledged. Or else the newbies to Yocto may be in puzzle how our sample profiles can satisfy their requirements. || 2|| Review|| || ktian1|| enhancement<br />
|-<br />
|| Distribution / components|| i18n support || internationalization is an important system wide feature. Many component like font, locale affect the i18n. Yocto alreay has some i18n related package like pango, but so far did not consider i18n systematically. so this is place holder to systematically add i18n support. || 2|| Review|| || yuke/qing|| enhancement<br />
|-<br />
|| Distribution / components|| more demos || demos are a good way to educate, push the envelope, and at the same time tout the strengths of the platform. This item just records a current set of ideas from various sources which could/should be implemented: * face-recognition/face-finding, * robotic control/application of face-finding to 'camera-as-sensor' (hexbug demo), * others [tbd, add here]|| 2|| Review|| || tzanussi|| enhancement <br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer support for image-creator and needed yocto-metadata design||Come up design what need to be created as packages to support using "opkg install" for image-creator and needed yocto-metadata|| 2|| WIP, pending comments from RP regarding how to packaging metadata|| Jessica|| rpurdie|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer image-creator and needed poky-metadata support|| The poky build system will build packages for image-creator and needed poky-metadata, which the Yocto Installer will be able to use "opkg install" to install them|| 2|| Review|| Jessica|| rpurdie|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Provide qemu management UI|| In current eclipse plugin, QEMU settings are put together with project configuration. So we can only have limited settings. If we can have a separate QEMU management UI, the end user could firstly create a QEMU config, such as (env file of arch, image location, unfs or not, sato or lsb, mem size, disk size). And then he can launch a QEMU with a specific config. The dependency between project configuration and QEMU config will be resolved. After all QEMU has nothing to do project configuration. Need to careful review the UI to ensure minimal impact to testing matrix. || 3|| Review|| || criping|| "Enhancement, duplicate of ""Qemu mem/disk size can be adjusted"""<br />
|-<br />
|| Tool Development and SDK Features|| QT plugin For Eclipse|| Integrate QT Ecplise plugin and extend for Yocto Project || 3|| Review|| || jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Profiling/Trace GUI's|| We have a wealth of great tracing and profiling tools but the UI's for them are all extremely minimal and usually quite ugly. Would be great if we could compete with, or even better, Apple's offerings here. We have the technology! || 2|| Review|| || josh|| "Enhancement, duplicate of ""Tracing/Profiling Planning Complete"""<br />
|-<br />
|| Tool Development and SDK Features|| Other profiling tools|| Complete Tom's review of profiling tools and architecture || 2|| Review|| || josh|| "Enhancement, duplicate of ""Tracing/Profiling Planning Complete"""<br />
|-<br />
|| Tool Development and SDK Features|| Design next-gen tracing/profiling tools|| Yocto 1.0 will include all the essential existing tracing/profiling tools expected by users, and Josh has proposed a UI integration of all those tools as far as it's possible to do so. That level of integration, basically a 'plugin-level' integration is necessary and useful, but doesn't go far enough. A next-generation tracing tool would integrate at a much more fundamental level; if done properly, it would provide unmatched levels of power and usability to users, and would allow Yocto to distinguish itself in the embedded tracing/profiling space in a way also unmatched by any other distro/build-tool. The implementation would of course not be available for Yocto 1.0, but a coherent design, including prototypes, that could be taken to the community and implemented in a V 1.5 or 2.0 should be done in that time frame. || 1|| Review|| || tzanussi|| "Enhancement, duplicate of ""Tracing/Profiling Planning Complete"""<br />
|-<br />
|| Documentation Features|| Self Documentation of image contents|| "I'd like to see the -doc packages Poky builds being combined into some kind of large documentation index representing the collective API docs of the target being built. This can then be placed on a webserver and viewed over the web. We'd have a demonstration of this for a ""bitbake world"" target. Part of the idea here is to start making good use of the docs as if developers see this they might start writing better docs too. Aim is to lead the field :). There are a number of places poky packages disable doc generation due to missing tools so we'd need to add these so we can enable the doc generation. Many packages already have many docs though too. "|| 2|| Review|| || rpurdie|| enhancement<br />
|-<br />
|| Validation|| Testing Framework|| Add a framework for doing automated testing in the project|| 1|| Review|| || davest|| project commitment<br />
|-<br />
|| Validation|| more SDK builds on autobuilder|| enable more SDK related tests on autobuilder such as meta-ide-support, etc.|| 2|| Review|| || ktian1|| project commitment, addressed by test plan (?)<br />
|-<br />
|| Validation|| more people should try using SDK|| this may not be a feature, but a requirement. SDK including meta-toolchain is one key factor impacting user experience on Yocto. It's not enough to have only SDK team play with it|| 2|| Review|| || ktian1|| project commitment, addressed by test plan (?)<br />
|-<br />
|| Validation|| Unit Testing Framework|| Add a mechanism to bitbake to parse source packages that have unit tests and then execute them on the target|| 3|| Review|| || sgw|| "project commitment, duplicate of ""Testing Framework"""<br />
|-<br />
|| Validation|| Test Case open source|| Open source Yocto test cases with xml format|| 1|| Review|| || yyou|| "project commitment, duplicate of ""Testing Framework"""<br />
|}</div>Davesthttps://wiki.yoctoproject.org/wiki/index.php?title=Yocto_1.0_Schedule&diff=599Yocto 1.0 Schedule2011-01-25T16:31:49Z<p>Davest: /* Sprint D (closes Jan 21, 11:59pm PDT -- pull request sent, initially reviewed) */</p>
<hr />
<div>= v1.0 (release date: Apr 15, 2011) =<br />
----<br />
The detailed milestone map for v1.0 is as below. During the first week of each subsequent milestone past M1 we will have a demonstration of the previous milestone capabilities as well as a planning and design session for the current milestone.<br><br><br />
<br />
== M2 (Nov 08 to Dec 24 -- Dev Complete Dec 10, Stabilize Complete Dec 17, Release Complete Dec 24) ==<br />
=== Sprint A (closes Nov 12, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links''' <br />
|-<br />
|| Poky Features || Kernel interactive targets || To support incremental kernel development having the ability to run menuconfig (or xconfig, etc) directly is a common request. We'll need to add this for commercialization anyway. i.e. bitbake -c menuconfig. This fuctionality already exists. || 1 || Done || Richard || bruceashfield || Enhancement <br />
|-<br />
|| Distribution / components || Distro Audit: Upgrades Planned (Phase 1) || Complete plan for package upgrades in M2 || 1 || Done || Saul || || Continual Maintenance<br />
|-<br />
|| Validation || Runtime testing || Runtime testing of images as part of the autobuilder || 1 || Done || Jiajun/ScottG || rpurdie || project commitment<br />
|- <br />
|| || Poky Image Creator Wireframe/Interaction Plans Complete || || 1 || Done || Josh || ||<br />
|-<br />
|| || SDK Generator Interaction: Plans Complete || || 1 || Done || Jessica || ||<br />
|-<br />
|| || Tracing/Profiling Planning Complete || This needs to cover where we're at now, what we're missing and also propose the future enhancements that may be needed. M2 targets getting existing tools integrated and documented. F2f discussion n the future enhancements || || Done || Tom || ||<br />
|-<br />
|| || Swabber. (Still needs to be integrated into weekly build by default) || || 1 || Done || Josh || ||<br />
|-<br />
|| Build/Release || Release process documentation || || || Done || Beth || ||<br />
|-<br />
|| Validation || Test plan for v1.0 (to address any deficiencies in coverage from v0.9)|| || 1 || Done || Jiajun || ||<br />
|}<br />
<br />
=== Sprint B (closes Nov 19, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| Distro Audit: World Packages|| Audit world packages making sure it all build, making sure all are packages are required || 2|| Done || Saul|| sgw|| Hygiene<br />
|-<br />
|| Tool Development and SDK Features|| SDK Generator Installer UI|| Look at different ways of Installer UI (GTK+ and ncurses) seems none of them is the right choice, decide to go with script to implement all the functionalities of installer and later add UI part on top of it || 1||Done|| Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Customize sysroot setup || Add and test out "--sysroot" config option to cross compiler within Eclipse IDE || 1|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| SDK Generator Installer design revision|| Close all open questions regarding Yocto SDK Generator Installer function design and come up HLD || 1|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Distribution / components|| kernel version|| keeping 2.6.34 as a -stable kernel is the best option. I've also got a newer -devel tree that can be made available or made the default. || 3|| Done || Bruce|| bruceashfield|| enhancement<br />
|-<br />
|| || assign Yocto Project PM|| acquire and assign a program manager for Yocto Project|| || Done || DaveST|| || <br />
|-<br />
|| || assign Yocto Project Sys Admin|| || || Done || Saul|| || <br />
|-<br />
|| Tool Development and SDK Features|| oprofileUI|| Fixing various bugs of the oprofileUI to make it workable on big endian host.(i.e. ppc, mips) || 2 || Done || Jessica || lianhao.lu || Bug #382 / Bug #493<br />
|-<br />
|| Poky Feature|| SDK Version Control|| If we can expect that yocto SDK has lots of release in the future, we might need to consider SDK version control. Currently, every thing installed under /opt/poky which leads to things be overriden, we need to be able to use a scheme like /opt/poky-1.0, /opt/poky-2.0 to distiguish things. || 2|| Done || Josh|| jzhang|| Enhancement<br />
|-<br />
|| Kernel || Kernel plan complete || Flesh our kernel deliverables and add to Yocto 1.0 schedule || || Done|| Darren || dvhart ||<br />
|}<br />
<br />
=== Sprint C (closes Nov 26, 11:59pm PDT -- pull request sent, initially reviewed) :: NOTE: this is US Thanksgiving week ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| Distro Audit: Licence Checksums|| licence checksums || 1|| Done || Saul|| rpurdie|| Hygiene<br />
|-<br />
|| Poky Features || Performance Analysis Completed|| "I'd like someone to instrument a green release build, see where it spends time (hot/cold parsing time, individual task building time) and then compare this with our 0.9 release build. I'd also like to compare the disk usage between the two. Once we have a blame list we can then set about fixing it. Some things I know will come up: a) pseudo, b) checksums/signature code, c) exec() vs fork for executing tasks, d) task based prebuilds increasing disk usage, e) rpm dependency calculations, f) using rpm vs. ipk but I may be wrong and there may be others. We need numbers. "|| 1|| Done || Saul / Qing, Dongxiao|| rpurdie|| Enhancement<br />
|-<br />
|| Poky Features || environment variables for kernel builds|| switching a branch, or adding a configuration feature (and even changing the kernel repo) is often done during development of a BSP. Having some additional variables that are pass the bitbake environment scrub would be useful. i.e. KBRANCH=foo bitbake -c configure linux-yocto. This goes along with the other BSP bootstrapping suggestions. || 2|| Done || Bruce|| bruceashfield|| Enhancement<br />
|-<br />
|| Supported Targets|| ARM Platform Support|| Replace beagleboard with Beagleboard XM - decision || 2|| Done || Bruce|| alex|| Basic Yocto hardware support <br />
|-<br />
|| Distribution / components|| Security Process|| We need a dedicated person to scan and apply critical security updates to the distro. The MeeGo team already has a similar process with some scripts which may be leveraged. To complete the task, the process should be documented and a first pass over the metadata made to establish the current position on security. Any upgrades needed should be identified and a plan to address them should be in place but doesn't have to be implemented by this point.|| 1|| Done || ScottG|| ktian1|| enhancement<br />
|-<br />
|| Tool Development and SDK Features|| SDK Generator Installer Opkg repo design|| Come up a opkg repo design that will mimic the final Yocto package repo layout to be used by SDK Generator Installer to test against|| 2 || Done || Jessica || jzhang || <br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer tar creaion|| Create a Yocto Installer tar ball which contains Installer script and supported opkg component that will be used for installing other Yocto components|| 2 || Done || Jessica || jzhang || <br />
|-<br />
|| Documentation|| Kernel Framework Paper from WR|| The paper from WR needs to be re-written and then posted somewhere on the Yocto Project site. This will involve examiniation of the text and re-writing and formatting for presentation. Currently it is simply a text document. Completion time assuming uninterrupted time is one week.|| High|| Done || Scott Rifenbark|| 1 Week|| Documentation<br />
|-<br />
|| Documentation|| Poky Reference Manual|| This guide exists in the 0.9 form. The re-write of the text needs to be completed. So far, all the chapters have been rewritten but not re-posted on the site. Only the appendices remain for a text scrub. Time to complete this would be a week of uninterrupted time. Ideally, the manual would be a sub-manual that would be referenced and architected into the Yocto Project Development Guide.|| Medium|| Done|| Scott Rifenbark|| 1 Week|| Documentation<br />
|-<br />
|| Kernel || Initial meta-linaro layer || meta-linaro layer providing a kernel, tool-chain, and uboot loader. This deliverable is primarily to get the infrastructure in place and have a buildable kernel. Toolchain on best effort basis. || || Done || Darren || dvhart || Moderate risk of slippage due to holidays.<br />
|-<br />
|| Kernel || Tracing: blktrace and sysprof recipes || || || Done || Tom || dvhart ||<br />
|}<br />
<br />
=== Sprint D (closes Dec 3, 11:59pm PDT -- pull request sent, initially reviewed) :: NOTE: week of the F2F planning meeting ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Kernel || Kernel git branching structure revamped || || 1 || Done || Bruce || dvhart ||<br />
|-<br />
|| Kernel || Tunnel Creek (Crown Bay) || || 1 || Done || Tom || dvhart ||<br />
|}<br />
<br />
=== Sprint E (closes Dec 9 (THURSDAY), 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| Distro Audit: Upgrades Completed (Phase 1)|| Update to new versions as per the agreed plan for M2 from Sprint A|| 1|| Done || Saul|| rpurdie|| Continual Maintenance<br />
|-<br />
|| Distribution / components|| Distro Audit: Src Checksums|| Make sure all SRC_URI components have checksums too || 1|| Done || Saul|| rpurdie|| Hygiene<br />
|-<br />
|| Poky Features || enable KVM with qemu|| today all new Intel processors support VT, which are enabled on most desktop machines which are most frequently used build machine. with VT support, x86/x86-64 qemu target runs faster which is a good thing for emulation environment. This may require some qemu option tweaks and also poky-qemu script enhancement. || 2|| Done || Saul / Edwin|| ktian1|| Enhancement<br />
|-<br />
|| Kernel || New kernel recipes || dev, -devel, -custom || 3 || Done || Bruce || dvhart ||<br />
|-<br />
|| Swabber || Documentation for swabber || || 1 || Done || Alex || ||<br />
|-<br />
|| CCB || Defect triage process in public documented and implemented || || 1 || Done. Triage process is documented, out for review. || Saul || ||<br />
|}<br />
<br />
== M3 (Dec 20 to Feb 08 -- Dev Complete Feb 04, Stabilize Complete Feb 11, Release Complete Feb 18) ==<br />
=== Sprint A (closes Dec 24, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Kernel || Initial meta-rt layer || PREEMPT_RT kernel and related test-cases and benchmarks || 2 || Done || Darren || dvhart || slipped out from M2<br />
|-<br />
|| Poky Features || Fetcher Overhaul Phase 1 - SRC_REV enhancement||<br />
* a) Add code in FetchData::__init__() which will check if the selected fetcher supports srcrev and the automatically call a function to set the src rev value instead of each fetcher doing this.\n <br />
* e) Break SRCREVINACTION deadlock. To do this, we need to start using a keyword for automatically increasing SRCREV, e.g. SRCREV = "AUTOINC". The actual revision can be injected into PV using SRCPV. If we do this there should no longer be a need of the deadlock; <br />
* k) Ensure that we only set __BB_DONT_CACHE when SRCREV = "AUTOREV". This may need a new method call for fetchers to tell whether they're "floating" or locked down.<br />
|| 1|| Done || Saul / Ke, RP|| rpurdie|| Enhancement, slipped out from M2<br />
|-<br />
|| Distribution / components|| Distro Audit Upgrades Planned (Phase 2)|| Complete plan for package upgrades in M2|| 1|| Done || Saul|| || Continual Maintenance<br />
|-<br />
|| Poky Features || Pseudo Performance || Implement the changes to bitbake based on pseudo's enable/disable switch|| 1|| done || Saul / Qing, Dongxiao || rpurdie|| Enhancement, slipped from M2 due to risk and not having Pseudo's change yet.<br />
|-<br />
|| Tool Development and SDK Features|| Fix the issue user target sysroot is owned by root || The ADT installer will use pseudo to extract user target sysroot which ended up owned by root, this need to be fixed || 1|| done || Jessica|| jzhang|| Cleanup <br />
|-<br />
|| Tool Development and SDK Features|| Eclipse poky tree interfacing (metadata file editor)|| Provide a metadata file editor with some syntax checking and keywords highlight capabilities|| 2|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| IDE Project templates|| Templates for various project types: Clutter GUI, Gtk+ GUI, to help developers get started quickly || 2|| Done || Jessica|| josh|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| push TCF/RSE patches upstream|| work with community to finish up our TCF terminal service, TCF/RSE integration remaining patches taken by upstream. Blocking issues including Eclipse Bug #327865 || 1|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Pseudo || Pseudo enhancement to enable on/off switch || || 1 || done || Mark || ||<br />
|-<br />
|| Pseudo || Bitbake enhancement for pseudo on/off switch || || 1 || done || Richard || ||<br />
|-<br />
|| bugzilla || Complete restructure of bugzilla categories || || 1 || done || Saul || ||<br />
|-<br />
|| Poky Features || Image creator ground work || Nomenclature determined, existing gui's bug fixed and backend work implemented || 1 || Done || Joshua || ||<br />
|-<br />
|| Kernel || Tracing: Initial SystemTap recipe || Works on x86 || 3 || Done || Tom || dvhart ||<br />
|-<br />
|| Distribution / components|| Distro Audit: Package Description/Summary completed|| Ensure DESCRIPTION/SUMMARY fields are all audited|| 2|| Done || Mark|| Mark|| Hygiene, was M2, Sprint B but missed window<br />
|-<br />
|| Distribution / components|| Zypper/RPM|| Small write-up of the problems we're having w/ Zypper and what we plan to do. (i.e. create a roadmap/design) - Includes rootfs generation - Package uprev/install/removal || 1 || Done || Mark/Qing || || was M2, Sprint B<br />
|-<br />
|| Distribution / components|| Distro Audit: Licence Checksums|| Make the licence checksums fatal if not present || 1|| Done || Saul|| rpurdie|| Hygiene, was M2, Sprint C<br />
|-<br />
|| Distribution / components|| push of all relevant Wind River patchs to Yocto (patch comparison)|| Ensure patches present to packages in WRS are also in Poky|| 1|| Done || Mark|| Mark|| was M2, Sprint C<br />
|-<br />
|| Poky Features || Performance Enhancement Completed || Initial changes to reduce disk space (sstate-build-*) || 1|| Done || Saul / Qing, Dongxiao || rpurdie|| Enhancement, was M2, Sprint E<br />
|-<br />
|| Distribution / components|| User specified qemu config support|| We'll provide user an edit box which allows advanced qemu user to specify arbitrary qemu configuration to meet their needs, which the poky-qemu scrip will just append the config list towards the end of the list of parameters to bring up qemu, it also expect the poky-qemu script to do some basic sanity check on the user specifications to catch the obvious mistake || 2|| Done || Saul / criping || criping|| enhancement, was M2, Sprint E<br />
|-<br />
|| Tool Development and SDK Features|| SDK Version Control support in SDK generator installer|| If we can expect that yocto SDK has lots of release in the future, we might need to consider SDK version control. Currently, if we un-tar the sdk, it will override the older version. It's not good for app developers since they might need the old version to do something. And also, maybe a finer installer than untar is preferred. Installer will tied to certain SDK version and the installation will go under /opt/poky-versionNo.|| 1|| Done || Jessica|| criping|| Enhancement-expect planning process by Jessica to handle this task. Was M2, Sprint E.<br />
|}<br />
<br />
=== Sprint B (closes Jan 07, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || Bitbake multi-threaded parsing|| Bitbake recipe parsing is currently single threaded. I want to make this multithreaded as the speedup would be nice. If I can only take a single task for myself for 1.0, I'm nominating this one as I enjoy this kind of thing and I have ideas on how to do it. || 1|| Done || Richard|| rpurdie|| Enhancement<br />
|-<br />
|| Distribution / components|| Lock in Kernel/Toolchain version|| Locked in 2.6.37 and gcc 4.5.1. Pending decision to move to 4.5.2 and Linaro || || Done || || Richard|| || <br />
|-<br />
|| Distribution / components|| License Update|| For each of the licences we support, I'd really like to have a licences directory with a copy of that license contained within. When it comes to deciding what a given LICENSE field means, this would be the reference. It also means we can include the licences a given image includes with the image. This continues to make our license handling world class and ahead of the field. || 2|| Done || Beth|| rpurdie|| Hygiene<br />
|-<br />
|| Tool Development and SDK Features|| Qemu configuration change|| Provice edit box for advanced user to specify qemu configurations|| 2|| Done || Jessica|| criping|| <br />
|-<br />
|| Tool Development and SDK Features|| Lock down Eclipse+CDT+TCF version|| Will use Eclipse Halo 3.6 || 1|| Done || Jessica|| || <br />
|-<br />
|| Demo|| Finalize on demo plans for v1.0 launch || || 1|| Done || Dave || || <br />
|-<br />
|| Release || Release plans for v1.0 launch || Fill out the M4 plan with the necessary release activities and timings || 1|| Done || Beth || || <br />
|-<br />
|| Poky Features || Basic image creator GUI || Functional UI missing some Advanced features || 1 || In replan || Joshua || || <br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer for SDK Generator Installation functions support||Detailed feature request can be found at: http://bugzilla.pokylinux.org/show_bug.cgi?id=589|| 1|| Done || Jessica|| rpurdie|| Enhancement<br />
|-<br />
|| Kernel || Tracing: trace-cmd python binding cleanup || || 3 || Done || Darren || dvhart ||<br />
|}<br />
<br />
=== Sprint C (closes Jan 14, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || kernel development layer|| The (correct) poky behaviour of building known revisions coupled with the fetcher requiring a BSP branch to already be present means that local modifications (and kernel source tree) are required for kernel development. I already have a layer that overrides/modifies the behaviour when added to the bblayers.conf and configured into an environment. This seems useful for more people to use. || 2|| Done || Bruce|| bruceashfield|| Enhancement, was M2, Sprint C<br />
|-<br />
|| Distribution / components|| Zypper/RPM|| RPM Up-rev / Zypper Up-rev [lets get to the latest versions]|| 1|| Feb 4 || Mark/Qing|| || was M2, Sprint C<br />
|-<br />
|| Supported Targets|| Intel Platform Support|| JasperForest|| 2|| Basic support in place; DPDK evaluation in process, overall BSP plan still TBD || Tom|| davest|| Basic ECG support (Moved from Sprint A)<br />
|-<br />
|| Tool Development and SDK Features|| Eclipse poky tree interfacing (git support)|| Use Eclipse git capability to install poky tree from git repo and able to interact with git repo at file level within Poky tree || 2|| Done || Jessica|| jzhang|| Enhancement<br />
<br />
|-<br />
|| Poky Features || Poky Image Creator|| A standalone application you can run which asks you to select a distro and machine, then presents a list of packages you can select. Once the selection is made, it goes off and bakes you an image which is then presented to you. Implementation wise, it should use the sstate packages, be a bitbake UI and use the usual poky bbclass files to do the image construction behind the scenes. || 1|| Re-plan || Joshua|| rpurdie|| Enhancement<br />
|-<br />
|| Distribution / components|| LSB Sanity|| execute LSB Test and improve passing rate and document failures with clear understanding|| 2|| Done || MarkH/Saul|| sgw|| Hygiene<br />
|-<br />
|| Tool Development and SDK Features|| Image creator integration with Eclipse || || 2|| replan|| Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Kernel || Tracing: perf trace marker support || This is from feedback to the new trace command. Ingo appears to have this nearly complete already. || 3 || Done || Darren || dvhart ||<br />
|-<br />
|| Cleanup || bitbake user experience error handling validation completed || || 2 || Done || Richard || ||<br />
|-<br />
|| Cleanup || variable scrub - ensure all metadata variables are documented || Script with a histogram of variable use done, identified 50 variables to document; Add task for actual documentation update is low on the list || 2 || Done || Scott/Darren || ||<br />
|-<br />
|| Kernel || Tracing: package kernelshark || || 3 || Done || Darren || dvhart ||<br />
|}<br />
<br />
=== Sprint D (closes Jan 21, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Swabber || Complete review of swabber outputs || Move to M3 Sprint D || 1 || Move to M3 Sprint D || Alex || ||<br />
|-<br />
|| Poky Features || Fetcher Overhaul Phase 2 - API reorg||<br />
* f) Add a generic unpack funciton to __init__.py based on the unpack task in Poky ;<br />
* g) Split go() methods into the following steps: i) download() - do whatever transfer is necessary to get the sources locally ii) build_mirror_data() - generate any data that would be needed to construct a source mirror iii) unpack() - takes a directory as an argument of where to place extracted sources;<br />
The existing go() methods should be replaced with a set of calls to the above sections of functionality as appropriate in the individual fetchers. Some of these categories of function make no sense in certain fetchers, in which case they shouldn't need to implement them. Functions are only executed if the method is present.<br />
* h) Change Poky's unpack to call an unpack method in the fetchers.<br />
* i) Change Poky's fetch task to call a "download" method in the fetcher instead of go().<br />
|| 1|| Done || Saul / Ke, RP|| rpurdie|| Enhancement<br />
|-<br />
|| Poky Features || Fetcher Overhaul Phase 3 - git enhancement||<br />
* j) Optimize git fetcher for the new layout so for a git checkout, we clone the repository in download(), then unpack just does a clone with references to the original repo. <br />
* k) Ensure that we only set __BB_DONT_CACHE when SRCREV = "AUTOREV". This may need a new method call for fetchers to tell whether they're "floating" or locked down. <br />
* l) Add a new "BB_NO_NETWORK" variable which the fetchers check before peforming an operation which hits anything remote. This means adding in error messages about why network access is needed at various points (e.g. SRCREV = "AUTOREV" for a given recipe) <br />
* m) Add multiple branch/srcrev support for git fetcher. These would be of the form: git://somelocation/somerepo.git;name=ref1;branch=foo;name=ref2;branch=bar SRCREV_ref1 = "hash1" SRCREV_ref2 = "hash2" which would ensure both hash1 and hash2 were in the final repo. <br />
* n) Change git fetcher to default to git protocol instead of rsync<br />
|| 1|| Slipped to Sprint D || Saul / Ke, RP|| rpurdie|| Enhancement<br />
|-<br />
|| Poky Features || DSO linking changes|| "By the default the gcc linker will automatically link any dependant objects/libraries. ""Inherited"" linkages can cause issues, for example, where a shared object changes its dependencies but a program has come to rely on symbols from an implicitly linked library. Fedora implemented this change in F13, seems like it would be useful to have in Poky too. "|| 2|| Done || Saul / Nitin || josh|| bug#516<br />
|-<br />
|| Distribution / components|| Distro Audit Documentation Output|| Audit package documentation output || 2|| on track for Feb 3 || Saul / ScottG || rpurdie|| Hygiene<br />
|-<br />
|| Distribution / components|| Review & Fix Standards Tests|| Review the results from LTP, POSIX and assess the result, fix as appropriate and clearly document failures.|| 2|| a Plan to resolve final items to be sent to the m.l. by Jan 14 || Saul/Kevin || sgw|| Hygiene<br />
|-<br />
|| Poky Features || libtool sysroot option|| libtool 2.4 has a sysroot option. We should try and use it, see how it works and whether we can ditch some of our libtool hacks. || 1|| Done || Saul / ScottG || rpurdie|| Enhancement<br />
|-<br />
|| Distribution / components|| MACHINE or Recipe specific sysroots|| Each machine should have its own sysroot. We'll probably have to split do_populate_sysroot into a two step process, creation of the package and than installtion of the package, which the installation of the package being made machine specific (put ${MACHINE} into ${STAMP} and bitbake should do that). Also allowing this to work per recipe would be desireable|| 1|| MACHINE-specific are on done; Recipe should be on post 1.0 list with a ? || Saul / Dongxiao || rpurdie|| Hygiene<br />
|-<br />
|| Distribution / components|| Toolchain Bootstrap Process|| The toolchain as it bootstraps overwrites files like libc.so and libgcc.so in the sysroot directory which causes issues if you just try and rebuild part of the toolchain. Each step of the bootstrap process should use a separate sysroot. Once this is once, sstate file overwriting detection can be added and enabled. || 1|| Done || Saul / Dexuan || rpurdie|| Hygiene<br />
|-<br />
|| Documentation Features|| Package report system|| move to public server [setup a package report system in an internal machine. We need push it publicly available. The basic features like search and report have been there. But there're still some enhancements in plan, to make it a fit place to feel Yocto metadata comfortably]|| 2|| Move to Sprint E|| KevinT|| ktian1|| enhancement<br />
|-<br />
|| Distribution / components||Add headers and libraries to qemu images ||Since we'll be using qemu images as target sysroot, need to create a set of qemu images for minimal, sato, LSB that contains target header and libraries.|| 2|| Done || Saul ||jzhang|| Enhancement<br />
|-<br />
|| Distribution / components|| push of all relevant Wind River patchs to Yocto (patch comparison)|| Update any additional patches needed since M2.|| 1|| May be done by Jan 28, pending RPM stuff || Mark|| Mark|| <br />
|-<br />
|| Distribution / components|| mklibs|| mklibs is a tool to optimize size of [e]glibc for a perticular root file system image. It is useful to save disk space on small devices. || 2|| Push to Sprint E || Saul|| Nitin Kamble|| enhancement<br />
|-<br />
|| Poky Features || Performance Enhancement || reduce disk space (hardlink) || 1 || On track for Jan 28, pending RP review || Saul / Qing, Dongxiao || rpurdie || Enhancement<br />
|-<br />
|| Kernel || Tracing: perf trace scripting support || || 3 || Move to Sprint E || Tom || dvhart ||<br />
|-<br />
|| Kernel || Tracing: tuna, oscillosope recipes || || 3 || Tom to discuss plan with Darren et al to see whether we should include these in 1.0 || Tom || dvhart ||<br />
|- <br />
|| BSP || Beagleboard XM Support || || 3 || 2.6.34 done, but 2.6.37 is troublesome, Darren will sync up with RP and Bruce || Darren || dvhart ||<br />
|-<br />
|| BSP || 2.6.37 Crown Bay Support || On Track for Jan 21 || 2 || || Tom || dvhart || <br />
|-<br />
|| BSP || 2.6.37 Emenlow Support || On track for Jan 21 || 2 || || Tom || dvhart || <br />
|}<br />
<br />
=== Sprint E (closes Jan 28, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| rootless X|| rootless x server has better security than x server launched by root. MeeGo already enable this feature. it would be nice for Yocto to also enable it. || 2|| On track for Jan 28 || Saul / Ke || yuke|| enhancement<br />
|-<br />
|| Documentation Features|| Package report system|| finish major feature development and internal review [setup a package report system in an internal machine. We need push it publicly available. The basic features like search and report have been there. But there're still some enhancements in plan, to make it a fit place to feel Yocto metadata comfortably]|| 2|| Move to Sprint E || Jonathan || ktian1|| enhancement, was M2, Sprint E<br />
|-<br />
|| Distribution / components|| perl upgrade|| perl is the most cross un-friendly recipe pending upgrade. || 2|| Slipping due to Linaro layer, moves to end of Sprint E || Nitin|| Nitin Kamble|| enhancement<br />
|-<br />
|| Supported Targets|| Intel Platform Support|| Sandybridge|| 2|| Accept|| Tom|| davest|| Basic ECG support<br />
|-<br />
|| Distribution / components|| performance indicators|| define some indicators (boot time, footprint, build time, power, component benchmarks, etc.) and then collect them for tracking purpose. The result could be posted on the wiki site, and the initial indicators can be easy ones which can be easily retrieved from autobuilder or weekly qa report). This way we have a clear track about the healthy of the Yocto project, and also identify weak areas. We can include qemu targets and several representational boards as the targets. || 2|| Review|| Beth/Jiajun|| ktian1|| enhancement<br />
|-<br />
|| Tool Development and SDK Features|| SDK user workshop|| Have some developers sit down and use our tools to develop demo software for Yocto. || 2|| Review|| Jessica|| josh|| Enhancement<br />
|-<br />
|| Distribution / components|| Zypper/RPM|| Integration based on design from Sprint B|| 1|| On track for Jan28 || Mark/Qing|| sgw|| Functionality, was M2, Sprint E<br />
|-<br />
|| Kernel || Final linux-yocto_git.bb || With 2.6.37 kernel || 1 || || Bruce || dvhart ||<br />
|-<br />
|| Kernel || Final meta-linaro layer || || || || Darren || dvhart ||<br />
|-<br />
|| Kernel || Final meta-rt layer || || || || Darren || dvhart ||<br />
|-<br />
|| Kernel || Sandy Bridge || || 1 || || Tom || dvhart ||<br />
|}<br />
<br />
=== Sprint F (closes Feb 03 (THURSDAY), 11:59pm PDT -- pull request sent, initially reviewed) :: NOTE: China New Year Holiday ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Documentation|| ADT Reference Guide Draft out for review || Outline complete|| High|| WIP || Scott Rifenbark|| jzhang|| Documentation<br />
|-<br />
|| || || || || || || || <br />
|}<br />
<br />
== M4 (Feb 07 to Apr 15 -- Stabilize Complete Mar 18, Release Complete Apr 01, Contingency to Apr 15) ==<br />
<br />
This sprint is the [[Yocto Project v. 1.0 Release Cycle]].<br />
<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Documentation|| Migration chapter in the Poky Reference Manual|| This chapter would cover the four identified use-cases for migrating up to the most recent version of Yocto Project. Additionally, it would cover migration scenarios from other development systems. The chapter does not yet exist. The chapter has not been scoped outside of having a meeting that identified four use-cases that did not include migration from a development system outside of Yocto Project. It will take some more scoping time to cover those areas (a day or two). Again, I have no idea of the length. See earlier entries for standard industry writing estimates for software documentation|| Medium|| Not Started|| Scott Rifenbark|| 3-4 Weeks|| Documentation<br />
|-<br />
|| Documentation|| Yocto Project Development Guide|| This manual would be an over-arching document that frames the complete development cycle within Yocto Project. The idea here is that the document would be an umbrella document that spawned and referenced subsequent documents. The organization would be the first chapter overviewing the major development pieces such as recipe creation, building, debugging, publishing, fail-safing, back-door hook creation, etc. Scoping would be about two weeks and length would probably be about 40 pages. Overall development time would likely be a month of uniterruped time.|| Medium|| Not Started|| Scott Rifenbark|| 3 Weeks|| Documentation<br />
|-<br />
|| Validation|| Boottime/Performance Analysis|| Compare Yocto Project performance to other projects such as MeeGo|| 1|| Initial report on where we are by Feb 9 || Darren|| davest|| project commitment<br />
|-<br />
|| || Multilib Support|| Consider developing post-1.0 branch || 1|| to start in M4 || Richard|| ||<br />
|-<br />
|| Validation|| Alpha testing complete|| 4-5 internal developers unfamiliar with Yocto Project try to do a build and report on the experience and issues encountered|| 1|| Done by Feb 18 || Julie|| davest|| <br />
|-<br />
|| || || || || || || || <br />
|}<br />
<br />
== Features needed and to be put into sprints by assigned owners: ==<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || package config option enhancement|| there're several enhancements we may do here: * allow users setting specific config options (local or global) from external tool, such as poky image creator, instead of changing recipes manually. Need a mechanism to convert from variable assignments into exact config options (e.g. feature_${PN} = ""1"" -> ""--enable-feature""). Consequently dependency chain needs update with option status. * host contamination check. We have swabber to check host contamination, but I'm not sure whether it covers configuration phase. If not, this is one area to improve, as not ususually we see configure script checks host bits for available features * conditional option manipulation. In many recipes we enable/disable one option based on availability of other packages. Now this is done manually and not flexible. this should be made automatically though some new annotation to indicate condition, or just base_contains (not convenient: long line, need define distro features) || 2|| Review|| Richard/MarkH|| ktian1|| Enhancement<br />
|-<br />
|| Media|| Yocto Project Awareness Video|| This 2.5 minute video would introduce and describe the benefits of Yocto Project. The video would use entertaining animations that described concepts and benefits. The result would be suitable for YouTube, conferences, and the website. The production is called an "Epipheo" and will be created by Epipheo Studios. The engagement process has begun and the kick-off meeting will be soon. The PO is in place. Time for development is 10 weeks.|| High|| Kick-off Imminent|| Scott Rifenbark|| 10 Weeks|| Media<br />
|-<br />
|| Documentation|| Yocto Project Debugging Guide|| This would be a guide for the debugging and bug tracking process in Yocto Project. Originally, the thought was that we needed a Bugzilla User's Manual. However, since we don't own Bugzilla it doesn't make sense to produce documentation for it. Rather, we should document the process as it fits into the Yocto Project environment. Ideally, the manual would be a sub-manual that would be referenced and architected into the Yocto Project Development Guide. The manual has not been scoped and would take a week to scope. Again, I have no idea of the length. See the previous item for standard industry writing estimates for software documenation.|| Medium|| Not Started|| Scott Rifenbark|| 3-4 Weeks|| Documentation<br />
|-<br />
|| Website|| Yocto Project Website|| The 0.9 website is in place but needs updates. Items for consideration are the left-panel naviagation scheme, a contributions guidance page, color-scheming and theme (possibly).|| Medium|| Not Started|| Scott Rifenbark|| 1-2 Weeks|| Website<br />
|}<br />
<br />
== Features not believed to be needed in v1.0: ==<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || OpenEmbedded/Bitbake Upstreaming|| "We firstly need to review where we are and where OE is. We then need to make a plan about what we're going to push upstream and what we're not. I'd suggest when we're in PRC, we do a crash course in ""dealing with OE"" and then many dedicate a block of time (a week) where the distro team comes up with a patch set we then propose and get merged into OE. I'd like to find a couple of interested people to monitor OE more regularly and start a workflow of things between Poky/OE where appropriate. The key thing to remember is we need to keep the architectures compatible. The team is now at the point where I'm happy for them to actually try building OpenEmbedded and not worry about it tainting them! "|| 2|| Review|| || rpurdie|| Process<br />
|-<br />
|| Poky Features || Handle old versions in WORKDIR|| an incremental build directory may finally include many old versions WORKDIRS. It'll be good to have those old versions tracked in the cache, which can then either generate a report or allow selectively cleaning up an specific version WORKDIR. Or else it's difficult to figure it out when people want to keep the whole tmp directory but like to cleanup some old bits when disk usage is under pressure. If it's not easy to do in bitbake, perhaps some separate scripts would be also helpful || 3|| Review|| || ktian1|| Enhancement<br />
|-<br />
|| Poky Features || run bitbake w/o rebuilding the cache|| "sometimes it's useful to allow run bitbake w/o re-parsing recipes, if we know nothing metadata is changed. we can just allow reusing existing persistent cache. this is useful when people is debugging WORKDIR w/o metadata change. also sometimes ""bitbake -e"" is used frequently to check poky variable information. with existing cache, several seconds can be saved which are not negligible for a developer daily working on Yocto "|| 2|| Review|| || ktian1|| Enhancement<br />
|-<br />
|| Poky Features || parallel make improvement|| parallel make experience is not good, especially when bb threads and make threads are increased larger than 8. So far we either try to fix package makefile or mark the recipe as no parallel make, when build faiures are reported. But this greatly impacts user experience for a successfully continuous build process. Could we define a safe number we do want to support for 1.0 release? and then have our autobuilder, QA test, and developers cover that number immediately and fix any issues accordingly. Then the safe number can be suggested to the Yocto user || 2|| Review|| || ktian1|| Enhancement<br />
|-<br />
|| Poky Features || Dependency packages rebuild/clean|| It is a mechanism to rebulid or clean a package and all other packages which have build/runtime dependency on it. With this change, we can find potential influences of package upgrade to its related packages, which can make the incremental build more trustable. For example, if we upgrade a package to a new vesion which changes its API, this mechanism can easily find out the incompatibility to other packages which have dependency on it. || 2|| Review|| || dongxiao.xu|| Enhancement, replaced by checksum feature<br />
|-<br />
|| Distribution / components|| FOSSology|| This may be similar to License Update above, but start to use FOSSology to track licenses. || 2|| Review|| || sgw|| Hygiene<br />
|-<br />
|| Distribution / components|| Package Developer Tools|| Create a set of Init scripts template and then review our current init scripts and modify them to confirm to the template. || 2|| Review|| || sgw|| Easy of Use<br />
|-<br />
|| Distribution / components|| Package Website|| Complete the work the intern has started on generating the distro tracking information and get it out on the external site. || 2|| Review|| || sgw|| "Hygiene, duplicate of ""Package report system"""<br />
|-<br />
|| Distribution / components|| Bluetooth UI support|| Currently we have bluez package in poky, and we need to have a workable graphic user interface to connect/configure BT devices. One choice may be gnome-bluetooth-applet. || 3|| Review|| || dongxiao.xu|| enhancement<br />
|-<br />
|| Distribution / components|| Connman-gnome enhancement features|| Enable connman-gnome to support features like, WPA Enterprise connection, hidden SSID, etc. || 3|| Review|| || dongxiao.xu|| enhancement<br />
|-<br />
|| Distribution / components|| Java Running Environment support|| Since most embedded systems support java applications running in it, maybe we'd better consider supporting some kinds of JVMs(Embeded JVM). The JVM may not run by default, but user can launch it if running java applications. Compared with GTK/QT, java user number is not small too. || 3|| Review|| || criping|| enhancement<br />
|-<br />
|| Distribution / components|| create more use cases|| UPnP demo is one really good use case showing how Yocto is utilized to make real functionality. and we could create more to show how Yocto is easily adapted to real use cases. Those use cases can be either maintained as seperate demo layers in yocto repo, or in seperate branches for reference. We can also call for community's contribution on this which would make 1.0 full-fledged. Or else the newbies to Yocto may be in puzzle how our sample profiles can satisfy their requirements. || 2|| Review|| || ktian1|| enhancement<br />
|-<br />
|| Distribution / components|| i18n support || internationalization is an important system wide feature. Many component like font, locale affect the i18n. Yocto alreay has some i18n related package like pango, but so far did not consider i18n systematically. so this is place holder to systematically add i18n support. || 2|| Review|| || yuke/qing|| enhancement<br />
|-<br />
|| Distribution / components|| more demos || demos are a good way to educate, push the envelope, and at the same time tout the strengths of the platform. This item just records a current set of ideas from various sources which could/should be implemented: * face-recognition/face-finding, * robotic control/application of face-finding to 'camera-as-sensor' (hexbug demo), * others [tbd, add here]|| 2|| Review|| || tzanussi|| enhancement <br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer support for image-creator and needed yocto-metadata design||Come up design what need to be created as packages to support using "opkg install" for image-creator and needed yocto-metadata|| 2|| WIP, pending comments from RP regarding how to packaging metadata|| Jessica|| rpurdie|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer image-creator and needed poky-metadata support|| The poky build system will build packages for image-creator and needed poky-metadata, which the Yocto Installer will be able to use "opkg install" to install them|| 2|| Review|| Jessica|| rpurdie|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Provide qemu management UI|| In current eclipse plugin, QEMU settings are put together with project configuration. So we can only have limited settings. If we can have a separate QEMU management UI, the end user could firstly create a QEMU config, such as (env file of arch, image location, unfs or not, sato or lsb, mem size, disk size). And then he can launch a QEMU with a specific config. The dependency between project configuration and QEMU config will be resolved. After all QEMU has nothing to do project configuration. Need to careful review the UI to ensure minimal impact to testing matrix. || 3|| Review|| || criping|| "Enhancement, duplicate of ""Qemu mem/disk size can be adjusted"""<br />
|-<br />
|| Tool Development and SDK Features|| QT plugin For Eclipse|| Integrate QT Ecplise plugin and extend for Yocto Project || 3|| Review|| || jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Profiling/Trace GUI's|| We have a wealth of great tracing and profiling tools but the UI's for them are all extremely minimal and usually quite ugly. Would be great if we could compete with, or even better, Apple's offerings here. We have the technology! || 2|| Review|| || josh|| "Enhancement, duplicate of ""Tracing/Profiling Planning Complete"""<br />
|-<br />
|| Tool Development and SDK Features|| Other profiling tools|| Complete Tom's review of profiling tools and architecture || 2|| Review|| || josh|| "Enhancement, duplicate of ""Tracing/Profiling Planning Complete"""<br />
|-<br />
|| Tool Development and SDK Features|| Design next-gen tracing/profiling tools|| Yocto 1.0 will include all the essential existing tracing/profiling tools expected by users, and Josh has proposed a UI integration of all those tools as far as it's possible to do so. That level of integration, basically a 'plugin-level' integration is necessary and useful, but doesn't go far enough. A next-generation tracing tool would integrate at a much more fundamental level; if done properly, it would provide unmatched levels of power and usability to users, and would allow Yocto to distinguish itself in the embedded tracing/profiling space in a way also unmatched by any other distro/build-tool. The implementation would of course not be available for Yocto 1.0, but a coherent design, including prototypes, that could be taken to the community and implemented in a V 1.5 or 2.0 should be done in that time frame. || 1|| Review|| || tzanussi|| "Enhancement, duplicate of ""Tracing/Profiling Planning Complete"""<br />
|-<br />
|| Documentation Features|| Self Documentation of image contents|| "I'd like to see the -doc packages Poky builds being combined into some kind of large documentation index representing the collective API docs of the target being built. This can then be placed on a webserver and viewed over the web. We'd have a demonstration of this for a ""bitbake world"" target. Part of the idea here is to start making good use of the docs as if developers see this they might start writing better docs too. Aim is to lead the field :). There are a number of places poky packages disable doc generation due to missing tools so we'd need to add these so we can enable the doc generation. Many packages already have many docs though too. "|| 2|| Review|| || rpurdie|| enhancement<br />
|-<br />
|| Validation|| Testing Framework|| Add a framework for doing automated testing in the project|| 1|| Review|| || davest|| project commitment<br />
|-<br />
|| Validation|| more SDK builds on autobuilder|| enable more SDK related tests on autobuilder such as meta-ide-support, etc.|| 2|| Review|| || ktian1|| project commitment, addressed by test plan (?)<br />
|-<br />
|| Validation|| more people should try using SDK|| this may not be a feature, but a requirement. SDK including meta-toolchain is one key factor impacting user experience on Yocto. It's not enough to have only SDK team play with it|| 2|| Review|| || ktian1|| project commitment, addressed by test plan (?)<br />
|-<br />
|| Validation|| Unit Testing Framework|| Add a mechanism to bitbake to parse source packages that have unit tests and then execute them on the target|| 3|| Review|| || sgw|| "project commitment, duplicate of ""Testing Framework"""<br />
|-<br />
|| Validation|| Test Case open source|| Open source Yocto test cases with xml format|| 1|| Review|| || yyou|| "project commitment, duplicate of ""Testing Framework"""<br />
|}</div>Davesthttps://wiki.yoctoproject.org/wiki/index.php?title=Yocto_1.0_Schedule&diff=598Yocto 1.0 Schedule2011-01-25T16:12:11Z<p>Davest: /* Sprint C (closes Jan 14, 11:59pm PDT -- pull request sent, initially reviewed) */</p>
<hr />
<div>= v1.0 (release date: Apr 15, 2011) =<br />
----<br />
The detailed milestone map for v1.0 is as below. During the first week of each subsequent milestone past M1 we will have a demonstration of the previous milestone capabilities as well as a planning and design session for the current milestone.<br><br><br />
<br />
== M2 (Nov 08 to Dec 24 -- Dev Complete Dec 10, Stabilize Complete Dec 17, Release Complete Dec 24) ==<br />
=== Sprint A (closes Nov 12, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links''' <br />
|-<br />
|| Poky Features || Kernel interactive targets || To support incremental kernel development having the ability to run menuconfig (or xconfig, etc) directly is a common request. We'll need to add this for commercialization anyway. i.e. bitbake -c menuconfig. This fuctionality already exists. || 1 || Done || Richard || bruceashfield || Enhancement <br />
|-<br />
|| Distribution / components || Distro Audit: Upgrades Planned (Phase 1) || Complete plan for package upgrades in M2 || 1 || Done || Saul || || Continual Maintenance<br />
|-<br />
|| Validation || Runtime testing || Runtime testing of images as part of the autobuilder || 1 || Done || Jiajun/ScottG || rpurdie || project commitment<br />
|- <br />
|| || Poky Image Creator Wireframe/Interaction Plans Complete || || 1 || Done || Josh || ||<br />
|-<br />
|| || SDK Generator Interaction: Plans Complete || || 1 || Done || Jessica || ||<br />
|-<br />
|| || Tracing/Profiling Planning Complete || This needs to cover where we're at now, what we're missing and also propose the future enhancements that may be needed. M2 targets getting existing tools integrated and documented. F2f discussion n the future enhancements || || Done || Tom || ||<br />
|-<br />
|| || Swabber. (Still needs to be integrated into weekly build by default) || || 1 || Done || Josh || ||<br />
|-<br />
|| Build/Release || Release process documentation || || || Done || Beth || ||<br />
|-<br />
|| Validation || Test plan for v1.0 (to address any deficiencies in coverage from v0.9)|| || 1 || Done || Jiajun || ||<br />
|}<br />
<br />
=== Sprint B (closes Nov 19, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| Distro Audit: World Packages|| Audit world packages making sure it all build, making sure all are packages are required || 2|| Done || Saul|| sgw|| Hygiene<br />
|-<br />
|| Tool Development and SDK Features|| SDK Generator Installer UI|| Look at different ways of Installer UI (GTK+ and ncurses) seems none of them is the right choice, decide to go with script to implement all the functionalities of installer and later add UI part on top of it || 1||Done|| Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Customize sysroot setup || Add and test out "--sysroot" config option to cross compiler within Eclipse IDE || 1|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| SDK Generator Installer design revision|| Close all open questions regarding Yocto SDK Generator Installer function design and come up HLD || 1|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Distribution / components|| kernel version|| keeping 2.6.34 as a -stable kernel is the best option. I've also got a newer -devel tree that can be made available or made the default. || 3|| Done || Bruce|| bruceashfield|| enhancement<br />
|-<br />
|| || assign Yocto Project PM|| acquire and assign a program manager for Yocto Project|| || Done || DaveST|| || <br />
|-<br />
|| || assign Yocto Project Sys Admin|| || || Done || Saul|| || <br />
|-<br />
|| Tool Development and SDK Features|| oprofileUI|| Fixing various bugs of the oprofileUI to make it workable on big endian host.(i.e. ppc, mips) || 2 || Done || Jessica || lianhao.lu || Bug #382 / Bug #493<br />
|-<br />
|| Poky Feature|| SDK Version Control|| If we can expect that yocto SDK has lots of release in the future, we might need to consider SDK version control. Currently, every thing installed under /opt/poky which leads to things be overriden, we need to be able to use a scheme like /opt/poky-1.0, /opt/poky-2.0 to distiguish things. || 2|| Done || Josh|| jzhang|| Enhancement<br />
|-<br />
|| Kernel || Kernel plan complete || Flesh our kernel deliverables and add to Yocto 1.0 schedule || || Done|| Darren || dvhart ||<br />
|}<br />
<br />
=== Sprint C (closes Nov 26, 11:59pm PDT -- pull request sent, initially reviewed) :: NOTE: this is US Thanksgiving week ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| Distro Audit: Licence Checksums|| licence checksums || 1|| Done || Saul|| rpurdie|| Hygiene<br />
|-<br />
|| Poky Features || Performance Analysis Completed|| "I'd like someone to instrument a green release build, see where it spends time (hot/cold parsing time, individual task building time) and then compare this with our 0.9 release build. I'd also like to compare the disk usage between the two. Once we have a blame list we can then set about fixing it. Some things I know will come up: a) pseudo, b) checksums/signature code, c) exec() vs fork for executing tasks, d) task based prebuilds increasing disk usage, e) rpm dependency calculations, f) using rpm vs. ipk but I may be wrong and there may be others. We need numbers. "|| 1|| Done || Saul / Qing, Dongxiao|| rpurdie|| Enhancement<br />
|-<br />
|| Poky Features || environment variables for kernel builds|| switching a branch, or adding a configuration feature (and even changing the kernel repo) is often done during development of a BSP. Having some additional variables that are pass the bitbake environment scrub would be useful. i.e. KBRANCH=foo bitbake -c configure linux-yocto. This goes along with the other BSP bootstrapping suggestions. || 2|| Done || Bruce|| bruceashfield|| Enhancement<br />
|-<br />
|| Supported Targets|| ARM Platform Support|| Replace beagleboard with Beagleboard XM - decision || 2|| Done || Bruce|| alex|| Basic Yocto hardware support <br />
|-<br />
|| Distribution / components|| Security Process|| We need a dedicated person to scan and apply critical security updates to the distro. The MeeGo team already has a similar process with some scripts which may be leveraged. To complete the task, the process should be documented and a first pass over the metadata made to establish the current position on security. Any upgrades needed should be identified and a plan to address them should be in place but doesn't have to be implemented by this point.|| 1|| Done || ScottG|| ktian1|| enhancement<br />
|-<br />
|| Tool Development and SDK Features|| SDK Generator Installer Opkg repo design|| Come up a opkg repo design that will mimic the final Yocto package repo layout to be used by SDK Generator Installer to test against|| 2 || Done || Jessica || jzhang || <br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer tar creaion|| Create a Yocto Installer tar ball which contains Installer script and supported opkg component that will be used for installing other Yocto components|| 2 || Done || Jessica || jzhang || <br />
|-<br />
|| Documentation|| Kernel Framework Paper from WR|| The paper from WR needs to be re-written and then posted somewhere on the Yocto Project site. This will involve examiniation of the text and re-writing and formatting for presentation. Currently it is simply a text document. Completion time assuming uninterrupted time is one week.|| High|| Done || Scott Rifenbark|| 1 Week|| Documentation<br />
|-<br />
|| Documentation|| Poky Reference Manual|| This guide exists in the 0.9 form. The re-write of the text needs to be completed. So far, all the chapters have been rewritten but not re-posted on the site. Only the appendices remain for a text scrub. Time to complete this would be a week of uninterrupted time. Ideally, the manual would be a sub-manual that would be referenced and architected into the Yocto Project Development Guide.|| Medium|| Done|| Scott Rifenbark|| 1 Week|| Documentation<br />
|-<br />
|| Kernel || Initial meta-linaro layer || meta-linaro layer providing a kernel, tool-chain, and uboot loader. This deliverable is primarily to get the infrastructure in place and have a buildable kernel. Toolchain on best effort basis. || || Done || Darren || dvhart || Moderate risk of slippage due to holidays.<br />
|-<br />
|| Kernel || Tracing: blktrace and sysprof recipes || || || Done || Tom || dvhart ||<br />
|}<br />
<br />
=== Sprint D (closes Dec 3, 11:59pm PDT -- pull request sent, initially reviewed) :: NOTE: week of the F2F planning meeting ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Kernel || Kernel git branching structure revamped || || 1 || Done || Bruce || dvhart ||<br />
|-<br />
|| Kernel || Tunnel Creek (Crown Bay) || || 1 || Done || Tom || dvhart ||<br />
|}<br />
<br />
=== Sprint E (closes Dec 9 (THURSDAY), 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| Distro Audit: Upgrades Completed (Phase 1)|| Update to new versions as per the agreed plan for M2 from Sprint A|| 1|| Done || Saul|| rpurdie|| Continual Maintenance<br />
|-<br />
|| Distribution / components|| Distro Audit: Src Checksums|| Make sure all SRC_URI components have checksums too || 1|| Done || Saul|| rpurdie|| Hygiene<br />
|-<br />
|| Poky Features || enable KVM with qemu|| today all new Intel processors support VT, which are enabled on most desktop machines which are most frequently used build machine. with VT support, x86/x86-64 qemu target runs faster which is a good thing for emulation environment. This may require some qemu option tweaks and also poky-qemu script enhancement. || 2|| Done || Saul / Edwin|| ktian1|| Enhancement<br />
|-<br />
|| Kernel || New kernel recipes || dev, -devel, -custom || 3 || Done || Bruce || dvhart ||<br />
|-<br />
|| Swabber || Documentation for swabber || || 1 || Done || Alex || ||<br />
|-<br />
|| CCB || Defect triage process in public documented and implemented || || 1 || Done. Triage process is documented, out for review. || Saul || ||<br />
|}<br />
<br />
== M3 (Dec 20 to Feb 08 -- Dev Complete Feb 04, Stabilize Complete Feb 11, Release Complete Feb 18) ==<br />
=== Sprint A (closes Dec 24, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Kernel || Initial meta-rt layer || PREEMPT_RT kernel and related test-cases and benchmarks || 2 || Done || Darren || dvhart || slipped out from M2<br />
|-<br />
|| Poky Features || Fetcher Overhaul Phase 1 - SRC_REV enhancement||<br />
* a) Add code in FetchData::__init__() which will check if the selected fetcher supports srcrev and the automatically call a function to set the src rev value instead of each fetcher doing this.\n <br />
* e) Break SRCREVINACTION deadlock. To do this, we need to start using a keyword for automatically increasing SRCREV, e.g. SRCREV = "AUTOINC". The actual revision can be injected into PV using SRCPV. If we do this there should no longer be a need of the deadlock; <br />
* k) Ensure that we only set __BB_DONT_CACHE when SRCREV = "AUTOREV". This may need a new method call for fetchers to tell whether they're "floating" or locked down.<br />
|| 1|| Done || Saul / Ke, RP|| rpurdie|| Enhancement, slipped out from M2<br />
|-<br />
|| Distribution / components|| Distro Audit Upgrades Planned (Phase 2)|| Complete plan for package upgrades in M2|| 1|| Done || Saul|| || Continual Maintenance<br />
|-<br />
|| Poky Features || Pseudo Performance || Implement the changes to bitbake based on pseudo's enable/disable switch|| 1|| done || Saul / Qing, Dongxiao || rpurdie|| Enhancement, slipped from M2 due to risk and not having Pseudo's change yet.<br />
|-<br />
|| Tool Development and SDK Features|| Fix the issue user target sysroot is owned by root || The ADT installer will use pseudo to extract user target sysroot which ended up owned by root, this need to be fixed || 1|| done || Jessica|| jzhang|| Cleanup <br />
|-<br />
|| Tool Development and SDK Features|| Eclipse poky tree interfacing (metadata file editor)|| Provide a metadata file editor with some syntax checking and keywords highlight capabilities|| 2|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| IDE Project templates|| Templates for various project types: Clutter GUI, Gtk+ GUI, to help developers get started quickly || 2|| Done || Jessica|| josh|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| push TCF/RSE patches upstream|| work with community to finish up our TCF terminal service, TCF/RSE integration remaining patches taken by upstream. Blocking issues including Eclipse Bug #327865 || 1|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Pseudo || Pseudo enhancement to enable on/off switch || || 1 || done || Mark || ||<br />
|-<br />
|| Pseudo || Bitbake enhancement for pseudo on/off switch || || 1 || done || Richard || ||<br />
|-<br />
|| bugzilla || Complete restructure of bugzilla categories || || 1 || done || Saul || ||<br />
|-<br />
|| Poky Features || Image creator ground work || Nomenclature determined, existing gui's bug fixed and backend work implemented || 1 || Done || Joshua || ||<br />
|-<br />
|| Kernel || Tracing: Initial SystemTap recipe || Works on x86 || 3 || Done || Tom || dvhart ||<br />
|-<br />
|| Distribution / components|| Distro Audit: Package Description/Summary completed|| Ensure DESCRIPTION/SUMMARY fields are all audited|| 2|| Done || Mark|| Mark|| Hygiene, was M2, Sprint B but missed window<br />
|-<br />
|| Distribution / components|| Zypper/RPM|| Small write-up of the problems we're having w/ Zypper and what we plan to do. (i.e. create a roadmap/design) - Includes rootfs generation - Package uprev/install/removal || 1 || Done || Mark/Qing || || was M2, Sprint B<br />
|-<br />
|| Distribution / components|| Distro Audit: Licence Checksums|| Make the licence checksums fatal if not present || 1|| Done || Saul|| rpurdie|| Hygiene, was M2, Sprint C<br />
|-<br />
|| Distribution / components|| push of all relevant Wind River patchs to Yocto (patch comparison)|| Ensure patches present to packages in WRS are also in Poky|| 1|| Done || Mark|| Mark|| was M2, Sprint C<br />
|-<br />
|| Poky Features || Performance Enhancement Completed || Initial changes to reduce disk space (sstate-build-*) || 1|| Done || Saul / Qing, Dongxiao || rpurdie|| Enhancement, was M2, Sprint E<br />
|-<br />
|| Distribution / components|| User specified qemu config support|| We'll provide user an edit box which allows advanced qemu user to specify arbitrary qemu configuration to meet their needs, which the poky-qemu scrip will just append the config list towards the end of the list of parameters to bring up qemu, it also expect the poky-qemu script to do some basic sanity check on the user specifications to catch the obvious mistake || 2|| Done || Saul / criping || criping|| enhancement, was M2, Sprint E<br />
|-<br />
|| Tool Development and SDK Features|| SDK Version Control support in SDK generator installer|| If we can expect that yocto SDK has lots of release in the future, we might need to consider SDK version control. Currently, if we un-tar the sdk, it will override the older version. It's not good for app developers since they might need the old version to do something. And also, maybe a finer installer than untar is preferred. Installer will tied to certain SDK version and the installation will go under /opt/poky-versionNo.|| 1|| Done || Jessica|| criping|| Enhancement-expect planning process by Jessica to handle this task. Was M2, Sprint E.<br />
|}<br />
<br />
=== Sprint B (closes Jan 07, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || Bitbake multi-threaded parsing|| Bitbake recipe parsing is currently single threaded. I want to make this multithreaded as the speedup would be nice. If I can only take a single task for myself for 1.0, I'm nominating this one as I enjoy this kind of thing and I have ideas on how to do it. || 1|| Done || Richard|| rpurdie|| Enhancement<br />
|-<br />
|| Distribution / components|| Lock in Kernel/Toolchain version|| Locked in 2.6.37 and gcc 4.5.1. Pending decision to move to 4.5.2 and Linaro || || Done || || Richard|| || <br />
|-<br />
|| Distribution / components|| License Update|| For each of the licences we support, I'd really like to have a licences directory with a copy of that license contained within. When it comes to deciding what a given LICENSE field means, this would be the reference. It also means we can include the licences a given image includes with the image. This continues to make our license handling world class and ahead of the field. || 2|| Done || Beth|| rpurdie|| Hygiene<br />
|-<br />
|| Tool Development and SDK Features|| Qemu configuration change|| Provice edit box for advanced user to specify qemu configurations|| 2|| Done || Jessica|| criping|| <br />
|-<br />
|| Tool Development and SDK Features|| Lock down Eclipse+CDT+TCF version|| Will use Eclipse Halo 3.6 || 1|| Done || Jessica|| || <br />
|-<br />
|| Demo|| Finalize on demo plans for v1.0 launch || || 1|| Done || Dave || || <br />
|-<br />
|| Release || Release plans for v1.0 launch || Fill out the M4 plan with the necessary release activities and timings || 1|| Done || Beth || || <br />
|-<br />
|| Poky Features || Basic image creator GUI || Functional UI missing some Advanced features || 1 || In replan || Joshua || || <br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer for SDK Generator Installation functions support||Detailed feature request can be found at: http://bugzilla.pokylinux.org/show_bug.cgi?id=589|| 1|| Done || Jessica|| rpurdie|| Enhancement<br />
|-<br />
|| Kernel || Tracing: trace-cmd python binding cleanup || || 3 || Done || Darren || dvhart ||<br />
|}<br />
<br />
=== Sprint C (closes Jan 14, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || kernel development layer|| The (correct) poky behaviour of building known revisions coupled with the fetcher requiring a BSP branch to already be present means that local modifications (and kernel source tree) are required for kernel development. I already have a layer that overrides/modifies the behaviour when added to the bblayers.conf and configured into an environment. This seems useful for more people to use. || 2|| Done || Bruce|| bruceashfield|| Enhancement, was M2, Sprint C<br />
|-<br />
|| Distribution / components|| Zypper/RPM|| RPM Up-rev / Zypper Up-rev [lets get to the latest versions]|| 1|| Feb 4 || Mark/Qing|| || was M2, Sprint C<br />
|-<br />
|| Supported Targets|| Intel Platform Support|| JasperForest|| 2|| Basic support in place; DPDK evaluation in process, overall BSP plan still TBD || Tom|| davest|| Basic ECG support (Moved from Sprint A)<br />
|-<br />
|| Tool Development and SDK Features|| Eclipse poky tree interfacing (git support)|| Use Eclipse git capability to install poky tree from git repo and able to interact with git repo at file level within Poky tree || 2|| Done || Jessica|| jzhang|| Enhancement<br />
<br />
|-<br />
|| Poky Features || Poky Image Creator|| A standalone application you can run which asks you to select a distro and machine, then presents a list of packages you can select. Once the selection is made, it goes off and bakes you an image which is then presented to you. Implementation wise, it should use the sstate packages, be a bitbake UI and use the usual poky bbclass files to do the image construction behind the scenes. || 1|| Re-plan || Joshua|| rpurdie|| Enhancement<br />
|-<br />
|| Distribution / components|| LSB Sanity|| execute LSB Test and improve passing rate and document failures with clear understanding|| 2|| Done || MarkH/Saul|| sgw|| Hygiene<br />
|-<br />
|| Tool Development and SDK Features|| Image creator integration with Eclipse || || 2|| replan|| Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Kernel || Tracing: perf trace marker support || This is from feedback to the new trace command. Ingo appears to have this nearly complete already. || 3 || Done || Darren || dvhart ||<br />
|-<br />
|| Cleanup || bitbake user experience error handling validation completed || || 2 || Done || Richard || ||<br />
|-<br />
|| Cleanup || variable scrub - ensure all metadata variables are documented || Script with a histogram of variable use done, identified 50 variables to document; Add task for actual documentation update is low on the list || 2 || Done || Scott/Darren || ||<br />
|-<br />
|| Kernel || Tracing: package kernelshark || || 3 || Done || Darren || dvhart ||<br />
|}<br />
<br />
=== Sprint D (closes Jan 21, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Swabber || Complete review of swabber outputs || Move to M3 Sprint D || 1 || Move to M3 Sprint D || Alex || ||<br />
|-<br />
|| Poky Features || Fetcher Overhaul Phase 2 - API reorg||<br />
* f) Add a generic unpack funciton to __init__.py based on the unpack task in Poky ;<br />
* g) Split go() methods into the following steps: i) download() - do whatever transfer is necessary to get the sources locally ii) build_mirror_data() - generate any data that would be needed to construct a source mirror iii) unpack() - takes a directory as an argument of where to place extracted sources;<br />
The existing go() methods should be replaced with a set of calls to the above sections of functionality as appropriate in the individual fetchers. Some of these categories of function make no sense in certain fetchers, in which case they shouldn't need to implement them. Functions are only executed if the method is present.<br />
* h) Change Poky's unpack to call an unpack method in the fetchers.<br />
* i) Change Poky's fetch task to call a "download" method in the fetcher instead of go().<br />
|| 1|| Will land with phase 3 in Jan 21 || Saul / Ke, RP|| rpurdie|| Enhancement<br />
|-<br />
|| Poky Features || Fetcher Overhaul Phase 3 - git enhancement||<br />
* j) Optimize git fetcher for the new layout so for a git checkout, we clone the repository in download(), then unpack just does a clone with references to the original repo. <br />
* k) Ensure that we only set __BB_DONT_CACHE when SRCREV = "AUTOREV". This may need a new method call for fetchers to tell whether they're "floating" or locked down. <br />
* l) Add a new "BB_NO_NETWORK" variable which the fetchers check before peforming an operation which hits anything remote. This means adding in error messages about why network access is needed at various points (e.g. SRCREV = "AUTOREV" for a given recipe) <br />
* m) Add multiple branch/srcrev support for git fetcher. These would be of the form: git://somelocation/somerepo.git;name=ref1;branch=foo;name=ref2;branch=bar SRCREV_ref1 = "hash1" SRCREV_ref2 = "hash2" which would ensure both hash1 and hash2 were in the final repo. <br />
* n) Change git fetcher to default to git protocol instead of rsync<br />
|| 1|| Slipped to Sprint D || Saul / Ke, RP|| rpurdie|| Enhancement<br />
|-<br />
|| Poky Features || DSO linking changes|| "By the default the gcc linker will automatically link any dependant objects/libraries. ""Inherited"" linkages can cause issues, for example, where a shared object changes its dependencies but a program has come to rely on symbols from an implicitly linked library. Fedora implemented this change in F13, seems like it would be useful to have in Poky too. "|| 2|| On track for Jan 21 || Saul / Nitin || josh|| bug#516<br />
|-<br />
|| Distribution / components|| Distro Audit Documentation Output|| Audit package documentation output || 2|| Move to Sprint D due to libtool work || Saul / ScottG || rpurdie|| Hygiene<br />
|-<br />
|| Distribution / components|| Review & Fix Standards Tests|| Review the results from LTP, POSIX and asses the result, fix as appropriate and clearly document failures.|| 2|| a Plan to resolve final items to be sent to the m.l. by Jan 14 || Saul/Kevin || sgw|| Hygiene<br />
|-<br />
|| Poky Features || libtool sysroot option|| libtool 2.4 has a sysroot option. We should try and use it, see how it works and whether we can ditch some of our libtool hacks. || 1|| On track for Jan 21 || Saul / ScottG || rpurdie|| Enhancement<br />
|-<br />
|| Distribution / components|| MACHINE or Recipe specific sysroots|| Each machine should have its own sysroot. We'll probably have to split do_populate_sysroot into a two step process, creation of the package and than installtion of the package, which the installation of the package being made machine specific (put ${MACHINE} into ${STAMP} and bitbake should do that). Also allowing this to work per recipe would be desireable|| 1|| On track 21 || Saul / Dongxiao || rpurdie|| Hygiene<br />
|-<br />
|| Distribution / components|| Toolchain Bootstrap Process|| The toolchain as it bootstraps overwrites files like libc.so and libgcc.so in the sysroot directory which causes issues if you just try and rebuild part of the toolchain. Each step of the bootstrap process should use a separate sysroot. Once this is once, sstate file overwriting detection can be added and enabled. || 1|| Patches submitted for comment, slip to Sprint D || Saul / Dexuan || rpurdie|| Hygiene<br />
|-<br />
|| Documentation Features|| Package report system|| move to public server [setup a package report system in an internal machine. We need push it publicly available. The basic features like search and report have been there. But there're still some enhancements in plan, to make it a fit place to feel Yocto metadata comfortably]|| 2|| Move to Sprint E|| KevinT|| ktian1|| enhancement<br />
|-<br />
|| Distribution / components||Add headers and libraries to qemu images ||Since we'll be using qemu images as target sysroot, need to create a set of qemu images for minimal, sato, LSB that contains target header and libraries.|| 2|| Pending a discussion on Jan 18 || Saul ||jzhang|| Enhancement<br />
|-<br />
|| Distribution / components|| push of all relevant Wind River patchs to Yocto (patch comparison)|| Update any additional patches needed since M2.|| 1|| May be done by Jan 21, pending RPM stuff || Mark|| Mark|| <br />
|-<br />
|| Distribution / components|| mklibs|| mklibs is a tool to optimize size of [e]glibc for a perticular root file system image. It is useful to save disk space on small devices. || 2|| Push to Sprint E || Saul|| Nitin Kamble|| enhancement<br />
|-<br />
|| Poky Features || Performance Enhancement || reduce disk space (hardlink) || 1 || On track for Jan 21, pending RP review || Saul / Qing, Dongxiao || rpurdie || Enhancement<br />
|-<br />
|| Kernel || Tracing: perf trace scripting support || || 3 || Move to Sprint D; on track for Jan 21 || Tom || dvhart ||<br />
|-<br />
|| Kernel || Tracing: tuna, oscillosope recipes || || 3 || Tom to discuss plan with Darren et al || Tom || dvhart ||<br />
|- <br />
|| BSP || Beagleboard XM Support || || 3 || Move to Sprint D || Darren || dvhart ||<br />
|-<br />
|| BSP || 2.6.37 Crown Bay Support || On Track for Jan 21 || 2 || || Tom || dvhart || <br />
|-<br />
|| BSP || 2.6.37 Emenlow Support || On track for Jan 21 || 2 || || Tom || dvhart || <br />
|}<br />
<br />
=== Sprint E (closes Jan 28, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| rootless X|| rootless x server has better security than x server launched by root. MeeGo already enable this feature. it would be nice for Yocto to also enable it. || 2|| On track for Jan 28 || Saul / Ke || yuke|| enhancement<br />
|-<br />
|| Documentation Features|| Package report system|| finish major feature development and internal review [setup a package report system in an internal machine. We need push it publicly available. The basic features like search and report have been there. But there're still some enhancements in plan, to make it a fit place to feel Yocto metadata comfortably]|| 2|| Move to Sprint E || Jonathan || ktian1|| enhancement, was M2, Sprint E<br />
|-<br />
|| Distribution / components|| perl upgrade|| perl is the most cross un-friendly recipe pending upgrade. || 2|| Slipping due to Linaro layer, moves to end of Sprint E || Nitin|| Nitin Kamble|| enhancement<br />
|-<br />
|| Supported Targets|| Intel Platform Support|| Sandybridge|| 2|| Accept|| Tom|| davest|| Basic ECG support<br />
|-<br />
|| Distribution / components|| performance indicators|| define some indicators (boot time, footprint, build time, power, component benchmarks, etc.) and then collect them for tracking purpose. The result could be posted on the wiki site, and the initial indicators can be easy ones which can be easily retrieved from autobuilder or weekly qa report). This way we have a clear track about the healthy of the Yocto project, and also identify weak areas. We can include qemu targets and several representational boards as the targets. || 2|| Review|| Beth/Jiajun|| ktian1|| enhancement<br />
|-<br />
|| Tool Development and SDK Features|| SDK user workshop|| Have some developers sit down and use our tools to develop demo software for Yocto. || 2|| Review|| Jessica|| josh|| Enhancement<br />
|-<br />
|| Distribution / components|| Zypper/RPM|| Integration based on design from Sprint B|| 1|| On track for Jan28 || Mark/Qing|| sgw|| Functionality, was M2, Sprint E<br />
|-<br />
|| Kernel || Final linux-yocto_git.bb || With 2.6.37 kernel || 1 || || Bruce || dvhart ||<br />
|-<br />
|| Kernel || Final meta-linaro layer || || || || Darren || dvhart ||<br />
|-<br />
|| Kernel || Final meta-rt layer || || || || Darren || dvhart ||<br />
|-<br />
|| Kernel || Sandy Bridge || || 1 || || Tom || dvhart ||<br />
|}<br />
<br />
=== Sprint F (closes Feb 03 (THURSDAY), 11:59pm PDT -- pull request sent, initially reviewed) :: NOTE: China New Year Holiday ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Documentation|| ADT Reference Guide Draft out for review || Outline complete|| High|| WIP || Scott Rifenbark|| jzhang|| Documentation<br />
|-<br />
|| || || || || || || || <br />
|}<br />
<br />
== M4 (Feb 07 to Apr 15 -- Stabilize Complete Mar 18, Release Complete Apr 01, Contingency to Apr 15) ==<br />
<br />
This sprint is the [[Yocto Project v. 1.0 Release Cycle]].<br />
<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Documentation|| Migration chapter in the Poky Reference Manual|| This chapter would cover the four identified use-cases for migrating up to the most recent version of Yocto Project. Additionally, it would cover migration scenarios from other development systems. The chapter does not yet exist. The chapter has not been scoped outside of having a meeting that identified four use-cases that did not include migration from a development system outside of Yocto Project. It will take some more scoping time to cover those areas (a day or two). Again, I have no idea of the length. See earlier entries for standard industry writing estimates for software documentation|| Medium|| Not Started|| Scott Rifenbark|| 3-4 Weeks|| Documentation<br />
|-<br />
|| Documentation|| Yocto Project Development Guide|| This manual would be an over-arching document that frames the complete development cycle within Yocto Project. The idea here is that the document would be an umbrella document that spawned and referenced subsequent documents. The organization would be the first chapter overviewing the major development pieces such as recipe creation, building, debugging, publishing, fail-safing, back-door hook creation, etc. Scoping would be about two weeks and length would probably be about 40 pages. Overall development time would likely be a month of uniterruped time.|| Medium|| Not Started|| Scott Rifenbark|| 3 Weeks|| Documentation<br />
|-<br />
|| Validation|| Boottime/Performance Analysis|| Compare Yocto Project performance to other projects such as MeeGo|| 1|| Initial report on where we are by Feb 9 || Darren|| davest|| project commitment<br />
|-<br />
|| || Multilib Support|| Consider developing post-1.0 branch || 1|| to start in M4 || Richard|| ||<br />
|-<br />
|| Validation|| Alpha testing complete|| 4-5 internal developers unfamiliar with Yocto Project try to do a build and report on the experience and issues encountered|| 1|| Done by Feb 18 || Julie|| davest|| <br />
|-<br />
|| || || || || || || || <br />
|}<br />
<br />
== Features needed and to be put into sprints by assigned owners: ==<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || package config option enhancement|| there're several enhancements we may do here: * allow users setting specific config options (local or global) from external tool, such as poky image creator, instead of changing recipes manually. Need a mechanism to convert from variable assignments into exact config options (e.g. feature_${PN} = ""1"" -> ""--enable-feature""). Consequently dependency chain needs update with option status. * host contamination check. We have swabber to check host contamination, but I'm not sure whether it covers configuration phase. If not, this is one area to improve, as not ususually we see configure script checks host bits for available features * conditional option manipulation. In many recipes we enable/disable one option based on availability of other packages. Now this is done manually and not flexible. this should be made automatically though some new annotation to indicate condition, or just base_contains (not convenient: long line, need define distro features) || 2|| Review|| Richard/MarkH|| ktian1|| Enhancement<br />
|-<br />
|| Media|| Yocto Project Awareness Video|| This 2.5 minute video would introduce and describe the benefits of Yocto Project. The video would use entertaining animations that described concepts and benefits. The result would be suitable for YouTube, conferences, and the website. The production is called an "Epipheo" and will be created by Epipheo Studios. The engagement process has begun and the kick-off meeting will be soon. The PO is in place. Time for development is 10 weeks.|| High|| Kick-off Imminent|| Scott Rifenbark|| 10 Weeks|| Media<br />
|-<br />
|| Documentation|| Yocto Project Debugging Guide|| This would be a guide for the debugging and bug tracking process in Yocto Project. Originally, the thought was that we needed a Bugzilla User's Manual. However, since we don't own Bugzilla it doesn't make sense to produce documentation for it. Rather, we should document the process as it fits into the Yocto Project environment. Ideally, the manual would be a sub-manual that would be referenced and architected into the Yocto Project Development Guide. The manual has not been scoped and would take a week to scope. Again, I have no idea of the length. See the previous item for standard industry writing estimates for software documenation.|| Medium|| Not Started|| Scott Rifenbark|| 3-4 Weeks|| Documentation<br />
|-<br />
|| Website|| Yocto Project Website|| The 0.9 website is in place but needs updates. Items for consideration are the left-panel naviagation scheme, a contributions guidance page, color-scheming and theme (possibly).|| Medium|| Not Started|| Scott Rifenbark|| 1-2 Weeks|| Website<br />
|}<br />
<br />
== Features not believed to be needed in v1.0: ==<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || OpenEmbedded/Bitbake Upstreaming|| "We firstly need to review where we are and where OE is. We then need to make a plan about what we're going to push upstream and what we're not. I'd suggest when we're in PRC, we do a crash course in ""dealing with OE"" and then many dedicate a block of time (a week) where the distro team comes up with a patch set we then propose and get merged into OE. I'd like to find a couple of interested people to monitor OE more regularly and start a workflow of things between Poky/OE where appropriate. The key thing to remember is we need to keep the architectures compatible. The team is now at the point where I'm happy for them to actually try building OpenEmbedded and not worry about it tainting them! "|| 2|| Review|| || rpurdie|| Process<br />
|-<br />
|| Poky Features || Handle old versions in WORKDIR|| an incremental build directory may finally include many old versions WORKDIRS. It'll be good to have those old versions tracked in the cache, which can then either generate a report or allow selectively cleaning up an specific version WORKDIR. Or else it's difficult to figure it out when people want to keep the whole tmp directory but like to cleanup some old bits when disk usage is under pressure. If it's not easy to do in bitbake, perhaps some separate scripts would be also helpful || 3|| Review|| || ktian1|| Enhancement<br />
|-<br />
|| Poky Features || run bitbake w/o rebuilding the cache|| "sometimes it's useful to allow run bitbake w/o re-parsing recipes, if we know nothing metadata is changed. we can just allow reusing existing persistent cache. this is useful when people is debugging WORKDIR w/o metadata change. also sometimes ""bitbake -e"" is used frequently to check poky variable information. with existing cache, several seconds can be saved which are not negligible for a developer daily working on Yocto "|| 2|| Review|| || ktian1|| Enhancement<br />
|-<br />
|| Poky Features || parallel make improvement|| parallel make experience is not good, especially when bb threads and make threads are increased larger than 8. So far we either try to fix package makefile or mark the recipe as no parallel make, when build faiures are reported. But this greatly impacts user experience for a successfully continuous build process. Could we define a safe number we do want to support for 1.0 release? and then have our autobuilder, QA test, and developers cover that number immediately and fix any issues accordingly. Then the safe number can be suggested to the Yocto user || 2|| Review|| || ktian1|| Enhancement<br />
|-<br />
|| Poky Features || Dependency packages rebuild/clean|| It is a mechanism to rebulid or clean a package and all other packages which have build/runtime dependency on it. With this change, we can find potential influences of package upgrade to its related packages, which can make the incremental build more trustable. For example, if we upgrade a package to a new vesion which changes its API, this mechanism can easily find out the incompatibility to other packages which have dependency on it. || 2|| Review|| || dongxiao.xu|| Enhancement, replaced by checksum feature<br />
|-<br />
|| Distribution / components|| FOSSology|| This may be similar to License Update above, but start to use FOSSology to track licenses. || 2|| Review|| || sgw|| Hygiene<br />
|-<br />
|| Distribution / components|| Package Developer Tools|| Create a set of Init scripts template and then review our current init scripts and modify them to confirm to the template. || 2|| Review|| || sgw|| Easy of Use<br />
|-<br />
|| Distribution / components|| Package Website|| Complete the work the intern has started on generating the distro tracking information and get it out on the external site. || 2|| Review|| || sgw|| "Hygiene, duplicate of ""Package report system"""<br />
|-<br />
|| Distribution / components|| Bluetooth UI support|| Currently we have bluez package in poky, and we need to have a workable graphic user interface to connect/configure BT devices. One choice may be gnome-bluetooth-applet. || 3|| Review|| || dongxiao.xu|| enhancement<br />
|-<br />
|| Distribution / components|| Connman-gnome enhancement features|| Enable connman-gnome to support features like, WPA Enterprise connection, hidden SSID, etc. || 3|| Review|| || dongxiao.xu|| enhancement<br />
|-<br />
|| Distribution / components|| Java Running Environment support|| Since most embedded systems support java applications running in it, maybe we'd better consider supporting some kinds of JVMs(Embeded JVM). The JVM may not run by default, but user can launch it if running java applications. Compared with GTK/QT, java user number is not small too. || 3|| Review|| || criping|| enhancement<br />
|-<br />
|| Distribution / components|| create more use cases|| UPnP demo is one really good use case showing how Yocto is utilized to make real functionality. and we could create more to show how Yocto is easily adapted to real use cases. Those use cases can be either maintained as seperate demo layers in yocto repo, or in seperate branches for reference. We can also call for community's contribution on this which would make 1.0 full-fledged. Or else the newbies to Yocto may be in puzzle how our sample profiles can satisfy their requirements. || 2|| Review|| || ktian1|| enhancement<br />
|-<br />
|| Distribution / components|| i18n support || internationalization is an important system wide feature. Many component like font, locale affect the i18n. Yocto alreay has some i18n related package like pango, but so far did not consider i18n systematically. so this is place holder to systematically add i18n support. || 2|| Review|| || yuke/qing|| enhancement<br />
|-<br />
|| Distribution / components|| more demos || demos are a good way to educate, push the envelope, and at the same time tout the strengths of the platform. This item just records a current set of ideas from various sources which could/should be implemented: * face-recognition/face-finding, * robotic control/application of face-finding to 'camera-as-sensor' (hexbug demo), * others [tbd, add here]|| 2|| Review|| || tzanussi|| enhancement <br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer support for image-creator and needed yocto-metadata design||Come up design what need to be created as packages to support using "opkg install" for image-creator and needed yocto-metadata|| 2|| WIP, pending comments from RP regarding how to packaging metadata|| Jessica|| rpurdie|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer image-creator and needed poky-metadata support|| The poky build system will build packages for image-creator and needed poky-metadata, which the Yocto Installer will be able to use "opkg install" to install them|| 2|| Review|| Jessica|| rpurdie|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Provide qemu management UI|| In current eclipse plugin, QEMU settings are put together with project configuration. So we can only have limited settings. If we can have a separate QEMU management UI, the end user could firstly create a QEMU config, such as (env file of arch, image location, unfs or not, sato or lsb, mem size, disk size). And then he can launch a QEMU with a specific config. The dependency between project configuration and QEMU config will be resolved. After all QEMU has nothing to do project configuration. Need to careful review the UI to ensure minimal impact to testing matrix. || 3|| Review|| || criping|| "Enhancement, duplicate of ""Qemu mem/disk size can be adjusted"""<br />
|-<br />
|| Tool Development and SDK Features|| QT plugin For Eclipse|| Integrate QT Ecplise plugin and extend for Yocto Project || 3|| Review|| || jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Profiling/Trace GUI's|| We have a wealth of great tracing and profiling tools but the UI's for them are all extremely minimal and usually quite ugly. Would be great if we could compete with, or even better, Apple's offerings here. We have the technology! || 2|| Review|| || josh|| "Enhancement, duplicate of ""Tracing/Profiling Planning Complete"""<br />
|-<br />
|| Tool Development and SDK Features|| Other profiling tools|| Complete Tom's review of profiling tools and architecture || 2|| Review|| || josh|| "Enhancement, duplicate of ""Tracing/Profiling Planning Complete"""<br />
|-<br />
|| Tool Development and SDK Features|| Design next-gen tracing/profiling tools|| Yocto 1.0 will include all the essential existing tracing/profiling tools expected by users, and Josh has proposed a UI integration of all those tools as far as it's possible to do so. That level of integration, basically a 'plugin-level' integration is necessary and useful, but doesn't go far enough. A next-generation tracing tool would integrate at a much more fundamental level; if done properly, it would provide unmatched levels of power and usability to users, and would allow Yocto to distinguish itself in the embedded tracing/profiling space in a way also unmatched by any other distro/build-tool. The implementation would of course not be available for Yocto 1.0, but a coherent design, including prototypes, that could be taken to the community and implemented in a V 1.5 or 2.0 should be done in that time frame. || 1|| Review|| || tzanussi|| "Enhancement, duplicate of ""Tracing/Profiling Planning Complete"""<br />
|-<br />
|| Documentation Features|| Self Documentation of image contents|| "I'd like to see the -doc packages Poky builds being combined into some kind of large documentation index representing the collective API docs of the target being built. This can then be placed on a webserver and viewed over the web. We'd have a demonstration of this for a ""bitbake world"" target. Part of the idea here is to start making good use of the docs as if developers see this they might start writing better docs too. Aim is to lead the field :). There are a number of places poky packages disable doc generation due to missing tools so we'd need to add these so we can enable the doc generation. Many packages already have many docs though too. "|| 2|| Review|| || rpurdie|| enhancement<br />
|-<br />
|| Validation|| Testing Framework|| Add a framework for doing automated testing in the project|| 1|| Review|| || davest|| project commitment<br />
|-<br />
|| Validation|| more SDK builds on autobuilder|| enable more SDK related tests on autobuilder such as meta-ide-support, etc.|| 2|| Review|| || ktian1|| project commitment, addressed by test plan (?)<br />
|-<br />
|| Validation|| more people should try using SDK|| this may not be a feature, but a requirement. SDK including meta-toolchain is one key factor impacting user experience on Yocto. It's not enough to have only SDK team play with it|| 2|| Review|| || ktian1|| project commitment, addressed by test plan (?)<br />
|-<br />
|| Validation|| Unit Testing Framework|| Add a mechanism to bitbake to parse source packages that have unit tests and then execute them on the target|| 3|| Review|| || sgw|| "project commitment, duplicate of ""Testing Framework"""<br />
|-<br />
|| Validation|| Test Case open source|| Open source Yocto test cases with xml format|| 1|| Review|| || yyou|| "project commitment, duplicate of ""Testing Framework"""<br />
|}</div>Davesthttps://wiki.yoctoproject.org/wiki/index.php?title=Yocto_1.0_Schedule&diff=597Yocto 1.0 Schedule2011-01-25T16:07:44Z<p>Davest: /* Sprint A (closes Dec 24, 11:59pm PDT -- pull request sent, initially reviewed) */</p>
<hr />
<div>= v1.0 (release date: Apr 15, 2011) =<br />
----<br />
The detailed milestone map for v1.0 is as below. During the first week of each subsequent milestone past M1 we will have a demonstration of the previous milestone capabilities as well as a planning and design session for the current milestone.<br><br><br />
<br />
== M2 (Nov 08 to Dec 24 -- Dev Complete Dec 10, Stabilize Complete Dec 17, Release Complete Dec 24) ==<br />
=== Sprint A (closes Nov 12, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links''' <br />
|-<br />
|| Poky Features || Kernel interactive targets || To support incremental kernel development having the ability to run menuconfig (or xconfig, etc) directly is a common request. We'll need to add this for commercialization anyway. i.e. bitbake -c menuconfig. This fuctionality already exists. || 1 || Done || Richard || bruceashfield || Enhancement <br />
|-<br />
|| Distribution / components || Distro Audit: Upgrades Planned (Phase 1) || Complete plan for package upgrades in M2 || 1 || Done || Saul || || Continual Maintenance<br />
|-<br />
|| Validation || Runtime testing || Runtime testing of images as part of the autobuilder || 1 || Done || Jiajun/ScottG || rpurdie || project commitment<br />
|- <br />
|| || Poky Image Creator Wireframe/Interaction Plans Complete || || 1 || Done || Josh || ||<br />
|-<br />
|| || SDK Generator Interaction: Plans Complete || || 1 || Done || Jessica || ||<br />
|-<br />
|| || Tracing/Profiling Planning Complete || This needs to cover where we're at now, what we're missing and also propose the future enhancements that may be needed. M2 targets getting existing tools integrated and documented. F2f discussion n the future enhancements || || Done || Tom || ||<br />
|-<br />
|| || Swabber. (Still needs to be integrated into weekly build by default) || || 1 || Done || Josh || ||<br />
|-<br />
|| Build/Release || Release process documentation || || || Done || Beth || ||<br />
|-<br />
|| Validation || Test plan for v1.0 (to address any deficiencies in coverage from v0.9)|| || 1 || Done || Jiajun || ||<br />
|}<br />
<br />
=== Sprint B (closes Nov 19, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| Distro Audit: World Packages|| Audit world packages making sure it all build, making sure all are packages are required || 2|| Done || Saul|| sgw|| Hygiene<br />
|-<br />
|| Tool Development and SDK Features|| SDK Generator Installer UI|| Look at different ways of Installer UI (GTK+ and ncurses) seems none of them is the right choice, decide to go with script to implement all the functionalities of installer and later add UI part on top of it || 1||Done|| Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Customize sysroot setup || Add and test out "--sysroot" config option to cross compiler within Eclipse IDE || 1|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| SDK Generator Installer design revision|| Close all open questions regarding Yocto SDK Generator Installer function design and come up HLD || 1|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Distribution / components|| kernel version|| keeping 2.6.34 as a -stable kernel is the best option. I've also got a newer -devel tree that can be made available or made the default. || 3|| Done || Bruce|| bruceashfield|| enhancement<br />
|-<br />
|| || assign Yocto Project PM|| acquire and assign a program manager for Yocto Project|| || Done || DaveST|| || <br />
|-<br />
|| || assign Yocto Project Sys Admin|| || || Done || Saul|| || <br />
|-<br />
|| Tool Development and SDK Features|| oprofileUI|| Fixing various bugs of the oprofileUI to make it workable on big endian host.(i.e. ppc, mips) || 2 || Done || Jessica || lianhao.lu || Bug #382 / Bug #493<br />
|-<br />
|| Poky Feature|| SDK Version Control|| If we can expect that yocto SDK has lots of release in the future, we might need to consider SDK version control. Currently, every thing installed under /opt/poky which leads to things be overriden, we need to be able to use a scheme like /opt/poky-1.0, /opt/poky-2.0 to distiguish things. || 2|| Done || Josh|| jzhang|| Enhancement<br />
|-<br />
|| Kernel || Kernel plan complete || Flesh our kernel deliverables and add to Yocto 1.0 schedule || || Done|| Darren || dvhart ||<br />
|}<br />
<br />
=== Sprint C (closes Nov 26, 11:59pm PDT -- pull request sent, initially reviewed) :: NOTE: this is US Thanksgiving week ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| Distro Audit: Licence Checksums|| licence checksums || 1|| Done || Saul|| rpurdie|| Hygiene<br />
|-<br />
|| Poky Features || Performance Analysis Completed|| "I'd like someone to instrument a green release build, see where it spends time (hot/cold parsing time, individual task building time) and then compare this with our 0.9 release build. I'd also like to compare the disk usage between the two. Once we have a blame list we can then set about fixing it. Some things I know will come up: a) pseudo, b) checksums/signature code, c) exec() vs fork for executing tasks, d) task based prebuilds increasing disk usage, e) rpm dependency calculations, f) using rpm vs. ipk but I may be wrong and there may be others. We need numbers. "|| 1|| Done || Saul / Qing, Dongxiao|| rpurdie|| Enhancement<br />
|-<br />
|| Poky Features || environment variables for kernel builds|| switching a branch, or adding a configuration feature (and even changing the kernel repo) is often done during development of a BSP. Having some additional variables that are pass the bitbake environment scrub would be useful. i.e. KBRANCH=foo bitbake -c configure linux-yocto. This goes along with the other BSP bootstrapping suggestions. || 2|| Done || Bruce|| bruceashfield|| Enhancement<br />
|-<br />
|| Supported Targets|| ARM Platform Support|| Replace beagleboard with Beagleboard XM - decision || 2|| Done || Bruce|| alex|| Basic Yocto hardware support <br />
|-<br />
|| Distribution / components|| Security Process|| We need a dedicated person to scan and apply critical security updates to the distro. The MeeGo team already has a similar process with some scripts which may be leveraged. To complete the task, the process should be documented and a first pass over the metadata made to establish the current position on security. Any upgrades needed should be identified and a plan to address them should be in place but doesn't have to be implemented by this point.|| 1|| Done || ScottG|| ktian1|| enhancement<br />
|-<br />
|| Tool Development and SDK Features|| SDK Generator Installer Opkg repo design|| Come up a opkg repo design that will mimic the final Yocto package repo layout to be used by SDK Generator Installer to test against|| 2 || Done || Jessica || jzhang || <br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer tar creaion|| Create a Yocto Installer tar ball which contains Installer script and supported opkg component that will be used for installing other Yocto components|| 2 || Done || Jessica || jzhang || <br />
|-<br />
|| Documentation|| Kernel Framework Paper from WR|| The paper from WR needs to be re-written and then posted somewhere on the Yocto Project site. This will involve examiniation of the text and re-writing and formatting for presentation. Currently it is simply a text document. Completion time assuming uninterrupted time is one week.|| High|| Done || Scott Rifenbark|| 1 Week|| Documentation<br />
|-<br />
|| Documentation|| Poky Reference Manual|| This guide exists in the 0.9 form. The re-write of the text needs to be completed. So far, all the chapters have been rewritten but not re-posted on the site. Only the appendices remain for a text scrub. Time to complete this would be a week of uninterrupted time. Ideally, the manual would be a sub-manual that would be referenced and architected into the Yocto Project Development Guide.|| Medium|| Done|| Scott Rifenbark|| 1 Week|| Documentation<br />
|-<br />
|| Kernel || Initial meta-linaro layer || meta-linaro layer providing a kernel, tool-chain, and uboot loader. This deliverable is primarily to get the infrastructure in place and have a buildable kernel. Toolchain on best effort basis. || || Done || Darren || dvhart || Moderate risk of slippage due to holidays.<br />
|-<br />
|| Kernel || Tracing: blktrace and sysprof recipes || || || Done || Tom || dvhart ||<br />
|}<br />
<br />
=== Sprint D (closes Dec 3, 11:59pm PDT -- pull request sent, initially reviewed) :: NOTE: week of the F2F planning meeting ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Kernel || Kernel git branching structure revamped || || 1 || Done || Bruce || dvhart ||<br />
|-<br />
|| Kernel || Tunnel Creek (Crown Bay) || || 1 || Done || Tom || dvhart ||<br />
|}<br />
<br />
=== Sprint E (closes Dec 9 (THURSDAY), 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| Distro Audit: Upgrades Completed (Phase 1)|| Update to new versions as per the agreed plan for M2 from Sprint A|| 1|| Done || Saul|| rpurdie|| Continual Maintenance<br />
|-<br />
|| Distribution / components|| Distro Audit: Src Checksums|| Make sure all SRC_URI components have checksums too || 1|| Done || Saul|| rpurdie|| Hygiene<br />
|-<br />
|| Poky Features || enable KVM with qemu|| today all new Intel processors support VT, which are enabled on most desktop machines which are most frequently used build machine. with VT support, x86/x86-64 qemu target runs faster which is a good thing for emulation environment. This may require some qemu option tweaks and also poky-qemu script enhancement. || 2|| Done || Saul / Edwin|| ktian1|| Enhancement<br />
|-<br />
|| Kernel || New kernel recipes || dev, -devel, -custom || 3 || Done || Bruce || dvhart ||<br />
|-<br />
|| Swabber || Documentation for swabber || || 1 || Done || Alex || ||<br />
|-<br />
|| CCB || Defect triage process in public documented and implemented || || 1 || Done. Triage process is documented, out for review. || Saul || ||<br />
|}<br />
<br />
== M3 (Dec 20 to Feb 08 -- Dev Complete Feb 04, Stabilize Complete Feb 11, Release Complete Feb 18) ==<br />
=== Sprint A (closes Dec 24, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Kernel || Initial meta-rt layer || PREEMPT_RT kernel and related test-cases and benchmarks || 2 || Done || Darren || dvhart || slipped out from M2<br />
|-<br />
|| Poky Features || Fetcher Overhaul Phase 1 - SRC_REV enhancement||<br />
* a) Add code in FetchData::__init__() which will check if the selected fetcher supports srcrev and the automatically call a function to set the src rev value instead of each fetcher doing this.\n <br />
* e) Break SRCREVINACTION deadlock. To do this, we need to start using a keyword for automatically increasing SRCREV, e.g. SRCREV = "AUTOINC". The actual revision can be injected into PV using SRCPV. If we do this there should no longer be a need of the deadlock; <br />
* k) Ensure that we only set __BB_DONT_CACHE when SRCREV = "AUTOREV". This may need a new method call for fetchers to tell whether they're "floating" or locked down.<br />
|| 1|| Done || Saul / Ke, RP|| rpurdie|| Enhancement, slipped out from M2<br />
|-<br />
|| Distribution / components|| Distro Audit Upgrades Planned (Phase 2)|| Complete plan for package upgrades in M2|| 1|| Done || Saul|| || Continual Maintenance<br />
|-<br />
|| Poky Features || Pseudo Performance || Implement the changes to bitbake based on pseudo's enable/disable switch|| 1|| done || Saul / Qing, Dongxiao || rpurdie|| Enhancement, slipped from M2 due to risk and not having Pseudo's change yet.<br />
|-<br />
|| Tool Development and SDK Features|| Fix the issue user target sysroot is owned by root || The ADT installer will use pseudo to extract user target sysroot which ended up owned by root, this need to be fixed || 1|| done || Jessica|| jzhang|| Cleanup <br />
|-<br />
|| Tool Development and SDK Features|| Eclipse poky tree interfacing (metadata file editor)|| Provide a metadata file editor with some syntax checking and keywords highlight capabilities|| 2|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| IDE Project templates|| Templates for various project types: Clutter GUI, Gtk+ GUI, to help developers get started quickly || 2|| Done || Jessica|| josh|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| push TCF/RSE patches upstream|| work with community to finish up our TCF terminal service, TCF/RSE integration remaining patches taken by upstream. Blocking issues including Eclipse Bug #327865 || 1|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Pseudo || Pseudo enhancement to enable on/off switch || || 1 || done || Mark || ||<br />
|-<br />
|| Pseudo || Bitbake enhancement for pseudo on/off switch || || 1 || done || Richard || ||<br />
|-<br />
|| bugzilla || Complete restructure of bugzilla categories || || 1 || done || Saul || ||<br />
|-<br />
|| Poky Features || Image creator ground work || Nomenclature determined, existing gui's bug fixed and backend work implemented || 1 || Done || Joshua || ||<br />
|-<br />
|| Kernel || Tracing: Initial SystemTap recipe || Works on x86 || 3 || Done || Tom || dvhart ||<br />
|-<br />
|| Distribution / components|| Distro Audit: Package Description/Summary completed|| Ensure DESCRIPTION/SUMMARY fields are all audited|| 2|| Done || Mark|| Mark|| Hygiene, was M2, Sprint B but missed window<br />
|-<br />
|| Distribution / components|| Zypper/RPM|| Small write-up of the problems we're having w/ Zypper and what we plan to do. (i.e. create a roadmap/design) - Includes rootfs generation - Package uprev/install/removal || 1 || Done || Mark/Qing || || was M2, Sprint B<br />
|-<br />
|| Distribution / components|| Distro Audit: Licence Checksums|| Make the licence checksums fatal if not present || 1|| Done || Saul|| rpurdie|| Hygiene, was M2, Sprint C<br />
|-<br />
|| Distribution / components|| push of all relevant Wind River patchs to Yocto (patch comparison)|| Ensure patches present to packages in WRS are also in Poky|| 1|| Done || Mark|| Mark|| was M2, Sprint C<br />
|-<br />
|| Poky Features || Performance Enhancement Completed || Initial changes to reduce disk space (sstate-build-*) || 1|| Done || Saul / Qing, Dongxiao || rpurdie|| Enhancement, was M2, Sprint E<br />
|-<br />
|| Distribution / components|| User specified qemu config support|| We'll provide user an edit box which allows advanced qemu user to specify arbitrary qemu configuration to meet their needs, which the poky-qemu scrip will just append the config list towards the end of the list of parameters to bring up qemu, it also expect the poky-qemu script to do some basic sanity check on the user specifications to catch the obvious mistake || 2|| Done || Saul / criping || criping|| enhancement, was M2, Sprint E<br />
|-<br />
|| Tool Development and SDK Features|| SDK Version Control support in SDK generator installer|| If we can expect that yocto SDK has lots of release in the future, we might need to consider SDK version control. Currently, if we un-tar the sdk, it will override the older version. It's not good for app developers since they might need the old version to do something. And also, maybe a finer installer than untar is preferred. Installer will tied to certain SDK version and the installation will go under /opt/poky-versionNo.|| 1|| Done || Jessica|| criping|| Enhancement-expect planning process by Jessica to handle this task. Was M2, Sprint E.<br />
|}<br />
<br />
=== Sprint B (closes Jan 07, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || Bitbake multi-threaded parsing|| Bitbake recipe parsing is currently single threaded. I want to make this multithreaded as the speedup would be nice. If I can only take a single task for myself for 1.0, I'm nominating this one as I enjoy this kind of thing and I have ideas on how to do it. || 1|| Done || Richard|| rpurdie|| Enhancement<br />
|-<br />
|| Distribution / components|| Lock in Kernel/Toolchain version|| Locked in 2.6.37 and gcc 4.5.1. Pending decision to move to 4.5.2 and Linaro || || Done || || Richard|| || <br />
|-<br />
|| Distribution / components|| License Update|| For each of the licences we support, I'd really like to have a licences directory with a copy of that license contained within. When it comes to deciding what a given LICENSE field means, this would be the reference. It also means we can include the licences a given image includes with the image. This continues to make our license handling world class and ahead of the field. || 2|| Done || Beth|| rpurdie|| Hygiene<br />
|-<br />
|| Tool Development and SDK Features|| Qemu configuration change|| Provice edit box for advanced user to specify qemu configurations|| 2|| Done || Jessica|| criping|| <br />
|-<br />
|| Tool Development and SDK Features|| Lock down Eclipse+CDT+TCF version|| Will use Eclipse Halo 3.6 || 1|| Done || Jessica|| || <br />
|-<br />
|| Demo|| Finalize on demo plans for v1.0 launch || || 1|| Done || Dave || || <br />
|-<br />
|| Release || Release plans for v1.0 launch || Fill out the M4 plan with the necessary release activities and timings || 1|| Done || Beth || || <br />
|-<br />
|| Poky Features || Basic image creator GUI || Functional UI missing some Advanced features || 1 || In replan || Joshua || || <br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer for SDK Generator Installation functions support||Detailed feature request can be found at: http://bugzilla.pokylinux.org/show_bug.cgi?id=589|| 1|| Done || Jessica|| rpurdie|| Enhancement<br />
|-<br />
|| Kernel || Tracing: trace-cmd python binding cleanup || || 3 || Done || Darren || dvhart ||<br />
|}<br />
<br />
=== Sprint C (closes Jan 14, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || kernel development layer|| The (correct) poky behaviour of building known revisions coupled with the fetcher requiring a BSP branch to already be present means that local modifications (and kernel source tree) are required for kernel development. I already have a layer that overrides/modifies the behaviour when added to the bblayers.conf and configured into an environment. This seems useful for more people to use. || 2|| Done || Bruce|| bruceashfield|| Enhancement, was M2, Sprint C<br />
|-<br />
|| Distribution / components|| Zypper/RPM|| RPM Uprev / Zypper Uprev [lets get to the latest versions]|| 1|| pull request by Jan 19; || Mark/Qing|| || was M2, Sprint C<br />
|-<br />
|| Supported Targets|| Intel Platform Support|| JasperForest|| 2|| Basic support in place; DPDK evaluation in process, overall BSP plan still TBD || Tom|| davest|| Basic ECG support (Moved from Sprint A)<br />
|-<br />
|| Tool Development and SDK Features|| Eclipse poky tree interfacing (git support)|| Use Eclipse git capability to install poky tree from git repo and able to interact with git repo at file level within Poky tree || 2|| Done || Jessica|| jzhang|| Enhancement<br />
<br />
|-<br />
|| Poky Features || Poky Image Creator|| A standalone application you can run which asks you to select a distro and machine, then presents a list of packages you can select. Once the selection is made, it goes off and bakes you an image which is then presented to you. Implementation wise, it should use the sstate packages, be a bitbake UI and use the usual poky bbclass files to do the image construction behind the scenes. || 1|| Re-plan || Joshua|| rpurdie|| Enhancement<br />
|-<br />
|| Distribution / components|| LSB Sanity|| execute LSB Test and improve passing rate and document failures with clear understanding|| 2|| Done || MarkH/Saul|| sgw|| Hygiene<br />
|-<br />
|| Tool Development and SDK Features|| Image creator integration with Eclipse || || 2|| replan|| Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Kernel || Tracing: perf trace marker support || This is from feedback to the new trace command. Ingo appears to have this nearly complete already. || 3 || Done || Darren || dvhart ||<br />
|-<br />
|| Cleanup || bitbake user experience error handling validation completed || || 2 || Done || Richard || ||<br />
|-<br />
|| Cleanup || variable scrub - ensure all metadata variables are documented || Script with a histogram of variable use done, identified 50 variables to document; Add task for actual documentation update is low on the list || 2 || Done || Scott/Darren || ||<br />
|-<br />
|| Kernel || Tracing: package kernelshark || || 3 || Done || Darren || dvhart ||<br />
|}<br />
<br />
=== Sprint D (closes Jan 21, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Swabber || Complete review of swabber outputs || Move to M3 Sprint D || 1 || Move to M3 Sprint D || Alex || ||<br />
|-<br />
|| Poky Features || Fetcher Overhaul Phase 2 - API reorg||<br />
* f) Add a generic unpack funciton to __init__.py based on the unpack task in Poky ;<br />
* g) Split go() methods into the following steps: i) download() - do whatever transfer is necessary to get the sources locally ii) build_mirror_data() - generate any data that would be needed to construct a source mirror iii) unpack() - takes a directory as an argument of where to place extracted sources;<br />
The existing go() methods should be replaced with a set of calls to the above sections of functionality as appropriate in the individual fetchers. Some of these categories of function make no sense in certain fetchers, in which case they shouldn't need to implement them. Functions are only executed if the method is present.<br />
* h) Change Poky's unpack to call an unpack method in the fetchers.<br />
* i) Change Poky's fetch task to call a "download" method in the fetcher instead of go().<br />
|| 1|| Will land with phase 3 in Jan 21 || Saul / Ke, RP|| rpurdie|| Enhancement<br />
|-<br />
|| Poky Features || Fetcher Overhaul Phase 3 - git enhancement||<br />
* j) Optimize git fetcher for the new layout so for a git checkout, we clone the repository in download(), then unpack just does a clone with references to the original repo. <br />
* k) Ensure that we only set __BB_DONT_CACHE when SRCREV = "AUTOREV". This may need a new method call for fetchers to tell whether they're "floating" or locked down. <br />
* l) Add a new "BB_NO_NETWORK" variable which the fetchers check before peforming an operation which hits anything remote. This means adding in error messages about why network access is needed at various points (e.g. SRCREV = "AUTOREV" for a given recipe) <br />
* m) Add multiple branch/srcrev support for git fetcher. These would be of the form: git://somelocation/somerepo.git;name=ref1;branch=foo;name=ref2;branch=bar SRCREV_ref1 = "hash1" SRCREV_ref2 = "hash2" which would ensure both hash1 and hash2 were in the final repo. <br />
* n) Change git fetcher to default to git protocol instead of rsync<br />
|| 1|| Slipped to Sprint D || Saul / Ke, RP|| rpurdie|| Enhancement<br />
|-<br />
|| Poky Features || DSO linking changes|| "By the default the gcc linker will automatically link any dependant objects/libraries. ""Inherited"" linkages can cause issues, for example, where a shared object changes its dependencies but a program has come to rely on symbols from an implicitly linked library. Fedora implemented this change in F13, seems like it would be useful to have in Poky too. "|| 2|| On track for Jan 21 || Saul / Nitin || josh|| bug#516<br />
|-<br />
|| Distribution / components|| Distro Audit Documentation Output|| Audit package documentation output || 2|| Move to Sprint D due to libtool work || Saul / ScottG || rpurdie|| Hygiene<br />
|-<br />
|| Distribution / components|| Review & Fix Standards Tests|| Review the results from LTP, POSIX and asses the result, fix as appropriate and clearly document failures.|| 2|| a Plan to resolve final items to be sent to the m.l. by Jan 14 || Saul/Kevin || sgw|| Hygiene<br />
|-<br />
|| Poky Features || libtool sysroot option|| libtool 2.4 has a sysroot option. We should try and use it, see how it works and whether we can ditch some of our libtool hacks. || 1|| On track for Jan 21 || Saul / ScottG || rpurdie|| Enhancement<br />
|-<br />
|| Distribution / components|| MACHINE or Recipe specific sysroots|| Each machine should have its own sysroot. We'll probably have to split do_populate_sysroot into a two step process, creation of the package and than installtion of the package, which the installation of the package being made machine specific (put ${MACHINE} into ${STAMP} and bitbake should do that). Also allowing this to work per recipe would be desireable|| 1|| On track 21 || Saul / Dongxiao || rpurdie|| Hygiene<br />
|-<br />
|| Distribution / components|| Toolchain Bootstrap Process|| The toolchain as it bootstraps overwrites files like libc.so and libgcc.so in the sysroot directory which causes issues if you just try and rebuild part of the toolchain. Each step of the bootstrap process should use a separate sysroot. Once this is once, sstate file overwriting detection can be added and enabled. || 1|| Patches submitted for comment, slip to Sprint D || Saul / Dexuan || rpurdie|| Hygiene<br />
|-<br />
|| Documentation Features|| Package report system|| move to public server [setup a package report system in an internal machine. We need push it publicly available. The basic features like search and report have been there. But there're still some enhancements in plan, to make it a fit place to feel Yocto metadata comfortably]|| 2|| Move to Sprint E|| KevinT|| ktian1|| enhancement<br />
|-<br />
|| Distribution / components||Add headers and libraries to qemu images ||Since we'll be using qemu images as target sysroot, need to create a set of qemu images for minimal, sato, LSB that contains target header and libraries.|| 2|| Pending a discussion on Jan 18 || Saul ||jzhang|| Enhancement<br />
|-<br />
|| Distribution / components|| push of all relevant Wind River patchs to Yocto (patch comparison)|| Update any additional patches needed since M2.|| 1|| May be done by Jan 21, pending RPM stuff || Mark|| Mark|| <br />
|-<br />
|| Distribution / components|| mklibs|| mklibs is a tool to optimize size of [e]glibc for a perticular root file system image. It is useful to save disk space on small devices. || 2|| Push to Sprint E || Saul|| Nitin Kamble|| enhancement<br />
|-<br />
|| Poky Features || Performance Enhancement || reduce disk space (hardlink) || 1 || On track for Jan 21, pending RP review || Saul / Qing, Dongxiao || rpurdie || Enhancement<br />
|-<br />
|| Kernel || Tracing: perf trace scripting support || || 3 || Move to Sprint D; on track for Jan 21 || Tom || dvhart ||<br />
|-<br />
|| Kernel || Tracing: tuna, oscillosope recipes || || 3 || Tom to discuss plan with Darren et al || Tom || dvhart ||<br />
|- <br />
|| BSP || Beagleboard XM Support || || 3 || Move to Sprint D || Darren || dvhart ||<br />
|-<br />
|| BSP || 2.6.37 Crown Bay Support || On Track for Jan 21 || 2 || || Tom || dvhart || <br />
|-<br />
|| BSP || 2.6.37 Emenlow Support || On track for Jan 21 || 2 || || Tom || dvhart || <br />
|}<br />
<br />
=== Sprint E (closes Jan 28, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| rootless X|| rootless x server has better security than x server launched by root. MeeGo already enable this feature. it would be nice for Yocto to also enable it. || 2|| On track for Jan 28 || Saul / Ke || yuke|| enhancement<br />
|-<br />
|| Documentation Features|| Package report system|| finish major feature development and internal review [setup a package report system in an internal machine. We need push it publicly available. The basic features like search and report have been there. But there're still some enhancements in plan, to make it a fit place to feel Yocto metadata comfortably]|| 2|| Move to Sprint E || Jonathan || ktian1|| enhancement, was M2, Sprint E<br />
|-<br />
|| Distribution / components|| perl upgrade|| perl is the most cross un-friendly recipe pending upgrade. || 2|| Slipping due to Linaro layer, moves to end of Sprint E || Nitin|| Nitin Kamble|| enhancement<br />
|-<br />
|| Supported Targets|| Intel Platform Support|| Sandybridge|| 2|| Accept|| Tom|| davest|| Basic ECG support<br />
|-<br />
|| Distribution / components|| performance indicators|| define some indicators (boot time, footprint, build time, power, component benchmarks, etc.) and then collect them for tracking purpose. The result could be posted on the wiki site, and the initial indicators can be easy ones which can be easily retrieved from autobuilder or weekly qa report). This way we have a clear track about the healthy of the Yocto project, and also identify weak areas. We can include qemu targets and several representational boards as the targets. || 2|| Review|| Beth/Jiajun|| ktian1|| enhancement<br />
|-<br />
|| Tool Development and SDK Features|| SDK user workshop|| Have some developers sit down and use our tools to develop demo software for Yocto. || 2|| Review|| Jessica|| josh|| Enhancement<br />
|-<br />
|| Distribution / components|| Zypper/RPM|| Integration based on design from Sprint B|| 1|| On track for Jan28 || Mark/Qing|| sgw|| Functionality, was M2, Sprint E<br />
|-<br />
|| Kernel || Final linux-yocto_git.bb || With 2.6.37 kernel || 1 || || Bruce || dvhart ||<br />
|-<br />
|| Kernel || Final meta-linaro layer || || || || Darren || dvhart ||<br />
|-<br />
|| Kernel || Final meta-rt layer || || || || Darren || dvhart ||<br />
|-<br />
|| Kernel || Sandy Bridge || || 1 || || Tom || dvhart ||<br />
|}<br />
<br />
=== Sprint F (closes Feb 03 (THURSDAY), 11:59pm PDT -- pull request sent, initially reviewed) :: NOTE: China New Year Holiday ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Documentation|| ADT Reference Guide Draft out for review || Outline complete|| High|| WIP || Scott Rifenbark|| jzhang|| Documentation<br />
|-<br />
|| || || || || || || || <br />
|}<br />
<br />
== M4 (Feb 07 to Apr 15 -- Stabilize Complete Mar 18, Release Complete Apr 01, Contingency to Apr 15) ==<br />
<br />
This sprint is the [[Yocto Project v. 1.0 Release Cycle]].<br />
<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Documentation|| Migration chapter in the Poky Reference Manual|| This chapter would cover the four identified use-cases for migrating up to the most recent version of Yocto Project. Additionally, it would cover migration scenarios from other development systems. The chapter does not yet exist. The chapter has not been scoped outside of having a meeting that identified four use-cases that did not include migration from a development system outside of Yocto Project. It will take some more scoping time to cover those areas (a day or two). Again, I have no idea of the length. See earlier entries for standard industry writing estimates for software documentation|| Medium|| Not Started|| Scott Rifenbark|| 3-4 Weeks|| Documentation<br />
|-<br />
|| Documentation|| Yocto Project Development Guide|| This manual would be an over-arching document that frames the complete development cycle within Yocto Project. The idea here is that the document would be an umbrella document that spawned and referenced subsequent documents. The organization would be the first chapter overviewing the major development pieces such as recipe creation, building, debugging, publishing, fail-safing, back-door hook creation, etc. Scoping would be about two weeks and length would probably be about 40 pages. Overall development time would likely be a month of uniterruped time.|| Medium|| Not Started|| Scott Rifenbark|| 3 Weeks|| Documentation<br />
|-<br />
|| Validation|| Boottime/Performance Analysis|| Compare Yocto Project performance to other projects such as MeeGo|| 1|| Initial report on where we are by Feb 9 || Darren|| davest|| project commitment<br />
|-<br />
|| || Multilib Support|| Consider developing post-1.0 branch || 1|| to start in M4 || Richard|| ||<br />
|-<br />
|| Validation|| Alpha testing complete|| 4-5 internal developers unfamiliar with Yocto Project try to do a build and report on the experience and issues encountered|| 1|| Done by Feb 18 || Julie|| davest|| <br />
|-<br />
|| || || || || || || || <br />
|}<br />
<br />
== Features needed and to be put into sprints by assigned owners: ==<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || package config option enhancement|| there're several enhancements we may do here: * allow users setting specific config options (local or global) from external tool, such as poky image creator, instead of changing recipes manually. Need a mechanism to convert from variable assignments into exact config options (e.g. feature_${PN} = ""1"" -> ""--enable-feature""). Consequently dependency chain needs update with option status. * host contamination check. We have swabber to check host contamination, but I'm not sure whether it covers configuration phase. If not, this is one area to improve, as not ususually we see configure script checks host bits for available features * conditional option manipulation. In many recipes we enable/disable one option based on availability of other packages. Now this is done manually and not flexible. this should be made automatically though some new annotation to indicate condition, or just base_contains (not convenient: long line, need define distro features) || 2|| Review|| Richard/MarkH|| ktian1|| Enhancement<br />
|-<br />
|| Media|| Yocto Project Awareness Video|| This 2.5 minute video would introduce and describe the benefits of Yocto Project. The video would use entertaining animations that described concepts and benefits. The result would be suitable for YouTube, conferences, and the website. The production is called an "Epipheo" and will be created by Epipheo Studios. The engagement process has begun and the kick-off meeting will be soon. The PO is in place. Time for development is 10 weeks.|| High|| Kick-off Imminent|| Scott Rifenbark|| 10 Weeks|| Media<br />
|-<br />
|| Documentation|| Yocto Project Debugging Guide|| This would be a guide for the debugging and bug tracking process in Yocto Project. Originally, the thought was that we needed a Bugzilla User's Manual. However, since we don't own Bugzilla it doesn't make sense to produce documentation for it. Rather, we should document the process as it fits into the Yocto Project environment. Ideally, the manual would be a sub-manual that would be referenced and architected into the Yocto Project Development Guide. The manual has not been scoped and would take a week to scope. Again, I have no idea of the length. See the previous item for standard industry writing estimates for software documenation.|| Medium|| Not Started|| Scott Rifenbark|| 3-4 Weeks|| Documentation<br />
|-<br />
|| Website|| Yocto Project Website|| The 0.9 website is in place but needs updates. Items for consideration are the left-panel naviagation scheme, a contributions guidance page, color-scheming and theme (possibly).|| Medium|| Not Started|| Scott Rifenbark|| 1-2 Weeks|| Website<br />
|}<br />
<br />
== Features not believed to be needed in v1.0: ==<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || OpenEmbedded/Bitbake Upstreaming|| "We firstly need to review where we are and where OE is. We then need to make a plan about what we're going to push upstream and what we're not. I'd suggest when we're in PRC, we do a crash course in ""dealing with OE"" and then many dedicate a block of time (a week) where the distro team comes up with a patch set we then propose and get merged into OE. I'd like to find a couple of interested people to monitor OE more regularly and start a workflow of things between Poky/OE where appropriate. The key thing to remember is we need to keep the architectures compatible. The team is now at the point where I'm happy for them to actually try building OpenEmbedded and not worry about it tainting them! "|| 2|| Review|| || rpurdie|| Process<br />
|-<br />
|| Poky Features || Handle old versions in WORKDIR|| an incremental build directory may finally include many old versions WORKDIRS. It'll be good to have those old versions tracked in the cache, which can then either generate a report or allow selectively cleaning up an specific version WORKDIR. Or else it's difficult to figure it out when people want to keep the whole tmp directory but like to cleanup some old bits when disk usage is under pressure. If it's not easy to do in bitbake, perhaps some separate scripts would be also helpful || 3|| Review|| || ktian1|| Enhancement<br />
|-<br />
|| Poky Features || run bitbake w/o rebuilding the cache|| "sometimes it's useful to allow run bitbake w/o re-parsing recipes, if we know nothing metadata is changed. we can just allow reusing existing persistent cache. this is useful when people is debugging WORKDIR w/o metadata change. also sometimes ""bitbake -e"" is used frequently to check poky variable information. with existing cache, several seconds can be saved which are not negligible for a developer daily working on Yocto "|| 2|| Review|| || ktian1|| Enhancement<br />
|-<br />
|| Poky Features || parallel make improvement|| parallel make experience is not good, especially when bb threads and make threads are increased larger than 8. So far we either try to fix package makefile or mark the recipe as no parallel make, when build faiures are reported. But this greatly impacts user experience for a successfully continuous build process. Could we define a safe number we do want to support for 1.0 release? and then have our autobuilder, QA test, and developers cover that number immediately and fix any issues accordingly. Then the safe number can be suggested to the Yocto user || 2|| Review|| || ktian1|| Enhancement<br />
|-<br />
|| Poky Features || Dependency packages rebuild/clean|| It is a mechanism to rebulid or clean a package and all other packages which have build/runtime dependency on it. With this change, we can find potential influences of package upgrade to its related packages, which can make the incremental build more trustable. For example, if we upgrade a package to a new vesion which changes its API, this mechanism can easily find out the incompatibility to other packages which have dependency on it. || 2|| Review|| || dongxiao.xu|| Enhancement, replaced by checksum feature<br />
|-<br />
|| Distribution / components|| FOSSology|| This may be similar to License Update above, but start to use FOSSology to track licenses. || 2|| Review|| || sgw|| Hygiene<br />
|-<br />
|| Distribution / components|| Package Developer Tools|| Create a set of Init scripts template and then review our current init scripts and modify them to confirm to the template. || 2|| Review|| || sgw|| Easy of Use<br />
|-<br />
|| Distribution / components|| Package Website|| Complete the work the intern has started on generating the distro tracking information and get it out on the external site. || 2|| Review|| || sgw|| "Hygiene, duplicate of ""Package report system"""<br />
|-<br />
|| Distribution / components|| Bluetooth UI support|| Currently we have bluez package in poky, and we need to have a workable graphic user interface to connect/configure BT devices. One choice may be gnome-bluetooth-applet. || 3|| Review|| || dongxiao.xu|| enhancement<br />
|-<br />
|| Distribution / components|| Connman-gnome enhancement features|| Enable connman-gnome to support features like, WPA Enterprise connection, hidden SSID, etc. || 3|| Review|| || dongxiao.xu|| enhancement<br />
|-<br />
|| Distribution / components|| Java Running Environment support|| Since most embedded systems support java applications running in it, maybe we'd better consider supporting some kinds of JVMs(Embeded JVM). The JVM may not run by default, but user can launch it if running java applications. Compared with GTK/QT, java user number is not small too. || 3|| Review|| || criping|| enhancement<br />
|-<br />
|| Distribution / components|| create more use cases|| UPnP demo is one really good use case showing how Yocto is utilized to make real functionality. and we could create more to show how Yocto is easily adapted to real use cases. Those use cases can be either maintained as seperate demo layers in yocto repo, or in seperate branches for reference. We can also call for community's contribution on this which would make 1.0 full-fledged. Or else the newbies to Yocto may be in puzzle how our sample profiles can satisfy their requirements. || 2|| Review|| || ktian1|| enhancement<br />
|-<br />
|| Distribution / components|| i18n support || internationalization is an important system wide feature. Many component like font, locale affect the i18n. Yocto alreay has some i18n related package like pango, but so far did not consider i18n systematically. so this is place holder to systematically add i18n support. || 2|| Review|| || yuke/qing|| enhancement<br />
|-<br />
|| Distribution / components|| more demos || demos are a good way to educate, push the envelope, and at the same time tout the strengths of the platform. This item just records a current set of ideas from various sources which could/should be implemented: * face-recognition/face-finding, * robotic control/application of face-finding to 'camera-as-sensor' (hexbug demo), * others [tbd, add here]|| 2|| Review|| || tzanussi|| enhancement <br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer support for image-creator and needed yocto-metadata design||Come up design what need to be created as packages to support using "opkg install" for image-creator and needed yocto-metadata|| 2|| WIP, pending comments from RP regarding how to packaging metadata|| Jessica|| rpurdie|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer image-creator and needed poky-metadata support|| The poky build system will build packages for image-creator and needed poky-metadata, which the Yocto Installer will be able to use "opkg install" to install them|| 2|| Review|| Jessica|| rpurdie|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Provide qemu management UI|| In current eclipse plugin, QEMU settings are put together with project configuration. So we can only have limited settings. If we can have a separate QEMU management UI, the end user could firstly create a QEMU config, such as (env file of arch, image location, unfs or not, sato or lsb, mem size, disk size). And then he can launch a QEMU with a specific config. The dependency between project configuration and QEMU config will be resolved. After all QEMU has nothing to do project configuration. Need to careful review the UI to ensure minimal impact to testing matrix. || 3|| Review|| || criping|| "Enhancement, duplicate of ""Qemu mem/disk size can be adjusted"""<br />
|-<br />
|| Tool Development and SDK Features|| QT plugin For Eclipse|| Integrate QT Ecplise plugin and extend for Yocto Project || 3|| Review|| || jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Profiling/Trace GUI's|| We have a wealth of great tracing and profiling tools but the UI's for them are all extremely minimal and usually quite ugly. Would be great if we could compete with, or even better, Apple's offerings here. We have the technology! || 2|| Review|| || josh|| "Enhancement, duplicate of ""Tracing/Profiling Planning Complete"""<br />
|-<br />
|| Tool Development and SDK Features|| Other profiling tools|| Complete Tom's review of profiling tools and architecture || 2|| Review|| || josh|| "Enhancement, duplicate of ""Tracing/Profiling Planning Complete"""<br />
|-<br />
|| Tool Development and SDK Features|| Design next-gen tracing/profiling tools|| Yocto 1.0 will include all the essential existing tracing/profiling tools expected by users, and Josh has proposed a UI integration of all those tools as far as it's possible to do so. That level of integration, basically a 'plugin-level' integration is necessary and useful, but doesn't go far enough. A next-generation tracing tool would integrate at a much more fundamental level; if done properly, it would provide unmatched levels of power and usability to users, and would allow Yocto to distinguish itself in the embedded tracing/profiling space in a way also unmatched by any other distro/build-tool. The implementation would of course not be available for Yocto 1.0, but a coherent design, including prototypes, that could be taken to the community and implemented in a V 1.5 or 2.0 should be done in that time frame. || 1|| Review|| || tzanussi|| "Enhancement, duplicate of ""Tracing/Profiling Planning Complete"""<br />
|-<br />
|| Documentation Features|| Self Documentation of image contents|| "I'd like to see the -doc packages Poky builds being combined into some kind of large documentation index representing the collective API docs of the target being built. This can then be placed on a webserver and viewed over the web. We'd have a demonstration of this for a ""bitbake world"" target. Part of the idea here is to start making good use of the docs as if developers see this they might start writing better docs too. Aim is to lead the field :). There are a number of places poky packages disable doc generation due to missing tools so we'd need to add these so we can enable the doc generation. Many packages already have many docs though too. "|| 2|| Review|| || rpurdie|| enhancement<br />
|-<br />
|| Validation|| Testing Framework|| Add a framework for doing automated testing in the project|| 1|| Review|| || davest|| project commitment<br />
|-<br />
|| Validation|| more SDK builds on autobuilder|| enable more SDK related tests on autobuilder such as meta-ide-support, etc.|| 2|| Review|| || ktian1|| project commitment, addressed by test plan (?)<br />
|-<br />
|| Validation|| more people should try using SDK|| this may not be a feature, but a requirement. SDK including meta-toolchain is one key factor impacting user experience on Yocto. It's not enough to have only SDK team play with it|| 2|| Review|| || ktian1|| project commitment, addressed by test plan (?)<br />
|-<br />
|| Validation|| Unit Testing Framework|| Add a mechanism to bitbake to parse source packages that have unit tests and then execute them on the target|| 3|| Review|| || sgw|| "project commitment, duplicate of ""Testing Framework"""<br />
|-<br />
|| Validation|| Test Case open source|| Open source Yocto test cases with xml format|| 1|| Review|| || yyou|| "project commitment, duplicate of ""Testing Framework"""<br />
|}</div>Davesthttps://wiki.yoctoproject.org/wiki/index.php?title=Yocto_1.0_Schedule&diff=596Yocto 1.0 Schedule2011-01-25T01:39:32Z<p>Davest: /* Sprint D (closes Jan 21, 11:59pm PDT -- pull request sent, initially reviewed) */</p>
<hr />
<div>= v1.0 (release date: Apr 15, 2011) =<br />
----<br />
The detailed milestone map for v1.0 is as below. During the first week of each subsequent milestone past M1 we will have a demonstration of the previous milestone capabilities as well as a planning and design session for the current milestone.<br><br><br />
<br />
== M2 (Nov 08 to Dec 24 -- Dev Complete Dec 10, Stabilize Complete Dec 17, Release Complete Dec 24) ==<br />
=== Sprint A (closes Nov 12, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links''' <br />
|-<br />
|| Poky Features || Kernel interactive targets || To support incremental kernel development having the ability to run menuconfig (or xconfig, etc) directly is a common request. We'll need to add this for commercialization anyway. i.e. bitbake -c menuconfig. This fuctionality already exists. || 1 || Done || Richard || bruceashfield || Enhancement <br />
|-<br />
|| Distribution / components || Distro Audit: Upgrades Planned (Phase 1) || Complete plan for package upgrades in M2 || 1 || Done || Saul || || Continual Maintenance<br />
|-<br />
|| Validation || Runtime testing || Runtime testing of images as part of the autobuilder || 1 || Done || Jiajun/ScottG || rpurdie || project commitment<br />
|- <br />
|| || Poky Image Creator Wireframe/Interaction Plans Complete || || 1 || Done || Josh || ||<br />
|-<br />
|| || SDK Generator Interaction: Plans Complete || || 1 || Done || Jessica || ||<br />
|-<br />
|| || Tracing/Profiling Planning Complete || This needs to cover where we're at now, what we're missing and also propose the future enhancements that may be needed. M2 targets getting existing tools integrated and documented. F2f discussion n the future enhancements || || Done || Tom || ||<br />
|-<br />
|| || Swabber. (Still needs to be integrated into weekly build by default) || || 1 || Done || Josh || ||<br />
|-<br />
|| Build/Release || Release process documentation || || || Done || Beth || ||<br />
|-<br />
|| Validation || Test plan for v1.0 (to address any deficiencies in coverage from v0.9)|| || 1 || Done || Jiajun || ||<br />
|}<br />
<br />
=== Sprint B (closes Nov 19, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| Distro Audit: World Packages|| Audit world packages making sure it all build, making sure all are packages are required || 2|| Done || Saul|| sgw|| Hygiene<br />
|-<br />
|| Tool Development and SDK Features|| SDK Generator Installer UI|| Look at different ways of Installer UI (GTK+ and ncurses) seems none of them is the right choice, decide to go with script to implement all the functionalities of installer and later add UI part on top of it || 1||Done|| Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Customize sysroot setup || Add and test out "--sysroot" config option to cross compiler within Eclipse IDE || 1|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| SDK Generator Installer design revision|| Close all open questions regarding Yocto SDK Generator Installer function design and come up HLD || 1|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Distribution / components|| kernel version|| keeping 2.6.34 as a -stable kernel is the best option. I've also got a newer -devel tree that can be made available or made the default. || 3|| Done || Bruce|| bruceashfield|| enhancement<br />
|-<br />
|| || assign Yocto Project PM|| acquire and assign a program manager for Yocto Project|| || Done || DaveST|| || <br />
|-<br />
|| || assign Yocto Project Sys Admin|| || || Done || Saul|| || <br />
|-<br />
|| Tool Development and SDK Features|| oprofileUI|| Fixing various bugs of the oprofileUI to make it workable on big endian host.(i.e. ppc, mips) || 2 || Done || Jessica || lianhao.lu || Bug #382 / Bug #493<br />
|-<br />
|| Poky Feature|| SDK Version Control|| If we can expect that yocto SDK has lots of release in the future, we might need to consider SDK version control. Currently, every thing installed under /opt/poky which leads to things be overriden, we need to be able to use a scheme like /opt/poky-1.0, /opt/poky-2.0 to distiguish things. || 2|| Done || Josh|| jzhang|| Enhancement<br />
|-<br />
|| Kernel || Kernel plan complete || Flesh our kernel deliverables and add to Yocto 1.0 schedule || || Done|| Darren || dvhart ||<br />
|}<br />
<br />
=== Sprint C (closes Nov 26, 11:59pm PDT -- pull request sent, initially reviewed) :: NOTE: this is US Thanksgiving week ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| Distro Audit: Licence Checksums|| licence checksums || 1|| Done || Saul|| rpurdie|| Hygiene<br />
|-<br />
|| Poky Features || Performance Analysis Completed|| "I'd like someone to instrument a green release build, see where it spends time (hot/cold parsing time, individual task building time) and then compare this with our 0.9 release build. I'd also like to compare the disk usage between the two. Once we have a blame list we can then set about fixing it. Some things I know will come up: a) pseudo, b) checksums/signature code, c) exec() vs fork for executing tasks, d) task based prebuilds increasing disk usage, e) rpm dependency calculations, f) using rpm vs. ipk but I may be wrong and there may be others. We need numbers. "|| 1|| Done || Saul / Qing, Dongxiao|| rpurdie|| Enhancement<br />
|-<br />
|| Poky Features || environment variables for kernel builds|| switching a branch, or adding a configuration feature (and even changing the kernel repo) is often done during development of a BSP. Having some additional variables that are pass the bitbake environment scrub would be useful. i.e. KBRANCH=foo bitbake -c configure linux-yocto. This goes along with the other BSP bootstrapping suggestions. || 2|| Done || Bruce|| bruceashfield|| Enhancement<br />
|-<br />
|| Supported Targets|| ARM Platform Support|| Replace beagleboard with Beagleboard XM - decision || 2|| Done || Bruce|| alex|| Basic Yocto hardware support <br />
|-<br />
|| Distribution / components|| Security Process|| We need a dedicated person to scan and apply critical security updates to the distro. The MeeGo team already has a similar process with some scripts which may be leveraged. To complete the task, the process should be documented and a first pass over the metadata made to establish the current position on security. Any upgrades needed should be identified and a plan to address them should be in place but doesn't have to be implemented by this point.|| 1|| Done || ScottG|| ktian1|| enhancement<br />
|-<br />
|| Tool Development and SDK Features|| SDK Generator Installer Opkg repo design|| Come up a opkg repo design that will mimic the final Yocto package repo layout to be used by SDK Generator Installer to test against|| 2 || Done || Jessica || jzhang || <br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer tar creaion|| Create a Yocto Installer tar ball which contains Installer script and supported opkg component that will be used for installing other Yocto components|| 2 || Done || Jessica || jzhang || <br />
|-<br />
|| Documentation|| Kernel Framework Paper from WR|| The paper from WR needs to be re-written and then posted somewhere on the Yocto Project site. This will involve examiniation of the text and re-writing and formatting for presentation. Currently it is simply a text document. Completion time assuming uninterrupted time is one week.|| High|| Done || Scott Rifenbark|| 1 Week|| Documentation<br />
|-<br />
|| Documentation|| Poky Reference Manual|| This guide exists in the 0.9 form. The re-write of the text needs to be completed. So far, all the chapters have been rewritten but not re-posted on the site. Only the appendices remain for a text scrub. Time to complete this would be a week of uninterrupted time. Ideally, the manual would be a sub-manual that would be referenced and architected into the Yocto Project Development Guide.|| Medium|| Done|| Scott Rifenbark|| 1 Week|| Documentation<br />
|-<br />
|| Kernel || Initial meta-linaro layer || meta-linaro layer providing a kernel, tool-chain, and uboot loader. This deliverable is primarily to get the infrastructure in place and have a buildable kernel. Toolchain on best effort basis. || || Done || Darren || dvhart || Moderate risk of slippage due to holidays.<br />
|-<br />
|| Kernel || Tracing: blktrace and sysprof recipes || || || Done || Tom || dvhart ||<br />
|}<br />
<br />
=== Sprint D (closes Dec 3, 11:59pm PDT -- pull request sent, initially reviewed) :: NOTE: week of the F2F planning meeting ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Kernel || Kernel git branching structure revamped || || 1 || Done || Bruce || dvhart ||<br />
|-<br />
|| Kernel || Tunnel Creek (Crown Bay) || || 1 || Done || Tom || dvhart ||<br />
|}<br />
<br />
=== Sprint E (closes Dec 9 (THURSDAY), 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| Distro Audit: Upgrades Completed (Phase 1)|| Update to new versions as per the agreed plan for M2 from Sprint A|| 1|| Done || Saul|| rpurdie|| Continual Maintenance<br />
|-<br />
|| Distribution / components|| Distro Audit: Src Checksums|| Make sure all SRC_URI components have checksums too || 1|| Done || Saul|| rpurdie|| Hygiene<br />
|-<br />
|| Poky Features || enable KVM with qemu|| today all new Intel processors support VT, which are enabled on most desktop machines which are most frequently used build machine. with VT support, x86/x86-64 qemu target runs faster which is a good thing for emulation environment. This may require some qemu option tweaks and also poky-qemu script enhancement. || 2|| Done || Saul / Edwin|| ktian1|| Enhancement<br />
|-<br />
|| Kernel || New kernel recipes || dev, -devel, -custom || 3 || Done || Bruce || dvhart ||<br />
|-<br />
|| Swabber || Documentation for swabber || || 1 || Done || Alex || ||<br />
|-<br />
|| CCB || Defect triage process in public documented and implemented || || 1 || Done. Triage process is documented, out for review. || Saul || ||<br />
|}<br />
<br />
== M3 (Dec 20 to Feb 08 -- Dev Complete Feb 04, Stabilize Complete Feb 11, Release Complete Feb 18) ==<br />
=== Sprint A (closes Dec 24, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Kernel || Initial meta-rt layer || PREEMPT_RT kernel and related test-cases and benchmarks || 2 || Done by Jan 21 || Darren || dvhart || slipped out from M2<br />
|-<br />
|| Poky Features || Fetcher Overhaul Phase 1 - SRC_REV enhancement||<br />
* a) Add code in FetchData::__init__() which will check if the selected fetcher supports srcrev and the automatically call a function to set the src rev value instead of each fetcher doing this.\n <br />
* e) Break SRCREVINACTION deadlock. To do this, we need to start using a keyword for automatically increasing SRCREV, e.g. SRCREV = "AUTOINC". The actual revision can be injected into PV using SRCPV. If we do this there should no longer be a need of the deadlock; <br />
* k) Ensure that we only set __BB_DONT_CACHE when SRCREV = "AUTOREV". This may need a new method call for fetchers to tell whether they're "floating" or locked down.<br />
|| 1|| Done || Saul / Ke, RP|| rpurdie|| Enhancement, slipped out from M2<br />
|-<br />
|| Distribution / components|| Distro Audit Upgrades Planned (Phase 2)|| Complete plan for package upgrades in M2|| 1|| Done || Saul|| || Continual Maintenance<br />
|-<br />
|| Poky Features || Pseudo Performance || Implement the changes to bitbake based on pseudo's enable/disable switch|| 1|| done || Saul / Qing, Dongxiao || rpurdie|| Enhancement, slipped from M2 due to risk and not having Pseudo's change yet.<br />
|-<br />
|| Tool Development and SDK Features|| Fix the issue user target sysroot is owned by root || The ADT installer will use pseudo to extract user target sysroot which ended up owned by root, this need to be fixed || 1|| done || Jessica|| jzhang|| Cleanup <br />
|-<br />
|| Tool Development and SDK Features|| Eclipse poky tree interfacing (metadata file editor)|| Provide a metadata file editor with some syntax checking and keywords highlight capabilities|| 2|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| IDE Project templates|| Templates for various project types: Clutter GUI, Gtk+ GUI, to help developers get started quickly || 2|| Done || Jessica|| josh|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| push TCF/RSE patches upstream|| work with community to finish up our TCF terminal service, TCF/RSE integration remaining patches taken by upstream. Blocking issues including Eclipse Bug #327865 || 1|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Pseudo || Pseudo enhancement to enable on/off switch || || 1 || done || Mark || ||<br />
|-<br />
|| Pseudo || Bitbake enhancement for pseudo on/off switch || || 1 || done || Richard || ||<br />
|-<br />
|| bugzilla || Complete restructure of bugzilla categories || || 1 || done || Saul || ||<br />
|-<br />
|| Poky Features || Image creator ground work || Nomenclature determined, existing gui's bug fixed and backend work implemented || 1 || Done || Joshua || ||<br />
|-<br />
|| Kernel || Tracing: Initial SystemTap recipe || Works on x86 || 3 || Done || Tom || dvhart ||<br />
|-<br />
|| Distribution / components|| Distro Audit: Package Description/Summary completed|| Ensure DESCRIPTION/SUMMARY fields are all audited|| 2|| Done || Mark|| Mark|| Hygiene, was M2, Sprint B but missed window<br />
|-<br />
|| Distribution / components|| Zypper/RPM|| Small write-up of the problems we're having w/ Zypper and what we plan to do. (i.e. create a roadmap/design) - Includes rootfs generation - Package uprev/install/removal || 1 || Done || Mark/Qing || || was M2, Sprint B<br />
|-<br />
|| Distribution / components|| Distro Audit: Licence Checksums|| Make the licence checksums fatal if not present || 1|| Done || Saul|| rpurdie|| Hygiene, was M2, Sprint C<br />
|-<br />
|| Distribution / components|| push of all relevant Wind River patchs to Yocto (patch comparison)|| Ensure patches present to packages in WRS are also in Poky|| 1|| Done || Mark|| Mark|| was M2, Sprint C<br />
|-<br />
|| Poky Features || Performance Enhancement Completed || Initial changes to reduce disk space (sstate-build-*) || 1|| Done || Saul / Qing, Dongxiao || rpurdie|| Enhancement, was M2, Sprint E<br />
|-<br />
|| Distribution / components|| User specified qemu config support|| We'll provide user an edit box which allows advanced qemu user to specify arbitrary qemu configuration to meet their needs, which the poky-qemu scrip will just append the config list towards the end of the list of parameters to bring up qemu, it also expect the poky-qemu script to do some basic sanity check on the user specifications to catch the obvious mistake || 2|| Done || Saul / criping || criping|| enhancement, was M2, Sprint E<br />
|-<br />
|| Tool Development and SDK Features|| SDK Version Control support in SDK generator installer|| If we can expect that yocto SDK has lots of release in the future, we might need to consider SDK version control. Currently, if we un-tar the sdk, it will override the older version. It's not good for app developers since they might need the old version to do something. And also, maybe a finer installer than untar is preferred. Installer will tied to certain SDK version and the installation will go under /opt/poky-versionNo.|| 1|| Done || Jessica|| criping|| Enhancement-expect planning process by Jessica to handle this task. Was M2, Sprint E.<br />
|}<br />
<br />
=== Sprint B (closes Jan 07, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || Bitbake multi-threaded parsing|| Bitbake recipe parsing is currently single threaded. I want to make this multithreaded as the speedup would be nice. If I can only take a single task for myself for 1.0, I'm nominating this one as I enjoy this kind of thing and I have ideas on how to do it. || 1|| Done || Richard|| rpurdie|| Enhancement<br />
|-<br />
|| Distribution / components|| Lock in Kernel/Toolchain version|| Locked in 2.6.37 and gcc 4.5.1. Pending decision to move to 4.5.2 and Linaro || || Done || || Richard|| || <br />
|-<br />
|| Distribution / components|| License Update|| For each of the licences we support, I'd really like to have a licences directory with a copy of that license contained within. When it comes to deciding what a given LICENSE field means, this would be the reference. It also means we can include the licences a given image includes with the image. This continues to make our license handling world class and ahead of the field. || 2|| Done || Beth|| rpurdie|| Hygiene<br />
|-<br />
|| Tool Development and SDK Features|| Qemu configuration change|| Provice edit box for advanced user to specify qemu configurations|| 2|| Done || Jessica|| criping|| <br />
|-<br />
|| Tool Development and SDK Features|| Lock down Eclipse+CDT+TCF version|| Will use Eclipse Halo 3.6 || 1|| Done || Jessica|| || <br />
|-<br />
|| Demo|| Finalize on demo plans for v1.0 launch || || 1|| Done || Dave || || <br />
|-<br />
|| Release || Release plans for v1.0 launch || Fill out the M4 plan with the necessary release activities and timings || 1|| Done || Beth || || <br />
|-<br />
|| Poky Features || Basic image creator GUI || Functional UI missing some Advanced features || 1 || In replan || Joshua || || <br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer for SDK Generator Installation functions support||Detailed feature request can be found at: http://bugzilla.pokylinux.org/show_bug.cgi?id=589|| 1|| Done || Jessica|| rpurdie|| Enhancement<br />
|-<br />
|| Kernel || Tracing: trace-cmd python binding cleanup || || 3 || Done || Darren || dvhart ||<br />
|}<br />
<br />
=== Sprint C (closes Jan 14, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || kernel development layer|| The (correct) poky behaviour of building known revisions coupled with the fetcher requiring a BSP branch to already be present means that local modifications (and kernel source tree) are required for kernel development. I already have a layer that overrides/modifies the behaviour when added to the bblayers.conf and configured into an environment. This seems useful for more people to use. || 2|| Done || Bruce|| bruceashfield|| Enhancement, was M2, Sprint C<br />
|-<br />
|| Distribution / components|| Zypper/RPM|| RPM Uprev / Zypper Uprev [lets get to the latest versions]|| 1|| pull request by Jan 19; || Mark/Qing|| || was M2, Sprint C<br />
|-<br />
|| Supported Targets|| Intel Platform Support|| JasperForest|| 2|| Basic support in place; DPDK evaluation in process, overall BSP plan still TBD || Tom|| davest|| Basic ECG support (Moved from Sprint A)<br />
|-<br />
|| Tool Development and SDK Features|| Eclipse poky tree interfacing (git support)|| Use Eclipse git capability to install poky tree from git repo and able to interact with git repo at file level within Poky tree || 2|| Done || Jessica|| jzhang|| Enhancement<br />
<br />
|-<br />
|| Poky Features || Poky Image Creator|| A standalone application you can run which asks you to select a distro and machine, then presents a list of packages you can select. Once the selection is made, it goes off and bakes you an image which is then presented to you. Implementation wise, it should use the sstate packages, be a bitbake UI and use the usual poky bbclass files to do the image construction behind the scenes. || 1|| Re-plan || Joshua|| rpurdie|| Enhancement<br />
|-<br />
|| Distribution / components|| LSB Sanity|| execute LSB Test and improve passing rate and document failures with clear understanding|| 2|| Done || MarkH/Saul|| sgw|| Hygiene<br />
|-<br />
|| Tool Development and SDK Features|| Image creator integration with Eclipse || || 2|| replan|| Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Kernel || Tracing: perf trace marker support || This is from feedback to the new trace command. Ingo appears to have this nearly complete already. || 3 || Done || Darren || dvhart ||<br />
|-<br />
|| Cleanup || bitbake user experience error handling validation completed || || 2 || Done || Richard || ||<br />
|-<br />
|| Cleanup || variable scrub - ensure all metadata variables are documented || Script with a histogram of variable use done, identified 50 variables to document; Add task for actual documentation update is low on the list || 2 || Done || Scott/Darren || ||<br />
|-<br />
|| Kernel || Tracing: package kernelshark || || 3 || Done || Darren || dvhart ||<br />
|}<br />
<br />
=== Sprint D (closes Jan 21, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Swabber || Complete review of swabber outputs || Move to M3 Sprint D || 1 || Move to M3 Sprint D || Alex || ||<br />
|-<br />
|| Poky Features || Fetcher Overhaul Phase 2 - API reorg||<br />
* f) Add a generic unpack funciton to __init__.py based on the unpack task in Poky ;<br />
* g) Split go() methods into the following steps: i) download() - do whatever transfer is necessary to get the sources locally ii) build_mirror_data() - generate any data that would be needed to construct a source mirror iii) unpack() - takes a directory as an argument of where to place extracted sources;<br />
The existing go() methods should be replaced with a set of calls to the above sections of functionality as appropriate in the individual fetchers. Some of these categories of function make no sense in certain fetchers, in which case they shouldn't need to implement them. Functions are only executed if the method is present.<br />
* h) Change Poky's unpack to call an unpack method in the fetchers.<br />
* i) Change Poky's fetch task to call a "download" method in the fetcher instead of go().<br />
|| 1|| Will land with phase 3 in Jan 21 || Saul / Ke, RP|| rpurdie|| Enhancement<br />
|-<br />
|| Poky Features || Fetcher Overhaul Phase 3 - git enhancement||<br />
* j) Optimize git fetcher for the new layout so for a git checkout, we clone the repository in download(), then unpack just does a clone with references to the original repo. <br />
* k) Ensure that we only set __BB_DONT_CACHE when SRCREV = "AUTOREV". This may need a new method call for fetchers to tell whether they're "floating" or locked down. <br />
* l) Add a new "BB_NO_NETWORK" variable which the fetchers check before peforming an operation which hits anything remote. This means adding in error messages about why network access is needed at various points (e.g. SRCREV = "AUTOREV" for a given recipe) <br />
* m) Add multiple branch/srcrev support for git fetcher. These would be of the form: git://somelocation/somerepo.git;name=ref1;branch=foo;name=ref2;branch=bar SRCREV_ref1 = "hash1" SRCREV_ref2 = "hash2" which would ensure both hash1 and hash2 were in the final repo. <br />
* n) Change git fetcher to default to git protocol instead of rsync<br />
|| 1|| Slipped to Sprint D || Saul / Ke, RP|| rpurdie|| Enhancement<br />
|-<br />
|| Poky Features || DSO linking changes|| "By the default the gcc linker will automatically link any dependant objects/libraries. ""Inherited"" linkages can cause issues, for example, where a shared object changes its dependencies but a program has come to rely on symbols from an implicitly linked library. Fedora implemented this change in F13, seems like it would be useful to have in Poky too. "|| 2|| On track for Jan 21 || Saul / Nitin || josh|| bug#516<br />
|-<br />
|| Distribution / components|| Distro Audit Documentation Output|| Audit package documentation output || 2|| Move to Sprint D due to libtool work || Saul / ScottG || rpurdie|| Hygiene<br />
|-<br />
|| Distribution / components|| Review & Fix Standards Tests|| Review the results from LTP, POSIX and asses the result, fix as appropriate and clearly document failures.|| 2|| a Plan to resolve final items to be sent to the m.l. by Jan 14 || Saul/Kevin || sgw|| Hygiene<br />
|-<br />
|| Poky Features || libtool sysroot option|| libtool 2.4 has a sysroot option. We should try and use it, see how it works and whether we can ditch some of our libtool hacks. || 1|| On track for Jan 21 || Saul / ScottG || rpurdie|| Enhancement<br />
|-<br />
|| Distribution / components|| MACHINE or Recipe specific sysroots|| Each machine should have its own sysroot. We'll probably have to split do_populate_sysroot into a two step process, creation of the package and than installtion of the package, which the installation of the package being made machine specific (put ${MACHINE} into ${STAMP} and bitbake should do that). Also allowing this to work per recipe would be desireable|| 1|| On track 21 || Saul / Dongxiao || rpurdie|| Hygiene<br />
|-<br />
|| Distribution / components|| Toolchain Bootstrap Process|| The toolchain as it bootstraps overwrites files like libc.so and libgcc.so in the sysroot directory which causes issues if you just try and rebuild part of the toolchain. Each step of the bootstrap process should use a separate sysroot. Once this is once, sstate file overwriting detection can be added and enabled. || 1|| Patches submitted for comment, slip to Sprint D || Saul / Dexuan || rpurdie|| Hygiene<br />
|-<br />
|| Documentation Features|| Package report system|| move to public server [setup a package report system in an internal machine. We need push it publicly available. The basic features like search and report have been there. But there're still some enhancements in plan, to make it a fit place to feel Yocto metadata comfortably]|| 2|| Move to Sprint E|| KevinT|| ktian1|| enhancement<br />
|-<br />
|| Distribution / components||Add headers and libraries to qemu images ||Since we'll be using qemu images as target sysroot, need to create a set of qemu images for minimal, sato, LSB that contains target header and libraries.|| 2|| Pending a discussion on Jan 18 || Saul ||jzhang|| Enhancement<br />
|-<br />
|| Distribution / components|| push of all relevant Wind River patchs to Yocto (patch comparison)|| Update any additional patches needed since M2.|| 1|| May be done by Jan 21, pending RPM stuff || Mark|| Mark|| <br />
|-<br />
|| Distribution / components|| mklibs|| mklibs is a tool to optimize size of [e]glibc for a perticular root file system image. It is useful to save disk space on small devices. || 2|| Push to Sprint E || Saul|| Nitin Kamble|| enhancement<br />
|-<br />
|| Poky Features || Performance Enhancement || reduce disk space (hardlink) || 1 || On track for Jan 21, pending RP review || Saul / Qing, Dongxiao || rpurdie || Enhancement<br />
|-<br />
|| Kernel || Tracing: perf trace scripting support || || 3 || Move to Sprint D; on track for Jan 21 || Tom || dvhart ||<br />
|-<br />
|| Kernel || Tracing: tuna, oscillosope recipes || || 3 || Tom to discuss plan with Darren et al || Tom || dvhart ||<br />
|- <br />
|| BSP || Beagleboard XM Support || || 3 || Move to Sprint D || Darren || dvhart ||<br />
|-<br />
|| BSP || 2.6.37 Crown Bay Support || On Track for Jan 21 || 2 || || Tom || dvhart || <br />
|-<br />
|| BSP || 2.6.37 Emenlow Support || On track for Jan 21 || 2 || || Tom || dvhart || <br />
|}<br />
<br />
=== Sprint E (closes Jan 28, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| rootless X|| rootless x server has better security than x server launched by root. MeeGo already enable this feature. it would be nice for Yocto to also enable it. || 2|| On track for Jan 28 || Saul / Ke || yuke|| enhancement<br />
|-<br />
|| Documentation Features|| Package report system|| finish major feature development and internal review [setup a package report system in an internal machine. We need push it publicly available. The basic features like search and report have been there. But there're still some enhancements in plan, to make it a fit place to feel Yocto metadata comfortably]|| 2|| Move to Sprint E || Jonathan || ktian1|| enhancement, was M2, Sprint E<br />
|-<br />
|| Distribution / components|| perl upgrade|| perl is the most cross un-friendly recipe pending upgrade. || 2|| Slipping due to Linaro layer, moves to end of Sprint E || Nitin|| Nitin Kamble|| enhancement<br />
|-<br />
|| Supported Targets|| Intel Platform Support|| Sandybridge|| 2|| Accept|| Tom|| davest|| Basic ECG support<br />
|-<br />
|| Distribution / components|| performance indicators|| define some indicators (boot time, footprint, build time, power, component benchmarks, etc.) and then collect them for tracking purpose. The result could be posted on the wiki site, and the initial indicators can be easy ones which can be easily retrieved from autobuilder or weekly qa report). This way we have a clear track about the healthy of the Yocto project, and also identify weak areas. We can include qemu targets and several representational boards as the targets. || 2|| Review|| Beth/Jiajun|| ktian1|| enhancement<br />
|-<br />
|| Tool Development and SDK Features|| SDK user workshop|| Have some developers sit down and use our tools to develop demo software for Yocto. || 2|| Review|| Jessica|| josh|| Enhancement<br />
|-<br />
|| Distribution / components|| Zypper/RPM|| Integration based on design from Sprint B|| 1|| On track for Jan28 || Mark/Qing|| sgw|| Functionality, was M2, Sprint E<br />
|-<br />
|| Kernel || Final linux-yocto_git.bb || With 2.6.37 kernel || 1 || || Bruce || dvhart ||<br />
|-<br />
|| Kernel || Final meta-linaro layer || || || || Darren || dvhart ||<br />
|-<br />
|| Kernel || Final meta-rt layer || || || || Darren || dvhart ||<br />
|-<br />
|| Kernel || Sandy Bridge || || 1 || || Tom || dvhart ||<br />
|}<br />
<br />
=== Sprint F (closes Feb 03 (THURSDAY), 11:59pm PDT -- pull request sent, initially reviewed) :: NOTE: China New Year Holiday ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Documentation|| ADT Reference Guide Draft out for review || Outline complete|| High|| WIP || Scott Rifenbark|| jzhang|| Documentation<br />
|-<br />
|| || || || || || || || <br />
|}<br />
<br />
== M4 (Feb 07 to Apr 15 -- Stabilize Complete Mar 18, Release Complete Apr 01, Contingency to Apr 15) ==<br />
<br />
This sprint is the [[Yocto Project v. 1.0 Release Cycle]].<br />
<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Documentation|| Migration chapter in the Poky Reference Manual|| This chapter would cover the four identified use-cases for migrating up to the most recent version of Yocto Project. Additionally, it would cover migration scenarios from other development systems. The chapter does not yet exist. The chapter has not been scoped outside of having a meeting that identified four use-cases that did not include migration from a development system outside of Yocto Project. It will take some more scoping time to cover those areas (a day or two). Again, I have no idea of the length. See earlier entries for standard industry writing estimates for software documentation|| Medium|| Not Started|| Scott Rifenbark|| 3-4 Weeks|| Documentation<br />
|-<br />
|| Documentation|| Yocto Project Development Guide|| This manual would be an over-arching document that frames the complete development cycle within Yocto Project. The idea here is that the document would be an umbrella document that spawned and referenced subsequent documents. The organization would be the first chapter overviewing the major development pieces such as recipe creation, building, debugging, publishing, fail-safing, back-door hook creation, etc. Scoping would be about two weeks and length would probably be about 40 pages. Overall development time would likely be a month of uniterruped time.|| Medium|| Not Started|| Scott Rifenbark|| 3 Weeks|| Documentation<br />
|-<br />
|| Validation|| Boottime/Performance Analysis|| Compare Yocto Project performance to other projects such as MeeGo|| 1|| Initial report on where we are by Feb 9 || Darren|| davest|| project commitment<br />
|-<br />
|| || Multilib Support|| Consider developing post-1.0 branch || 1|| to start in M4 || Richard|| ||<br />
|-<br />
|| Validation|| Alpha testing complete|| 4-5 internal developers unfamiliar with Yocto Project try to do a build and report on the experience and issues encountered|| 1|| Done by Feb 18 || Julie|| davest|| <br />
|-<br />
|| || || || || || || || <br />
|}<br />
<br />
== Features needed and to be put into sprints by assigned owners: ==<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || package config option enhancement|| there're several enhancements we may do here: * allow users setting specific config options (local or global) from external tool, such as poky image creator, instead of changing recipes manually. Need a mechanism to convert from variable assignments into exact config options (e.g. feature_${PN} = ""1"" -> ""--enable-feature""). Consequently dependency chain needs update with option status. * host contamination check. We have swabber to check host contamination, but I'm not sure whether it covers configuration phase. If not, this is one area to improve, as not ususually we see configure script checks host bits for available features * conditional option manipulation. In many recipes we enable/disable one option based on availability of other packages. Now this is done manually and not flexible. this should be made automatically though some new annotation to indicate condition, or just base_contains (not convenient: long line, need define distro features) || 2|| Review|| Richard/MarkH|| ktian1|| Enhancement<br />
|-<br />
|| Media|| Yocto Project Awareness Video|| This 2.5 minute video would introduce and describe the benefits of Yocto Project. The video would use entertaining animations that described concepts and benefits. The result would be suitable for YouTube, conferences, and the website. The production is called an "Epipheo" and will be created by Epipheo Studios. The engagement process has begun and the kick-off meeting will be soon. The PO is in place. Time for development is 10 weeks.|| High|| Kick-off Imminent|| Scott Rifenbark|| 10 Weeks|| Media<br />
|-<br />
|| Documentation|| Yocto Project Debugging Guide|| This would be a guide for the debugging and bug tracking process in Yocto Project. Originally, the thought was that we needed a Bugzilla User's Manual. However, since we don't own Bugzilla it doesn't make sense to produce documentation for it. Rather, we should document the process as it fits into the Yocto Project environment. Ideally, the manual would be a sub-manual that would be referenced and architected into the Yocto Project Development Guide. The manual has not been scoped and would take a week to scope. Again, I have no idea of the length. See the previous item for standard industry writing estimates for software documenation.|| Medium|| Not Started|| Scott Rifenbark|| 3-4 Weeks|| Documentation<br />
|-<br />
|| Website|| Yocto Project Website|| The 0.9 website is in place but needs updates. Items for consideration are the left-panel naviagation scheme, a contributions guidance page, color-scheming and theme (possibly).|| Medium|| Not Started|| Scott Rifenbark|| 1-2 Weeks|| Website<br />
|}<br />
<br />
== Features not believed to be needed in v1.0: ==<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || OpenEmbedded/Bitbake Upstreaming|| "We firstly need to review where we are and where OE is. We then need to make a plan about what we're going to push upstream and what we're not. I'd suggest when we're in PRC, we do a crash course in ""dealing with OE"" and then many dedicate a block of time (a week) where the distro team comes up with a patch set we then propose and get merged into OE. I'd like to find a couple of interested people to monitor OE more regularly and start a workflow of things between Poky/OE where appropriate. The key thing to remember is we need to keep the architectures compatible. The team is now at the point where I'm happy for them to actually try building OpenEmbedded and not worry about it tainting them! "|| 2|| Review|| || rpurdie|| Process<br />
|-<br />
|| Poky Features || Handle old versions in WORKDIR|| an incremental build directory may finally include many old versions WORKDIRS. It'll be good to have those old versions tracked in the cache, which can then either generate a report or allow selectively cleaning up an specific version WORKDIR. Or else it's difficult to figure it out when people want to keep the whole tmp directory but like to cleanup some old bits when disk usage is under pressure. If it's not easy to do in bitbake, perhaps some separate scripts would be also helpful || 3|| Review|| || ktian1|| Enhancement<br />
|-<br />
|| Poky Features || run bitbake w/o rebuilding the cache|| "sometimes it's useful to allow run bitbake w/o re-parsing recipes, if we know nothing metadata is changed. we can just allow reusing existing persistent cache. this is useful when people is debugging WORKDIR w/o metadata change. also sometimes ""bitbake -e"" is used frequently to check poky variable information. with existing cache, several seconds can be saved which are not negligible for a developer daily working on Yocto "|| 2|| Review|| || ktian1|| Enhancement<br />
|-<br />
|| Poky Features || parallel make improvement|| parallel make experience is not good, especially when bb threads and make threads are increased larger than 8. So far we either try to fix package makefile or mark the recipe as no parallel make, when build faiures are reported. But this greatly impacts user experience for a successfully continuous build process. Could we define a safe number we do want to support for 1.0 release? and then have our autobuilder, QA test, and developers cover that number immediately and fix any issues accordingly. Then the safe number can be suggested to the Yocto user || 2|| Review|| || ktian1|| Enhancement<br />
|-<br />
|| Poky Features || Dependency packages rebuild/clean|| It is a mechanism to rebulid or clean a package and all other packages which have build/runtime dependency on it. With this change, we can find potential influences of package upgrade to its related packages, which can make the incremental build more trustable. For example, if we upgrade a package to a new vesion which changes its API, this mechanism can easily find out the incompatibility to other packages which have dependency on it. || 2|| Review|| || dongxiao.xu|| Enhancement, replaced by checksum feature<br />
|-<br />
|| Distribution / components|| FOSSology|| This may be similar to License Update above, but start to use FOSSology to track licenses. || 2|| Review|| || sgw|| Hygiene<br />
|-<br />
|| Distribution / components|| Package Developer Tools|| Create a set of Init scripts template and then review our current init scripts and modify them to confirm to the template. || 2|| Review|| || sgw|| Easy of Use<br />
|-<br />
|| Distribution / components|| Package Website|| Complete the work the intern has started on generating the distro tracking information and get it out on the external site. || 2|| Review|| || sgw|| "Hygiene, duplicate of ""Package report system"""<br />
|-<br />
|| Distribution / components|| Bluetooth UI support|| Currently we have bluez package in poky, and we need to have a workable graphic user interface to connect/configure BT devices. One choice may be gnome-bluetooth-applet. || 3|| Review|| || dongxiao.xu|| enhancement<br />
|-<br />
|| Distribution / components|| Connman-gnome enhancement features|| Enable connman-gnome to support features like, WPA Enterprise connection, hidden SSID, etc. || 3|| Review|| || dongxiao.xu|| enhancement<br />
|-<br />
|| Distribution / components|| Java Running Environment support|| Since most embedded systems support java applications running in it, maybe we'd better consider supporting some kinds of JVMs(Embeded JVM). The JVM may not run by default, but user can launch it if running java applications. Compared with GTK/QT, java user number is not small too. || 3|| Review|| || criping|| enhancement<br />
|-<br />
|| Distribution / components|| create more use cases|| UPnP demo is one really good use case showing how Yocto is utilized to make real functionality. and we could create more to show how Yocto is easily adapted to real use cases. Those use cases can be either maintained as seperate demo layers in yocto repo, or in seperate branches for reference. We can also call for community's contribution on this which would make 1.0 full-fledged. Or else the newbies to Yocto may be in puzzle how our sample profiles can satisfy their requirements. || 2|| Review|| || ktian1|| enhancement<br />
|-<br />
|| Distribution / components|| i18n support || internationalization is an important system wide feature. Many component like font, locale affect the i18n. Yocto alreay has some i18n related package like pango, but so far did not consider i18n systematically. so this is place holder to systematically add i18n support. || 2|| Review|| || yuke/qing|| enhancement<br />
|-<br />
|| Distribution / components|| more demos || demos are a good way to educate, push the envelope, and at the same time tout the strengths of the platform. This item just records a current set of ideas from various sources which could/should be implemented: * face-recognition/face-finding, * robotic control/application of face-finding to 'camera-as-sensor' (hexbug demo), * others [tbd, add here]|| 2|| Review|| || tzanussi|| enhancement <br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer support for image-creator and needed yocto-metadata design||Come up design what need to be created as packages to support using "opkg install" for image-creator and needed yocto-metadata|| 2|| WIP, pending comments from RP regarding how to packaging metadata|| Jessica|| rpurdie|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer image-creator and needed poky-metadata support|| The poky build system will build packages for image-creator and needed poky-metadata, which the Yocto Installer will be able to use "opkg install" to install them|| 2|| Review|| Jessica|| rpurdie|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Provide qemu management UI|| In current eclipse plugin, QEMU settings are put together with project configuration. So we can only have limited settings. If we can have a separate QEMU management UI, the end user could firstly create a QEMU config, such as (env file of arch, image location, unfs or not, sato or lsb, mem size, disk size). And then he can launch a QEMU with a specific config. The dependency between project configuration and QEMU config will be resolved. After all QEMU has nothing to do project configuration. Need to careful review the UI to ensure minimal impact to testing matrix. || 3|| Review|| || criping|| "Enhancement, duplicate of ""Qemu mem/disk size can be adjusted"""<br />
|-<br />
|| Tool Development and SDK Features|| QT plugin For Eclipse|| Integrate QT Ecplise plugin and extend for Yocto Project || 3|| Review|| || jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Profiling/Trace GUI's|| We have a wealth of great tracing and profiling tools but the UI's for them are all extremely minimal and usually quite ugly. Would be great if we could compete with, or even better, Apple's offerings here. We have the technology! || 2|| Review|| || josh|| "Enhancement, duplicate of ""Tracing/Profiling Planning Complete"""<br />
|-<br />
|| Tool Development and SDK Features|| Other profiling tools|| Complete Tom's review of profiling tools and architecture || 2|| Review|| || josh|| "Enhancement, duplicate of ""Tracing/Profiling Planning Complete"""<br />
|-<br />
|| Tool Development and SDK Features|| Design next-gen tracing/profiling tools|| Yocto 1.0 will include all the essential existing tracing/profiling tools expected by users, and Josh has proposed a UI integration of all those tools as far as it's possible to do so. That level of integration, basically a 'plugin-level' integration is necessary and useful, but doesn't go far enough. A next-generation tracing tool would integrate at a much more fundamental level; if done properly, it would provide unmatched levels of power and usability to users, and would allow Yocto to distinguish itself in the embedded tracing/profiling space in a way also unmatched by any other distro/build-tool. The implementation would of course not be available for Yocto 1.0, but a coherent design, including prototypes, that could be taken to the community and implemented in a V 1.5 or 2.0 should be done in that time frame. || 1|| Review|| || tzanussi|| "Enhancement, duplicate of ""Tracing/Profiling Planning Complete"""<br />
|-<br />
|| Documentation Features|| Self Documentation of image contents|| "I'd like to see the -doc packages Poky builds being combined into some kind of large documentation index representing the collective API docs of the target being built. This can then be placed on a webserver and viewed over the web. We'd have a demonstration of this for a ""bitbake world"" target. Part of the idea here is to start making good use of the docs as if developers see this they might start writing better docs too. Aim is to lead the field :). There are a number of places poky packages disable doc generation due to missing tools so we'd need to add these so we can enable the doc generation. Many packages already have many docs though too. "|| 2|| Review|| || rpurdie|| enhancement<br />
|-<br />
|| Validation|| Testing Framework|| Add a framework for doing automated testing in the project|| 1|| Review|| || davest|| project commitment<br />
|-<br />
|| Validation|| more SDK builds on autobuilder|| enable more SDK related tests on autobuilder such as meta-ide-support, etc.|| 2|| Review|| || ktian1|| project commitment, addressed by test plan (?)<br />
|-<br />
|| Validation|| more people should try using SDK|| this may not be a feature, but a requirement. SDK including meta-toolchain is one key factor impacting user experience on Yocto. It's not enough to have only SDK team play with it|| 2|| Review|| || ktian1|| project commitment, addressed by test plan (?)<br />
|-<br />
|| Validation|| Unit Testing Framework|| Add a mechanism to bitbake to parse source packages that have unit tests and then execute them on the target|| 3|| Review|| || sgw|| "project commitment, duplicate of ""Testing Framework"""<br />
|-<br />
|| Validation|| Test Case open source|| Open source Yocto test cases with xml format|| 1|| Review|| || yyou|| "project commitment, duplicate of ""Testing Framework"""<br />
|}</div>Davesthttps://wiki.yoctoproject.org/wiki/index.php?title=Yocto_1.0_Schedule&diff=595Yocto 1.0 Schedule2011-01-25T01:38:58Z<p>Davest: /* Sprint C (closes Jan 14, 11:59pm PDT -- pull request sent, initially reviewed) */</p>
<hr />
<div>= v1.0 (release date: Apr 15, 2011) =<br />
----<br />
The detailed milestone map for v1.0 is as below. During the first week of each subsequent milestone past M1 we will have a demonstration of the previous milestone capabilities as well as a planning and design session for the current milestone.<br><br><br />
<br />
== M2 (Nov 08 to Dec 24 -- Dev Complete Dec 10, Stabilize Complete Dec 17, Release Complete Dec 24) ==<br />
=== Sprint A (closes Nov 12, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links''' <br />
|-<br />
|| Poky Features || Kernel interactive targets || To support incremental kernel development having the ability to run menuconfig (or xconfig, etc) directly is a common request. We'll need to add this for commercialization anyway. i.e. bitbake -c menuconfig. This fuctionality already exists. || 1 || Done || Richard || bruceashfield || Enhancement <br />
|-<br />
|| Distribution / components || Distro Audit: Upgrades Planned (Phase 1) || Complete plan for package upgrades in M2 || 1 || Done || Saul || || Continual Maintenance<br />
|-<br />
|| Validation || Runtime testing || Runtime testing of images as part of the autobuilder || 1 || Done || Jiajun/ScottG || rpurdie || project commitment<br />
|- <br />
|| || Poky Image Creator Wireframe/Interaction Plans Complete || || 1 || Done || Josh || ||<br />
|-<br />
|| || SDK Generator Interaction: Plans Complete || || 1 || Done || Jessica || ||<br />
|-<br />
|| || Tracing/Profiling Planning Complete || This needs to cover where we're at now, what we're missing and also propose the future enhancements that may be needed. M2 targets getting existing tools integrated and documented. F2f discussion n the future enhancements || || Done || Tom || ||<br />
|-<br />
|| || Swabber. (Still needs to be integrated into weekly build by default) || || 1 || Done || Josh || ||<br />
|-<br />
|| Build/Release || Release process documentation || || || Done || Beth || ||<br />
|-<br />
|| Validation || Test plan for v1.0 (to address any deficiencies in coverage from v0.9)|| || 1 || Done || Jiajun || ||<br />
|}<br />
<br />
=== Sprint B (closes Nov 19, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| Distro Audit: World Packages|| Audit world packages making sure it all build, making sure all are packages are required || 2|| Done || Saul|| sgw|| Hygiene<br />
|-<br />
|| Tool Development and SDK Features|| SDK Generator Installer UI|| Look at different ways of Installer UI (GTK+ and ncurses) seems none of them is the right choice, decide to go with script to implement all the functionalities of installer and later add UI part on top of it || 1||Done|| Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Customize sysroot setup || Add and test out "--sysroot" config option to cross compiler within Eclipse IDE || 1|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| SDK Generator Installer design revision|| Close all open questions regarding Yocto SDK Generator Installer function design and come up HLD || 1|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Distribution / components|| kernel version|| keeping 2.6.34 as a -stable kernel is the best option. I've also got a newer -devel tree that can be made available or made the default. || 3|| Done || Bruce|| bruceashfield|| enhancement<br />
|-<br />
|| || assign Yocto Project PM|| acquire and assign a program manager for Yocto Project|| || Done || DaveST|| || <br />
|-<br />
|| || assign Yocto Project Sys Admin|| || || Done || Saul|| || <br />
|-<br />
|| Tool Development and SDK Features|| oprofileUI|| Fixing various bugs of the oprofileUI to make it workable on big endian host.(i.e. ppc, mips) || 2 || Done || Jessica || lianhao.lu || Bug #382 / Bug #493<br />
|-<br />
|| Poky Feature|| SDK Version Control|| If we can expect that yocto SDK has lots of release in the future, we might need to consider SDK version control. Currently, every thing installed under /opt/poky which leads to things be overriden, we need to be able to use a scheme like /opt/poky-1.0, /opt/poky-2.0 to distiguish things. || 2|| Done || Josh|| jzhang|| Enhancement<br />
|-<br />
|| Kernel || Kernel plan complete || Flesh our kernel deliverables and add to Yocto 1.0 schedule || || Done|| Darren || dvhart ||<br />
|}<br />
<br />
=== Sprint C (closes Nov 26, 11:59pm PDT -- pull request sent, initially reviewed) :: NOTE: this is US Thanksgiving week ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| Distro Audit: Licence Checksums|| licence checksums || 1|| Done || Saul|| rpurdie|| Hygiene<br />
|-<br />
|| Poky Features || Performance Analysis Completed|| "I'd like someone to instrument a green release build, see where it spends time (hot/cold parsing time, individual task building time) and then compare this with our 0.9 release build. I'd also like to compare the disk usage between the two. Once we have a blame list we can then set about fixing it. Some things I know will come up: a) pseudo, b) checksums/signature code, c) exec() vs fork for executing tasks, d) task based prebuilds increasing disk usage, e) rpm dependency calculations, f) using rpm vs. ipk but I may be wrong and there may be others. We need numbers. "|| 1|| Done || Saul / Qing, Dongxiao|| rpurdie|| Enhancement<br />
|-<br />
|| Poky Features || environment variables for kernel builds|| switching a branch, or adding a configuration feature (and even changing the kernel repo) is often done during development of a BSP. Having some additional variables that are pass the bitbake environment scrub would be useful. i.e. KBRANCH=foo bitbake -c configure linux-yocto. This goes along with the other BSP bootstrapping suggestions. || 2|| Done || Bruce|| bruceashfield|| Enhancement<br />
|-<br />
|| Supported Targets|| ARM Platform Support|| Replace beagleboard with Beagleboard XM - decision || 2|| Done || Bruce|| alex|| Basic Yocto hardware support <br />
|-<br />
|| Distribution / components|| Security Process|| We need a dedicated person to scan and apply critical security updates to the distro. The MeeGo team already has a similar process with some scripts which may be leveraged. To complete the task, the process should be documented and a first pass over the metadata made to establish the current position on security. Any upgrades needed should be identified and a plan to address them should be in place but doesn't have to be implemented by this point.|| 1|| Done || ScottG|| ktian1|| enhancement<br />
|-<br />
|| Tool Development and SDK Features|| SDK Generator Installer Opkg repo design|| Come up a opkg repo design that will mimic the final Yocto package repo layout to be used by SDK Generator Installer to test against|| 2 || Done || Jessica || jzhang || <br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer tar creaion|| Create a Yocto Installer tar ball which contains Installer script and supported opkg component that will be used for installing other Yocto components|| 2 || Done || Jessica || jzhang || <br />
|-<br />
|| Documentation|| Kernel Framework Paper from WR|| The paper from WR needs to be re-written and then posted somewhere on the Yocto Project site. This will involve examiniation of the text and re-writing and formatting for presentation. Currently it is simply a text document. Completion time assuming uninterrupted time is one week.|| High|| Done || Scott Rifenbark|| 1 Week|| Documentation<br />
|-<br />
|| Documentation|| Poky Reference Manual|| This guide exists in the 0.9 form. The re-write of the text needs to be completed. So far, all the chapters have been rewritten but not re-posted on the site. Only the appendices remain for a text scrub. Time to complete this would be a week of uninterrupted time. Ideally, the manual would be a sub-manual that would be referenced and architected into the Yocto Project Development Guide.|| Medium|| Done|| Scott Rifenbark|| 1 Week|| Documentation<br />
|-<br />
|| Kernel || Initial meta-linaro layer || meta-linaro layer providing a kernel, tool-chain, and uboot loader. This deliverable is primarily to get the infrastructure in place and have a buildable kernel. Toolchain on best effort basis. || || Done || Darren || dvhart || Moderate risk of slippage due to holidays.<br />
|-<br />
|| Kernel || Tracing: blktrace and sysprof recipes || || || Done || Tom || dvhart ||<br />
|}<br />
<br />
=== Sprint D (closes Dec 3, 11:59pm PDT -- pull request sent, initially reviewed) :: NOTE: week of the F2F planning meeting ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Kernel || Kernel git branching structure revamped || || 1 || Done || Bruce || dvhart ||<br />
|-<br />
|| Kernel || Tunnel Creek (Crown Bay) || || 1 || Done || Tom || dvhart ||<br />
|}<br />
<br />
=== Sprint E (closes Dec 9 (THURSDAY), 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| Distro Audit: Upgrades Completed (Phase 1)|| Update to new versions as per the agreed plan for M2 from Sprint A|| 1|| Done || Saul|| rpurdie|| Continual Maintenance<br />
|-<br />
|| Distribution / components|| Distro Audit: Src Checksums|| Make sure all SRC_URI components have checksums too || 1|| Done || Saul|| rpurdie|| Hygiene<br />
|-<br />
|| Poky Features || enable KVM with qemu|| today all new Intel processors support VT, which are enabled on most desktop machines which are most frequently used build machine. with VT support, x86/x86-64 qemu target runs faster which is a good thing for emulation environment. This may require some qemu option tweaks and also poky-qemu script enhancement. || 2|| Done || Saul / Edwin|| ktian1|| Enhancement<br />
|-<br />
|| Kernel || New kernel recipes || dev, -devel, -custom || 3 || Done || Bruce || dvhart ||<br />
|-<br />
|| Swabber || Documentation for swabber || || 1 || Done || Alex || ||<br />
|-<br />
|| CCB || Defect triage process in public documented and implemented || || 1 || Done. Triage process is documented, out for review. || Saul || ||<br />
|}<br />
<br />
== M3 (Dec 20 to Feb 08 -- Dev Complete Feb 04, Stabilize Complete Feb 11, Release Complete Feb 18) ==<br />
=== Sprint A (closes Dec 24, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Kernel || Initial meta-rt layer || PREEMPT_RT kernel and related test-cases and benchmarks || 2 || Done by Jan 21 || Darren || dvhart || slipped out from M2<br />
|-<br />
|| Poky Features || Fetcher Overhaul Phase 1 - SRC_REV enhancement||<br />
* a) Add code in FetchData::__init__() which will check if the selected fetcher supports srcrev and the automatically call a function to set the src rev value instead of each fetcher doing this.\n <br />
* e) Break SRCREVINACTION deadlock. To do this, we need to start using a keyword for automatically increasing SRCREV, e.g. SRCREV = "AUTOINC". The actual revision can be injected into PV using SRCPV. If we do this there should no longer be a need of the deadlock; <br />
* k) Ensure that we only set __BB_DONT_CACHE when SRCREV = "AUTOREV". This may need a new method call for fetchers to tell whether they're "floating" or locked down.<br />
|| 1|| Done || Saul / Ke, RP|| rpurdie|| Enhancement, slipped out from M2<br />
|-<br />
|| Distribution / components|| Distro Audit Upgrades Planned (Phase 2)|| Complete plan for package upgrades in M2|| 1|| Done || Saul|| || Continual Maintenance<br />
|-<br />
|| Poky Features || Pseudo Performance || Implement the changes to bitbake based on pseudo's enable/disable switch|| 1|| done || Saul / Qing, Dongxiao || rpurdie|| Enhancement, slipped from M2 due to risk and not having Pseudo's change yet.<br />
|-<br />
|| Tool Development and SDK Features|| Fix the issue user target sysroot is owned by root || The ADT installer will use pseudo to extract user target sysroot which ended up owned by root, this need to be fixed || 1|| done || Jessica|| jzhang|| Cleanup <br />
|-<br />
|| Tool Development and SDK Features|| Eclipse poky tree interfacing (metadata file editor)|| Provide a metadata file editor with some syntax checking and keywords highlight capabilities|| 2|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| IDE Project templates|| Templates for various project types: Clutter GUI, Gtk+ GUI, to help developers get started quickly || 2|| Done || Jessica|| josh|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| push TCF/RSE patches upstream|| work with community to finish up our TCF terminal service, TCF/RSE integration remaining patches taken by upstream. Blocking issues including Eclipse Bug #327865 || 1|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Pseudo || Pseudo enhancement to enable on/off switch || || 1 || done || Mark || ||<br />
|-<br />
|| Pseudo || Bitbake enhancement for pseudo on/off switch || || 1 || done || Richard || ||<br />
|-<br />
|| bugzilla || Complete restructure of bugzilla categories || || 1 || done || Saul || ||<br />
|-<br />
|| Poky Features || Image creator ground work || Nomenclature determined, existing gui's bug fixed and backend work implemented || 1 || Done || Joshua || ||<br />
|-<br />
|| Kernel || Tracing: Initial SystemTap recipe || Works on x86 || 3 || Done || Tom || dvhart ||<br />
|-<br />
|| Distribution / components|| Distro Audit: Package Description/Summary completed|| Ensure DESCRIPTION/SUMMARY fields are all audited|| 2|| Done || Mark|| Mark|| Hygiene, was M2, Sprint B but missed window<br />
|-<br />
|| Distribution / components|| Zypper/RPM|| Small write-up of the problems we're having w/ Zypper and what we plan to do. (i.e. create a roadmap/design) - Includes rootfs generation - Package uprev/install/removal || 1 || Done || Mark/Qing || || was M2, Sprint B<br />
|-<br />
|| Distribution / components|| Distro Audit: Licence Checksums|| Make the licence checksums fatal if not present || 1|| Done || Saul|| rpurdie|| Hygiene, was M2, Sprint C<br />
|-<br />
|| Distribution / components|| push of all relevant Wind River patchs to Yocto (patch comparison)|| Ensure patches present to packages in WRS are also in Poky|| 1|| Done || Mark|| Mark|| was M2, Sprint C<br />
|-<br />
|| Poky Features || Performance Enhancement Completed || Initial changes to reduce disk space (sstate-build-*) || 1|| Done || Saul / Qing, Dongxiao || rpurdie|| Enhancement, was M2, Sprint E<br />
|-<br />
|| Distribution / components|| User specified qemu config support|| We'll provide user an edit box which allows advanced qemu user to specify arbitrary qemu configuration to meet their needs, which the poky-qemu scrip will just append the config list towards the end of the list of parameters to bring up qemu, it also expect the poky-qemu script to do some basic sanity check on the user specifications to catch the obvious mistake || 2|| Done || Saul / criping || criping|| enhancement, was M2, Sprint E<br />
|-<br />
|| Tool Development and SDK Features|| SDK Version Control support in SDK generator installer|| If we can expect that yocto SDK has lots of release in the future, we might need to consider SDK version control. Currently, if we un-tar the sdk, it will override the older version. It's not good for app developers since they might need the old version to do something. And also, maybe a finer installer than untar is preferred. Installer will tied to certain SDK version and the installation will go under /opt/poky-versionNo.|| 1|| Done || Jessica|| criping|| Enhancement-expect planning process by Jessica to handle this task. Was M2, Sprint E.<br />
|}<br />
<br />
=== Sprint B (closes Jan 07, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || Bitbake multi-threaded parsing|| Bitbake recipe parsing is currently single threaded. I want to make this multithreaded as the speedup would be nice. If I can only take a single task for myself for 1.0, I'm nominating this one as I enjoy this kind of thing and I have ideas on how to do it. || 1|| Done || Richard|| rpurdie|| Enhancement<br />
|-<br />
|| Distribution / components|| Lock in Kernel/Toolchain version|| Locked in 2.6.37 and gcc 4.5.1. Pending decision to move to 4.5.2 and Linaro || || Done || || Richard|| || <br />
|-<br />
|| Distribution / components|| License Update|| For each of the licences we support, I'd really like to have a licences directory with a copy of that license contained within. When it comes to deciding what a given LICENSE field means, this would be the reference. It also means we can include the licences a given image includes with the image. This continues to make our license handling world class and ahead of the field. || 2|| Done || Beth|| rpurdie|| Hygiene<br />
|-<br />
|| Tool Development and SDK Features|| Qemu configuration change|| Provice edit box for advanced user to specify qemu configurations|| 2|| Done || Jessica|| criping|| <br />
|-<br />
|| Tool Development and SDK Features|| Lock down Eclipse+CDT+TCF version|| Will use Eclipse Halo 3.6 || 1|| Done || Jessica|| || <br />
|-<br />
|| Demo|| Finalize on demo plans for v1.0 launch || || 1|| Done || Dave || || <br />
|-<br />
|| Release || Release plans for v1.0 launch || Fill out the M4 plan with the necessary release activities and timings || 1|| Done || Beth || || <br />
|-<br />
|| Poky Features || Basic image creator GUI || Functional UI missing some Advanced features || 1 || In replan || Joshua || || <br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer for SDK Generator Installation functions support||Detailed feature request can be found at: http://bugzilla.pokylinux.org/show_bug.cgi?id=589|| 1|| Done || Jessica|| rpurdie|| Enhancement<br />
|-<br />
|| Kernel || Tracing: trace-cmd python binding cleanup || || 3 || Done || Darren || dvhart ||<br />
|}<br />
<br />
=== Sprint C (closes Jan 14, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || kernel development layer|| The (correct) poky behaviour of building known revisions coupled with the fetcher requiring a BSP branch to already be present means that local modifications (and kernel source tree) are required for kernel development. I already have a layer that overrides/modifies the behaviour when added to the bblayers.conf and configured into an environment. This seems useful for more people to use. || 2|| Done || Bruce|| bruceashfield|| Enhancement, was M2, Sprint C<br />
|-<br />
|| Distribution / components|| Zypper/RPM|| RPM Uprev / Zypper Uprev [lets get to the latest versions]|| 1|| pull request by Jan 19; || Mark/Qing|| || was M2, Sprint C<br />
|-<br />
|| Supported Targets|| Intel Platform Support|| JasperForest|| 2|| Basic support in place; DPDK evaluation in process, overall BSP plan still TBD || Tom|| davest|| Basic ECG support (Moved from Sprint A)<br />
|-<br />
|| Tool Development and SDK Features|| Eclipse poky tree interfacing (git support)|| Use Eclipse git capability to install poky tree from git repo and able to interact with git repo at file level within Poky tree || 2|| Done || Jessica|| jzhang|| Enhancement<br />
<br />
|-<br />
|| Poky Features || Poky Image Creator|| A standalone application you can run which asks you to select a distro and machine, then presents a list of packages you can select. Once the selection is made, it goes off and bakes you an image which is then presented to you. Implementation wise, it should use the sstate packages, be a bitbake UI and use the usual poky bbclass files to do the image construction behind the scenes. || 1|| Re-plan || Joshua|| rpurdie|| Enhancement<br />
|-<br />
|| Distribution / components|| LSB Sanity|| execute LSB Test and improve passing rate and document failures with clear understanding|| 2|| Done || MarkH/Saul|| sgw|| Hygiene<br />
|-<br />
|| Tool Development and SDK Features|| Image creator integration with Eclipse || || 2|| replan|| Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Kernel || Tracing: perf trace marker support || This is from feedback to the new trace command. Ingo appears to have this nearly complete already. || 3 || Done || Darren || dvhart ||<br />
|-<br />
|| Cleanup || bitbake user experience error handling validation completed || || 2 || Done || Richard || ||<br />
|-<br />
|| Cleanup || variable scrub - ensure all metadata variables are documented || Script with a histogram of variable use done, identified 50 variables to document; Add task for actual documentation update is low on the list || 2 || Done || Scott/Darren || ||<br />
|-<br />
|| Kernel || Tracing: package kernelshark || || 3 || Done || Darren || dvhart ||<br />
|}<br />
<br />
=== Sprint D (closes Jan 21, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Swabber || Complete review of swabber outputs || Move to M3 Sprint D || 1 || Move to M3 Sprint D || Alex || ||<br />
|-<br />
|| Poky Features || Fetcher Overhaul Phase 2 - API reorg||<br />
* f) Add a generic unpack funciton to __init__.py based on the unpack task in Poky ;<br />
* g) Split go() methods into the following steps: i) download() - do whatever transfer is necessary to get the sources locally ii) build_mirror_data() - generate any data that would be needed to construct a source mirror iii) unpack() - takes a directory as an argument of where to place extracted sources;<br />
The existing go() methods should be replaced with a set of calls to the above sections of functionality as appropriate in the individual fetchers. Some of these categories of function make no sense in certain fetchers, in which case they shouldn't need to implement them. Functions are only executed if the method is present.<br />
* h) Change Poky's unpack to call an unpack method in the fetchers.<br />
* i) Change Poky's fetch task to call a "download" method in the fetcher instead of go().<br />
|| 1|| Will land with phase 3 in Jan 21 || Saul / Ke, RP|| rpurdie|| Enhancement<br />
|-<br />
|| Poky Features || Fetcher Overhaul Phase 3 - git enhancement||<br />
* j) Optimize git fetcher for the new layout so for a git checkout, we clone the repository in download(), then unpack just does a clone with references to the original repo. <br />
* k) Ensure that we only set __BB_DONT_CACHE when SRCREV = "AUTOREV". This may need a new method call for fetchers to tell whether they're "floating" or locked down. <br />
* l) Add a new "BB_NO_NETWORK" variable which the fetchers check before peforming an operation which hits anything remote. This means adding in error messages about why network access is needed at various points (e.g. SRCREV = "AUTOREV" for a given recipe) <br />
* m) Add multiple branch/srcrev support for git fetcher. These would be of the form: git://somelocation/somerepo.git;name=ref1;branch=foo;name=ref2;branch=bar SRCREV_ref1 = "hash1" SRCREV_ref2 = "hash2" which would ensure both hash1 and hash2 were in the final repo. <br />
* n) Change git fetcher to default to git protocol instead of rsync<br />
|| 1|| Slipped to Sprint D || Saul / Ke, RP|| rpurdie|| Enhancement<br />
|-<br />
|| Poky Features || DSO linking changes|| "By the default the gcc linker will automatically link any dependant objects/libraries. ""Inherited"" linkages can cause issues, for example, where a shared object changes its dependencies but a program has come to rely on symbols from an implicitly linked library. Fedora implemented this change in F13, seems like it would be useful to have in Poky too. "|| 2|| On track for Jan 21 || Saul / Nitin || josh|| bug#516<br />
|-<br />
|| Distribution / components|| Distro Audit Documentation Output|| Audit package documentation output || 2|| Move to Sprint D due to libtool work || Saul / ScottG || rpurdie|| Hygiene<br />
|-<br />
|| Distribution / components|| Review & Fix Standards Tests|| Review the results from LTP, POSIX and asses the result, fix as appropriate and clearly document failures.|| 2|| a Plan to resolve final items to be sent to the m.l. by Jan 14 || Saul/Kevin || sgw|| Hygiene<br />
|-<br />
|| Poky Features || libtool sysroot option|| libtool 2.4 has a sysroot option. We should try and use it, see how it works and whether we can ditch some of our libtool hacks. || 1|| On track for Jan 21 || Saul / ScottG || rpurdie|| Enhancement<br />
|-<br />
|| Distribution / components|| MACHINE or Recipe specific sysroots|| Each machine should have its own sysroot. We'll probably have to split do_populate_sysroot into a two step process, creation of the package and than installtion of the package, which the installation of the package being made machine specific (put ${MACHINE} into ${STAMP} and bitbake should do that). Also allowing this to work per recipe would be desireable|| 1|| On track 21 || Saul / Dongxiao || rpurdie|| Hygiene<br />
|-<br />
|| Distribution / components|| Toolchain Bootstrap Process|| The toolchain as it bootstraps overwrites files like libc.so and libgcc.so in the sysroot directory which causes issues if you just try and rebuild part of the toolchain. Each step of the bootstrap process should use a separate sysroot. Once this is once, sstate file overwriting detection can be added and enabled. || 1|| Patches submitted for comment, slip to Sprint D || Saul / Dexuan || rpurdie|| Hygiene<br />
|-<br />
|| Documentation Features|| Package report system|| move to public server [setup a package report system in an internal machine. We need push it publicly available. The basic features like search and report have been there. But there're still some enhancements in plan, to make it a fit place to feel Yocto metadata comfortably]|| 2|| Move to Sprint E|| KevinT|| ktian1|| enhancement<br />
|-<br />
|| Distribution / components||Add headers and libraries to qemu images ||Since we'll be using qemu images as target sysroot, need to create a set of qemu images for minimal, sato, LSB that contains target header and libraries.|| 2|| Pending a discussion on Jan 18 || Saul ||jzhang|| Enhancement<br />
|-<br />
|| Distribution / components|| push of all relevant Wind River patchs to Yocto (patch comparison)|| Update any additional patches needed since M2.|| 1|| May be done by Jan 21, pending RPM stuff || Mark|| Mark|| <br />
|-<br />
|| Distribution / components|| mklibs|| mklibs is a tool to optimize size of [e]glibc for a perticular root file system image. It is useful to save disk space on small devices. || 2|| Push to Sprint E || Saul|| Nitin Kamble|| enhancement<br />
|-<br />
|| Poky Features || Performance Enhancement || reduce disk space (hardlink) || 1 || On track for Jan 21, pending RP review || Saul / Qing, Dongxiao || rpurdie || Enhancement<br />
|-<br />
|| Kernel || Tracing: perf trace scripting support || || 3 || Move to Sprint D; on track for Jan 21 || Tom || dvhart ||<br />
|-<br />
|| BSP || 2.6.37 Crown Bay Support || On Track for Jan 21 || 2 || || Tom || dvhart || <br />
|-<br />
|| BSP || 2.6.37 Emenlow Support || On track for Jan 21 || 2 || || Tom || dvhart || <br />
|}<br />
<br />
=== Sprint E (closes Jan 28, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| rootless X|| rootless x server has better security than x server launched by root. MeeGo already enable this feature. it would be nice for Yocto to also enable it. || 2|| On track for Jan 28 || Saul / Ke || yuke|| enhancement<br />
|-<br />
|| Documentation Features|| Package report system|| finish major feature development and internal review [setup a package report system in an internal machine. We need push it publicly available. The basic features like search and report have been there. But there're still some enhancements in plan, to make it a fit place to feel Yocto metadata comfortably]|| 2|| Move to Sprint E || Jonathan || ktian1|| enhancement, was M2, Sprint E<br />
|-<br />
|| Distribution / components|| perl upgrade|| perl is the most cross un-friendly recipe pending upgrade. || 2|| Slipping due to Linaro layer, moves to end of Sprint E || Nitin|| Nitin Kamble|| enhancement<br />
|-<br />
|| Supported Targets|| Intel Platform Support|| Sandybridge|| 2|| Accept|| Tom|| davest|| Basic ECG support<br />
|-<br />
|| Distribution / components|| performance indicators|| define some indicators (boot time, footprint, build time, power, component benchmarks, etc.) and then collect them for tracking purpose. The result could be posted on the wiki site, and the initial indicators can be easy ones which can be easily retrieved from autobuilder or weekly qa report). This way we have a clear track about the healthy of the Yocto project, and also identify weak areas. We can include qemu targets and several representational boards as the targets. || 2|| Review|| Beth/Jiajun|| ktian1|| enhancement<br />
|-<br />
|| Tool Development and SDK Features|| SDK user workshop|| Have some developers sit down and use our tools to develop demo software for Yocto. || 2|| Review|| Jessica|| josh|| Enhancement<br />
|-<br />
|| Distribution / components|| Zypper/RPM|| Integration based on design from Sprint B|| 1|| On track for Jan28 || Mark/Qing|| sgw|| Functionality, was M2, Sprint E<br />
|-<br />
|| Kernel || Final linux-yocto_git.bb || With 2.6.37 kernel || 1 || || Bruce || dvhart ||<br />
|-<br />
|| Kernel || Final meta-linaro layer || || || || Darren || dvhart ||<br />
|-<br />
|| Kernel || Final meta-rt layer || || || || Darren || dvhart ||<br />
|-<br />
|| Kernel || Sandy Bridge || || 1 || || Tom || dvhart ||<br />
|}<br />
<br />
=== Sprint F (closes Feb 03 (THURSDAY), 11:59pm PDT -- pull request sent, initially reviewed) :: NOTE: China New Year Holiday ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Documentation|| ADT Reference Guide Draft out for review || Outline complete|| High|| WIP || Scott Rifenbark|| jzhang|| Documentation<br />
|-<br />
|| || || || || || || || <br />
|}<br />
<br />
== M4 (Feb 07 to Apr 15 -- Stabilize Complete Mar 18, Release Complete Apr 01, Contingency to Apr 15) ==<br />
<br />
This sprint is the [[Yocto Project v. 1.0 Release Cycle]].<br />
<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Documentation|| Migration chapter in the Poky Reference Manual|| This chapter would cover the four identified use-cases for migrating up to the most recent version of Yocto Project. Additionally, it would cover migration scenarios from other development systems. The chapter does not yet exist. The chapter has not been scoped outside of having a meeting that identified four use-cases that did not include migration from a development system outside of Yocto Project. It will take some more scoping time to cover those areas (a day or two). Again, I have no idea of the length. See earlier entries for standard industry writing estimates for software documentation|| Medium|| Not Started|| Scott Rifenbark|| 3-4 Weeks|| Documentation<br />
|-<br />
|| Documentation|| Yocto Project Development Guide|| This manual would be an over-arching document that frames the complete development cycle within Yocto Project. The idea here is that the document would be an umbrella document that spawned and referenced subsequent documents. The organization would be the first chapter overviewing the major development pieces such as recipe creation, building, debugging, publishing, fail-safing, back-door hook creation, etc. Scoping would be about two weeks and length would probably be about 40 pages. Overall development time would likely be a month of uniterruped time.|| Medium|| Not Started|| Scott Rifenbark|| 3 Weeks|| Documentation<br />
|-<br />
|| Validation|| Boottime/Performance Analysis|| Compare Yocto Project performance to other projects such as MeeGo|| 1|| Initial report on where we are by Feb 9 || Darren|| davest|| project commitment<br />
|-<br />
|| || Multilib Support|| Consider developing post-1.0 branch || 1|| to start in M4 || Richard|| ||<br />
|-<br />
|| Validation|| Alpha testing complete|| 4-5 internal developers unfamiliar with Yocto Project try to do a build and report on the experience and issues encountered|| 1|| Done by Feb 18 || Julie|| davest|| <br />
|-<br />
|| || || || || || || || <br />
|}<br />
<br />
== Features needed and to be put into sprints by assigned owners: ==<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || package config option enhancement|| there're several enhancements we may do here: * allow users setting specific config options (local or global) from external tool, such as poky image creator, instead of changing recipes manually. Need a mechanism to convert from variable assignments into exact config options (e.g. feature_${PN} = ""1"" -> ""--enable-feature""). Consequently dependency chain needs update with option status. * host contamination check. We have swabber to check host contamination, but I'm not sure whether it covers configuration phase. If not, this is one area to improve, as not ususually we see configure script checks host bits for available features * conditional option manipulation. In many recipes we enable/disable one option based on availability of other packages. Now this is done manually and not flexible. this should be made automatically though some new annotation to indicate condition, or just base_contains (not convenient: long line, need define distro features) || 2|| Review|| Richard/MarkH|| ktian1|| Enhancement<br />
|-<br />
|| Media|| Yocto Project Awareness Video|| This 2.5 minute video would introduce and describe the benefits of Yocto Project. The video would use entertaining animations that described concepts and benefits. The result would be suitable for YouTube, conferences, and the website. The production is called an "Epipheo" and will be created by Epipheo Studios. The engagement process has begun and the kick-off meeting will be soon. The PO is in place. Time for development is 10 weeks.|| High|| Kick-off Imminent|| Scott Rifenbark|| 10 Weeks|| Media<br />
|-<br />
|| Documentation|| Yocto Project Debugging Guide|| This would be a guide for the debugging and bug tracking process in Yocto Project. Originally, the thought was that we needed a Bugzilla User's Manual. However, since we don't own Bugzilla it doesn't make sense to produce documentation for it. Rather, we should document the process as it fits into the Yocto Project environment. Ideally, the manual would be a sub-manual that would be referenced and architected into the Yocto Project Development Guide. The manual has not been scoped and would take a week to scope. Again, I have no idea of the length. See the previous item for standard industry writing estimates for software documenation.|| Medium|| Not Started|| Scott Rifenbark|| 3-4 Weeks|| Documentation<br />
|-<br />
|| Website|| Yocto Project Website|| The 0.9 website is in place but needs updates. Items for consideration are the left-panel naviagation scheme, a contributions guidance page, color-scheming and theme (possibly).|| Medium|| Not Started|| Scott Rifenbark|| 1-2 Weeks|| Website<br />
|}<br />
<br />
== Features not believed to be needed in v1.0: ==<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || OpenEmbedded/Bitbake Upstreaming|| "We firstly need to review where we are and where OE is. We then need to make a plan about what we're going to push upstream and what we're not. I'd suggest when we're in PRC, we do a crash course in ""dealing with OE"" and then many dedicate a block of time (a week) where the distro team comes up with a patch set we then propose and get merged into OE. I'd like to find a couple of interested people to monitor OE more regularly and start a workflow of things between Poky/OE where appropriate. The key thing to remember is we need to keep the architectures compatible. The team is now at the point where I'm happy for them to actually try building OpenEmbedded and not worry about it tainting them! "|| 2|| Review|| || rpurdie|| Process<br />
|-<br />
|| Poky Features || Handle old versions in WORKDIR|| an incremental build directory may finally include many old versions WORKDIRS. It'll be good to have those old versions tracked in the cache, which can then either generate a report or allow selectively cleaning up an specific version WORKDIR. Or else it's difficult to figure it out when people want to keep the whole tmp directory but like to cleanup some old bits when disk usage is under pressure. If it's not easy to do in bitbake, perhaps some separate scripts would be also helpful || 3|| Review|| || ktian1|| Enhancement<br />
|-<br />
|| Poky Features || run bitbake w/o rebuilding the cache|| "sometimes it's useful to allow run bitbake w/o re-parsing recipes, if we know nothing metadata is changed. we can just allow reusing existing persistent cache. this is useful when people is debugging WORKDIR w/o metadata change. also sometimes ""bitbake -e"" is used frequently to check poky variable information. with existing cache, several seconds can be saved which are not negligible for a developer daily working on Yocto "|| 2|| Review|| || ktian1|| Enhancement<br />
|-<br />
|| Poky Features || parallel make improvement|| parallel make experience is not good, especially when bb threads and make threads are increased larger than 8. So far we either try to fix package makefile or mark the recipe as no parallel make, when build faiures are reported. But this greatly impacts user experience for a successfully continuous build process. Could we define a safe number we do want to support for 1.0 release? and then have our autobuilder, QA test, and developers cover that number immediately and fix any issues accordingly. Then the safe number can be suggested to the Yocto user || 2|| Review|| || ktian1|| Enhancement<br />
|-<br />
|| Poky Features || Dependency packages rebuild/clean|| It is a mechanism to rebulid or clean a package and all other packages which have build/runtime dependency on it. With this change, we can find potential influences of package upgrade to its related packages, which can make the incremental build more trustable. For example, if we upgrade a package to a new vesion which changes its API, this mechanism can easily find out the incompatibility to other packages which have dependency on it. || 2|| Review|| || dongxiao.xu|| Enhancement, replaced by checksum feature<br />
|-<br />
|| Distribution / components|| FOSSology|| This may be similar to License Update above, but start to use FOSSology to track licenses. || 2|| Review|| || sgw|| Hygiene<br />
|-<br />
|| Distribution / components|| Package Developer Tools|| Create a set of Init scripts template and then review our current init scripts and modify them to confirm to the template. || 2|| Review|| || sgw|| Easy of Use<br />
|-<br />
|| Distribution / components|| Package Website|| Complete the work the intern has started on generating the distro tracking information and get it out on the external site. || 2|| Review|| || sgw|| "Hygiene, duplicate of ""Package report system"""<br />
|-<br />
|| Distribution / components|| Bluetooth UI support|| Currently we have bluez package in poky, and we need to have a workable graphic user interface to connect/configure BT devices. One choice may be gnome-bluetooth-applet. || 3|| Review|| || dongxiao.xu|| enhancement<br />
|-<br />
|| Distribution / components|| Connman-gnome enhancement features|| Enable connman-gnome to support features like, WPA Enterprise connection, hidden SSID, etc. || 3|| Review|| || dongxiao.xu|| enhancement<br />
|-<br />
|| Distribution / components|| Java Running Environment support|| Since most embedded systems support java applications running in it, maybe we'd better consider supporting some kinds of JVMs(Embeded JVM). The JVM may not run by default, but user can launch it if running java applications. Compared with GTK/QT, java user number is not small too. || 3|| Review|| || criping|| enhancement<br />
|-<br />
|| Distribution / components|| create more use cases|| UPnP demo is one really good use case showing how Yocto is utilized to make real functionality. and we could create more to show how Yocto is easily adapted to real use cases. Those use cases can be either maintained as seperate demo layers in yocto repo, or in seperate branches for reference. We can also call for community's contribution on this which would make 1.0 full-fledged. Or else the newbies to Yocto may be in puzzle how our sample profiles can satisfy their requirements. || 2|| Review|| || ktian1|| enhancement<br />
|-<br />
|| Distribution / components|| i18n support || internationalization is an important system wide feature. Many component like font, locale affect the i18n. Yocto alreay has some i18n related package like pango, but so far did not consider i18n systematically. so this is place holder to systematically add i18n support. || 2|| Review|| || yuke/qing|| enhancement<br />
|-<br />
|| Distribution / components|| more demos || demos are a good way to educate, push the envelope, and at the same time tout the strengths of the platform. This item just records a current set of ideas from various sources which could/should be implemented: * face-recognition/face-finding, * robotic control/application of face-finding to 'camera-as-sensor' (hexbug demo), * others [tbd, add here]|| 2|| Review|| || tzanussi|| enhancement <br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer support for image-creator and needed yocto-metadata design||Come up design what need to be created as packages to support using "opkg install" for image-creator and needed yocto-metadata|| 2|| WIP, pending comments from RP regarding how to packaging metadata|| Jessica|| rpurdie|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer image-creator and needed poky-metadata support|| The poky build system will build packages for image-creator and needed poky-metadata, which the Yocto Installer will be able to use "opkg install" to install them|| 2|| Review|| Jessica|| rpurdie|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Provide qemu management UI|| In current eclipse plugin, QEMU settings are put together with project configuration. So we can only have limited settings. If we can have a separate QEMU management UI, the end user could firstly create a QEMU config, such as (env file of arch, image location, unfs or not, sato or lsb, mem size, disk size). And then he can launch a QEMU with a specific config. The dependency between project configuration and QEMU config will be resolved. After all QEMU has nothing to do project configuration. Need to careful review the UI to ensure minimal impact to testing matrix. || 3|| Review|| || criping|| "Enhancement, duplicate of ""Qemu mem/disk size can be adjusted"""<br />
|-<br />
|| Tool Development and SDK Features|| QT plugin For Eclipse|| Integrate QT Ecplise plugin and extend for Yocto Project || 3|| Review|| || jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Profiling/Trace GUI's|| We have a wealth of great tracing and profiling tools but the UI's for them are all extremely minimal and usually quite ugly. Would be great if we could compete with, or even better, Apple's offerings here. We have the technology! || 2|| Review|| || josh|| "Enhancement, duplicate of ""Tracing/Profiling Planning Complete"""<br />
|-<br />
|| Tool Development and SDK Features|| Other profiling tools|| Complete Tom's review of profiling tools and architecture || 2|| Review|| || josh|| "Enhancement, duplicate of ""Tracing/Profiling Planning Complete"""<br />
|-<br />
|| Tool Development and SDK Features|| Design next-gen tracing/profiling tools|| Yocto 1.0 will include all the essential existing tracing/profiling tools expected by users, and Josh has proposed a UI integration of all those tools as far as it's possible to do so. That level of integration, basically a 'plugin-level' integration is necessary and useful, but doesn't go far enough. A next-generation tracing tool would integrate at a much more fundamental level; if done properly, it would provide unmatched levels of power and usability to users, and would allow Yocto to distinguish itself in the embedded tracing/profiling space in a way also unmatched by any other distro/build-tool. The implementation would of course not be available for Yocto 1.0, but a coherent design, including prototypes, that could be taken to the community and implemented in a V 1.5 or 2.0 should be done in that time frame. || 1|| Review|| || tzanussi|| "Enhancement, duplicate of ""Tracing/Profiling Planning Complete"""<br />
|-<br />
|| Documentation Features|| Self Documentation of image contents|| "I'd like to see the -doc packages Poky builds being combined into some kind of large documentation index representing the collective API docs of the target being built. This can then be placed on a webserver and viewed over the web. We'd have a demonstration of this for a ""bitbake world"" target. Part of the idea here is to start making good use of the docs as if developers see this they might start writing better docs too. Aim is to lead the field :). There are a number of places poky packages disable doc generation due to missing tools so we'd need to add these so we can enable the doc generation. Many packages already have many docs though too. "|| 2|| Review|| || rpurdie|| enhancement<br />
|-<br />
|| Validation|| Testing Framework|| Add a framework for doing automated testing in the project|| 1|| Review|| || davest|| project commitment<br />
|-<br />
|| Validation|| more SDK builds on autobuilder|| enable more SDK related tests on autobuilder such as meta-ide-support, etc.|| 2|| Review|| || ktian1|| project commitment, addressed by test plan (?)<br />
|-<br />
|| Validation|| more people should try using SDK|| this may not be a feature, but a requirement. SDK including meta-toolchain is one key factor impacting user experience on Yocto. It's not enough to have only SDK team play with it|| 2|| Review|| || ktian1|| project commitment, addressed by test plan (?)<br />
|-<br />
|| Validation|| Unit Testing Framework|| Add a mechanism to bitbake to parse source packages that have unit tests and then execute them on the target|| 3|| Review|| || sgw|| "project commitment, duplicate of ""Testing Framework"""<br />
|-<br />
|| Validation|| Test Case open source|| Open source Yocto test cases with xml format|| 1|| Review|| || yyou|| "project commitment, duplicate of ""Testing Framework"""<br />
|}</div>Davesthttps://wiki.yoctoproject.org/wiki/index.php?title=Yocto_1.0_Schedule&diff=594Yocto 1.0 Schedule2011-01-25T01:38:14Z<p>Davest: /* Sprint E (closes Jan 28, 11:59pm PDT -- pull request sent, initially reviewed) */</p>
<hr />
<div>= v1.0 (release date: Apr 15, 2011) =<br />
----<br />
The detailed milestone map for v1.0 is as below. During the first week of each subsequent milestone past M1 we will have a demonstration of the previous milestone capabilities as well as a planning and design session for the current milestone.<br><br><br />
<br />
== M2 (Nov 08 to Dec 24 -- Dev Complete Dec 10, Stabilize Complete Dec 17, Release Complete Dec 24) ==<br />
=== Sprint A (closes Nov 12, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links''' <br />
|-<br />
|| Poky Features || Kernel interactive targets || To support incremental kernel development having the ability to run menuconfig (or xconfig, etc) directly is a common request. We'll need to add this for commercialization anyway. i.e. bitbake -c menuconfig. This fuctionality already exists. || 1 || Done || Richard || bruceashfield || Enhancement <br />
|-<br />
|| Distribution / components || Distro Audit: Upgrades Planned (Phase 1) || Complete plan for package upgrades in M2 || 1 || Done || Saul || || Continual Maintenance<br />
|-<br />
|| Validation || Runtime testing || Runtime testing of images as part of the autobuilder || 1 || Done || Jiajun/ScottG || rpurdie || project commitment<br />
|- <br />
|| || Poky Image Creator Wireframe/Interaction Plans Complete || || 1 || Done || Josh || ||<br />
|-<br />
|| || SDK Generator Interaction: Plans Complete || || 1 || Done || Jessica || ||<br />
|-<br />
|| || Tracing/Profiling Planning Complete || This needs to cover where we're at now, what we're missing and also propose the future enhancements that may be needed. M2 targets getting existing tools integrated and documented. F2f discussion n the future enhancements || || Done || Tom || ||<br />
|-<br />
|| || Swabber. (Still needs to be integrated into weekly build by default) || || 1 || Done || Josh || ||<br />
|-<br />
|| Build/Release || Release process documentation || || || Done || Beth || ||<br />
|-<br />
|| Validation || Test plan for v1.0 (to address any deficiencies in coverage from v0.9)|| || 1 || Done || Jiajun || ||<br />
|}<br />
<br />
=== Sprint B (closes Nov 19, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| Distro Audit: World Packages|| Audit world packages making sure it all build, making sure all are packages are required || 2|| Done || Saul|| sgw|| Hygiene<br />
|-<br />
|| Tool Development and SDK Features|| SDK Generator Installer UI|| Look at different ways of Installer UI (GTK+ and ncurses) seems none of them is the right choice, decide to go with script to implement all the functionalities of installer and later add UI part on top of it || 1||Done|| Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Customize sysroot setup || Add and test out "--sysroot" config option to cross compiler within Eclipse IDE || 1|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| SDK Generator Installer design revision|| Close all open questions regarding Yocto SDK Generator Installer function design and come up HLD || 1|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Distribution / components|| kernel version|| keeping 2.6.34 as a -stable kernel is the best option. I've also got a newer -devel tree that can be made available or made the default. || 3|| Done || Bruce|| bruceashfield|| enhancement<br />
|-<br />
|| || assign Yocto Project PM|| acquire and assign a program manager for Yocto Project|| || Done || DaveST|| || <br />
|-<br />
|| || assign Yocto Project Sys Admin|| || || Done || Saul|| || <br />
|-<br />
|| Tool Development and SDK Features|| oprofileUI|| Fixing various bugs of the oprofileUI to make it workable on big endian host.(i.e. ppc, mips) || 2 || Done || Jessica || lianhao.lu || Bug #382 / Bug #493<br />
|-<br />
|| Poky Feature|| SDK Version Control|| If we can expect that yocto SDK has lots of release in the future, we might need to consider SDK version control. Currently, every thing installed under /opt/poky which leads to things be overriden, we need to be able to use a scheme like /opt/poky-1.0, /opt/poky-2.0 to distiguish things. || 2|| Done || Josh|| jzhang|| Enhancement<br />
|-<br />
|| Kernel || Kernel plan complete || Flesh our kernel deliverables and add to Yocto 1.0 schedule || || Done|| Darren || dvhart ||<br />
|}<br />
<br />
=== Sprint C (closes Nov 26, 11:59pm PDT -- pull request sent, initially reviewed) :: NOTE: this is US Thanksgiving week ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| Distro Audit: Licence Checksums|| licence checksums || 1|| Done || Saul|| rpurdie|| Hygiene<br />
|-<br />
|| Poky Features || Performance Analysis Completed|| "I'd like someone to instrument a green release build, see where it spends time (hot/cold parsing time, individual task building time) and then compare this with our 0.9 release build. I'd also like to compare the disk usage between the two. Once we have a blame list we can then set about fixing it. Some things I know will come up: a) pseudo, b) checksums/signature code, c) exec() vs fork for executing tasks, d) task based prebuilds increasing disk usage, e) rpm dependency calculations, f) using rpm vs. ipk but I may be wrong and there may be others. We need numbers. "|| 1|| Done || Saul / Qing, Dongxiao|| rpurdie|| Enhancement<br />
|-<br />
|| Poky Features || environment variables for kernel builds|| switching a branch, or adding a configuration feature (and even changing the kernel repo) is often done during development of a BSP. Having some additional variables that are pass the bitbake environment scrub would be useful. i.e. KBRANCH=foo bitbake -c configure linux-yocto. This goes along with the other BSP bootstrapping suggestions. || 2|| Done || Bruce|| bruceashfield|| Enhancement<br />
|-<br />
|| Supported Targets|| ARM Platform Support|| Replace beagleboard with Beagleboard XM - decision || 2|| Done || Bruce|| alex|| Basic Yocto hardware support <br />
|-<br />
|| Distribution / components|| Security Process|| We need a dedicated person to scan and apply critical security updates to the distro. The MeeGo team already has a similar process with some scripts which may be leveraged. To complete the task, the process should be documented and a first pass over the metadata made to establish the current position on security. Any upgrades needed should be identified and a plan to address them should be in place but doesn't have to be implemented by this point.|| 1|| Done || ScottG|| ktian1|| enhancement<br />
|-<br />
|| Tool Development and SDK Features|| SDK Generator Installer Opkg repo design|| Come up a opkg repo design that will mimic the final Yocto package repo layout to be used by SDK Generator Installer to test against|| 2 || Done || Jessica || jzhang || <br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer tar creaion|| Create a Yocto Installer tar ball which contains Installer script and supported opkg component that will be used for installing other Yocto components|| 2 || Done || Jessica || jzhang || <br />
|-<br />
|| Documentation|| Kernel Framework Paper from WR|| The paper from WR needs to be re-written and then posted somewhere on the Yocto Project site. This will involve examiniation of the text and re-writing and formatting for presentation. Currently it is simply a text document. Completion time assuming uninterrupted time is one week.|| High|| Done || Scott Rifenbark|| 1 Week|| Documentation<br />
|-<br />
|| Documentation|| Poky Reference Manual|| This guide exists in the 0.9 form. The re-write of the text needs to be completed. So far, all the chapters have been rewritten but not re-posted on the site. Only the appendices remain for a text scrub. Time to complete this would be a week of uninterrupted time. Ideally, the manual would be a sub-manual that would be referenced and architected into the Yocto Project Development Guide.|| Medium|| Done|| Scott Rifenbark|| 1 Week|| Documentation<br />
|-<br />
|| Kernel || Initial meta-linaro layer || meta-linaro layer providing a kernel, tool-chain, and uboot loader. This deliverable is primarily to get the infrastructure in place and have a buildable kernel. Toolchain on best effort basis. || || Done || Darren || dvhart || Moderate risk of slippage due to holidays.<br />
|-<br />
|| Kernel || Tracing: blktrace and sysprof recipes || || || Done || Tom || dvhart ||<br />
|}<br />
<br />
=== Sprint D (closes Dec 3, 11:59pm PDT -- pull request sent, initially reviewed) :: NOTE: week of the F2F planning meeting ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Kernel || Kernel git branching structure revamped || || 1 || Done || Bruce || dvhart ||<br />
|-<br />
|| Kernel || Tunnel Creek (Crown Bay) || || 1 || Done || Tom || dvhart ||<br />
|}<br />
<br />
=== Sprint E (closes Dec 9 (THURSDAY), 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| Distro Audit: Upgrades Completed (Phase 1)|| Update to new versions as per the agreed plan for M2 from Sprint A|| 1|| Done || Saul|| rpurdie|| Continual Maintenance<br />
|-<br />
|| Distribution / components|| Distro Audit: Src Checksums|| Make sure all SRC_URI components have checksums too || 1|| Done || Saul|| rpurdie|| Hygiene<br />
|-<br />
|| Poky Features || enable KVM with qemu|| today all new Intel processors support VT, which are enabled on most desktop machines which are most frequently used build machine. with VT support, x86/x86-64 qemu target runs faster which is a good thing for emulation environment. This may require some qemu option tweaks and also poky-qemu script enhancement. || 2|| Done || Saul / Edwin|| ktian1|| Enhancement<br />
|-<br />
|| Kernel || New kernel recipes || dev, -devel, -custom || 3 || Done || Bruce || dvhart ||<br />
|-<br />
|| Swabber || Documentation for swabber || || 1 || Done || Alex || ||<br />
|-<br />
|| CCB || Defect triage process in public documented and implemented || || 1 || Done. Triage process is documented, out for review. || Saul || ||<br />
|}<br />
<br />
== M3 (Dec 20 to Feb 08 -- Dev Complete Feb 04, Stabilize Complete Feb 11, Release Complete Feb 18) ==<br />
=== Sprint A (closes Dec 24, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Kernel || Initial meta-rt layer || PREEMPT_RT kernel and related test-cases and benchmarks || 2 || Done by Jan 21 || Darren || dvhart || slipped out from M2<br />
|-<br />
|| Poky Features || Fetcher Overhaul Phase 1 - SRC_REV enhancement||<br />
* a) Add code in FetchData::__init__() which will check if the selected fetcher supports srcrev and the automatically call a function to set the src rev value instead of each fetcher doing this.\n <br />
* e) Break SRCREVINACTION deadlock. To do this, we need to start using a keyword for automatically increasing SRCREV, e.g. SRCREV = "AUTOINC". The actual revision can be injected into PV using SRCPV. If we do this there should no longer be a need of the deadlock; <br />
* k) Ensure that we only set __BB_DONT_CACHE when SRCREV = "AUTOREV". This may need a new method call for fetchers to tell whether they're "floating" or locked down.<br />
|| 1|| Done || Saul / Ke, RP|| rpurdie|| Enhancement, slipped out from M2<br />
|-<br />
|| Distribution / components|| Distro Audit Upgrades Planned (Phase 2)|| Complete plan for package upgrades in M2|| 1|| Done || Saul|| || Continual Maintenance<br />
|-<br />
|| Poky Features || Pseudo Performance || Implement the changes to bitbake based on pseudo's enable/disable switch|| 1|| done || Saul / Qing, Dongxiao || rpurdie|| Enhancement, slipped from M2 due to risk and not having Pseudo's change yet.<br />
|-<br />
|| Tool Development and SDK Features|| Fix the issue user target sysroot is owned by root || The ADT installer will use pseudo to extract user target sysroot which ended up owned by root, this need to be fixed || 1|| done || Jessica|| jzhang|| Cleanup <br />
|-<br />
|| Tool Development and SDK Features|| Eclipse poky tree interfacing (metadata file editor)|| Provide a metadata file editor with some syntax checking and keywords highlight capabilities|| 2|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| IDE Project templates|| Templates for various project types: Clutter GUI, Gtk+ GUI, to help developers get started quickly || 2|| Done || Jessica|| josh|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| push TCF/RSE patches upstream|| work with community to finish up our TCF terminal service, TCF/RSE integration remaining patches taken by upstream. Blocking issues including Eclipse Bug #327865 || 1|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Pseudo || Pseudo enhancement to enable on/off switch || || 1 || done || Mark || ||<br />
|-<br />
|| Pseudo || Bitbake enhancement for pseudo on/off switch || || 1 || done || Richard || ||<br />
|-<br />
|| bugzilla || Complete restructure of bugzilla categories || || 1 || done || Saul || ||<br />
|-<br />
|| Poky Features || Image creator ground work || Nomenclature determined, existing gui's bug fixed and backend work implemented || 1 || Done || Joshua || ||<br />
|-<br />
|| Kernel || Tracing: Initial SystemTap recipe || Works on x86 || 3 || Done || Tom || dvhart ||<br />
|-<br />
|| Distribution / components|| Distro Audit: Package Description/Summary completed|| Ensure DESCRIPTION/SUMMARY fields are all audited|| 2|| Done || Mark|| Mark|| Hygiene, was M2, Sprint B but missed window<br />
|-<br />
|| Distribution / components|| Zypper/RPM|| Small write-up of the problems we're having w/ Zypper and what we plan to do. (i.e. create a roadmap/design) - Includes rootfs generation - Package uprev/install/removal || 1 || Done || Mark/Qing || || was M2, Sprint B<br />
|-<br />
|| Distribution / components|| Distro Audit: Licence Checksums|| Make the licence checksums fatal if not present || 1|| Done || Saul|| rpurdie|| Hygiene, was M2, Sprint C<br />
|-<br />
|| Distribution / components|| push of all relevant Wind River patchs to Yocto (patch comparison)|| Ensure patches present to packages in WRS are also in Poky|| 1|| Done || Mark|| Mark|| was M2, Sprint C<br />
|-<br />
|| Poky Features || Performance Enhancement Completed || Initial changes to reduce disk space (sstate-build-*) || 1|| Done || Saul / Qing, Dongxiao || rpurdie|| Enhancement, was M2, Sprint E<br />
|-<br />
|| Distribution / components|| User specified qemu config support|| We'll provide user an edit box which allows advanced qemu user to specify arbitrary qemu configuration to meet their needs, which the poky-qemu scrip will just append the config list towards the end of the list of parameters to bring up qemu, it also expect the poky-qemu script to do some basic sanity check on the user specifications to catch the obvious mistake || 2|| Done || Saul / criping || criping|| enhancement, was M2, Sprint E<br />
|-<br />
|| Tool Development and SDK Features|| SDK Version Control support in SDK generator installer|| If we can expect that yocto SDK has lots of release in the future, we might need to consider SDK version control. Currently, if we un-tar the sdk, it will override the older version. It's not good for app developers since they might need the old version to do something. And also, maybe a finer installer than untar is preferred. Installer will tied to certain SDK version and the installation will go under /opt/poky-versionNo.|| 1|| Done || Jessica|| criping|| Enhancement-expect planning process by Jessica to handle this task. Was M2, Sprint E.<br />
|}<br />
<br />
=== Sprint B (closes Jan 07, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || Bitbake multi-threaded parsing|| Bitbake recipe parsing is currently single threaded. I want to make this multithreaded as the speedup would be nice. If I can only take a single task for myself for 1.0, I'm nominating this one as I enjoy this kind of thing and I have ideas on how to do it. || 1|| Done || Richard|| rpurdie|| Enhancement<br />
|-<br />
|| Distribution / components|| Lock in Kernel/Toolchain version|| Locked in 2.6.37 and gcc 4.5.1. Pending decision to move to 4.5.2 and Linaro || || Done || || Richard|| || <br />
|-<br />
|| Distribution / components|| License Update|| For each of the licences we support, I'd really like to have a licences directory with a copy of that license contained within. When it comes to deciding what a given LICENSE field means, this would be the reference. It also means we can include the licences a given image includes with the image. This continues to make our license handling world class and ahead of the field. || 2|| Done || Beth|| rpurdie|| Hygiene<br />
|-<br />
|| Tool Development and SDK Features|| Qemu configuration change|| Provice edit box for advanced user to specify qemu configurations|| 2|| Done || Jessica|| criping|| <br />
|-<br />
|| Tool Development and SDK Features|| Lock down Eclipse+CDT+TCF version|| Will use Eclipse Halo 3.6 || 1|| Done || Jessica|| || <br />
|-<br />
|| Demo|| Finalize on demo plans for v1.0 launch || || 1|| Done || Dave || || <br />
|-<br />
|| Release || Release plans for v1.0 launch || Fill out the M4 plan with the necessary release activities and timings || 1|| Done || Beth || || <br />
|-<br />
|| Poky Features || Basic image creator GUI || Functional UI missing some Advanced features || 1 || In replan || Joshua || || <br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer for SDK Generator Installation functions support||Detailed feature request can be found at: http://bugzilla.pokylinux.org/show_bug.cgi?id=589|| 1|| Done || Jessica|| rpurdie|| Enhancement<br />
|-<br />
|| Kernel || Tracing: trace-cmd python binding cleanup || || 3 || Done || Darren || dvhart ||<br />
|}<br />
<br />
=== Sprint C (closes Jan 14, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || kernel development layer|| The (correct) poky behaviour of building known revisions coupled with the fetcher requiring a BSP branch to already be present means that local modifications (and kernel source tree) are required for kernel development. I already have a layer that overrides/modifies the behaviour when added to the bblayers.conf and configured into an environment. This seems useful for more people to use. || 2|| Done || Bruce|| bruceashfield|| Enhancement, was M2, Sprint C<br />
|-<br />
|| Distribution / components|| Zypper/RPM|| RPM Uprev / Zypper Uprev [lets get to the latest versions]|| 1|| pull request by Jan 19; || Mark/Qing|| || was M2, Sprint C<br />
|-<br />
|| Supported Targets|| Intel Platform Support|| JasperForest|| 2|| Basic support in place; DPDK evaluation in process, overall BSP plan still TBD || Tom|| davest|| Basic ECG support (Moved from Sprint A)<br />
|-<br />
|| Tool Development and SDK Features|| Eclipse poky tree interfacing (git support)|| Use Eclipse git capability to install poky tree from git repo and able to interact with git repo at file level within Poky tree || 2|| Done || Jessica|| jzhang|| Enhancement<br />
<br />
|-<br />
|| Poky Features || Poky Image Creator|| A standalone application you can run which asks you to select a distro and machine, then presents a list of packages you can select. Once the selection is made, it goes off and bakes you an image which is then presented to you. Implementation wise, it should use the sstate packages, be a bitbake UI and use the usual poky bbclass files to do the image construction behind the scenes. || 1|| Re-plan || Joshua|| rpurdie|| Enhancement<br />
|-<br />
|| Distribution / components|| LSB Sanity|| execute LSB Test and improve passing rate and document failures with clear understanding|| 2|| Done || MarkH/Saul|| sgw|| Hygiene<br />
|-<br />
|| Tool Development and SDK Features|| Image creator integration with Eclipse || || 2|| replan|| Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Kernel || Tracing: perf trace marker support || This is from feedback to the new trace command. Ingo appears to have this nearly complete already. || 3 || Done || Darren || dvhart ||<br />
|-<br />
|| Cleanup || bitbake user experience error handling validation completed || || 2 || Done || Richard || ||<br />
|-<br />
|| Cleanup || variable scrub - ensure all metadata variables are documented || Script with a histogram of variable use done, identified 50 variables to document; Add task for actual documentation update is low on the list || 2 || Done || Scott/Darren || ||<br />
|-<br />
|| Kernel || Tracing: package kernelshark || || 3 || Done || Darren || dvhart ||<br />
|-<br />
|| Kernel || Tracing: tuna, oscillosope recipes || || 3 || Tom to discuss plan with Darren et al || Tom || dvhart ||<br />
|- <br />
|| BSP || Beagleboard XM Support || || 3 || Move to Sprint D || Darren || dvhart ||<br />
|}<br />
<br />
=== Sprint D (closes Jan 21, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Swabber || Complete review of swabber outputs || Move to M3 Sprint D || 1 || Move to M3 Sprint D || Alex || ||<br />
|-<br />
|| Poky Features || Fetcher Overhaul Phase 2 - API reorg||<br />
* f) Add a generic unpack funciton to __init__.py based on the unpack task in Poky ;<br />
* g) Split go() methods into the following steps: i) download() - do whatever transfer is necessary to get the sources locally ii) build_mirror_data() - generate any data that would be needed to construct a source mirror iii) unpack() - takes a directory as an argument of where to place extracted sources;<br />
The existing go() methods should be replaced with a set of calls to the above sections of functionality as appropriate in the individual fetchers. Some of these categories of function make no sense in certain fetchers, in which case they shouldn't need to implement them. Functions are only executed if the method is present.<br />
* h) Change Poky's unpack to call an unpack method in the fetchers.<br />
* i) Change Poky's fetch task to call a "download" method in the fetcher instead of go().<br />
|| 1|| Will land with phase 3 in Jan 21 || Saul / Ke, RP|| rpurdie|| Enhancement<br />
|-<br />
|| Poky Features || Fetcher Overhaul Phase 3 - git enhancement||<br />
* j) Optimize git fetcher for the new layout so for a git checkout, we clone the repository in download(), then unpack just does a clone with references to the original repo. <br />
* k) Ensure that we only set __BB_DONT_CACHE when SRCREV = "AUTOREV". This may need a new method call for fetchers to tell whether they're "floating" or locked down. <br />
* l) Add a new "BB_NO_NETWORK" variable which the fetchers check before peforming an operation which hits anything remote. This means adding in error messages about why network access is needed at various points (e.g. SRCREV = "AUTOREV" for a given recipe) <br />
* m) Add multiple branch/srcrev support for git fetcher. These would be of the form: git://somelocation/somerepo.git;name=ref1;branch=foo;name=ref2;branch=bar SRCREV_ref1 = "hash1" SRCREV_ref2 = "hash2" which would ensure both hash1 and hash2 were in the final repo. <br />
* n) Change git fetcher to default to git protocol instead of rsync<br />
|| 1|| Slipped to Sprint D || Saul / Ke, RP|| rpurdie|| Enhancement<br />
|-<br />
|| Poky Features || DSO linking changes|| "By the default the gcc linker will automatically link any dependant objects/libraries. ""Inherited"" linkages can cause issues, for example, where a shared object changes its dependencies but a program has come to rely on symbols from an implicitly linked library. Fedora implemented this change in F13, seems like it would be useful to have in Poky too. "|| 2|| On track for Jan 21 || Saul / Nitin || josh|| bug#516<br />
|-<br />
|| Distribution / components|| Distro Audit Documentation Output|| Audit package documentation output || 2|| Move to Sprint D due to libtool work || Saul / ScottG || rpurdie|| Hygiene<br />
|-<br />
|| Distribution / components|| Review & Fix Standards Tests|| Review the results from LTP, POSIX and asses the result, fix as appropriate and clearly document failures.|| 2|| a Plan to resolve final items to be sent to the m.l. by Jan 14 || Saul/Kevin || sgw|| Hygiene<br />
|-<br />
|| Poky Features || libtool sysroot option|| libtool 2.4 has a sysroot option. We should try and use it, see how it works and whether we can ditch some of our libtool hacks. || 1|| On track for Jan 21 || Saul / ScottG || rpurdie|| Enhancement<br />
|-<br />
|| Distribution / components|| MACHINE or Recipe specific sysroots|| Each machine should have its own sysroot. We'll probably have to split do_populate_sysroot into a two step process, creation of the package and than installtion of the package, which the installation of the package being made machine specific (put ${MACHINE} into ${STAMP} and bitbake should do that). Also allowing this to work per recipe would be desireable|| 1|| On track 21 || Saul / Dongxiao || rpurdie|| Hygiene<br />
|-<br />
|| Distribution / components|| Toolchain Bootstrap Process|| The toolchain as it bootstraps overwrites files like libc.so and libgcc.so in the sysroot directory which causes issues if you just try and rebuild part of the toolchain. Each step of the bootstrap process should use a separate sysroot. Once this is once, sstate file overwriting detection can be added and enabled. || 1|| Patches submitted for comment, slip to Sprint D || Saul / Dexuan || rpurdie|| Hygiene<br />
|-<br />
|| Documentation Features|| Package report system|| move to public server [setup a package report system in an internal machine. We need push it publicly available. The basic features like search and report have been there. But there're still some enhancements in plan, to make it a fit place to feel Yocto metadata comfortably]|| 2|| Move to Sprint E|| KevinT|| ktian1|| enhancement<br />
|-<br />
|| Distribution / components||Add headers and libraries to qemu images ||Since we'll be using qemu images as target sysroot, need to create a set of qemu images for minimal, sato, LSB that contains target header and libraries.|| 2|| Pending a discussion on Jan 18 || Saul ||jzhang|| Enhancement<br />
|-<br />
|| Distribution / components|| push of all relevant Wind River patchs to Yocto (patch comparison)|| Update any additional patches needed since M2.|| 1|| May be done by Jan 21, pending RPM stuff || Mark|| Mark|| <br />
|-<br />
|| Distribution / components|| mklibs|| mklibs is a tool to optimize size of [e]glibc for a perticular root file system image. It is useful to save disk space on small devices. || 2|| Push to Sprint E || Saul|| Nitin Kamble|| enhancement<br />
|-<br />
|| Poky Features || Performance Enhancement || reduce disk space (hardlink) || 1 || On track for Jan 21, pending RP review || Saul / Qing, Dongxiao || rpurdie || Enhancement<br />
|-<br />
|| Kernel || Tracing: perf trace scripting support || || 3 || Move to Sprint D; on track for Jan 21 || Tom || dvhart ||<br />
|-<br />
|| BSP || 2.6.37 Crown Bay Support || On Track for Jan 21 || 2 || || Tom || dvhart || <br />
|-<br />
|| BSP || 2.6.37 Emenlow Support || On track for Jan 21 || 2 || || Tom || dvhart || <br />
|}<br />
<br />
=== Sprint E (closes Jan 28, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| rootless X|| rootless x server has better security than x server launched by root. MeeGo already enable this feature. it would be nice for Yocto to also enable it. || 2|| On track for Jan 28 || Saul / Ke || yuke|| enhancement<br />
|-<br />
|| Documentation Features|| Package report system|| finish major feature development and internal review [setup a package report system in an internal machine. We need push it publicly available. The basic features like search and report have been there. But there're still some enhancements in plan, to make it a fit place to feel Yocto metadata comfortably]|| 2|| Move to Sprint E || Jonathan || ktian1|| enhancement, was M2, Sprint E<br />
|-<br />
|| Distribution / components|| perl upgrade|| perl is the most cross un-friendly recipe pending upgrade. || 2|| Slipping due to Linaro layer, moves to end of Sprint E || Nitin|| Nitin Kamble|| enhancement<br />
|-<br />
|| Supported Targets|| Intel Platform Support|| Sandybridge|| 2|| Accept|| Tom|| davest|| Basic ECG support<br />
|-<br />
|| Distribution / components|| performance indicators|| define some indicators (boot time, footprint, build time, power, component benchmarks, etc.) and then collect them for tracking purpose. The result could be posted on the wiki site, and the initial indicators can be easy ones which can be easily retrieved from autobuilder or weekly qa report). This way we have a clear track about the healthy of the Yocto project, and also identify weak areas. We can include qemu targets and several representational boards as the targets. || 2|| Review|| Beth/Jiajun|| ktian1|| enhancement<br />
|-<br />
|| Tool Development and SDK Features|| SDK user workshop|| Have some developers sit down and use our tools to develop demo software for Yocto. || 2|| Review|| Jessica|| josh|| Enhancement<br />
|-<br />
|| Distribution / components|| Zypper/RPM|| Integration based on design from Sprint B|| 1|| On track for Jan28 || Mark/Qing|| sgw|| Functionality, was M2, Sprint E<br />
|-<br />
|| Kernel || Final linux-yocto_git.bb || With 2.6.37 kernel || 1 || || Bruce || dvhart ||<br />
|-<br />
|| Kernel || Final meta-linaro layer || || || || Darren || dvhart ||<br />
|-<br />
|| Kernel || Final meta-rt layer || || || || Darren || dvhart ||<br />
|-<br />
|| Kernel || Sandy Bridge || || 1 || || Tom || dvhart ||<br />
|}<br />
<br />
=== Sprint F (closes Feb 03 (THURSDAY), 11:59pm PDT -- pull request sent, initially reviewed) :: NOTE: China New Year Holiday ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Documentation|| ADT Reference Guide Draft out for review || Outline complete|| High|| WIP || Scott Rifenbark|| jzhang|| Documentation<br />
|-<br />
|| || || || || || || || <br />
|}<br />
<br />
== M4 (Feb 07 to Apr 15 -- Stabilize Complete Mar 18, Release Complete Apr 01, Contingency to Apr 15) ==<br />
<br />
This sprint is the [[Yocto Project v. 1.0 Release Cycle]].<br />
<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Documentation|| Migration chapter in the Poky Reference Manual|| This chapter would cover the four identified use-cases for migrating up to the most recent version of Yocto Project. Additionally, it would cover migration scenarios from other development systems. The chapter does not yet exist. The chapter has not been scoped outside of having a meeting that identified four use-cases that did not include migration from a development system outside of Yocto Project. It will take some more scoping time to cover those areas (a day or two). Again, I have no idea of the length. See earlier entries for standard industry writing estimates for software documentation|| Medium|| Not Started|| Scott Rifenbark|| 3-4 Weeks|| Documentation<br />
|-<br />
|| Documentation|| Yocto Project Development Guide|| This manual would be an over-arching document that frames the complete development cycle within Yocto Project. The idea here is that the document would be an umbrella document that spawned and referenced subsequent documents. The organization would be the first chapter overviewing the major development pieces such as recipe creation, building, debugging, publishing, fail-safing, back-door hook creation, etc. Scoping would be about two weeks and length would probably be about 40 pages. Overall development time would likely be a month of uniterruped time.|| Medium|| Not Started|| Scott Rifenbark|| 3 Weeks|| Documentation<br />
|-<br />
|| Validation|| Boottime/Performance Analysis|| Compare Yocto Project performance to other projects such as MeeGo|| 1|| Initial report on where we are by Feb 9 || Darren|| davest|| project commitment<br />
|-<br />
|| || Multilib Support|| Consider developing post-1.0 branch || 1|| to start in M4 || Richard|| ||<br />
|-<br />
|| Validation|| Alpha testing complete|| 4-5 internal developers unfamiliar with Yocto Project try to do a build and report on the experience and issues encountered|| 1|| Done by Feb 18 || Julie|| davest|| <br />
|-<br />
|| || || || || || || || <br />
|}<br />
<br />
== Features needed and to be put into sprints by assigned owners: ==<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || package config option enhancement|| there're several enhancements we may do here: * allow users setting specific config options (local or global) from external tool, such as poky image creator, instead of changing recipes manually. Need a mechanism to convert from variable assignments into exact config options (e.g. feature_${PN} = ""1"" -> ""--enable-feature""). Consequently dependency chain needs update with option status. * host contamination check. We have swabber to check host contamination, but I'm not sure whether it covers configuration phase. If not, this is one area to improve, as not ususually we see configure script checks host bits for available features * conditional option manipulation. In many recipes we enable/disable one option based on availability of other packages. Now this is done manually and not flexible. this should be made automatically though some new annotation to indicate condition, or just base_contains (not convenient: long line, need define distro features) || 2|| Review|| Richard/MarkH|| ktian1|| Enhancement<br />
|-<br />
|| Media|| Yocto Project Awareness Video|| This 2.5 minute video would introduce and describe the benefits of Yocto Project. The video would use entertaining animations that described concepts and benefits. The result would be suitable for YouTube, conferences, and the website. The production is called an "Epipheo" and will be created by Epipheo Studios. The engagement process has begun and the kick-off meeting will be soon. The PO is in place. Time for development is 10 weeks.|| High|| Kick-off Imminent|| Scott Rifenbark|| 10 Weeks|| Media<br />
|-<br />
|| Documentation|| Yocto Project Debugging Guide|| This would be a guide for the debugging and bug tracking process in Yocto Project. Originally, the thought was that we needed a Bugzilla User's Manual. However, since we don't own Bugzilla it doesn't make sense to produce documentation for it. Rather, we should document the process as it fits into the Yocto Project environment. Ideally, the manual would be a sub-manual that would be referenced and architected into the Yocto Project Development Guide. The manual has not been scoped and would take a week to scope. Again, I have no idea of the length. See the previous item for standard industry writing estimates for software documenation.|| Medium|| Not Started|| Scott Rifenbark|| 3-4 Weeks|| Documentation<br />
|-<br />
|| Website|| Yocto Project Website|| The 0.9 website is in place but needs updates. Items for consideration are the left-panel naviagation scheme, a contributions guidance page, color-scheming and theme (possibly).|| Medium|| Not Started|| Scott Rifenbark|| 1-2 Weeks|| Website<br />
|}<br />
<br />
== Features not believed to be needed in v1.0: ==<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || OpenEmbedded/Bitbake Upstreaming|| "We firstly need to review where we are and where OE is. We then need to make a plan about what we're going to push upstream and what we're not. I'd suggest when we're in PRC, we do a crash course in ""dealing with OE"" and then many dedicate a block of time (a week) where the distro team comes up with a patch set we then propose and get merged into OE. I'd like to find a couple of interested people to monitor OE more regularly and start a workflow of things between Poky/OE where appropriate. The key thing to remember is we need to keep the architectures compatible. The team is now at the point where I'm happy for them to actually try building OpenEmbedded and not worry about it tainting them! "|| 2|| Review|| || rpurdie|| Process<br />
|-<br />
|| Poky Features || Handle old versions in WORKDIR|| an incremental build directory may finally include many old versions WORKDIRS. It'll be good to have those old versions tracked in the cache, which can then either generate a report or allow selectively cleaning up an specific version WORKDIR. Or else it's difficult to figure it out when people want to keep the whole tmp directory but like to cleanup some old bits when disk usage is under pressure. If it's not easy to do in bitbake, perhaps some separate scripts would be also helpful || 3|| Review|| || ktian1|| Enhancement<br />
|-<br />
|| Poky Features || run bitbake w/o rebuilding the cache|| "sometimes it's useful to allow run bitbake w/o re-parsing recipes, if we know nothing metadata is changed. we can just allow reusing existing persistent cache. this is useful when people is debugging WORKDIR w/o metadata change. also sometimes ""bitbake -e"" is used frequently to check poky variable information. with existing cache, several seconds can be saved which are not negligible for a developer daily working on Yocto "|| 2|| Review|| || ktian1|| Enhancement<br />
|-<br />
|| Poky Features || parallel make improvement|| parallel make experience is not good, especially when bb threads and make threads are increased larger than 8. So far we either try to fix package makefile or mark the recipe as no parallel make, when build faiures are reported. But this greatly impacts user experience for a successfully continuous build process. Could we define a safe number we do want to support for 1.0 release? and then have our autobuilder, QA test, and developers cover that number immediately and fix any issues accordingly. Then the safe number can be suggested to the Yocto user || 2|| Review|| || ktian1|| Enhancement<br />
|-<br />
|| Poky Features || Dependency packages rebuild/clean|| It is a mechanism to rebulid or clean a package and all other packages which have build/runtime dependency on it. With this change, we can find potential influences of package upgrade to its related packages, which can make the incremental build more trustable. For example, if we upgrade a package to a new vesion which changes its API, this mechanism can easily find out the incompatibility to other packages which have dependency on it. || 2|| Review|| || dongxiao.xu|| Enhancement, replaced by checksum feature<br />
|-<br />
|| Distribution / components|| FOSSology|| This may be similar to License Update above, but start to use FOSSology to track licenses. || 2|| Review|| || sgw|| Hygiene<br />
|-<br />
|| Distribution / components|| Package Developer Tools|| Create a set of Init scripts template and then review our current init scripts and modify them to confirm to the template. || 2|| Review|| || sgw|| Easy of Use<br />
|-<br />
|| Distribution / components|| Package Website|| Complete the work the intern has started on generating the distro tracking information and get it out on the external site. || 2|| Review|| || sgw|| "Hygiene, duplicate of ""Package report system"""<br />
|-<br />
|| Distribution / components|| Bluetooth UI support|| Currently we have bluez package in poky, and we need to have a workable graphic user interface to connect/configure BT devices. One choice may be gnome-bluetooth-applet. || 3|| Review|| || dongxiao.xu|| enhancement<br />
|-<br />
|| Distribution / components|| Connman-gnome enhancement features|| Enable connman-gnome to support features like, WPA Enterprise connection, hidden SSID, etc. || 3|| Review|| || dongxiao.xu|| enhancement<br />
|-<br />
|| Distribution / components|| Java Running Environment support|| Since most embedded systems support java applications running in it, maybe we'd better consider supporting some kinds of JVMs(Embeded JVM). The JVM may not run by default, but user can launch it if running java applications. Compared with GTK/QT, java user number is not small too. || 3|| Review|| || criping|| enhancement<br />
|-<br />
|| Distribution / components|| create more use cases|| UPnP demo is one really good use case showing how Yocto is utilized to make real functionality. and we could create more to show how Yocto is easily adapted to real use cases. Those use cases can be either maintained as seperate demo layers in yocto repo, or in seperate branches for reference. We can also call for community's contribution on this which would make 1.0 full-fledged. Or else the newbies to Yocto may be in puzzle how our sample profiles can satisfy their requirements. || 2|| Review|| || ktian1|| enhancement<br />
|-<br />
|| Distribution / components|| i18n support || internationalization is an important system wide feature. Many component like font, locale affect the i18n. Yocto alreay has some i18n related package like pango, but so far did not consider i18n systematically. so this is place holder to systematically add i18n support. || 2|| Review|| || yuke/qing|| enhancement<br />
|-<br />
|| Distribution / components|| more demos || demos are a good way to educate, push the envelope, and at the same time tout the strengths of the platform. This item just records a current set of ideas from various sources which could/should be implemented: * face-recognition/face-finding, * robotic control/application of face-finding to 'camera-as-sensor' (hexbug demo), * others [tbd, add here]|| 2|| Review|| || tzanussi|| enhancement <br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer support for image-creator and needed yocto-metadata design||Come up design what need to be created as packages to support using "opkg install" for image-creator and needed yocto-metadata|| 2|| WIP, pending comments from RP regarding how to packaging metadata|| Jessica|| rpurdie|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer image-creator and needed poky-metadata support|| The poky build system will build packages for image-creator and needed poky-metadata, which the Yocto Installer will be able to use "opkg install" to install them|| 2|| Review|| Jessica|| rpurdie|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Provide qemu management UI|| In current eclipse plugin, QEMU settings are put together with project configuration. So we can only have limited settings. If we can have a separate QEMU management UI, the end user could firstly create a QEMU config, such as (env file of arch, image location, unfs or not, sato or lsb, mem size, disk size). And then he can launch a QEMU with a specific config. The dependency between project configuration and QEMU config will be resolved. After all QEMU has nothing to do project configuration. Need to careful review the UI to ensure minimal impact to testing matrix. || 3|| Review|| || criping|| "Enhancement, duplicate of ""Qemu mem/disk size can be adjusted"""<br />
|-<br />
|| Tool Development and SDK Features|| QT plugin For Eclipse|| Integrate QT Ecplise plugin and extend for Yocto Project || 3|| Review|| || jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Profiling/Trace GUI's|| We have a wealth of great tracing and profiling tools but the UI's for them are all extremely minimal and usually quite ugly. Would be great if we could compete with, or even better, Apple's offerings here. We have the technology! || 2|| Review|| || josh|| "Enhancement, duplicate of ""Tracing/Profiling Planning Complete"""<br />
|-<br />
|| Tool Development and SDK Features|| Other profiling tools|| Complete Tom's review of profiling tools and architecture || 2|| Review|| || josh|| "Enhancement, duplicate of ""Tracing/Profiling Planning Complete"""<br />
|-<br />
|| Tool Development and SDK Features|| Design next-gen tracing/profiling tools|| Yocto 1.0 will include all the essential existing tracing/profiling tools expected by users, and Josh has proposed a UI integration of all those tools as far as it's possible to do so. That level of integration, basically a 'plugin-level' integration is necessary and useful, but doesn't go far enough. A next-generation tracing tool would integrate at a much more fundamental level; if done properly, it would provide unmatched levels of power and usability to users, and would allow Yocto to distinguish itself in the embedded tracing/profiling space in a way also unmatched by any other distro/build-tool. The implementation would of course not be available for Yocto 1.0, but a coherent design, including prototypes, that could be taken to the community and implemented in a V 1.5 or 2.0 should be done in that time frame. || 1|| Review|| || tzanussi|| "Enhancement, duplicate of ""Tracing/Profiling Planning Complete"""<br />
|-<br />
|| Documentation Features|| Self Documentation of image contents|| "I'd like to see the -doc packages Poky builds being combined into some kind of large documentation index representing the collective API docs of the target being built. This can then be placed on a webserver and viewed over the web. We'd have a demonstration of this for a ""bitbake world"" target. Part of the idea here is to start making good use of the docs as if developers see this they might start writing better docs too. Aim is to lead the field :). There are a number of places poky packages disable doc generation due to missing tools so we'd need to add these so we can enable the doc generation. Many packages already have many docs though too. "|| 2|| Review|| || rpurdie|| enhancement<br />
|-<br />
|| Validation|| Testing Framework|| Add a framework for doing automated testing in the project|| 1|| Review|| || davest|| project commitment<br />
|-<br />
|| Validation|| more SDK builds on autobuilder|| enable more SDK related tests on autobuilder such as meta-ide-support, etc.|| 2|| Review|| || ktian1|| project commitment, addressed by test plan (?)<br />
|-<br />
|| Validation|| more people should try using SDK|| this may not be a feature, but a requirement. SDK including meta-toolchain is one key factor impacting user experience on Yocto. It's not enough to have only SDK team play with it|| 2|| Review|| || ktian1|| project commitment, addressed by test plan (?)<br />
|-<br />
|| Validation|| Unit Testing Framework|| Add a mechanism to bitbake to parse source packages that have unit tests and then execute them on the target|| 3|| Review|| || sgw|| "project commitment, duplicate of ""Testing Framework"""<br />
|-<br />
|| Validation|| Test Case open source|| Open source Yocto test cases with xml format|| 1|| Review|| || yyou|| "project commitment, duplicate of ""Testing Framework"""<br />
|}</div>Davesthttps://wiki.yoctoproject.org/wiki/index.php?title=Yocto_1.0_Schedule&diff=593Yocto 1.0 Schedule2011-01-25T01:37:55Z<p>Davest: /* Sprint C (closes Jan 14, 11:59pm PDT -- pull request sent, initially reviewed) */</p>
<hr />
<div>= v1.0 (release date: Apr 15, 2011) =<br />
----<br />
The detailed milestone map for v1.0 is as below. During the first week of each subsequent milestone past M1 we will have a demonstration of the previous milestone capabilities as well as a planning and design session for the current milestone.<br><br><br />
<br />
== M2 (Nov 08 to Dec 24 -- Dev Complete Dec 10, Stabilize Complete Dec 17, Release Complete Dec 24) ==<br />
=== Sprint A (closes Nov 12, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links''' <br />
|-<br />
|| Poky Features || Kernel interactive targets || To support incremental kernel development having the ability to run menuconfig (or xconfig, etc) directly is a common request. We'll need to add this for commercialization anyway. i.e. bitbake -c menuconfig. This fuctionality already exists. || 1 || Done || Richard || bruceashfield || Enhancement <br />
|-<br />
|| Distribution / components || Distro Audit: Upgrades Planned (Phase 1) || Complete plan for package upgrades in M2 || 1 || Done || Saul || || Continual Maintenance<br />
|-<br />
|| Validation || Runtime testing || Runtime testing of images as part of the autobuilder || 1 || Done || Jiajun/ScottG || rpurdie || project commitment<br />
|- <br />
|| || Poky Image Creator Wireframe/Interaction Plans Complete || || 1 || Done || Josh || ||<br />
|-<br />
|| || SDK Generator Interaction: Plans Complete || || 1 || Done || Jessica || ||<br />
|-<br />
|| || Tracing/Profiling Planning Complete || This needs to cover where we're at now, what we're missing and also propose the future enhancements that may be needed. M2 targets getting existing tools integrated and documented. F2f discussion n the future enhancements || || Done || Tom || ||<br />
|-<br />
|| || Swabber. (Still needs to be integrated into weekly build by default) || || 1 || Done || Josh || ||<br />
|-<br />
|| Build/Release || Release process documentation || || || Done || Beth || ||<br />
|-<br />
|| Validation || Test plan for v1.0 (to address any deficiencies in coverage from v0.9)|| || 1 || Done || Jiajun || ||<br />
|}<br />
<br />
=== Sprint B (closes Nov 19, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| Distro Audit: World Packages|| Audit world packages making sure it all build, making sure all are packages are required || 2|| Done || Saul|| sgw|| Hygiene<br />
|-<br />
|| Tool Development and SDK Features|| SDK Generator Installer UI|| Look at different ways of Installer UI (GTK+ and ncurses) seems none of them is the right choice, decide to go with script to implement all the functionalities of installer and later add UI part on top of it || 1||Done|| Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Customize sysroot setup || Add and test out "--sysroot" config option to cross compiler within Eclipse IDE || 1|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| SDK Generator Installer design revision|| Close all open questions regarding Yocto SDK Generator Installer function design and come up HLD || 1|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Distribution / components|| kernel version|| keeping 2.6.34 as a -stable kernel is the best option. I've also got a newer -devel tree that can be made available or made the default. || 3|| Done || Bruce|| bruceashfield|| enhancement<br />
|-<br />
|| || assign Yocto Project PM|| acquire and assign a program manager for Yocto Project|| || Done || DaveST|| || <br />
|-<br />
|| || assign Yocto Project Sys Admin|| || || Done || Saul|| || <br />
|-<br />
|| Tool Development and SDK Features|| oprofileUI|| Fixing various bugs of the oprofileUI to make it workable on big endian host.(i.e. ppc, mips) || 2 || Done || Jessica || lianhao.lu || Bug #382 / Bug #493<br />
|-<br />
|| Poky Feature|| SDK Version Control|| If we can expect that yocto SDK has lots of release in the future, we might need to consider SDK version control. Currently, every thing installed under /opt/poky which leads to things be overriden, we need to be able to use a scheme like /opt/poky-1.0, /opt/poky-2.0 to distiguish things. || 2|| Done || Josh|| jzhang|| Enhancement<br />
|-<br />
|| Kernel || Kernel plan complete || Flesh our kernel deliverables and add to Yocto 1.0 schedule || || Done|| Darren || dvhart ||<br />
|}<br />
<br />
=== Sprint C (closes Nov 26, 11:59pm PDT -- pull request sent, initially reviewed) :: NOTE: this is US Thanksgiving week ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| Distro Audit: Licence Checksums|| licence checksums || 1|| Done || Saul|| rpurdie|| Hygiene<br />
|-<br />
|| Poky Features || Performance Analysis Completed|| "I'd like someone to instrument a green release build, see where it spends time (hot/cold parsing time, individual task building time) and then compare this with our 0.9 release build. I'd also like to compare the disk usage between the two. Once we have a blame list we can then set about fixing it. Some things I know will come up: a) pseudo, b) checksums/signature code, c) exec() vs fork for executing tasks, d) task based prebuilds increasing disk usage, e) rpm dependency calculations, f) using rpm vs. ipk but I may be wrong and there may be others. We need numbers. "|| 1|| Done || Saul / Qing, Dongxiao|| rpurdie|| Enhancement<br />
|-<br />
|| Poky Features || environment variables for kernel builds|| switching a branch, or adding a configuration feature (and even changing the kernel repo) is often done during development of a BSP. Having some additional variables that are pass the bitbake environment scrub would be useful. i.e. KBRANCH=foo bitbake -c configure linux-yocto. This goes along with the other BSP bootstrapping suggestions. || 2|| Done || Bruce|| bruceashfield|| Enhancement<br />
|-<br />
|| Supported Targets|| ARM Platform Support|| Replace beagleboard with Beagleboard XM - decision || 2|| Done || Bruce|| alex|| Basic Yocto hardware support <br />
|-<br />
|| Distribution / components|| Security Process|| We need a dedicated person to scan and apply critical security updates to the distro. The MeeGo team already has a similar process with some scripts which may be leveraged. To complete the task, the process should be documented and a first pass over the metadata made to establish the current position on security. Any upgrades needed should be identified and a plan to address them should be in place but doesn't have to be implemented by this point.|| 1|| Done || ScottG|| ktian1|| enhancement<br />
|-<br />
|| Tool Development and SDK Features|| SDK Generator Installer Opkg repo design|| Come up a opkg repo design that will mimic the final Yocto package repo layout to be used by SDK Generator Installer to test against|| 2 || Done || Jessica || jzhang || <br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer tar creaion|| Create a Yocto Installer tar ball which contains Installer script and supported opkg component that will be used for installing other Yocto components|| 2 || Done || Jessica || jzhang || <br />
|-<br />
|| Documentation|| Kernel Framework Paper from WR|| The paper from WR needs to be re-written and then posted somewhere on the Yocto Project site. This will involve examiniation of the text and re-writing and formatting for presentation. Currently it is simply a text document. Completion time assuming uninterrupted time is one week.|| High|| Done || Scott Rifenbark|| 1 Week|| Documentation<br />
|-<br />
|| Documentation|| Poky Reference Manual|| This guide exists in the 0.9 form. The re-write of the text needs to be completed. So far, all the chapters have been rewritten but not re-posted on the site. Only the appendices remain for a text scrub. Time to complete this would be a week of uninterrupted time. Ideally, the manual would be a sub-manual that would be referenced and architected into the Yocto Project Development Guide.|| Medium|| Done|| Scott Rifenbark|| 1 Week|| Documentation<br />
|-<br />
|| Kernel || Initial meta-linaro layer || meta-linaro layer providing a kernel, tool-chain, and uboot loader. This deliverable is primarily to get the infrastructure in place and have a buildable kernel. Toolchain on best effort basis. || || Done || Darren || dvhart || Moderate risk of slippage due to holidays.<br />
|-<br />
|| Kernel || Tracing: blktrace and sysprof recipes || || || Done || Tom || dvhart ||<br />
|}<br />
<br />
=== Sprint D (closes Dec 3, 11:59pm PDT -- pull request sent, initially reviewed) :: NOTE: week of the F2F planning meeting ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Kernel || Kernel git branching structure revamped || || 1 || Done || Bruce || dvhart ||<br />
|-<br />
|| Kernel || Tunnel Creek (Crown Bay) || || 1 || Done || Tom || dvhart ||<br />
|}<br />
<br />
=== Sprint E (closes Dec 9 (THURSDAY), 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| Distro Audit: Upgrades Completed (Phase 1)|| Update to new versions as per the agreed plan for M2 from Sprint A|| 1|| Done || Saul|| rpurdie|| Continual Maintenance<br />
|-<br />
|| Distribution / components|| Distro Audit: Src Checksums|| Make sure all SRC_URI components have checksums too || 1|| Done || Saul|| rpurdie|| Hygiene<br />
|-<br />
|| Poky Features || enable KVM with qemu|| today all new Intel processors support VT, which are enabled on most desktop machines which are most frequently used build machine. with VT support, x86/x86-64 qemu target runs faster which is a good thing for emulation environment. This may require some qemu option tweaks and also poky-qemu script enhancement. || 2|| Done || Saul / Edwin|| ktian1|| Enhancement<br />
|-<br />
|| Kernel || New kernel recipes || dev, -devel, -custom || 3 || Done || Bruce || dvhart ||<br />
|-<br />
|| Swabber || Documentation for swabber || || 1 || Done || Alex || ||<br />
|-<br />
|| CCB || Defect triage process in public documented and implemented || || 1 || Done. Triage process is documented, out for review. || Saul || ||<br />
|}<br />
<br />
== M3 (Dec 20 to Feb 08 -- Dev Complete Feb 04, Stabilize Complete Feb 11, Release Complete Feb 18) ==<br />
=== Sprint A (closes Dec 24, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Kernel || Initial meta-rt layer || PREEMPT_RT kernel and related test-cases and benchmarks || 2 || Done by Jan 21 || Darren || dvhart || slipped out from M2<br />
|-<br />
|| Poky Features || Fetcher Overhaul Phase 1 - SRC_REV enhancement||<br />
* a) Add code in FetchData::__init__() which will check if the selected fetcher supports srcrev and the automatically call a function to set the src rev value instead of each fetcher doing this.\n <br />
* e) Break SRCREVINACTION deadlock. To do this, we need to start using a keyword for automatically increasing SRCREV, e.g. SRCREV = "AUTOINC". The actual revision can be injected into PV using SRCPV. If we do this there should no longer be a need of the deadlock; <br />
* k) Ensure that we only set __BB_DONT_CACHE when SRCREV = "AUTOREV". This may need a new method call for fetchers to tell whether they're "floating" or locked down.<br />
|| 1|| Done || Saul / Ke, RP|| rpurdie|| Enhancement, slipped out from M2<br />
|-<br />
|| Distribution / components|| Distro Audit Upgrades Planned (Phase 2)|| Complete plan for package upgrades in M2|| 1|| Done || Saul|| || Continual Maintenance<br />
|-<br />
|| Poky Features || Pseudo Performance || Implement the changes to bitbake based on pseudo's enable/disable switch|| 1|| done || Saul / Qing, Dongxiao || rpurdie|| Enhancement, slipped from M2 due to risk and not having Pseudo's change yet.<br />
|-<br />
|| Tool Development and SDK Features|| Fix the issue user target sysroot is owned by root || The ADT installer will use pseudo to extract user target sysroot which ended up owned by root, this need to be fixed || 1|| done || Jessica|| jzhang|| Cleanup <br />
|-<br />
|| Tool Development and SDK Features|| Eclipse poky tree interfacing (metadata file editor)|| Provide a metadata file editor with some syntax checking and keywords highlight capabilities|| 2|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| IDE Project templates|| Templates for various project types: Clutter GUI, Gtk+ GUI, to help developers get started quickly || 2|| Done || Jessica|| josh|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| push TCF/RSE patches upstream|| work with community to finish up our TCF terminal service, TCF/RSE integration remaining patches taken by upstream. Blocking issues including Eclipse Bug #327865 || 1|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Pseudo || Pseudo enhancement to enable on/off switch || || 1 || done || Mark || ||<br />
|-<br />
|| Pseudo || Bitbake enhancement for pseudo on/off switch || || 1 || done || Richard || ||<br />
|-<br />
|| bugzilla || Complete restructure of bugzilla categories || || 1 || done || Saul || ||<br />
|-<br />
|| Poky Features || Image creator ground work || Nomenclature determined, existing gui's bug fixed and backend work implemented || 1 || Done || Joshua || ||<br />
|-<br />
|| Kernel || Tracing: Initial SystemTap recipe || Works on x86 || 3 || Done || Tom || dvhart ||<br />
|-<br />
|| Distribution / components|| Distro Audit: Package Description/Summary completed|| Ensure DESCRIPTION/SUMMARY fields are all audited|| 2|| Done || Mark|| Mark|| Hygiene, was M2, Sprint B but missed window<br />
|-<br />
|| Distribution / components|| Zypper/RPM|| Small write-up of the problems we're having w/ Zypper and what we plan to do. (i.e. create a roadmap/design) - Includes rootfs generation - Package uprev/install/removal || 1 || Done || Mark/Qing || || was M2, Sprint B<br />
|-<br />
|| Distribution / components|| Distro Audit: Licence Checksums|| Make the licence checksums fatal if not present || 1|| Done || Saul|| rpurdie|| Hygiene, was M2, Sprint C<br />
|-<br />
|| Distribution / components|| push of all relevant Wind River patchs to Yocto (patch comparison)|| Ensure patches present to packages in WRS are also in Poky|| 1|| Done || Mark|| Mark|| was M2, Sprint C<br />
|-<br />
|| Poky Features || Performance Enhancement Completed || Initial changes to reduce disk space (sstate-build-*) || 1|| Done || Saul / Qing, Dongxiao || rpurdie|| Enhancement, was M2, Sprint E<br />
|-<br />
|| Distribution / components|| User specified qemu config support|| We'll provide user an edit box which allows advanced qemu user to specify arbitrary qemu configuration to meet their needs, which the poky-qemu scrip will just append the config list towards the end of the list of parameters to bring up qemu, it also expect the poky-qemu script to do some basic sanity check on the user specifications to catch the obvious mistake || 2|| Done || Saul / criping || criping|| enhancement, was M2, Sprint E<br />
|-<br />
|| Tool Development and SDK Features|| SDK Version Control support in SDK generator installer|| If we can expect that yocto SDK has lots of release in the future, we might need to consider SDK version control. Currently, if we un-tar the sdk, it will override the older version. It's not good for app developers since they might need the old version to do something. And also, maybe a finer installer than untar is preferred. Installer will tied to certain SDK version and the installation will go under /opt/poky-versionNo.|| 1|| Done || Jessica|| criping|| Enhancement-expect planning process by Jessica to handle this task. Was M2, Sprint E.<br />
|}<br />
<br />
=== Sprint B (closes Jan 07, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || Bitbake multi-threaded parsing|| Bitbake recipe parsing is currently single threaded. I want to make this multithreaded as the speedup would be nice. If I can only take a single task for myself for 1.0, I'm nominating this one as I enjoy this kind of thing and I have ideas on how to do it. || 1|| Done || Richard|| rpurdie|| Enhancement<br />
|-<br />
|| Distribution / components|| Lock in Kernel/Toolchain version|| Locked in 2.6.37 and gcc 4.5.1. Pending decision to move to 4.5.2 and Linaro || || Done || || Richard|| || <br />
|-<br />
|| Distribution / components|| License Update|| For each of the licences we support, I'd really like to have a licences directory with a copy of that license contained within. When it comes to deciding what a given LICENSE field means, this would be the reference. It also means we can include the licences a given image includes with the image. This continues to make our license handling world class and ahead of the field. || 2|| Done || Beth|| rpurdie|| Hygiene<br />
|-<br />
|| Tool Development and SDK Features|| Qemu configuration change|| Provice edit box for advanced user to specify qemu configurations|| 2|| Done || Jessica|| criping|| <br />
|-<br />
|| Tool Development and SDK Features|| Lock down Eclipse+CDT+TCF version|| Will use Eclipse Halo 3.6 || 1|| Done || Jessica|| || <br />
|-<br />
|| Demo|| Finalize on demo plans for v1.0 launch || || 1|| Done || Dave || || <br />
|-<br />
|| Release || Release plans for v1.0 launch || Fill out the M4 plan with the necessary release activities and timings || 1|| Done || Beth || || <br />
|-<br />
|| Poky Features || Basic image creator GUI || Functional UI missing some Advanced features || 1 || In replan || Joshua || || <br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer for SDK Generator Installation functions support||Detailed feature request can be found at: http://bugzilla.pokylinux.org/show_bug.cgi?id=589|| 1|| Done || Jessica|| rpurdie|| Enhancement<br />
|-<br />
|| Kernel || Tracing: trace-cmd python binding cleanup || || 3 || Done || Darren || dvhart ||<br />
|}<br />
<br />
=== Sprint C (closes Jan 14, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || kernel development layer|| The (correct) poky behaviour of building known revisions coupled with the fetcher requiring a BSP branch to already be present means that local modifications (and kernel source tree) are required for kernel development. I already have a layer that overrides/modifies the behaviour when added to the bblayers.conf and configured into an environment. This seems useful for more people to use. || 2|| Done || Bruce|| bruceashfield|| Enhancement, was M2, Sprint C<br />
|-<br />
|| Distribution / components|| Zypper/RPM|| RPM Uprev / Zypper Uprev [lets get to the latest versions]|| 1|| pull request by Jan 19; || Mark/Qing|| || was M2, Sprint C<br />
|-<br />
|| Supported Targets|| Intel Platform Support|| JasperForest|| 2|| Basic support in place; DPDK evaluation in process, overall BSP plan still TBD || Tom|| davest|| Basic ECG support (Moved from Sprint A)<br />
|-<br />
|| Tool Development and SDK Features|| Eclipse poky tree interfacing (git support)|| Use Eclipse git capability to install poky tree from git repo and able to interact with git repo at file level within Poky tree || 2|| Done || Jessica|| jzhang|| Enhancement<br />
<br />
|-<br />
|| Poky Features || Poky Image Creator|| A standalone application you can run which asks you to select a distro and machine, then presents a list of packages you can select. Once the selection is made, it goes off and bakes you an image which is then presented to you. Implementation wise, it should use the sstate packages, be a bitbake UI and use the usual poky bbclass files to do the image construction behind the scenes. || 1|| Re-plan || Joshua|| rpurdie|| Enhancement<br />
|-<br />
|| Distribution / components|| LSB Sanity|| execute LSB Test and improve passing rate and document failures with clear understanding|| 2|| Done || MarkH/Saul|| sgw|| Hygiene<br />
|-<br />
|| Tool Development and SDK Features|| Image creator integration with Eclipse || || 2|| replan|| Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Kernel || Tracing: perf trace marker support || This is from feedback to the new trace command. Ingo appears to have this nearly complete already. || 3 || Done || Darren || dvhart ||<br />
|-<br />
|| Cleanup || bitbake user experience error handling validation completed || || 2 || Done || Richard || ||<br />
|-<br />
|| Cleanup || variable scrub - ensure all metadata variables are documented || Script with a histogram of variable use done, identified 50 variables to document; Add task for actual documentation update is low on the list || 2 || Done || Scott/Darren || ||<br />
|-<br />
|| Kernel || Tracing: package kernelshark || || 3 || Done || Darren || dvhart ||<br />
|-<br />
|| Kernel || Tracing: tuna, oscillosope recipes || || 3 || Tom to discuss plan with Darren et al || Tom || dvhart ||<br />
|- <br />
|| BSP || Beagleboard XM Support || || 3 || Move to Sprint D || Darren || dvhart ||<br />
|}<br />
<br />
=== Sprint D (closes Jan 21, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Swabber || Complete review of swabber outputs || Move to M3 Sprint D || 1 || Move to M3 Sprint D || Alex || ||<br />
|-<br />
|| Poky Features || Fetcher Overhaul Phase 2 - API reorg||<br />
* f) Add a generic unpack funciton to __init__.py based on the unpack task in Poky ;<br />
* g) Split go() methods into the following steps: i) download() - do whatever transfer is necessary to get the sources locally ii) build_mirror_data() - generate any data that would be needed to construct a source mirror iii) unpack() - takes a directory as an argument of where to place extracted sources;<br />
The existing go() methods should be replaced with a set of calls to the above sections of functionality as appropriate in the individual fetchers. Some of these categories of function make no sense in certain fetchers, in which case they shouldn't need to implement them. Functions are only executed if the method is present.<br />
* h) Change Poky's unpack to call an unpack method in the fetchers.<br />
* i) Change Poky's fetch task to call a "download" method in the fetcher instead of go().<br />
|| 1|| Will land with phase 3 in Jan 21 || Saul / Ke, RP|| rpurdie|| Enhancement<br />
|-<br />
|| Poky Features || Fetcher Overhaul Phase 3 - git enhancement||<br />
* j) Optimize git fetcher for the new layout so for a git checkout, we clone the repository in download(), then unpack just does a clone with references to the original repo. <br />
* k) Ensure that we only set __BB_DONT_CACHE when SRCREV = "AUTOREV". This may need a new method call for fetchers to tell whether they're "floating" or locked down. <br />
* l) Add a new "BB_NO_NETWORK" variable which the fetchers check before peforming an operation which hits anything remote. This means adding in error messages about why network access is needed at various points (e.g. SRCREV = "AUTOREV" for a given recipe) <br />
* m) Add multiple branch/srcrev support for git fetcher. These would be of the form: git://somelocation/somerepo.git;name=ref1;branch=foo;name=ref2;branch=bar SRCREV_ref1 = "hash1" SRCREV_ref2 = "hash2" which would ensure both hash1 and hash2 were in the final repo. <br />
* n) Change git fetcher to default to git protocol instead of rsync<br />
|| 1|| Slipped to Sprint D || Saul / Ke, RP|| rpurdie|| Enhancement<br />
|-<br />
|| Poky Features || DSO linking changes|| "By the default the gcc linker will automatically link any dependant objects/libraries. ""Inherited"" linkages can cause issues, for example, where a shared object changes its dependencies but a program has come to rely on symbols from an implicitly linked library. Fedora implemented this change in F13, seems like it would be useful to have in Poky too. "|| 2|| On track for Jan 21 || Saul / Nitin || josh|| bug#516<br />
|-<br />
|| Distribution / components|| Distro Audit Documentation Output|| Audit package documentation output || 2|| Move to Sprint D due to libtool work || Saul / ScottG || rpurdie|| Hygiene<br />
|-<br />
|| Distribution / components|| Review & Fix Standards Tests|| Review the results from LTP, POSIX and asses the result, fix as appropriate and clearly document failures.|| 2|| a Plan to resolve final items to be sent to the m.l. by Jan 14 || Saul/Kevin || sgw|| Hygiene<br />
|-<br />
|| Poky Features || libtool sysroot option|| libtool 2.4 has a sysroot option. We should try and use it, see how it works and whether we can ditch some of our libtool hacks. || 1|| On track for Jan 21 || Saul / ScottG || rpurdie|| Enhancement<br />
|-<br />
|| Distribution / components|| MACHINE or Recipe specific sysroots|| Each machine should have its own sysroot. We'll probably have to split do_populate_sysroot into a two step process, creation of the package and than installtion of the package, which the installation of the package being made machine specific (put ${MACHINE} into ${STAMP} and bitbake should do that). Also allowing this to work per recipe would be desireable|| 1|| On track 21 || Saul / Dongxiao || rpurdie|| Hygiene<br />
|-<br />
|| Distribution / components|| Toolchain Bootstrap Process|| The toolchain as it bootstraps overwrites files like libc.so and libgcc.so in the sysroot directory which causes issues if you just try and rebuild part of the toolchain. Each step of the bootstrap process should use a separate sysroot. Once this is once, sstate file overwriting detection can be added and enabled. || 1|| Patches submitted for comment, slip to Sprint D || Saul / Dexuan || rpurdie|| Hygiene<br />
|-<br />
|| Documentation Features|| Package report system|| move to public server [setup a package report system in an internal machine. We need push it publicly available. The basic features like search and report have been there. But there're still some enhancements in plan, to make it a fit place to feel Yocto metadata comfortably]|| 2|| Move to Sprint E|| KevinT|| ktian1|| enhancement<br />
|-<br />
|| Distribution / components||Add headers and libraries to qemu images ||Since we'll be using qemu images as target sysroot, need to create a set of qemu images for minimal, sato, LSB that contains target header and libraries.|| 2|| Pending a discussion on Jan 18 || Saul ||jzhang|| Enhancement<br />
|-<br />
|| Distribution / components|| push of all relevant Wind River patchs to Yocto (patch comparison)|| Update any additional patches needed since M2.|| 1|| May be done by Jan 21, pending RPM stuff || Mark|| Mark|| <br />
|-<br />
|| Distribution / components|| mklibs|| mklibs is a tool to optimize size of [e]glibc for a perticular root file system image. It is useful to save disk space on small devices. || 2|| Push to Sprint E || Saul|| Nitin Kamble|| enhancement<br />
|-<br />
|| Poky Features || Performance Enhancement || reduce disk space (hardlink) || 1 || On track for Jan 21, pending RP review || Saul / Qing, Dongxiao || rpurdie || Enhancement<br />
|-<br />
|| Kernel || Tracing: perf trace scripting support || || 3 || Move to Sprint D; on track for Jan 21 || Tom || dvhart ||<br />
|-<br />
|| BSP || 2.6.37 Crown Bay Support || On Track for Jan 21 || 2 || || Tom || dvhart || <br />
|-<br />
|| BSP || 2.6.37 Emenlow Support || On track for Jan 21 || 2 || || Tom || dvhart || <br />
|}<br />
<br />
=== Sprint E (closes Jan 28, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| rootless X|| rootless x server has better security than x server launched by root. MeeGo already enable this feature. it would be nice for Yocto to also enable it. || 2|| On track for Jan 28 || Saul / Ke || yuke|| enhancement<br />
|-<br />
|| Documentation Features|| Package report system|| finish major feature development and internal review [setup a package report system in an internal machine. We need push it publicly available. The basic features like search and report have been there. But there're still some enhancements in plan, to make it a fit place to feel Yocto metadata comfortably]|| 2|| Move to Sprint E || Jonathan || ktian1|| enhancement, was M2, Sprint E<br />
|-<br />
|| Distribution / components|| perl upgrade|| perl is the most cross un-friendly recipe pending upgrade. || 2|| Slipping due to Linaro layer, moves to end of Sprint E || Nitin|| Nitin Kamble|| enhancement<br />
|-<br />
|| Supported Targets|| Intel Platform Support|| Sandybridge|| 2|| Accept|| Tom|| davest|| Basic ECG support<br />
|-<br />
|| Distribution / components|| performance indicators|| define some indicators (boot time, footprint, build time, power, component benchmarks, etc.) and then collect them for tracking purpose. The result could be posted on the wiki site, and the initial indicators can be easy ones which can be easily retrieved from autobuilder or weekly qa report). This way we have a clear track about the healthy of the Yocto project, and also identify weak areas. We can include qemu targets and several representational boards as the targets. || 2|| Review|| Beth/Jiajun|| ktian1|| enhancement<br />
|-<br />
|| Tool Development and SDK Features|| SDK user workshop|| Have some developers sit down and use our tools to develop demo software for Yocto. || 2|| Review|| Jessica|| josh|| Enhancement<br />
|-<br />
|| Kernel || Final linux-yocto_git.bb || With 2.6.37 kernel || 1 || || Bruce || dvhart ||<br />
|-<br />
|| Kernel || Final meta-linaro layer || || || || Darren || dvhart ||<br />
|-<br />
|| Kernel || Final meta-rt layer || || || || Darren || dvhart ||<br />
|-<br />
|| Kernel || Sandy Bridge || || 1 || || Tom || dvhart ||<br />
|}<br />
<br />
=== Sprint F (closes Feb 03 (THURSDAY), 11:59pm PDT -- pull request sent, initially reviewed) :: NOTE: China New Year Holiday ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Documentation|| ADT Reference Guide Draft out for review || Outline complete|| High|| WIP || Scott Rifenbark|| jzhang|| Documentation<br />
|-<br />
|| || || || || || || || <br />
|}<br />
<br />
== M4 (Feb 07 to Apr 15 -- Stabilize Complete Mar 18, Release Complete Apr 01, Contingency to Apr 15) ==<br />
<br />
This sprint is the [[Yocto Project v. 1.0 Release Cycle]].<br />
<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Documentation|| Migration chapter in the Poky Reference Manual|| This chapter would cover the four identified use-cases for migrating up to the most recent version of Yocto Project. Additionally, it would cover migration scenarios from other development systems. The chapter does not yet exist. The chapter has not been scoped outside of having a meeting that identified four use-cases that did not include migration from a development system outside of Yocto Project. It will take some more scoping time to cover those areas (a day or two). Again, I have no idea of the length. See earlier entries for standard industry writing estimates for software documentation|| Medium|| Not Started|| Scott Rifenbark|| 3-4 Weeks|| Documentation<br />
|-<br />
|| Documentation|| Yocto Project Development Guide|| This manual would be an over-arching document that frames the complete development cycle within Yocto Project. The idea here is that the document would be an umbrella document that spawned and referenced subsequent documents. The organization would be the first chapter overviewing the major development pieces such as recipe creation, building, debugging, publishing, fail-safing, back-door hook creation, etc. Scoping would be about two weeks and length would probably be about 40 pages. Overall development time would likely be a month of uniterruped time.|| Medium|| Not Started|| Scott Rifenbark|| 3 Weeks|| Documentation<br />
|-<br />
|| Validation|| Boottime/Performance Analysis|| Compare Yocto Project performance to other projects such as MeeGo|| 1|| Initial report on where we are by Feb 9 || Darren|| davest|| project commitment<br />
|-<br />
|| || Multilib Support|| Consider developing post-1.0 branch || 1|| to start in M4 || Richard|| ||<br />
|-<br />
|| Validation|| Alpha testing complete|| 4-5 internal developers unfamiliar with Yocto Project try to do a build and report on the experience and issues encountered|| 1|| Done by Feb 18 || Julie|| davest|| <br />
|-<br />
|| || || || || || || || <br />
|}<br />
<br />
== Features needed and to be put into sprints by assigned owners: ==<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || package config option enhancement|| there're several enhancements we may do here: * allow users setting specific config options (local or global) from external tool, such as poky image creator, instead of changing recipes manually. Need a mechanism to convert from variable assignments into exact config options (e.g. feature_${PN} = ""1"" -> ""--enable-feature""). Consequently dependency chain needs update with option status. * host contamination check. We have swabber to check host contamination, but I'm not sure whether it covers configuration phase. If not, this is one area to improve, as not ususually we see configure script checks host bits for available features * conditional option manipulation. In many recipes we enable/disable one option based on availability of other packages. Now this is done manually and not flexible. this should be made automatically though some new annotation to indicate condition, or just base_contains (not convenient: long line, need define distro features) || 2|| Review|| Richard/MarkH|| ktian1|| Enhancement<br />
|-<br />
|| Media|| Yocto Project Awareness Video|| This 2.5 minute video would introduce and describe the benefits of Yocto Project. The video would use entertaining animations that described concepts and benefits. The result would be suitable for YouTube, conferences, and the website. The production is called an "Epipheo" and will be created by Epipheo Studios. The engagement process has begun and the kick-off meeting will be soon. The PO is in place. Time for development is 10 weeks.|| High|| Kick-off Imminent|| Scott Rifenbark|| 10 Weeks|| Media<br />
|-<br />
|| Documentation|| Yocto Project Debugging Guide|| This would be a guide for the debugging and bug tracking process in Yocto Project. Originally, the thought was that we needed a Bugzilla User's Manual. However, since we don't own Bugzilla it doesn't make sense to produce documentation for it. Rather, we should document the process as it fits into the Yocto Project environment. Ideally, the manual would be a sub-manual that would be referenced and architected into the Yocto Project Development Guide. The manual has not been scoped and would take a week to scope. Again, I have no idea of the length. See the previous item for standard industry writing estimates for software documenation.|| Medium|| Not Started|| Scott Rifenbark|| 3-4 Weeks|| Documentation<br />
|-<br />
|| Website|| Yocto Project Website|| The 0.9 website is in place but needs updates. Items for consideration are the left-panel naviagation scheme, a contributions guidance page, color-scheming and theme (possibly).|| Medium|| Not Started|| Scott Rifenbark|| 1-2 Weeks|| Website<br />
|}<br />
<br />
== Features not believed to be needed in v1.0: ==<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || OpenEmbedded/Bitbake Upstreaming|| "We firstly need to review where we are and where OE is. We then need to make a plan about what we're going to push upstream and what we're not. I'd suggest when we're in PRC, we do a crash course in ""dealing with OE"" and then many dedicate a block of time (a week) where the distro team comes up with a patch set we then propose and get merged into OE. I'd like to find a couple of interested people to monitor OE more regularly and start a workflow of things between Poky/OE where appropriate. The key thing to remember is we need to keep the architectures compatible. The team is now at the point where I'm happy for them to actually try building OpenEmbedded and not worry about it tainting them! "|| 2|| Review|| || rpurdie|| Process<br />
|-<br />
|| Poky Features || Handle old versions in WORKDIR|| an incremental build directory may finally include many old versions WORKDIRS. It'll be good to have those old versions tracked in the cache, which can then either generate a report or allow selectively cleaning up an specific version WORKDIR. Or else it's difficult to figure it out when people want to keep the whole tmp directory but like to cleanup some old bits when disk usage is under pressure. If it's not easy to do in bitbake, perhaps some separate scripts would be also helpful || 3|| Review|| || ktian1|| Enhancement<br />
|-<br />
|| Poky Features || run bitbake w/o rebuilding the cache|| "sometimes it's useful to allow run bitbake w/o re-parsing recipes, if we know nothing metadata is changed. we can just allow reusing existing persistent cache. this is useful when people is debugging WORKDIR w/o metadata change. also sometimes ""bitbake -e"" is used frequently to check poky variable information. with existing cache, several seconds can be saved which are not negligible for a developer daily working on Yocto "|| 2|| Review|| || ktian1|| Enhancement<br />
|-<br />
|| Poky Features || parallel make improvement|| parallel make experience is not good, especially when bb threads and make threads are increased larger than 8. So far we either try to fix package makefile or mark the recipe as no parallel make, when build faiures are reported. But this greatly impacts user experience for a successfully continuous build process. Could we define a safe number we do want to support for 1.0 release? and then have our autobuilder, QA test, and developers cover that number immediately and fix any issues accordingly. Then the safe number can be suggested to the Yocto user || 2|| Review|| || ktian1|| Enhancement<br />
|-<br />
|| Poky Features || Dependency packages rebuild/clean|| It is a mechanism to rebulid or clean a package and all other packages which have build/runtime dependency on it. With this change, we can find potential influences of package upgrade to its related packages, which can make the incremental build more trustable. For example, if we upgrade a package to a new vesion which changes its API, this mechanism can easily find out the incompatibility to other packages which have dependency on it. || 2|| Review|| || dongxiao.xu|| Enhancement, replaced by checksum feature<br />
|-<br />
|| Distribution / components|| FOSSology|| This may be similar to License Update above, but start to use FOSSology to track licenses. || 2|| Review|| || sgw|| Hygiene<br />
|-<br />
|| Distribution / components|| Package Developer Tools|| Create a set of Init scripts template and then review our current init scripts and modify them to confirm to the template. || 2|| Review|| || sgw|| Easy of Use<br />
|-<br />
|| Distribution / components|| Package Website|| Complete the work the intern has started on generating the distro tracking information and get it out on the external site. || 2|| Review|| || sgw|| "Hygiene, duplicate of ""Package report system"""<br />
|-<br />
|| Distribution / components|| Bluetooth UI support|| Currently we have bluez package in poky, and we need to have a workable graphic user interface to connect/configure BT devices. One choice may be gnome-bluetooth-applet. || 3|| Review|| || dongxiao.xu|| enhancement<br />
|-<br />
|| Distribution / components|| Connman-gnome enhancement features|| Enable connman-gnome to support features like, WPA Enterprise connection, hidden SSID, etc. || 3|| Review|| || dongxiao.xu|| enhancement<br />
|-<br />
|| Distribution / components|| Java Running Environment support|| Since most embedded systems support java applications running in it, maybe we'd better consider supporting some kinds of JVMs(Embeded JVM). The JVM may not run by default, but user can launch it if running java applications. Compared with GTK/QT, java user number is not small too. || 3|| Review|| || criping|| enhancement<br />
|-<br />
|| Distribution / components|| create more use cases|| UPnP demo is one really good use case showing how Yocto is utilized to make real functionality. and we could create more to show how Yocto is easily adapted to real use cases. Those use cases can be either maintained as seperate demo layers in yocto repo, or in seperate branches for reference. We can also call for community's contribution on this which would make 1.0 full-fledged. Or else the newbies to Yocto may be in puzzle how our sample profiles can satisfy their requirements. || 2|| Review|| || ktian1|| enhancement<br />
|-<br />
|| Distribution / components|| i18n support || internationalization is an important system wide feature. Many component like font, locale affect the i18n. Yocto alreay has some i18n related package like pango, but so far did not consider i18n systematically. so this is place holder to systematically add i18n support. || 2|| Review|| || yuke/qing|| enhancement<br />
|-<br />
|| Distribution / components|| more demos || demos are a good way to educate, push the envelope, and at the same time tout the strengths of the platform. This item just records a current set of ideas from various sources which could/should be implemented: * face-recognition/face-finding, * robotic control/application of face-finding to 'camera-as-sensor' (hexbug demo), * others [tbd, add here]|| 2|| Review|| || tzanussi|| enhancement <br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer support for image-creator and needed yocto-metadata design||Come up design what need to be created as packages to support using "opkg install" for image-creator and needed yocto-metadata|| 2|| WIP, pending comments from RP regarding how to packaging metadata|| Jessica|| rpurdie|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer image-creator and needed poky-metadata support|| The poky build system will build packages for image-creator and needed poky-metadata, which the Yocto Installer will be able to use "opkg install" to install them|| 2|| Review|| Jessica|| rpurdie|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Provide qemu management UI|| In current eclipse plugin, QEMU settings are put together with project configuration. So we can only have limited settings. If we can have a separate QEMU management UI, the end user could firstly create a QEMU config, such as (env file of arch, image location, unfs or not, sato or lsb, mem size, disk size). And then he can launch a QEMU with a specific config. The dependency between project configuration and QEMU config will be resolved. After all QEMU has nothing to do project configuration. Need to careful review the UI to ensure minimal impact to testing matrix. || 3|| Review|| || criping|| "Enhancement, duplicate of ""Qemu mem/disk size can be adjusted"""<br />
|-<br />
|| Tool Development and SDK Features|| QT plugin For Eclipse|| Integrate QT Ecplise plugin and extend for Yocto Project || 3|| Review|| || jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Profiling/Trace GUI's|| We have a wealth of great tracing and profiling tools but the UI's for them are all extremely minimal and usually quite ugly. Would be great if we could compete with, or even better, Apple's offerings here. We have the technology! || 2|| Review|| || josh|| "Enhancement, duplicate of ""Tracing/Profiling Planning Complete"""<br />
|-<br />
|| Tool Development and SDK Features|| Other profiling tools|| Complete Tom's review of profiling tools and architecture || 2|| Review|| || josh|| "Enhancement, duplicate of ""Tracing/Profiling Planning Complete"""<br />
|-<br />
|| Tool Development and SDK Features|| Design next-gen tracing/profiling tools|| Yocto 1.0 will include all the essential existing tracing/profiling tools expected by users, and Josh has proposed a UI integration of all those tools as far as it's possible to do so. That level of integration, basically a 'plugin-level' integration is necessary and useful, but doesn't go far enough. A next-generation tracing tool would integrate at a much more fundamental level; if done properly, it would provide unmatched levels of power and usability to users, and would allow Yocto to distinguish itself in the embedded tracing/profiling space in a way also unmatched by any other distro/build-tool. The implementation would of course not be available for Yocto 1.0, but a coherent design, including prototypes, that could be taken to the community and implemented in a V 1.5 or 2.0 should be done in that time frame. || 1|| Review|| || tzanussi|| "Enhancement, duplicate of ""Tracing/Profiling Planning Complete"""<br />
|-<br />
|| Documentation Features|| Self Documentation of image contents|| "I'd like to see the -doc packages Poky builds being combined into some kind of large documentation index representing the collective API docs of the target being built. This can then be placed on a webserver and viewed over the web. We'd have a demonstration of this for a ""bitbake world"" target. Part of the idea here is to start making good use of the docs as if developers see this they might start writing better docs too. Aim is to lead the field :). There are a number of places poky packages disable doc generation due to missing tools so we'd need to add these so we can enable the doc generation. Many packages already have many docs though too. "|| 2|| Review|| || rpurdie|| enhancement<br />
|-<br />
|| Validation|| Testing Framework|| Add a framework for doing automated testing in the project|| 1|| Review|| || davest|| project commitment<br />
|-<br />
|| Validation|| more SDK builds on autobuilder|| enable more SDK related tests on autobuilder such as meta-ide-support, etc.|| 2|| Review|| || ktian1|| project commitment, addressed by test plan (?)<br />
|-<br />
|| Validation|| more people should try using SDK|| this may not be a feature, but a requirement. SDK including meta-toolchain is one key factor impacting user experience on Yocto. It's not enough to have only SDK team play with it|| 2|| Review|| || ktian1|| project commitment, addressed by test plan (?)<br />
|-<br />
|| Validation|| Unit Testing Framework|| Add a mechanism to bitbake to parse source packages that have unit tests and then execute them on the target|| 3|| Review|| || sgw|| "project commitment, duplicate of ""Testing Framework"""<br />
|-<br />
|| Validation|| Test Case open source|| Open source Yocto test cases with xml format|| 1|| Review|| || yyou|| "project commitment, duplicate of ""Testing Framework"""<br />
|}</div>Davesthttps://wiki.yoctoproject.org/wiki/index.php?title=Yocto_1.0_Schedule&diff=592Yocto 1.0 Schedule2011-01-25T01:36:22Z<p>Davest: /* Sprint D (closes Jan 21, 11:59pm PDT -- pull request sent, initially reviewed) */</p>
<hr />
<div>= v1.0 (release date: Apr 15, 2011) =<br />
----<br />
The detailed milestone map for v1.0 is as below. During the first week of each subsequent milestone past M1 we will have a demonstration of the previous milestone capabilities as well as a planning and design session for the current milestone.<br><br><br />
<br />
== M2 (Nov 08 to Dec 24 -- Dev Complete Dec 10, Stabilize Complete Dec 17, Release Complete Dec 24) ==<br />
=== Sprint A (closes Nov 12, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links''' <br />
|-<br />
|| Poky Features || Kernel interactive targets || To support incremental kernel development having the ability to run menuconfig (or xconfig, etc) directly is a common request. We'll need to add this for commercialization anyway. i.e. bitbake -c menuconfig. This fuctionality already exists. || 1 || Done || Richard || bruceashfield || Enhancement <br />
|-<br />
|| Distribution / components || Distro Audit: Upgrades Planned (Phase 1) || Complete plan for package upgrades in M2 || 1 || Done || Saul || || Continual Maintenance<br />
|-<br />
|| Validation || Runtime testing || Runtime testing of images as part of the autobuilder || 1 || Done || Jiajun/ScottG || rpurdie || project commitment<br />
|- <br />
|| || Poky Image Creator Wireframe/Interaction Plans Complete || || 1 || Done || Josh || ||<br />
|-<br />
|| || SDK Generator Interaction: Plans Complete || || 1 || Done || Jessica || ||<br />
|-<br />
|| || Tracing/Profiling Planning Complete || This needs to cover where we're at now, what we're missing and also propose the future enhancements that may be needed. M2 targets getting existing tools integrated and documented. F2f discussion n the future enhancements || || Done || Tom || ||<br />
|-<br />
|| || Swabber. (Still needs to be integrated into weekly build by default) || || 1 || Done || Josh || ||<br />
|-<br />
|| Build/Release || Release process documentation || || || Done || Beth || ||<br />
|-<br />
|| Validation || Test plan for v1.0 (to address any deficiencies in coverage from v0.9)|| || 1 || Done || Jiajun || ||<br />
|}<br />
<br />
=== Sprint B (closes Nov 19, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| Distro Audit: World Packages|| Audit world packages making sure it all build, making sure all are packages are required || 2|| Done || Saul|| sgw|| Hygiene<br />
|-<br />
|| Tool Development and SDK Features|| SDK Generator Installer UI|| Look at different ways of Installer UI (GTK+ and ncurses) seems none of them is the right choice, decide to go with script to implement all the functionalities of installer and later add UI part on top of it || 1||Done|| Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Customize sysroot setup || Add and test out "--sysroot" config option to cross compiler within Eclipse IDE || 1|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| SDK Generator Installer design revision|| Close all open questions regarding Yocto SDK Generator Installer function design and come up HLD || 1|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Distribution / components|| kernel version|| keeping 2.6.34 as a -stable kernel is the best option. I've also got a newer -devel tree that can be made available or made the default. || 3|| Done || Bruce|| bruceashfield|| enhancement<br />
|-<br />
|| || assign Yocto Project PM|| acquire and assign a program manager for Yocto Project|| || Done || DaveST|| || <br />
|-<br />
|| || assign Yocto Project Sys Admin|| || || Done || Saul|| || <br />
|-<br />
|| Tool Development and SDK Features|| oprofileUI|| Fixing various bugs of the oprofileUI to make it workable on big endian host.(i.e. ppc, mips) || 2 || Done || Jessica || lianhao.lu || Bug #382 / Bug #493<br />
|-<br />
|| Poky Feature|| SDK Version Control|| If we can expect that yocto SDK has lots of release in the future, we might need to consider SDK version control. Currently, every thing installed under /opt/poky which leads to things be overriden, we need to be able to use a scheme like /opt/poky-1.0, /opt/poky-2.0 to distiguish things. || 2|| Done || Josh|| jzhang|| Enhancement<br />
|-<br />
|| Kernel || Kernel plan complete || Flesh our kernel deliverables and add to Yocto 1.0 schedule || || Done|| Darren || dvhart ||<br />
|}<br />
<br />
=== Sprint C (closes Nov 26, 11:59pm PDT -- pull request sent, initially reviewed) :: NOTE: this is US Thanksgiving week ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| Distro Audit: Licence Checksums|| licence checksums || 1|| Done || Saul|| rpurdie|| Hygiene<br />
|-<br />
|| Poky Features || Performance Analysis Completed|| "I'd like someone to instrument a green release build, see where it spends time (hot/cold parsing time, individual task building time) and then compare this with our 0.9 release build. I'd also like to compare the disk usage between the two. Once we have a blame list we can then set about fixing it. Some things I know will come up: a) pseudo, b) checksums/signature code, c) exec() vs fork for executing tasks, d) task based prebuilds increasing disk usage, e) rpm dependency calculations, f) using rpm vs. ipk but I may be wrong and there may be others. We need numbers. "|| 1|| Done || Saul / Qing, Dongxiao|| rpurdie|| Enhancement<br />
|-<br />
|| Poky Features || environment variables for kernel builds|| switching a branch, or adding a configuration feature (and even changing the kernel repo) is often done during development of a BSP. Having some additional variables that are pass the bitbake environment scrub would be useful. i.e. KBRANCH=foo bitbake -c configure linux-yocto. This goes along with the other BSP bootstrapping suggestions. || 2|| Done || Bruce|| bruceashfield|| Enhancement<br />
|-<br />
|| Supported Targets|| ARM Platform Support|| Replace beagleboard with Beagleboard XM - decision || 2|| Done || Bruce|| alex|| Basic Yocto hardware support <br />
|-<br />
|| Distribution / components|| Security Process|| We need a dedicated person to scan and apply critical security updates to the distro. The MeeGo team already has a similar process with some scripts which may be leveraged. To complete the task, the process should be documented and a first pass over the metadata made to establish the current position on security. Any upgrades needed should be identified and a plan to address them should be in place but doesn't have to be implemented by this point.|| 1|| Done || ScottG|| ktian1|| enhancement<br />
|-<br />
|| Tool Development and SDK Features|| SDK Generator Installer Opkg repo design|| Come up a opkg repo design that will mimic the final Yocto package repo layout to be used by SDK Generator Installer to test against|| 2 || Done || Jessica || jzhang || <br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer tar creaion|| Create a Yocto Installer tar ball which contains Installer script and supported opkg component that will be used for installing other Yocto components|| 2 || Done || Jessica || jzhang || <br />
|-<br />
|| Documentation|| Kernel Framework Paper from WR|| The paper from WR needs to be re-written and then posted somewhere on the Yocto Project site. This will involve examiniation of the text and re-writing and formatting for presentation. Currently it is simply a text document. Completion time assuming uninterrupted time is one week.|| High|| Done || Scott Rifenbark|| 1 Week|| Documentation<br />
|-<br />
|| Documentation|| Poky Reference Manual|| This guide exists in the 0.9 form. The re-write of the text needs to be completed. So far, all the chapters have been rewritten but not re-posted on the site. Only the appendices remain for a text scrub. Time to complete this would be a week of uninterrupted time. Ideally, the manual would be a sub-manual that would be referenced and architected into the Yocto Project Development Guide.|| Medium|| Done|| Scott Rifenbark|| 1 Week|| Documentation<br />
|-<br />
|| Kernel || Initial meta-linaro layer || meta-linaro layer providing a kernel, tool-chain, and uboot loader. This deliverable is primarily to get the infrastructure in place and have a buildable kernel. Toolchain on best effort basis. || || Done || Darren || dvhart || Moderate risk of slippage due to holidays.<br />
|-<br />
|| Kernel || Tracing: blktrace and sysprof recipes || || || Done || Tom || dvhart ||<br />
|}<br />
<br />
=== Sprint D (closes Dec 3, 11:59pm PDT -- pull request sent, initially reviewed) :: NOTE: week of the F2F planning meeting ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Kernel || Kernel git branching structure revamped || || 1 || Done || Bruce || dvhart ||<br />
|-<br />
|| Kernel || Tunnel Creek (Crown Bay) || || 1 || Done || Tom || dvhart ||<br />
|}<br />
<br />
=== Sprint E (closes Dec 9 (THURSDAY), 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| Distro Audit: Upgrades Completed (Phase 1)|| Update to new versions as per the agreed plan for M2 from Sprint A|| 1|| Done || Saul|| rpurdie|| Continual Maintenance<br />
|-<br />
|| Distribution / components|| Distro Audit: Src Checksums|| Make sure all SRC_URI components have checksums too || 1|| Done || Saul|| rpurdie|| Hygiene<br />
|-<br />
|| Poky Features || enable KVM with qemu|| today all new Intel processors support VT, which are enabled on most desktop machines which are most frequently used build machine. with VT support, x86/x86-64 qemu target runs faster which is a good thing for emulation environment. This may require some qemu option tweaks and also poky-qemu script enhancement. || 2|| Done || Saul / Edwin|| ktian1|| Enhancement<br />
|-<br />
|| Kernel || New kernel recipes || dev, -devel, -custom || 3 || Done || Bruce || dvhart ||<br />
|-<br />
|| Swabber || Documentation for swabber || || 1 || Done || Alex || ||<br />
|-<br />
|| CCB || Defect triage process in public documented and implemented || || 1 || Done. Triage process is documented, out for review. || Saul || ||<br />
|}<br />
<br />
== M3 (Dec 20 to Feb 08 -- Dev Complete Feb 04, Stabilize Complete Feb 11, Release Complete Feb 18) ==<br />
=== Sprint A (closes Dec 24, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Kernel || Initial meta-rt layer || PREEMPT_RT kernel and related test-cases and benchmarks || 2 || Done by Jan 21 || Darren || dvhart || slipped out from M2<br />
|-<br />
|| Poky Features || Fetcher Overhaul Phase 1 - SRC_REV enhancement||<br />
* a) Add code in FetchData::__init__() which will check if the selected fetcher supports srcrev and the automatically call a function to set the src rev value instead of each fetcher doing this.\n <br />
* e) Break SRCREVINACTION deadlock. To do this, we need to start using a keyword for automatically increasing SRCREV, e.g. SRCREV = "AUTOINC". The actual revision can be injected into PV using SRCPV. If we do this there should no longer be a need of the deadlock; <br />
* k) Ensure that we only set __BB_DONT_CACHE when SRCREV = "AUTOREV". This may need a new method call for fetchers to tell whether they're "floating" or locked down.<br />
|| 1|| Done || Saul / Ke, RP|| rpurdie|| Enhancement, slipped out from M2<br />
|-<br />
|| Distribution / components|| Distro Audit Upgrades Planned (Phase 2)|| Complete plan for package upgrades in M2|| 1|| Done || Saul|| || Continual Maintenance<br />
|-<br />
|| Poky Features || Pseudo Performance || Implement the changes to bitbake based on pseudo's enable/disable switch|| 1|| done || Saul / Qing, Dongxiao || rpurdie|| Enhancement, slipped from M2 due to risk and not having Pseudo's change yet.<br />
|-<br />
|| Tool Development and SDK Features|| Fix the issue user target sysroot is owned by root || The ADT installer will use pseudo to extract user target sysroot which ended up owned by root, this need to be fixed || 1|| done || Jessica|| jzhang|| Cleanup <br />
|-<br />
|| Tool Development and SDK Features|| Eclipse poky tree interfacing (metadata file editor)|| Provide a metadata file editor with some syntax checking and keywords highlight capabilities|| 2|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| IDE Project templates|| Templates for various project types: Clutter GUI, Gtk+ GUI, to help developers get started quickly || 2|| Done || Jessica|| josh|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| push TCF/RSE patches upstream|| work with community to finish up our TCF terminal service, TCF/RSE integration remaining patches taken by upstream. Blocking issues including Eclipse Bug #327865 || 1|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Pseudo || Pseudo enhancement to enable on/off switch || || 1 || done || Mark || ||<br />
|-<br />
|| Pseudo || Bitbake enhancement for pseudo on/off switch || || 1 || done || Richard || ||<br />
|-<br />
|| bugzilla || Complete restructure of bugzilla categories || || 1 || done || Saul || ||<br />
|-<br />
|| Poky Features || Image creator ground work || Nomenclature determined, existing gui's bug fixed and backend work implemented || 1 || Done || Joshua || ||<br />
|-<br />
|| Kernel || Tracing: Initial SystemTap recipe || Works on x86 || 3 || Done || Tom || dvhart ||<br />
|-<br />
|| Distribution / components|| Distro Audit: Package Description/Summary completed|| Ensure DESCRIPTION/SUMMARY fields are all audited|| 2|| Done || Mark|| Mark|| Hygiene, was M2, Sprint B but missed window<br />
|-<br />
|| Distribution / components|| Zypper/RPM|| Small write-up of the problems we're having w/ Zypper and what we plan to do. (i.e. create a roadmap/design) - Includes rootfs generation - Package uprev/install/removal || 1 || Done || Mark/Qing || || was M2, Sprint B<br />
|-<br />
|| Distribution / components|| Distro Audit: Licence Checksums|| Make the licence checksums fatal if not present || 1|| Done || Saul|| rpurdie|| Hygiene, was M2, Sprint C<br />
|-<br />
|| Distribution / components|| push of all relevant Wind River patchs to Yocto (patch comparison)|| Ensure patches present to packages in WRS are also in Poky|| 1|| Done || Mark|| Mark|| was M2, Sprint C<br />
|-<br />
|| Poky Features || Performance Enhancement Completed || Initial changes to reduce disk space (sstate-build-*) || 1|| Done || Saul / Qing, Dongxiao || rpurdie|| Enhancement, was M2, Sprint E<br />
|-<br />
|| Distribution / components|| User specified qemu config support|| We'll provide user an edit box which allows advanced qemu user to specify arbitrary qemu configuration to meet their needs, which the poky-qemu scrip will just append the config list towards the end of the list of parameters to bring up qemu, it also expect the poky-qemu script to do some basic sanity check on the user specifications to catch the obvious mistake || 2|| Done || Saul / criping || criping|| enhancement, was M2, Sprint E<br />
|-<br />
|| Tool Development and SDK Features|| SDK Version Control support in SDK generator installer|| If we can expect that yocto SDK has lots of release in the future, we might need to consider SDK version control. Currently, if we un-tar the sdk, it will override the older version. It's not good for app developers since they might need the old version to do something. And also, maybe a finer installer than untar is preferred. Installer will tied to certain SDK version and the installation will go under /opt/poky-versionNo.|| 1|| Done || Jessica|| criping|| Enhancement-expect planning process by Jessica to handle this task. Was M2, Sprint E.<br />
|}<br />
<br />
=== Sprint B (closes Jan 07, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || Bitbake multi-threaded parsing|| Bitbake recipe parsing is currently single threaded. I want to make this multithreaded as the speedup would be nice. If I can only take a single task for myself for 1.0, I'm nominating this one as I enjoy this kind of thing and I have ideas on how to do it. || 1|| Done || Richard|| rpurdie|| Enhancement<br />
|-<br />
|| Distribution / components|| Lock in Kernel/Toolchain version|| Locked in 2.6.37 and gcc 4.5.1. Pending decision to move to 4.5.2 and Linaro || || Done || || Richard|| || <br />
|-<br />
|| Distribution / components|| License Update|| For each of the licences we support, I'd really like to have a licences directory with a copy of that license contained within. When it comes to deciding what a given LICENSE field means, this would be the reference. It also means we can include the licences a given image includes with the image. This continues to make our license handling world class and ahead of the field. || 2|| Done || Beth|| rpurdie|| Hygiene<br />
|-<br />
|| Tool Development and SDK Features|| Qemu configuration change|| Provice edit box for advanced user to specify qemu configurations|| 2|| Done || Jessica|| criping|| <br />
|-<br />
|| Tool Development and SDK Features|| Lock down Eclipse+CDT+TCF version|| Will use Eclipse Halo 3.6 || 1|| Done || Jessica|| || <br />
|-<br />
|| Demo|| Finalize on demo plans for v1.0 launch || || 1|| Done || Dave || || <br />
|-<br />
|| Release || Release plans for v1.0 launch || Fill out the M4 plan with the necessary release activities and timings || 1|| Done || Beth || || <br />
|-<br />
|| Poky Features || Basic image creator GUI || Functional UI missing some Advanced features || 1 || In replan || Joshua || || <br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer for SDK Generator Installation functions support||Detailed feature request can be found at: http://bugzilla.pokylinux.org/show_bug.cgi?id=589|| 1|| Done || Jessica|| rpurdie|| Enhancement<br />
|-<br />
|| Kernel || Tracing: trace-cmd python binding cleanup || || 3 || Done || Darren || dvhart ||<br />
|}<br />
<br />
=== Sprint C (closes Jan 14, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || kernel development layer|| The (correct) poky behaviour of building known revisions coupled with the fetcher requiring a BSP branch to already be present means that local modifications (and kernel source tree) are required for kernel development. I already have a layer that overrides/modifies the behaviour when added to the bblayers.conf and configured into an environment. This seems useful for more people to use. || 2|| Done || Bruce|| bruceashfield|| Enhancement, was M2, Sprint C<br />
|-<br />
|| Distribution / components|| Zypper/RPM|| RPM Uprev / Zypper Uprev [lets get to the latest versions]|| 1|| pull request by Jan 19; || Mark/Qing|| || was M2, Sprint C<br />
|-<br />
|| Supported Targets|| Intel Platform Support|| JasperForest|| 2|| Basic support in place; DPDK evaluation in process, overall BSP plan still TBD || Tom|| davest|| Basic ECG support (Moved from Sprint A)<br />
|-<br />
|| Tool Development and SDK Features|| Eclipse poky tree interfacing (git support)|| Use Eclipse git capability to install poky tree from git repo and able to interact with git repo at file level within Poky tree || 2|| Done || Jessica|| jzhang|| Enhancement<br />
<br />
|-<br />
|| Poky Features || Poky Image Creator|| A standalone application you can run which asks you to select a distro and machine, then presents a list of packages you can select. Once the selection is made, it goes off and bakes you an image which is then presented to you. Implementation wise, it should use the sstate packages, be a bitbake UI and use the usual poky bbclass files to do the image construction behind the scenes. || 1|| Re-plan || Joshua|| rpurdie|| Enhancement<br />
|-<br />
|| Distribution / components|| LSB Sanity|| execute LSB Test and improve passing rate and document failures with clear understanding|| 2|| Done || MarkH/Saul|| sgw|| Hygiene<br />
|-<br />
|| Tool Development and SDK Features|| Image creator integration with Eclipse || || 2|| replan|| Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Kernel || Tracing: perf trace marker support || This is from feedback to the new trace command. Ingo appears to have this nearly complete already. || 3 || Done || Darren || dvhart ||<br />
|-<br />
|| Cleanup || bitbake user experience error handling validation completed || || 2 || Done || Richard || ||<br />
|-<br />
|| Cleanup || variable scrub - ensure all metadata variables are documented || Script with a histogram of variable use done, identified 50 variables to document; Add task for actual documentation update is low on the list || 2 || Done || Scott/Darren || ||<br />
|-<br />
|| Distribution / components|| Zypper/RPM|| Integration based on design from Sprint B|| 1|| On track for Jan28 || Mark/Qing|| sgw|| Functionality, was M2, Sprint E<br />
|-<br />
|| Kernel || Tracing: package kernelshark || || 3 || Done || Darren || dvhart ||<br />
|-<br />
|| Kernel || Tracing: tuna, oscillosope recipes || || 3 || Tom to discuss plan with Darren et al || Tom || dvhart ||<br />
|- <br />
|| BSP || Beagleboard XM Support || || 3 || Move to Sprint D || Darren || dvhart ||<br />
|}<br />
<br />
=== Sprint D (closes Jan 21, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Swabber || Complete review of swabber outputs || Move to M3 Sprint D || 1 || Move to M3 Sprint D || Alex || ||<br />
|-<br />
|| Poky Features || Fetcher Overhaul Phase 2 - API reorg||<br />
* f) Add a generic unpack funciton to __init__.py based on the unpack task in Poky ;<br />
* g) Split go() methods into the following steps: i) download() - do whatever transfer is necessary to get the sources locally ii) build_mirror_data() - generate any data that would be needed to construct a source mirror iii) unpack() - takes a directory as an argument of where to place extracted sources;<br />
The existing go() methods should be replaced with a set of calls to the above sections of functionality as appropriate in the individual fetchers. Some of these categories of function make no sense in certain fetchers, in which case they shouldn't need to implement them. Functions are only executed if the method is present.<br />
* h) Change Poky's unpack to call an unpack method in the fetchers.<br />
* i) Change Poky's fetch task to call a "download" method in the fetcher instead of go().<br />
|| 1|| Will land with phase 3 in Jan 21 || Saul / Ke, RP|| rpurdie|| Enhancement<br />
|-<br />
|| Poky Features || Fetcher Overhaul Phase 3 - git enhancement||<br />
* j) Optimize git fetcher for the new layout so for a git checkout, we clone the repository in download(), then unpack just does a clone with references to the original repo. <br />
* k) Ensure that we only set __BB_DONT_CACHE when SRCREV = "AUTOREV". This may need a new method call for fetchers to tell whether they're "floating" or locked down. <br />
* l) Add a new "BB_NO_NETWORK" variable which the fetchers check before peforming an operation which hits anything remote. This means adding in error messages about why network access is needed at various points (e.g. SRCREV = "AUTOREV" for a given recipe) <br />
* m) Add multiple branch/srcrev support for git fetcher. These would be of the form: git://somelocation/somerepo.git;name=ref1;branch=foo;name=ref2;branch=bar SRCREV_ref1 = "hash1" SRCREV_ref2 = "hash2" which would ensure both hash1 and hash2 were in the final repo. <br />
* n) Change git fetcher to default to git protocol instead of rsync<br />
|| 1|| Slipped to Sprint D || Saul / Ke, RP|| rpurdie|| Enhancement<br />
|-<br />
|| Poky Features || DSO linking changes|| "By the default the gcc linker will automatically link any dependant objects/libraries. ""Inherited"" linkages can cause issues, for example, where a shared object changes its dependencies but a program has come to rely on symbols from an implicitly linked library. Fedora implemented this change in F13, seems like it would be useful to have in Poky too. "|| 2|| On track for Jan 21 || Saul / Nitin || josh|| bug#516<br />
|-<br />
|| Distribution / components|| Distro Audit Documentation Output|| Audit package documentation output || 2|| Move to Sprint D due to libtool work || Saul / ScottG || rpurdie|| Hygiene<br />
|-<br />
|| Distribution / components|| Review & Fix Standards Tests|| Review the results from LTP, POSIX and asses the result, fix as appropriate and clearly document failures.|| 2|| a Plan to resolve final items to be sent to the m.l. by Jan 14 || Saul/Kevin || sgw|| Hygiene<br />
|-<br />
|| Poky Features || libtool sysroot option|| libtool 2.4 has a sysroot option. We should try and use it, see how it works and whether we can ditch some of our libtool hacks. || 1|| On track for Jan 21 || Saul / ScottG || rpurdie|| Enhancement<br />
|-<br />
|| Distribution / components|| MACHINE or Recipe specific sysroots|| Each machine should have its own sysroot. We'll probably have to split do_populate_sysroot into a two step process, creation of the package and than installtion of the package, which the installation of the package being made machine specific (put ${MACHINE} into ${STAMP} and bitbake should do that). Also allowing this to work per recipe would be desireable|| 1|| On track 21 || Saul / Dongxiao || rpurdie|| Hygiene<br />
|-<br />
|| Distribution / components|| Toolchain Bootstrap Process|| The toolchain as it bootstraps overwrites files like libc.so and libgcc.so in the sysroot directory which causes issues if you just try and rebuild part of the toolchain. Each step of the bootstrap process should use a separate sysroot. Once this is once, sstate file overwriting detection can be added and enabled. || 1|| Patches submitted for comment, slip to Sprint D || Saul / Dexuan || rpurdie|| Hygiene<br />
|-<br />
|| Documentation Features|| Package report system|| move to public server [setup a package report system in an internal machine. We need push it publicly available. The basic features like search and report have been there. But there're still some enhancements in plan, to make it a fit place to feel Yocto metadata comfortably]|| 2|| Move to Sprint E|| KevinT|| ktian1|| enhancement<br />
|-<br />
|| Distribution / components||Add headers and libraries to qemu images ||Since we'll be using qemu images as target sysroot, need to create a set of qemu images for minimal, sato, LSB that contains target header and libraries.|| 2|| Pending a discussion on Jan 18 || Saul ||jzhang|| Enhancement<br />
|-<br />
|| Distribution / components|| push of all relevant Wind River patchs to Yocto (patch comparison)|| Update any additional patches needed since M2.|| 1|| May be done by Jan 21, pending RPM stuff || Mark|| Mark|| <br />
|-<br />
|| Distribution / components|| mklibs|| mklibs is a tool to optimize size of [e]glibc for a perticular root file system image. It is useful to save disk space on small devices. || 2|| Push to Sprint E || Saul|| Nitin Kamble|| enhancement<br />
|-<br />
|| Poky Features || Performance Enhancement || reduce disk space (hardlink) || 1 || On track for Jan 21, pending RP review || Saul / Qing, Dongxiao || rpurdie || Enhancement<br />
|-<br />
|| Kernel || Tracing: perf trace scripting support || || 3 || Move to Sprint D; on track for Jan 21 || Tom || dvhart ||<br />
|-<br />
|| BSP || 2.6.37 Crown Bay Support || On Track for Jan 21 || 2 || || Tom || dvhart || <br />
|-<br />
|| BSP || 2.6.37 Emenlow Support || On track for Jan 21 || 2 || || Tom || dvhart || <br />
|}<br />
<br />
=== Sprint E (closes Jan 28, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| rootless X|| rootless x server has better security than x server launched by root. MeeGo already enable this feature. it would be nice for Yocto to also enable it. || 2|| On track for Jan 28 || Saul / Ke || yuke|| enhancement<br />
|-<br />
|| Documentation Features|| Package report system|| finish major feature development and internal review [setup a package report system in an internal machine. We need push it publicly available. The basic features like search and report have been there. But there're still some enhancements in plan, to make it a fit place to feel Yocto metadata comfortably]|| 2|| Move to Sprint E || Jonathan || ktian1|| enhancement, was M2, Sprint E<br />
|-<br />
|| Distribution / components|| perl upgrade|| perl is the most cross un-friendly recipe pending upgrade. || 2|| Slipping due to Linaro layer, moves to end of Sprint E || Nitin|| Nitin Kamble|| enhancement<br />
|-<br />
|| Supported Targets|| Intel Platform Support|| Sandybridge|| 2|| Accept|| Tom|| davest|| Basic ECG support<br />
|-<br />
|| Distribution / components|| performance indicators|| define some indicators (boot time, footprint, build time, power, component benchmarks, etc.) and then collect them for tracking purpose. The result could be posted on the wiki site, and the initial indicators can be easy ones which can be easily retrieved from autobuilder or weekly qa report). This way we have a clear track about the healthy of the Yocto project, and also identify weak areas. We can include qemu targets and several representational boards as the targets. || 2|| Review|| Beth/Jiajun|| ktian1|| enhancement<br />
|-<br />
|| Tool Development and SDK Features|| SDK user workshop|| Have some developers sit down and use our tools to develop demo software for Yocto. || 2|| Review|| Jessica|| josh|| Enhancement<br />
|-<br />
|| Kernel || Final linux-yocto_git.bb || With 2.6.37 kernel || 1 || || Bruce || dvhart ||<br />
|-<br />
|| Kernel || Final meta-linaro layer || || || || Darren || dvhart ||<br />
|-<br />
|| Kernel || Final meta-rt layer || || || || Darren || dvhart ||<br />
|-<br />
|| Kernel || Sandy Bridge || || 1 || || Tom || dvhart ||<br />
|}<br />
<br />
=== Sprint F (closes Feb 03 (THURSDAY), 11:59pm PDT -- pull request sent, initially reviewed) :: NOTE: China New Year Holiday ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Documentation|| ADT Reference Guide Draft out for review || Outline complete|| High|| WIP || Scott Rifenbark|| jzhang|| Documentation<br />
|-<br />
|| || || || || || || || <br />
|}<br />
<br />
== M4 (Feb 07 to Apr 15 -- Stabilize Complete Mar 18, Release Complete Apr 01, Contingency to Apr 15) ==<br />
<br />
This sprint is the [[Yocto Project v. 1.0 Release Cycle]].<br />
<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Documentation|| Migration chapter in the Poky Reference Manual|| This chapter would cover the four identified use-cases for migrating up to the most recent version of Yocto Project. Additionally, it would cover migration scenarios from other development systems. The chapter does not yet exist. The chapter has not been scoped outside of having a meeting that identified four use-cases that did not include migration from a development system outside of Yocto Project. It will take some more scoping time to cover those areas (a day or two). Again, I have no idea of the length. See earlier entries for standard industry writing estimates for software documentation|| Medium|| Not Started|| Scott Rifenbark|| 3-4 Weeks|| Documentation<br />
|-<br />
|| Documentation|| Yocto Project Development Guide|| This manual would be an over-arching document that frames the complete development cycle within Yocto Project. The idea here is that the document would be an umbrella document that spawned and referenced subsequent documents. The organization would be the first chapter overviewing the major development pieces such as recipe creation, building, debugging, publishing, fail-safing, back-door hook creation, etc. Scoping would be about two weeks and length would probably be about 40 pages. Overall development time would likely be a month of uniterruped time.|| Medium|| Not Started|| Scott Rifenbark|| 3 Weeks|| Documentation<br />
|-<br />
|| Validation|| Boottime/Performance Analysis|| Compare Yocto Project performance to other projects such as MeeGo|| 1|| Initial report on where we are by Feb 9 || Darren|| davest|| project commitment<br />
|-<br />
|| || Multilib Support|| Consider developing post-1.0 branch || 1|| to start in M4 || Richard|| ||<br />
|-<br />
|| Validation|| Alpha testing complete|| 4-5 internal developers unfamiliar with Yocto Project try to do a build and report on the experience and issues encountered|| 1|| Done by Feb 18 || Julie|| davest|| <br />
|-<br />
|| || || || || || || || <br />
|}<br />
<br />
== Features needed and to be put into sprints by assigned owners: ==<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || package config option enhancement|| there're several enhancements we may do here: * allow users setting specific config options (local or global) from external tool, such as poky image creator, instead of changing recipes manually. Need a mechanism to convert from variable assignments into exact config options (e.g. feature_${PN} = ""1"" -> ""--enable-feature""). Consequently dependency chain needs update with option status. * host contamination check. We have swabber to check host contamination, but I'm not sure whether it covers configuration phase. If not, this is one area to improve, as not ususually we see configure script checks host bits for available features * conditional option manipulation. In many recipes we enable/disable one option based on availability of other packages. Now this is done manually and not flexible. this should be made automatically though some new annotation to indicate condition, or just base_contains (not convenient: long line, need define distro features) || 2|| Review|| Richard/MarkH|| ktian1|| Enhancement<br />
|-<br />
|| Media|| Yocto Project Awareness Video|| This 2.5 minute video would introduce and describe the benefits of Yocto Project. The video would use entertaining animations that described concepts and benefits. The result would be suitable for YouTube, conferences, and the website. The production is called an "Epipheo" and will be created by Epipheo Studios. The engagement process has begun and the kick-off meeting will be soon. The PO is in place. Time for development is 10 weeks.|| High|| Kick-off Imminent|| Scott Rifenbark|| 10 Weeks|| Media<br />
|-<br />
|| Documentation|| Yocto Project Debugging Guide|| This would be a guide for the debugging and bug tracking process in Yocto Project. Originally, the thought was that we needed a Bugzilla User's Manual. However, since we don't own Bugzilla it doesn't make sense to produce documentation for it. Rather, we should document the process as it fits into the Yocto Project environment. Ideally, the manual would be a sub-manual that would be referenced and architected into the Yocto Project Development Guide. The manual has not been scoped and would take a week to scope. Again, I have no idea of the length. See the previous item for standard industry writing estimates for software documenation.|| Medium|| Not Started|| Scott Rifenbark|| 3-4 Weeks|| Documentation<br />
|-<br />
|| Website|| Yocto Project Website|| The 0.9 website is in place but needs updates. Items for consideration are the left-panel naviagation scheme, a contributions guidance page, color-scheming and theme (possibly).|| Medium|| Not Started|| Scott Rifenbark|| 1-2 Weeks|| Website<br />
|}<br />
<br />
== Features not believed to be needed in v1.0: ==<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || OpenEmbedded/Bitbake Upstreaming|| "We firstly need to review where we are and where OE is. We then need to make a plan about what we're going to push upstream and what we're not. I'd suggest when we're in PRC, we do a crash course in ""dealing with OE"" and then many dedicate a block of time (a week) where the distro team comes up with a patch set we then propose and get merged into OE. I'd like to find a couple of interested people to monitor OE more regularly and start a workflow of things between Poky/OE where appropriate. The key thing to remember is we need to keep the architectures compatible. The team is now at the point where I'm happy for them to actually try building OpenEmbedded and not worry about it tainting them! "|| 2|| Review|| || rpurdie|| Process<br />
|-<br />
|| Poky Features || Handle old versions in WORKDIR|| an incremental build directory may finally include many old versions WORKDIRS. It'll be good to have those old versions tracked in the cache, which can then either generate a report or allow selectively cleaning up an specific version WORKDIR. Or else it's difficult to figure it out when people want to keep the whole tmp directory but like to cleanup some old bits when disk usage is under pressure. If it's not easy to do in bitbake, perhaps some separate scripts would be also helpful || 3|| Review|| || ktian1|| Enhancement<br />
|-<br />
|| Poky Features || run bitbake w/o rebuilding the cache|| "sometimes it's useful to allow run bitbake w/o re-parsing recipes, if we know nothing metadata is changed. we can just allow reusing existing persistent cache. this is useful when people is debugging WORKDIR w/o metadata change. also sometimes ""bitbake -e"" is used frequently to check poky variable information. with existing cache, several seconds can be saved which are not negligible for a developer daily working on Yocto "|| 2|| Review|| || ktian1|| Enhancement<br />
|-<br />
|| Poky Features || parallel make improvement|| parallel make experience is not good, especially when bb threads and make threads are increased larger than 8. So far we either try to fix package makefile or mark the recipe as no parallel make, when build faiures are reported. But this greatly impacts user experience for a successfully continuous build process. Could we define a safe number we do want to support for 1.0 release? and then have our autobuilder, QA test, and developers cover that number immediately and fix any issues accordingly. Then the safe number can be suggested to the Yocto user || 2|| Review|| || ktian1|| Enhancement<br />
|-<br />
|| Poky Features || Dependency packages rebuild/clean|| It is a mechanism to rebulid or clean a package and all other packages which have build/runtime dependency on it. With this change, we can find potential influences of package upgrade to its related packages, which can make the incremental build more trustable. For example, if we upgrade a package to a new vesion which changes its API, this mechanism can easily find out the incompatibility to other packages which have dependency on it. || 2|| Review|| || dongxiao.xu|| Enhancement, replaced by checksum feature<br />
|-<br />
|| Distribution / components|| FOSSology|| This may be similar to License Update above, but start to use FOSSology to track licenses. || 2|| Review|| || sgw|| Hygiene<br />
|-<br />
|| Distribution / components|| Package Developer Tools|| Create a set of Init scripts template and then review our current init scripts and modify them to confirm to the template. || 2|| Review|| || sgw|| Easy of Use<br />
|-<br />
|| Distribution / components|| Package Website|| Complete the work the intern has started on generating the distro tracking information and get it out on the external site. || 2|| Review|| || sgw|| "Hygiene, duplicate of ""Package report system"""<br />
|-<br />
|| Distribution / components|| Bluetooth UI support|| Currently we have bluez package in poky, and we need to have a workable graphic user interface to connect/configure BT devices. One choice may be gnome-bluetooth-applet. || 3|| Review|| || dongxiao.xu|| enhancement<br />
|-<br />
|| Distribution / components|| Connman-gnome enhancement features|| Enable connman-gnome to support features like, WPA Enterprise connection, hidden SSID, etc. || 3|| Review|| || dongxiao.xu|| enhancement<br />
|-<br />
|| Distribution / components|| Java Running Environment support|| Since most embedded systems support java applications running in it, maybe we'd better consider supporting some kinds of JVMs(Embeded JVM). The JVM may not run by default, but user can launch it if running java applications. Compared with GTK/QT, java user number is not small too. || 3|| Review|| || criping|| enhancement<br />
|-<br />
|| Distribution / components|| create more use cases|| UPnP demo is one really good use case showing how Yocto is utilized to make real functionality. and we could create more to show how Yocto is easily adapted to real use cases. Those use cases can be either maintained as seperate demo layers in yocto repo, or in seperate branches for reference. We can also call for community's contribution on this which would make 1.0 full-fledged. Or else the newbies to Yocto may be in puzzle how our sample profiles can satisfy their requirements. || 2|| Review|| || ktian1|| enhancement<br />
|-<br />
|| Distribution / components|| i18n support || internationalization is an important system wide feature. Many component like font, locale affect the i18n. Yocto alreay has some i18n related package like pango, but so far did not consider i18n systematically. so this is place holder to systematically add i18n support. || 2|| Review|| || yuke/qing|| enhancement<br />
|-<br />
|| Distribution / components|| more demos || demos are a good way to educate, push the envelope, and at the same time tout the strengths of the platform. This item just records a current set of ideas from various sources which could/should be implemented: * face-recognition/face-finding, * robotic control/application of face-finding to 'camera-as-sensor' (hexbug demo), * others [tbd, add here]|| 2|| Review|| || tzanussi|| enhancement <br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer support for image-creator and needed yocto-metadata design||Come up design what need to be created as packages to support using "opkg install" for image-creator and needed yocto-metadata|| 2|| WIP, pending comments from RP regarding how to packaging metadata|| Jessica|| rpurdie|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer image-creator and needed poky-metadata support|| The poky build system will build packages for image-creator and needed poky-metadata, which the Yocto Installer will be able to use "opkg install" to install them|| 2|| Review|| Jessica|| rpurdie|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Provide qemu management UI|| In current eclipse plugin, QEMU settings are put together with project configuration. So we can only have limited settings. If we can have a separate QEMU management UI, the end user could firstly create a QEMU config, such as (env file of arch, image location, unfs or not, sato or lsb, mem size, disk size). And then he can launch a QEMU with a specific config. The dependency between project configuration and QEMU config will be resolved. After all QEMU has nothing to do project configuration. Need to careful review the UI to ensure minimal impact to testing matrix. || 3|| Review|| || criping|| "Enhancement, duplicate of ""Qemu mem/disk size can be adjusted"""<br />
|-<br />
|| Tool Development and SDK Features|| QT plugin For Eclipse|| Integrate QT Ecplise plugin and extend for Yocto Project || 3|| Review|| || jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Profiling/Trace GUI's|| We have a wealth of great tracing and profiling tools but the UI's for them are all extremely minimal and usually quite ugly. Would be great if we could compete with, or even better, Apple's offerings here. We have the technology! || 2|| Review|| || josh|| "Enhancement, duplicate of ""Tracing/Profiling Planning Complete"""<br />
|-<br />
|| Tool Development and SDK Features|| Other profiling tools|| Complete Tom's review of profiling tools and architecture || 2|| Review|| || josh|| "Enhancement, duplicate of ""Tracing/Profiling Planning Complete"""<br />
|-<br />
|| Tool Development and SDK Features|| Design next-gen tracing/profiling tools|| Yocto 1.0 will include all the essential existing tracing/profiling tools expected by users, and Josh has proposed a UI integration of all those tools as far as it's possible to do so. That level of integration, basically a 'plugin-level' integration is necessary and useful, but doesn't go far enough. A next-generation tracing tool would integrate at a much more fundamental level; if done properly, it would provide unmatched levels of power and usability to users, and would allow Yocto to distinguish itself in the embedded tracing/profiling space in a way also unmatched by any other distro/build-tool. The implementation would of course not be available for Yocto 1.0, but a coherent design, including prototypes, that could be taken to the community and implemented in a V 1.5 or 2.0 should be done in that time frame. || 1|| Review|| || tzanussi|| "Enhancement, duplicate of ""Tracing/Profiling Planning Complete"""<br />
|-<br />
|| Documentation Features|| Self Documentation of image contents|| "I'd like to see the -doc packages Poky builds being combined into some kind of large documentation index representing the collective API docs of the target being built. This can then be placed on a webserver and viewed over the web. We'd have a demonstration of this for a ""bitbake world"" target. Part of the idea here is to start making good use of the docs as if developers see this they might start writing better docs too. Aim is to lead the field :). There are a number of places poky packages disable doc generation due to missing tools so we'd need to add these so we can enable the doc generation. Many packages already have many docs though too. "|| 2|| Review|| || rpurdie|| enhancement<br />
|-<br />
|| Validation|| Testing Framework|| Add a framework for doing automated testing in the project|| 1|| Review|| || davest|| project commitment<br />
|-<br />
|| Validation|| more SDK builds on autobuilder|| enable more SDK related tests on autobuilder such as meta-ide-support, etc.|| 2|| Review|| || ktian1|| project commitment, addressed by test plan (?)<br />
|-<br />
|| Validation|| more people should try using SDK|| this may not be a feature, but a requirement. SDK including meta-toolchain is one key factor impacting user experience on Yocto. It's not enough to have only SDK team play with it|| 2|| Review|| || ktian1|| project commitment, addressed by test plan (?)<br />
|-<br />
|| Validation|| Unit Testing Framework|| Add a mechanism to bitbake to parse source packages that have unit tests and then execute them on the target|| 3|| Review|| || sgw|| "project commitment, duplicate of ""Testing Framework"""<br />
|-<br />
|| Validation|| Test Case open source|| Open source Yocto test cases with xml format|| 1|| Review|| || yyou|| "project commitment, duplicate of ""Testing Framework"""<br />
|}</div>Davesthttps://wiki.yoctoproject.org/wiki/index.php?title=Yocto_1.0_Schedule&diff=591Yocto 1.0 Schedule2011-01-25T01:35:55Z<p>Davest: /* Sprint C (closes Jan 14, 11:59pm PDT -- pull request sent, initially reviewed) */</p>
<hr />
<div>= v1.0 (release date: Apr 15, 2011) =<br />
----<br />
The detailed milestone map for v1.0 is as below. During the first week of each subsequent milestone past M1 we will have a demonstration of the previous milestone capabilities as well as a planning and design session for the current milestone.<br><br><br />
<br />
== M2 (Nov 08 to Dec 24 -- Dev Complete Dec 10, Stabilize Complete Dec 17, Release Complete Dec 24) ==<br />
=== Sprint A (closes Nov 12, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links''' <br />
|-<br />
|| Poky Features || Kernel interactive targets || To support incremental kernel development having the ability to run menuconfig (or xconfig, etc) directly is a common request. We'll need to add this for commercialization anyway. i.e. bitbake -c menuconfig. This fuctionality already exists. || 1 || Done || Richard || bruceashfield || Enhancement <br />
|-<br />
|| Distribution / components || Distro Audit: Upgrades Planned (Phase 1) || Complete plan for package upgrades in M2 || 1 || Done || Saul || || Continual Maintenance<br />
|-<br />
|| Validation || Runtime testing || Runtime testing of images as part of the autobuilder || 1 || Done || Jiajun/ScottG || rpurdie || project commitment<br />
|- <br />
|| || Poky Image Creator Wireframe/Interaction Plans Complete || || 1 || Done || Josh || ||<br />
|-<br />
|| || SDK Generator Interaction: Plans Complete || || 1 || Done || Jessica || ||<br />
|-<br />
|| || Tracing/Profiling Planning Complete || This needs to cover where we're at now, what we're missing and also propose the future enhancements that may be needed. M2 targets getting existing tools integrated and documented. F2f discussion n the future enhancements || || Done || Tom || ||<br />
|-<br />
|| || Swabber. (Still needs to be integrated into weekly build by default) || || 1 || Done || Josh || ||<br />
|-<br />
|| Build/Release || Release process documentation || || || Done || Beth || ||<br />
|-<br />
|| Validation || Test plan for v1.0 (to address any deficiencies in coverage from v0.9)|| || 1 || Done || Jiajun || ||<br />
|}<br />
<br />
=== Sprint B (closes Nov 19, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| Distro Audit: World Packages|| Audit world packages making sure it all build, making sure all are packages are required || 2|| Done || Saul|| sgw|| Hygiene<br />
|-<br />
|| Tool Development and SDK Features|| SDK Generator Installer UI|| Look at different ways of Installer UI (GTK+ and ncurses) seems none of them is the right choice, decide to go with script to implement all the functionalities of installer and later add UI part on top of it || 1||Done|| Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Customize sysroot setup || Add and test out "--sysroot" config option to cross compiler within Eclipse IDE || 1|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| SDK Generator Installer design revision|| Close all open questions regarding Yocto SDK Generator Installer function design and come up HLD || 1|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Distribution / components|| kernel version|| keeping 2.6.34 as a -stable kernel is the best option. I've also got a newer -devel tree that can be made available or made the default. || 3|| Done || Bruce|| bruceashfield|| enhancement<br />
|-<br />
|| || assign Yocto Project PM|| acquire and assign a program manager for Yocto Project|| || Done || DaveST|| || <br />
|-<br />
|| || assign Yocto Project Sys Admin|| || || Done || Saul|| || <br />
|-<br />
|| Tool Development and SDK Features|| oprofileUI|| Fixing various bugs of the oprofileUI to make it workable on big endian host.(i.e. ppc, mips) || 2 || Done || Jessica || lianhao.lu || Bug #382 / Bug #493<br />
|-<br />
|| Poky Feature|| SDK Version Control|| If we can expect that yocto SDK has lots of release in the future, we might need to consider SDK version control. Currently, every thing installed under /opt/poky which leads to things be overriden, we need to be able to use a scheme like /opt/poky-1.0, /opt/poky-2.0 to distiguish things. || 2|| Done || Josh|| jzhang|| Enhancement<br />
|-<br />
|| Kernel || Kernel plan complete || Flesh our kernel deliverables and add to Yocto 1.0 schedule || || Done|| Darren || dvhart ||<br />
|}<br />
<br />
=== Sprint C (closes Nov 26, 11:59pm PDT -- pull request sent, initially reviewed) :: NOTE: this is US Thanksgiving week ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| Distro Audit: Licence Checksums|| licence checksums || 1|| Done || Saul|| rpurdie|| Hygiene<br />
|-<br />
|| Poky Features || Performance Analysis Completed|| "I'd like someone to instrument a green release build, see where it spends time (hot/cold parsing time, individual task building time) and then compare this with our 0.9 release build. I'd also like to compare the disk usage between the two. Once we have a blame list we can then set about fixing it. Some things I know will come up: a) pseudo, b) checksums/signature code, c) exec() vs fork for executing tasks, d) task based prebuilds increasing disk usage, e) rpm dependency calculations, f) using rpm vs. ipk but I may be wrong and there may be others. We need numbers. "|| 1|| Done || Saul / Qing, Dongxiao|| rpurdie|| Enhancement<br />
|-<br />
|| Poky Features || environment variables for kernel builds|| switching a branch, or adding a configuration feature (and even changing the kernel repo) is often done during development of a BSP. Having some additional variables that are pass the bitbake environment scrub would be useful. i.e. KBRANCH=foo bitbake -c configure linux-yocto. This goes along with the other BSP bootstrapping suggestions. || 2|| Done || Bruce|| bruceashfield|| Enhancement<br />
|-<br />
|| Supported Targets|| ARM Platform Support|| Replace beagleboard with Beagleboard XM - decision || 2|| Done || Bruce|| alex|| Basic Yocto hardware support <br />
|-<br />
|| Distribution / components|| Security Process|| We need a dedicated person to scan and apply critical security updates to the distro. The MeeGo team already has a similar process with some scripts which may be leveraged. To complete the task, the process should be documented and a first pass over the metadata made to establish the current position on security. Any upgrades needed should be identified and a plan to address them should be in place but doesn't have to be implemented by this point.|| 1|| Done || ScottG|| ktian1|| enhancement<br />
|-<br />
|| Tool Development and SDK Features|| SDK Generator Installer Opkg repo design|| Come up a opkg repo design that will mimic the final Yocto package repo layout to be used by SDK Generator Installer to test against|| 2 || Done || Jessica || jzhang || <br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer tar creaion|| Create a Yocto Installer tar ball which contains Installer script and supported opkg component that will be used for installing other Yocto components|| 2 || Done || Jessica || jzhang || <br />
|-<br />
|| Documentation|| Kernel Framework Paper from WR|| The paper from WR needs to be re-written and then posted somewhere on the Yocto Project site. This will involve examiniation of the text and re-writing and formatting for presentation. Currently it is simply a text document. Completion time assuming uninterrupted time is one week.|| High|| Done || Scott Rifenbark|| 1 Week|| Documentation<br />
|-<br />
|| Documentation|| Poky Reference Manual|| This guide exists in the 0.9 form. The re-write of the text needs to be completed. So far, all the chapters have been rewritten but not re-posted on the site. Only the appendices remain for a text scrub. Time to complete this would be a week of uninterrupted time. Ideally, the manual would be a sub-manual that would be referenced and architected into the Yocto Project Development Guide.|| Medium|| Done|| Scott Rifenbark|| 1 Week|| Documentation<br />
|-<br />
|| Kernel || Initial meta-linaro layer || meta-linaro layer providing a kernel, tool-chain, and uboot loader. This deliverable is primarily to get the infrastructure in place and have a buildable kernel. Toolchain on best effort basis. || || Done || Darren || dvhart || Moderate risk of slippage due to holidays.<br />
|-<br />
|| Kernel || Tracing: blktrace and sysprof recipes || || || Done || Tom || dvhart ||<br />
|}<br />
<br />
=== Sprint D (closes Dec 3, 11:59pm PDT -- pull request sent, initially reviewed) :: NOTE: week of the F2F planning meeting ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Kernel || Kernel git branching structure revamped || || 1 || Done || Bruce || dvhart ||<br />
|-<br />
|| Kernel || Tunnel Creek (Crown Bay) || || 1 || Done || Tom || dvhart ||<br />
|}<br />
<br />
=== Sprint E (closes Dec 9 (THURSDAY), 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| Distro Audit: Upgrades Completed (Phase 1)|| Update to new versions as per the agreed plan for M2 from Sprint A|| 1|| Done || Saul|| rpurdie|| Continual Maintenance<br />
|-<br />
|| Distribution / components|| Distro Audit: Src Checksums|| Make sure all SRC_URI components have checksums too || 1|| Done || Saul|| rpurdie|| Hygiene<br />
|-<br />
|| Poky Features || enable KVM with qemu|| today all new Intel processors support VT, which are enabled on most desktop machines which are most frequently used build machine. with VT support, x86/x86-64 qemu target runs faster which is a good thing for emulation environment. This may require some qemu option tweaks and also poky-qemu script enhancement. || 2|| Done || Saul / Edwin|| ktian1|| Enhancement<br />
|-<br />
|| Kernel || New kernel recipes || dev, -devel, -custom || 3 || Done || Bruce || dvhart ||<br />
|-<br />
|| Swabber || Documentation for swabber || || 1 || Done || Alex || ||<br />
|-<br />
|| CCB || Defect triage process in public documented and implemented || || 1 || Done. Triage process is documented, out for review. || Saul || ||<br />
|}<br />
<br />
== M3 (Dec 20 to Feb 08 -- Dev Complete Feb 04, Stabilize Complete Feb 11, Release Complete Feb 18) ==<br />
=== Sprint A (closes Dec 24, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Kernel || Initial meta-rt layer || PREEMPT_RT kernel and related test-cases and benchmarks || 2 || Done by Jan 21 || Darren || dvhart || slipped out from M2<br />
|-<br />
|| Poky Features || Fetcher Overhaul Phase 1 - SRC_REV enhancement||<br />
* a) Add code in FetchData::__init__() which will check if the selected fetcher supports srcrev and the automatically call a function to set the src rev value instead of each fetcher doing this.\n <br />
* e) Break SRCREVINACTION deadlock. To do this, we need to start using a keyword for automatically increasing SRCREV, e.g. SRCREV = "AUTOINC". The actual revision can be injected into PV using SRCPV. If we do this there should no longer be a need of the deadlock; <br />
* k) Ensure that we only set __BB_DONT_CACHE when SRCREV = "AUTOREV". This may need a new method call for fetchers to tell whether they're "floating" or locked down.<br />
|| 1|| Done || Saul / Ke, RP|| rpurdie|| Enhancement, slipped out from M2<br />
|-<br />
|| Distribution / components|| Distro Audit Upgrades Planned (Phase 2)|| Complete plan for package upgrades in M2|| 1|| Done || Saul|| || Continual Maintenance<br />
|-<br />
|| Poky Features || Pseudo Performance || Implement the changes to bitbake based on pseudo's enable/disable switch|| 1|| done || Saul / Qing, Dongxiao || rpurdie|| Enhancement, slipped from M2 due to risk and not having Pseudo's change yet.<br />
|-<br />
|| Tool Development and SDK Features|| Fix the issue user target sysroot is owned by root || The ADT installer will use pseudo to extract user target sysroot which ended up owned by root, this need to be fixed || 1|| done || Jessica|| jzhang|| Cleanup <br />
|-<br />
|| Tool Development and SDK Features|| Eclipse poky tree interfacing (metadata file editor)|| Provide a metadata file editor with some syntax checking and keywords highlight capabilities|| 2|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| IDE Project templates|| Templates for various project types: Clutter GUI, Gtk+ GUI, to help developers get started quickly || 2|| Done || Jessica|| josh|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| push TCF/RSE patches upstream|| work with community to finish up our TCF terminal service, TCF/RSE integration remaining patches taken by upstream. Blocking issues including Eclipse Bug #327865 || 1|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Pseudo || Pseudo enhancement to enable on/off switch || || 1 || done || Mark || ||<br />
|-<br />
|| Pseudo || Bitbake enhancement for pseudo on/off switch || || 1 || done || Richard || ||<br />
|-<br />
|| bugzilla || Complete restructure of bugzilla categories || || 1 || done || Saul || ||<br />
|-<br />
|| Poky Features || Image creator ground work || Nomenclature determined, existing gui's bug fixed and backend work implemented || 1 || Done || Joshua || ||<br />
|-<br />
|| Kernel || Tracing: Initial SystemTap recipe || Works on x86 || 3 || Done || Tom || dvhart ||<br />
|-<br />
|| Distribution / components|| Distro Audit: Package Description/Summary completed|| Ensure DESCRIPTION/SUMMARY fields are all audited|| 2|| Done || Mark|| Mark|| Hygiene, was M2, Sprint B but missed window<br />
|-<br />
|| Distribution / components|| Zypper/RPM|| Small write-up of the problems we're having w/ Zypper and what we plan to do. (i.e. create a roadmap/design) - Includes rootfs generation - Package uprev/install/removal || 1 || Done || Mark/Qing || || was M2, Sprint B<br />
|-<br />
|| Distribution / components|| Distro Audit: Licence Checksums|| Make the licence checksums fatal if not present || 1|| Done || Saul|| rpurdie|| Hygiene, was M2, Sprint C<br />
|-<br />
|| Distribution / components|| push of all relevant Wind River patchs to Yocto (patch comparison)|| Ensure patches present to packages in WRS are also in Poky|| 1|| Done || Mark|| Mark|| was M2, Sprint C<br />
|-<br />
|| Poky Features || Performance Enhancement Completed || Initial changes to reduce disk space (sstate-build-*) || 1|| Done || Saul / Qing, Dongxiao || rpurdie|| Enhancement, was M2, Sprint E<br />
|-<br />
|| Distribution / components|| User specified qemu config support|| We'll provide user an edit box which allows advanced qemu user to specify arbitrary qemu configuration to meet their needs, which the poky-qemu scrip will just append the config list towards the end of the list of parameters to bring up qemu, it also expect the poky-qemu script to do some basic sanity check on the user specifications to catch the obvious mistake || 2|| Done || Saul / criping || criping|| enhancement, was M2, Sprint E<br />
|-<br />
|| Tool Development and SDK Features|| SDK Version Control support in SDK generator installer|| If we can expect that yocto SDK has lots of release in the future, we might need to consider SDK version control. Currently, if we un-tar the sdk, it will override the older version. It's not good for app developers since they might need the old version to do something. And also, maybe a finer installer than untar is preferred. Installer will tied to certain SDK version and the installation will go under /opt/poky-versionNo.|| 1|| Done || Jessica|| criping|| Enhancement-expect planning process by Jessica to handle this task. Was M2, Sprint E.<br />
|}<br />
<br />
=== Sprint B (closes Jan 07, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || Bitbake multi-threaded parsing|| Bitbake recipe parsing is currently single threaded. I want to make this multithreaded as the speedup would be nice. If I can only take a single task for myself for 1.0, I'm nominating this one as I enjoy this kind of thing and I have ideas on how to do it. || 1|| Done || Richard|| rpurdie|| Enhancement<br />
|-<br />
|| Distribution / components|| Lock in Kernel/Toolchain version|| Locked in 2.6.37 and gcc 4.5.1. Pending decision to move to 4.5.2 and Linaro || || Done || || Richard|| || <br />
|-<br />
|| Distribution / components|| License Update|| For each of the licences we support, I'd really like to have a licences directory with a copy of that license contained within. When it comes to deciding what a given LICENSE field means, this would be the reference. It also means we can include the licences a given image includes with the image. This continues to make our license handling world class and ahead of the field. || 2|| Done || Beth|| rpurdie|| Hygiene<br />
|-<br />
|| Tool Development and SDK Features|| Qemu configuration change|| Provice edit box for advanced user to specify qemu configurations|| 2|| Done || Jessica|| criping|| <br />
|-<br />
|| Tool Development and SDK Features|| Lock down Eclipse+CDT+TCF version|| Will use Eclipse Halo 3.6 || 1|| Done || Jessica|| || <br />
|-<br />
|| Demo|| Finalize on demo plans for v1.0 launch || || 1|| Done || Dave || || <br />
|-<br />
|| Release || Release plans for v1.0 launch || Fill out the M4 plan with the necessary release activities and timings || 1|| Done || Beth || || <br />
|-<br />
|| Poky Features || Basic image creator GUI || Functional UI missing some Advanced features || 1 || In replan || Joshua || || <br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer for SDK Generator Installation functions support||Detailed feature request can be found at: http://bugzilla.pokylinux.org/show_bug.cgi?id=589|| 1|| Done || Jessica|| rpurdie|| Enhancement<br />
|-<br />
|| Kernel || Tracing: trace-cmd python binding cleanup || || 3 || Done || Darren || dvhart ||<br />
|}<br />
<br />
=== Sprint C (closes Jan 14, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || kernel development layer|| The (correct) poky behaviour of building known revisions coupled with the fetcher requiring a BSP branch to already be present means that local modifications (and kernel source tree) are required for kernel development. I already have a layer that overrides/modifies the behaviour when added to the bblayers.conf and configured into an environment. This seems useful for more people to use. || 2|| Done || Bruce|| bruceashfield|| Enhancement, was M2, Sprint C<br />
|-<br />
|| Distribution / components|| Zypper/RPM|| RPM Uprev / Zypper Uprev [lets get to the latest versions]|| 1|| pull request by Jan 19; || Mark/Qing|| || was M2, Sprint C<br />
|-<br />
|| Supported Targets|| Intel Platform Support|| JasperForest|| 2|| Basic support in place; DPDK evaluation in process, overall BSP plan still TBD || Tom|| davest|| Basic ECG support (Moved from Sprint A)<br />
|-<br />
|| Tool Development and SDK Features|| Eclipse poky tree interfacing (git support)|| Use Eclipse git capability to install poky tree from git repo and able to interact with git repo at file level within Poky tree || 2|| Done || Jessica|| jzhang|| Enhancement<br />
<br />
|-<br />
|| Poky Features || Poky Image Creator|| A standalone application you can run which asks you to select a distro and machine, then presents a list of packages you can select. Once the selection is made, it goes off and bakes you an image which is then presented to you. Implementation wise, it should use the sstate packages, be a bitbake UI and use the usual poky bbclass files to do the image construction behind the scenes. || 1|| Re-plan || Joshua|| rpurdie|| Enhancement<br />
|-<br />
|| Distribution / components|| LSB Sanity|| execute LSB Test and improve passing rate and document failures with clear understanding|| 2|| Done || MarkH/Saul|| sgw|| Hygiene<br />
|-<br />
|| Tool Development and SDK Features|| Image creator integration with Eclipse || || 2|| replan|| Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Kernel || Tracing: perf trace marker support || This is from feedback to the new trace command. Ingo appears to have this nearly complete already. || 3 || Done || Darren || dvhart ||<br />
|-<br />
|| Cleanup || bitbake user experience error handling validation completed || || 2 || Done || Richard || ||<br />
|-<br />
|| Cleanup || variable scrub - ensure all metadata variables are documented || Script with a histogram of variable use done, identified 50 variables to document; Add task for actual documentation update is low on the list || 2 || Done || Scott/Darren || ||<br />
|-<br />
|| Distribution / components|| Zypper/RPM|| Integration based on design from Sprint B|| 1|| On track for Jan28 || Mark/Qing|| sgw|| Functionality, was M2, Sprint E<br />
|-<br />
|| Kernel || Tracing: package kernelshark || || 3 || Done || Darren || dvhart ||<br />
|-<br />
|| Kernel || Tracing: tuna, oscillosope recipes || || 3 || Tom to discuss plan with Darren et al || Tom || dvhart ||<br />
|- <br />
|| BSP || Beagleboard XM Support || || 3 || Move to Sprint D || Darren || dvhart ||<br />
|}<br />
<br />
=== Sprint D (closes Jan 21, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Swabber || Complete review of swabber outputs || Move to M3 Sprint D || 1 || Move to M3 Sprint D || Alex || ||<br />
|-<br />
|| Poky Features || Fetcher Overhaul Phase 2 - API reorg||<br />
* f) Add a generic unpack funciton to __init__.py based on the unpack task in Poky ;<br />
* g) Split go() methods into the following steps: i) download() - do whatever transfer is necessary to get the sources locally ii) build_mirror_data() - generate any data that would be needed to construct a source mirror iii) unpack() - takes a directory as an argument of where to place extracted sources;<br />
The existing go() methods should be replaced with a set of calls to the above sections of functionality as appropriate in the individual fetchers. Some of these categories of function make no sense in certain fetchers, in which case they shouldn't need to implement them. Functions are only executed if the method is present.<br />
* h) Change Poky's unpack to call an unpack method in the fetchers.<br />
* i) Change Poky's fetch task to call a "download" method in the fetcher instead of go().<br />
|| 1|| Will land with phase 3 in Jan 21 || Saul / Ke, RP|| rpurdie|| Enhancement<br />
|-<br />
|| Poky Features || Fetcher Overhaul Phase 3 - git enhancement||<br />
* j) Optimize git fetcher for the new layout so for a git checkout, we clone the repository in download(), then unpack just does a clone with references to the original repo. <br />
* k) Ensure that we only set __BB_DONT_CACHE when SRCREV = "AUTOREV". This may need a new method call for fetchers to tell whether they're "floating" or locked down. <br />
* l) Add a new "BB_NO_NETWORK" variable which the fetchers check before peforming an operation which hits anything remote. This means adding in error messages about why network access is needed at various points (e.g. SRCREV = "AUTOREV" for a given recipe) <br />
* m) Add multiple branch/srcrev support for git fetcher. These would be of the form: git://somelocation/somerepo.git;name=ref1;branch=foo;name=ref2;branch=bar SRCREV_ref1 = "hash1" SRCREV_ref2 = "hash2" which would ensure both hash1 and hash2 were in the final repo. <br />
* n) Change git fetcher to default to git protocol instead of rsync<br />
|| 1|| Slipped to Sprint D || Saul / Ke, RP|| rpurdie|| Enhancement<br />
|-<br />
|| Poky Features || DSO linking changes|| "By the default the gcc linker will automatically link any dependant objects/libraries. ""Inherited"" linkages can cause issues, for example, where a shared object changes its dependencies but a program has come to rely on symbols from an implicitly linked library. Fedora implemented this change in F13, seems like it would be useful to have in Poky too. "|| 2|| On track for Jan 21 || Saul / Nitin || josh|| bug#516<br />
|-<br />
|| Distribution / components|| Distro Audit Documentation Output|| Audit package documentation output || 2|| Move to Sprint D due to libtool work || Saul / ScottG || rpurdie|| Hygiene<br />
|-<br />
|| Distribution / components|| Review & Fix Standards Tests|| Review the results from LTP, POSIX and asses the result, fix as appropriate and clearly document failures.|| 2|| a Plan to resolve final items to be sent to the m.l. by Jan 14 || Saul/Kevin || sgw|| Hygiene<br />
|-<br />
|| Poky Features || libtool sysroot option|| libtool 2.4 has a sysroot option. We should try and use it, see how it works and whether we can ditch some of our libtool hacks. || 1|| On track for Jan 21 || Saul / ScottG || rpurdie|| Enhancement<br />
|-<br />
|| Distribution / components|| MACHINE or Recipe specific sysroots|| Each machine should have its own sysroot. We'll probably have to split do_populate_sysroot into a two step process, creation of the package and than installtion of the package, which the installation of the package being made machine specific (put ${MACHINE} into ${STAMP} and bitbake should do that). Also allowing this to work per recipe would be desireable|| 1|| On track 21 || Saul / Dongxiao || rpurdie|| Hygiene<br />
|-<br />
|| Distribution / components|| Toolchain Bootstrap Process|| The toolchain as it bootstraps overwrites files like libc.so and libgcc.so in the sysroot directory which causes issues if you just try and rebuild part of the toolchain. Each step of the bootstrap process should use a separate sysroot. Once this is once, sstate file overwriting detection can be added and enabled. || 1|| Patches submitted for comment, slip to Sprint D || Saul / Dexuan || rpurdie|| Hygiene<br />
|-<br />
|| Documentation Features|| Package report system|| move to public server [setup a package report system in an internal machine. We need push it publicly available. The basic features like search and report have been there. But there're still some enhancements in plan, to make it a fit place to feel Yocto metadata comfortably]|| 2|| Move to Sprint E|| KevinT|| ktian1|| enhancement<br />
|-<br />
|| Distribution / components||Add headers and libraries to qemu images ||Since we'll be using qemu images as target sysroot, need to create a set of qemu images for minimal, sato, LSB that contains target header and libraries.|| 2|| Pending a discussion on Jan 18 || Saul ||jzhang|| Enhancement<br />
|-<br />
|| Distribution / components|| push of all relevant Wind River patchs to Yocto (patch comparison)|| Update any additional patches needed since M2.|| 1|| May be done by Jan 21, pending RPM stuff || Mark|| Mark|| <br />
|-<br />
|| Distribution / components|| mklibs|| mklibs is a tool to optimize size of [e]glibc for a perticular root file system image. It is useful to save disk space on small devices. || 2|| Push to Sprint E || Saul|| Nitin Kamble|| enhancement<br />
|-<br />
|| Poky Features || Performance Enhancement || reduce disk space (hardlink) || 1 || On track for Jan 21, pending RP review || Saul / Qing, Dongxiao || rpurdie || Enhancement<br />
|-<br />
|| BSP || 2.6.37 Crown Bay Support || On Track for Jan 21 || 2 || || Tom || dvhart || <br />
|-<br />
|| BSP || 2.6.37 Emenlow Support || On track for Jan 21 || 2 || || Tom || dvhart || <br />
|}<br />
<br />
=== Sprint E (closes Jan 28, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| rootless X|| rootless x server has better security than x server launched by root. MeeGo already enable this feature. it would be nice for Yocto to also enable it. || 2|| On track for Jan 28 || Saul / Ke || yuke|| enhancement<br />
|-<br />
|| Documentation Features|| Package report system|| finish major feature development and internal review [setup a package report system in an internal machine. We need push it publicly available. The basic features like search and report have been there. But there're still some enhancements in plan, to make it a fit place to feel Yocto metadata comfortably]|| 2|| Move to Sprint E || Jonathan || ktian1|| enhancement, was M2, Sprint E<br />
|-<br />
|| Distribution / components|| perl upgrade|| perl is the most cross un-friendly recipe pending upgrade. || 2|| Slipping due to Linaro layer, moves to end of Sprint E || Nitin|| Nitin Kamble|| enhancement<br />
|-<br />
|| Supported Targets|| Intel Platform Support|| Sandybridge|| 2|| Accept|| Tom|| davest|| Basic ECG support<br />
|-<br />
|| Distribution / components|| performance indicators|| define some indicators (boot time, footprint, build time, power, component benchmarks, etc.) and then collect them for tracking purpose. The result could be posted on the wiki site, and the initial indicators can be easy ones which can be easily retrieved from autobuilder or weekly qa report). This way we have a clear track about the healthy of the Yocto project, and also identify weak areas. We can include qemu targets and several representational boards as the targets. || 2|| Review|| Beth/Jiajun|| ktian1|| enhancement<br />
|-<br />
|| Tool Development and SDK Features|| SDK user workshop|| Have some developers sit down and use our tools to develop demo software for Yocto. || 2|| Review|| Jessica|| josh|| Enhancement<br />
|-<br />
|| Kernel || Final linux-yocto_git.bb || With 2.6.37 kernel || 1 || || Bruce || dvhart ||<br />
|-<br />
|| Kernel || Final meta-linaro layer || || || || Darren || dvhart ||<br />
|-<br />
|| Kernel || Final meta-rt layer || || || || Darren || dvhart ||<br />
|-<br />
|| Kernel || Sandy Bridge || || 1 || || Tom || dvhart ||<br />
|}<br />
<br />
=== Sprint F (closes Feb 03 (THURSDAY), 11:59pm PDT -- pull request sent, initially reviewed) :: NOTE: China New Year Holiday ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Documentation|| ADT Reference Guide Draft out for review || Outline complete|| High|| WIP || Scott Rifenbark|| jzhang|| Documentation<br />
|-<br />
|| || || || || || || || <br />
|}<br />
<br />
== M4 (Feb 07 to Apr 15 -- Stabilize Complete Mar 18, Release Complete Apr 01, Contingency to Apr 15) ==<br />
<br />
This sprint is the [[Yocto Project v. 1.0 Release Cycle]].<br />
<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Documentation|| Migration chapter in the Poky Reference Manual|| This chapter would cover the four identified use-cases for migrating up to the most recent version of Yocto Project. Additionally, it would cover migration scenarios from other development systems. The chapter does not yet exist. The chapter has not been scoped outside of having a meeting that identified four use-cases that did not include migration from a development system outside of Yocto Project. It will take some more scoping time to cover those areas (a day or two). Again, I have no idea of the length. See earlier entries for standard industry writing estimates for software documentation|| Medium|| Not Started|| Scott Rifenbark|| 3-4 Weeks|| Documentation<br />
|-<br />
|| Documentation|| Yocto Project Development Guide|| This manual would be an over-arching document that frames the complete development cycle within Yocto Project. The idea here is that the document would be an umbrella document that spawned and referenced subsequent documents. The organization would be the first chapter overviewing the major development pieces such as recipe creation, building, debugging, publishing, fail-safing, back-door hook creation, etc. Scoping would be about two weeks and length would probably be about 40 pages. Overall development time would likely be a month of uniterruped time.|| Medium|| Not Started|| Scott Rifenbark|| 3 Weeks|| Documentation<br />
|-<br />
|| Validation|| Boottime/Performance Analysis|| Compare Yocto Project performance to other projects such as MeeGo|| 1|| Initial report on where we are by Feb 9 || Darren|| davest|| project commitment<br />
|-<br />
|| || Multilib Support|| Consider developing post-1.0 branch || 1|| to start in M4 || Richard|| ||<br />
|-<br />
|| Validation|| Alpha testing complete|| 4-5 internal developers unfamiliar with Yocto Project try to do a build and report on the experience and issues encountered|| 1|| Done by Feb 18 || Julie|| davest|| <br />
|-<br />
|| || || || || || || || <br />
|}<br />
<br />
== Features needed and to be put into sprints by assigned owners: ==<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || package config option enhancement|| there're several enhancements we may do here: * allow users setting specific config options (local or global) from external tool, such as poky image creator, instead of changing recipes manually. Need a mechanism to convert from variable assignments into exact config options (e.g. feature_${PN} = ""1"" -> ""--enable-feature""). Consequently dependency chain needs update with option status. * host contamination check. We have swabber to check host contamination, but I'm not sure whether it covers configuration phase. If not, this is one area to improve, as not ususually we see configure script checks host bits for available features * conditional option manipulation. In many recipes we enable/disable one option based on availability of other packages. Now this is done manually and not flexible. this should be made automatically though some new annotation to indicate condition, or just base_contains (not convenient: long line, need define distro features) || 2|| Review|| Richard/MarkH|| ktian1|| Enhancement<br />
|-<br />
|| Media|| Yocto Project Awareness Video|| This 2.5 minute video would introduce and describe the benefits of Yocto Project. The video would use entertaining animations that described concepts and benefits. The result would be suitable for YouTube, conferences, and the website. The production is called an "Epipheo" and will be created by Epipheo Studios. The engagement process has begun and the kick-off meeting will be soon. The PO is in place. Time for development is 10 weeks.|| High|| Kick-off Imminent|| Scott Rifenbark|| 10 Weeks|| Media<br />
|-<br />
|| Documentation|| Yocto Project Debugging Guide|| This would be a guide for the debugging and bug tracking process in Yocto Project. Originally, the thought was that we needed a Bugzilla User's Manual. However, since we don't own Bugzilla it doesn't make sense to produce documentation for it. Rather, we should document the process as it fits into the Yocto Project environment. Ideally, the manual would be a sub-manual that would be referenced and architected into the Yocto Project Development Guide. The manual has not been scoped and would take a week to scope. Again, I have no idea of the length. See the previous item for standard industry writing estimates for software documenation.|| Medium|| Not Started|| Scott Rifenbark|| 3-4 Weeks|| Documentation<br />
|-<br />
|| Website|| Yocto Project Website|| The 0.9 website is in place but needs updates. Items for consideration are the left-panel naviagation scheme, a contributions guidance page, color-scheming and theme (possibly).|| Medium|| Not Started|| Scott Rifenbark|| 1-2 Weeks|| Website<br />
|}<br />
<br />
== Features not believed to be needed in v1.0: ==<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || OpenEmbedded/Bitbake Upstreaming|| "We firstly need to review where we are and where OE is. We then need to make a plan about what we're going to push upstream and what we're not. I'd suggest when we're in PRC, we do a crash course in ""dealing with OE"" and then many dedicate a block of time (a week) where the distro team comes up with a patch set we then propose and get merged into OE. I'd like to find a couple of interested people to monitor OE more regularly and start a workflow of things between Poky/OE where appropriate. The key thing to remember is we need to keep the architectures compatible. The team is now at the point where I'm happy for them to actually try building OpenEmbedded and not worry about it tainting them! "|| 2|| Review|| || rpurdie|| Process<br />
|-<br />
|| Poky Features || Handle old versions in WORKDIR|| an incremental build directory may finally include many old versions WORKDIRS. It'll be good to have those old versions tracked in the cache, which can then either generate a report or allow selectively cleaning up an specific version WORKDIR. Or else it's difficult to figure it out when people want to keep the whole tmp directory but like to cleanup some old bits when disk usage is under pressure. If it's not easy to do in bitbake, perhaps some separate scripts would be also helpful || 3|| Review|| || ktian1|| Enhancement<br />
|-<br />
|| Poky Features || run bitbake w/o rebuilding the cache|| "sometimes it's useful to allow run bitbake w/o re-parsing recipes, if we know nothing metadata is changed. we can just allow reusing existing persistent cache. this is useful when people is debugging WORKDIR w/o metadata change. also sometimes ""bitbake -e"" is used frequently to check poky variable information. with existing cache, several seconds can be saved which are not negligible for a developer daily working on Yocto "|| 2|| Review|| || ktian1|| Enhancement<br />
|-<br />
|| Poky Features || parallel make improvement|| parallel make experience is not good, especially when bb threads and make threads are increased larger than 8. So far we either try to fix package makefile or mark the recipe as no parallel make, when build faiures are reported. But this greatly impacts user experience for a successfully continuous build process. Could we define a safe number we do want to support for 1.0 release? and then have our autobuilder, QA test, and developers cover that number immediately and fix any issues accordingly. Then the safe number can be suggested to the Yocto user || 2|| Review|| || ktian1|| Enhancement<br />
|-<br />
|| Poky Features || Dependency packages rebuild/clean|| It is a mechanism to rebulid or clean a package and all other packages which have build/runtime dependency on it. With this change, we can find potential influences of package upgrade to its related packages, which can make the incremental build more trustable. For example, if we upgrade a package to a new vesion which changes its API, this mechanism can easily find out the incompatibility to other packages which have dependency on it. || 2|| Review|| || dongxiao.xu|| Enhancement, replaced by checksum feature<br />
|-<br />
|| Distribution / components|| FOSSology|| This may be similar to License Update above, but start to use FOSSology to track licenses. || 2|| Review|| || sgw|| Hygiene<br />
|-<br />
|| Distribution / components|| Package Developer Tools|| Create a set of Init scripts template and then review our current init scripts and modify them to confirm to the template. || 2|| Review|| || sgw|| Easy of Use<br />
|-<br />
|| Distribution / components|| Package Website|| Complete the work the intern has started on generating the distro tracking information and get it out on the external site. || 2|| Review|| || sgw|| "Hygiene, duplicate of ""Package report system"""<br />
|-<br />
|| Distribution / components|| Bluetooth UI support|| Currently we have bluez package in poky, and we need to have a workable graphic user interface to connect/configure BT devices. One choice may be gnome-bluetooth-applet. || 3|| Review|| || dongxiao.xu|| enhancement<br />
|-<br />
|| Distribution / components|| Connman-gnome enhancement features|| Enable connman-gnome to support features like, WPA Enterprise connection, hidden SSID, etc. || 3|| Review|| || dongxiao.xu|| enhancement<br />
|-<br />
|| Distribution / components|| Java Running Environment support|| Since most embedded systems support java applications running in it, maybe we'd better consider supporting some kinds of JVMs(Embeded JVM). The JVM may not run by default, but user can launch it if running java applications. Compared with GTK/QT, java user number is not small too. || 3|| Review|| || criping|| enhancement<br />
|-<br />
|| Distribution / components|| create more use cases|| UPnP demo is one really good use case showing how Yocto is utilized to make real functionality. and we could create more to show how Yocto is easily adapted to real use cases. Those use cases can be either maintained as seperate demo layers in yocto repo, or in seperate branches for reference. We can also call for community's contribution on this which would make 1.0 full-fledged. Or else the newbies to Yocto may be in puzzle how our sample profiles can satisfy their requirements. || 2|| Review|| || ktian1|| enhancement<br />
|-<br />
|| Distribution / components|| i18n support || internationalization is an important system wide feature. Many component like font, locale affect the i18n. Yocto alreay has some i18n related package like pango, but so far did not consider i18n systematically. so this is place holder to systematically add i18n support. || 2|| Review|| || yuke/qing|| enhancement<br />
|-<br />
|| Distribution / components|| more demos || demos are a good way to educate, push the envelope, and at the same time tout the strengths of the platform. This item just records a current set of ideas from various sources which could/should be implemented: * face-recognition/face-finding, * robotic control/application of face-finding to 'camera-as-sensor' (hexbug demo), * others [tbd, add here]|| 2|| Review|| || tzanussi|| enhancement <br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer support for image-creator and needed yocto-metadata design||Come up design what need to be created as packages to support using "opkg install" for image-creator and needed yocto-metadata|| 2|| WIP, pending comments from RP regarding how to packaging metadata|| Jessica|| rpurdie|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer image-creator and needed poky-metadata support|| The poky build system will build packages for image-creator and needed poky-metadata, which the Yocto Installer will be able to use "opkg install" to install them|| 2|| Review|| Jessica|| rpurdie|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Provide qemu management UI|| In current eclipse plugin, QEMU settings are put together with project configuration. So we can only have limited settings. If we can have a separate QEMU management UI, the end user could firstly create a QEMU config, such as (env file of arch, image location, unfs or not, sato or lsb, mem size, disk size). And then he can launch a QEMU with a specific config. The dependency between project configuration and QEMU config will be resolved. After all QEMU has nothing to do project configuration. Need to careful review the UI to ensure minimal impact to testing matrix. || 3|| Review|| || criping|| "Enhancement, duplicate of ""Qemu mem/disk size can be adjusted"""<br />
|-<br />
|| Tool Development and SDK Features|| QT plugin For Eclipse|| Integrate QT Ecplise plugin and extend for Yocto Project || 3|| Review|| || jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Profiling/Trace GUI's|| We have a wealth of great tracing and profiling tools but the UI's for them are all extremely minimal and usually quite ugly. Would be great if we could compete with, or even better, Apple's offerings here. We have the technology! || 2|| Review|| || josh|| "Enhancement, duplicate of ""Tracing/Profiling Planning Complete"""<br />
|-<br />
|| Tool Development and SDK Features|| Other profiling tools|| Complete Tom's review of profiling tools and architecture || 2|| Review|| || josh|| "Enhancement, duplicate of ""Tracing/Profiling Planning Complete"""<br />
|-<br />
|| Tool Development and SDK Features|| Design next-gen tracing/profiling tools|| Yocto 1.0 will include all the essential existing tracing/profiling tools expected by users, and Josh has proposed a UI integration of all those tools as far as it's possible to do so. That level of integration, basically a 'plugin-level' integration is necessary and useful, but doesn't go far enough. A next-generation tracing tool would integrate at a much more fundamental level; if done properly, it would provide unmatched levels of power and usability to users, and would allow Yocto to distinguish itself in the embedded tracing/profiling space in a way also unmatched by any other distro/build-tool. The implementation would of course not be available for Yocto 1.0, but a coherent design, including prototypes, that could be taken to the community and implemented in a V 1.5 or 2.0 should be done in that time frame. || 1|| Review|| || tzanussi|| "Enhancement, duplicate of ""Tracing/Profiling Planning Complete"""<br />
|-<br />
|| Documentation Features|| Self Documentation of image contents|| "I'd like to see the -doc packages Poky builds being combined into some kind of large documentation index representing the collective API docs of the target being built. This can then be placed on a webserver and viewed over the web. We'd have a demonstration of this for a ""bitbake world"" target. Part of the idea here is to start making good use of the docs as if developers see this they might start writing better docs too. Aim is to lead the field :). There are a number of places poky packages disable doc generation due to missing tools so we'd need to add these so we can enable the doc generation. Many packages already have many docs though too. "|| 2|| Review|| || rpurdie|| enhancement<br />
|-<br />
|| Validation|| Testing Framework|| Add a framework for doing automated testing in the project|| 1|| Review|| || davest|| project commitment<br />
|-<br />
|| Validation|| more SDK builds on autobuilder|| enable more SDK related tests on autobuilder such as meta-ide-support, etc.|| 2|| Review|| || ktian1|| project commitment, addressed by test plan (?)<br />
|-<br />
|| Validation|| more people should try using SDK|| this may not be a feature, but a requirement. SDK including meta-toolchain is one key factor impacting user experience on Yocto. It's not enough to have only SDK team play with it|| 2|| Review|| || ktian1|| project commitment, addressed by test plan (?)<br />
|-<br />
|| Validation|| Unit Testing Framework|| Add a mechanism to bitbake to parse source packages that have unit tests and then execute them on the target|| 3|| Review|| || sgw|| "project commitment, duplicate of ""Testing Framework"""<br />
|-<br />
|| Validation|| Test Case open source|| Open source Yocto test cases with xml format|| 1|| Review|| || yyou|| "project commitment, duplicate of ""Testing Framework"""<br />
|}</div>Davesthttps://wiki.yoctoproject.org/wiki/index.php?title=Yocto_1.0_Schedule&diff=590Yocto 1.0 Schedule2011-01-25T01:33:12Z<p>Davest: /* Sprint D (closes Jan 21, 11:59pm PDT -- pull request sent, initially reviewed) */</p>
<hr />
<div>= v1.0 (release date: Apr 15, 2011) =<br />
----<br />
The detailed milestone map for v1.0 is as below. During the first week of each subsequent milestone past M1 we will have a demonstration of the previous milestone capabilities as well as a planning and design session for the current milestone.<br><br><br />
<br />
== M2 (Nov 08 to Dec 24 -- Dev Complete Dec 10, Stabilize Complete Dec 17, Release Complete Dec 24) ==<br />
=== Sprint A (closes Nov 12, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links''' <br />
|-<br />
|| Poky Features || Kernel interactive targets || To support incremental kernel development having the ability to run menuconfig (or xconfig, etc) directly is a common request. We'll need to add this for commercialization anyway. i.e. bitbake -c menuconfig. This fuctionality already exists. || 1 || Done || Richard || bruceashfield || Enhancement <br />
|-<br />
|| Distribution / components || Distro Audit: Upgrades Planned (Phase 1) || Complete plan for package upgrades in M2 || 1 || Done || Saul || || Continual Maintenance<br />
|-<br />
|| Validation || Runtime testing || Runtime testing of images as part of the autobuilder || 1 || Done || Jiajun/ScottG || rpurdie || project commitment<br />
|- <br />
|| || Poky Image Creator Wireframe/Interaction Plans Complete || || 1 || Done || Josh || ||<br />
|-<br />
|| || SDK Generator Interaction: Plans Complete || || 1 || Done || Jessica || ||<br />
|-<br />
|| || Tracing/Profiling Planning Complete || This needs to cover where we're at now, what we're missing and also propose the future enhancements that may be needed. M2 targets getting existing tools integrated and documented. F2f discussion n the future enhancements || || Done || Tom || ||<br />
|-<br />
|| || Swabber. (Still needs to be integrated into weekly build by default) || || 1 || Done || Josh || ||<br />
|-<br />
|| Build/Release || Release process documentation || || || Done || Beth || ||<br />
|-<br />
|| Validation || Test plan for v1.0 (to address any deficiencies in coverage from v0.9)|| || 1 || Done || Jiajun || ||<br />
|}<br />
<br />
=== Sprint B (closes Nov 19, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| Distro Audit: World Packages|| Audit world packages making sure it all build, making sure all are packages are required || 2|| Done || Saul|| sgw|| Hygiene<br />
|-<br />
|| Tool Development and SDK Features|| SDK Generator Installer UI|| Look at different ways of Installer UI (GTK+ and ncurses) seems none of them is the right choice, decide to go with script to implement all the functionalities of installer and later add UI part on top of it || 1||Done|| Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Customize sysroot setup || Add and test out "--sysroot" config option to cross compiler within Eclipse IDE || 1|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| SDK Generator Installer design revision|| Close all open questions regarding Yocto SDK Generator Installer function design and come up HLD || 1|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Distribution / components|| kernel version|| keeping 2.6.34 as a -stable kernel is the best option. I've also got a newer -devel tree that can be made available or made the default. || 3|| Done || Bruce|| bruceashfield|| enhancement<br />
|-<br />
|| || assign Yocto Project PM|| acquire and assign a program manager for Yocto Project|| || Done || DaveST|| || <br />
|-<br />
|| || assign Yocto Project Sys Admin|| || || Done || Saul|| || <br />
|-<br />
|| Tool Development and SDK Features|| oprofileUI|| Fixing various bugs of the oprofileUI to make it workable on big endian host.(i.e. ppc, mips) || 2 || Done || Jessica || lianhao.lu || Bug #382 / Bug #493<br />
|-<br />
|| Poky Feature|| SDK Version Control|| If we can expect that yocto SDK has lots of release in the future, we might need to consider SDK version control. Currently, every thing installed under /opt/poky which leads to things be overriden, we need to be able to use a scheme like /opt/poky-1.0, /opt/poky-2.0 to distiguish things. || 2|| Done || Josh|| jzhang|| Enhancement<br />
|-<br />
|| Kernel || Kernel plan complete || Flesh our kernel deliverables and add to Yocto 1.0 schedule || || Done|| Darren || dvhart ||<br />
|}<br />
<br />
=== Sprint C (closes Nov 26, 11:59pm PDT -- pull request sent, initially reviewed) :: NOTE: this is US Thanksgiving week ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| Distro Audit: Licence Checksums|| licence checksums || 1|| Done || Saul|| rpurdie|| Hygiene<br />
|-<br />
|| Poky Features || Performance Analysis Completed|| "I'd like someone to instrument a green release build, see where it spends time (hot/cold parsing time, individual task building time) and then compare this with our 0.9 release build. I'd also like to compare the disk usage between the two. Once we have a blame list we can then set about fixing it. Some things I know will come up: a) pseudo, b) checksums/signature code, c) exec() vs fork for executing tasks, d) task based prebuilds increasing disk usage, e) rpm dependency calculations, f) using rpm vs. ipk but I may be wrong and there may be others. We need numbers. "|| 1|| Done || Saul / Qing, Dongxiao|| rpurdie|| Enhancement<br />
|-<br />
|| Poky Features || environment variables for kernel builds|| switching a branch, or adding a configuration feature (and even changing the kernel repo) is often done during development of a BSP. Having some additional variables that are pass the bitbake environment scrub would be useful. i.e. KBRANCH=foo bitbake -c configure linux-yocto. This goes along with the other BSP bootstrapping suggestions. || 2|| Done || Bruce|| bruceashfield|| Enhancement<br />
|-<br />
|| Supported Targets|| ARM Platform Support|| Replace beagleboard with Beagleboard XM - decision || 2|| Done || Bruce|| alex|| Basic Yocto hardware support <br />
|-<br />
|| Distribution / components|| Security Process|| We need a dedicated person to scan and apply critical security updates to the distro. The MeeGo team already has a similar process with some scripts which may be leveraged. To complete the task, the process should be documented and a first pass over the metadata made to establish the current position on security. Any upgrades needed should be identified and a plan to address them should be in place but doesn't have to be implemented by this point.|| 1|| Done || ScottG|| ktian1|| enhancement<br />
|-<br />
|| Tool Development and SDK Features|| SDK Generator Installer Opkg repo design|| Come up a opkg repo design that will mimic the final Yocto package repo layout to be used by SDK Generator Installer to test against|| 2 || Done || Jessica || jzhang || <br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer tar creaion|| Create a Yocto Installer tar ball which contains Installer script and supported opkg component that will be used for installing other Yocto components|| 2 || Done || Jessica || jzhang || <br />
|-<br />
|| Documentation|| Kernel Framework Paper from WR|| The paper from WR needs to be re-written and then posted somewhere on the Yocto Project site. This will involve examiniation of the text and re-writing and formatting for presentation. Currently it is simply a text document. Completion time assuming uninterrupted time is one week.|| High|| Done || Scott Rifenbark|| 1 Week|| Documentation<br />
|-<br />
|| Documentation|| Poky Reference Manual|| This guide exists in the 0.9 form. The re-write of the text needs to be completed. So far, all the chapters have been rewritten but not re-posted on the site. Only the appendices remain for a text scrub. Time to complete this would be a week of uninterrupted time. Ideally, the manual would be a sub-manual that would be referenced and architected into the Yocto Project Development Guide.|| Medium|| Done|| Scott Rifenbark|| 1 Week|| Documentation<br />
|-<br />
|| Kernel || Initial meta-linaro layer || meta-linaro layer providing a kernel, tool-chain, and uboot loader. This deliverable is primarily to get the infrastructure in place and have a buildable kernel. Toolchain on best effort basis. || || Done || Darren || dvhart || Moderate risk of slippage due to holidays.<br />
|-<br />
|| Kernel || Tracing: blktrace and sysprof recipes || || || Done || Tom || dvhart ||<br />
|}<br />
<br />
=== Sprint D (closes Dec 3, 11:59pm PDT -- pull request sent, initially reviewed) :: NOTE: week of the F2F planning meeting ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Kernel || Kernel git branching structure revamped || || 1 || Done || Bruce || dvhart ||<br />
|-<br />
|| Kernel || Tunnel Creek (Crown Bay) || || 1 || Done || Tom || dvhart ||<br />
|}<br />
<br />
=== Sprint E (closes Dec 9 (THURSDAY), 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| Distro Audit: Upgrades Completed (Phase 1)|| Update to new versions as per the agreed plan for M2 from Sprint A|| 1|| Done || Saul|| rpurdie|| Continual Maintenance<br />
|-<br />
|| Distribution / components|| Distro Audit: Src Checksums|| Make sure all SRC_URI components have checksums too || 1|| Done || Saul|| rpurdie|| Hygiene<br />
|-<br />
|| Poky Features || enable KVM with qemu|| today all new Intel processors support VT, which are enabled on most desktop machines which are most frequently used build machine. with VT support, x86/x86-64 qemu target runs faster which is a good thing for emulation environment. This may require some qemu option tweaks and also poky-qemu script enhancement. || 2|| Done || Saul / Edwin|| ktian1|| Enhancement<br />
|-<br />
|| Kernel || New kernel recipes || dev, -devel, -custom || 3 || Done || Bruce || dvhart ||<br />
|-<br />
|| Swabber || Documentation for swabber || || 1 || Done || Alex || ||<br />
|-<br />
|| CCB || Defect triage process in public documented and implemented || || 1 || Done. Triage process is documented, out for review. || Saul || ||<br />
|}<br />
<br />
== M3 (Dec 20 to Feb 08 -- Dev Complete Feb 04, Stabilize Complete Feb 11, Release Complete Feb 18) ==<br />
=== Sprint A (closes Dec 24, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Kernel || Initial meta-rt layer || PREEMPT_RT kernel and related test-cases and benchmarks || 2 || Done by Jan 21 || Darren || dvhart || slipped out from M2<br />
|-<br />
|| Poky Features || Fetcher Overhaul Phase 1 - SRC_REV enhancement||<br />
* a) Add code in FetchData::__init__() which will check if the selected fetcher supports srcrev and the automatically call a function to set the src rev value instead of each fetcher doing this.\n <br />
* e) Break SRCREVINACTION deadlock. To do this, we need to start using a keyword for automatically increasing SRCREV, e.g. SRCREV = "AUTOINC". The actual revision can be injected into PV using SRCPV. If we do this there should no longer be a need of the deadlock; <br />
* k) Ensure that we only set __BB_DONT_CACHE when SRCREV = "AUTOREV". This may need a new method call for fetchers to tell whether they're "floating" or locked down.<br />
|| 1|| Done || Saul / Ke, RP|| rpurdie|| Enhancement, slipped out from M2<br />
|-<br />
|| Distribution / components|| Distro Audit Upgrades Planned (Phase 2)|| Complete plan for package upgrades in M2|| 1|| Done || Saul|| || Continual Maintenance<br />
|-<br />
|| Poky Features || Pseudo Performance || Implement the changes to bitbake based on pseudo's enable/disable switch|| 1|| done || Saul / Qing, Dongxiao || rpurdie|| Enhancement, slipped from M2 due to risk and not having Pseudo's change yet.<br />
|-<br />
|| Tool Development and SDK Features|| Fix the issue user target sysroot is owned by root || The ADT installer will use pseudo to extract user target sysroot which ended up owned by root, this need to be fixed || 1|| done || Jessica|| jzhang|| Cleanup <br />
|-<br />
|| Tool Development and SDK Features|| Eclipse poky tree interfacing (metadata file editor)|| Provide a metadata file editor with some syntax checking and keywords highlight capabilities|| 2|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| IDE Project templates|| Templates for various project types: Clutter GUI, Gtk+ GUI, to help developers get started quickly || 2|| Done || Jessica|| josh|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| push TCF/RSE patches upstream|| work with community to finish up our TCF terminal service, TCF/RSE integration remaining patches taken by upstream. Blocking issues including Eclipse Bug #327865 || 1|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Pseudo || Pseudo enhancement to enable on/off switch || || 1 || done || Mark || ||<br />
|-<br />
|| Pseudo || Bitbake enhancement for pseudo on/off switch || || 1 || done || Richard || ||<br />
|-<br />
|| bugzilla || Complete restructure of bugzilla categories || || 1 || done || Saul || ||<br />
|-<br />
|| Poky Features || Image creator ground work || Nomenclature determined, existing gui's bug fixed and backend work implemented || 1 || Done || Joshua || ||<br />
|-<br />
|| Kernel || Tracing: Initial SystemTap recipe || Works on x86 || 3 || Done || Tom || dvhart ||<br />
|-<br />
|| Distribution / components|| Distro Audit: Package Description/Summary completed|| Ensure DESCRIPTION/SUMMARY fields are all audited|| 2|| Done || Mark|| Mark|| Hygiene, was M2, Sprint B but missed window<br />
|-<br />
|| Distribution / components|| Zypper/RPM|| Small write-up of the problems we're having w/ Zypper and what we plan to do. (i.e. create a roadmap/design) - Includes rootfs generation - Package uprev/install/removal || 1 || Done || Mark/Qing || || was M2, Sprint B<br />
|-<br />
|| Distribution / components|| Distro Audit: Licence Checksums|| Make the licence checksums fatal if not present || 1|| Done || Saul|| rpurdie|| Hygiene, was M2, Sprint C<br />
|-<br />
|| Distribution / components|| push of all relevant Wind River patchs to Yocto (patch comparison)|| Ensure patches present to packages in WRS are also in Poky|| 1|| Done || Mark|| Mark|| was M2, Sprint C<br />
|-<br />
|| Poky Features || Performance Enhancement Completed || Initial changes to reduce disk space (sstate-build-*) || 1|| Done || Saul / Qing, Dongxiao || rpurdie|| Enhancement, was M2, Sprint E<br />
|-<br />
|| Distribution / components|| User specified qemu config support|| We'll provide user an edit box which allows advanced qemu user to specify arbitrary qemu configuration to meet their needs, which the poky-qemu scrip will just append the config list towards the end of the list of parameters to bring up qemu, it also expect the poky-qemu script to do some basic sanity check on the user specifications to catch the obvious mistake || 2|| Done || Saul / criping || criping|| enhancement, was M2, Sprint E<br />
|-<br />
|| Tool Development and SDK Features|| SDK Version Control support in SDK generator installer|| If we can expect that yocto SDK has lots of release in the future, we might need to consider SDK version control. Currently, if we un-tar the sdk, it will override the older version. It's not good for app developers since they might need the old version to do something. And also, maybe a finer installer than untar is preferred. Installer will tied to certain SDK version and the installation will go under /opt/poky-versionNo.|| 1|| Done || Jessica|| criping|| Enhancement-expect planning process by Jessica to handle this task. Was M2, Sprint E.<br />
|}<br />
<br />
=== Sprint B (closes Jan 07, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || Bitbake multi-threaded parsing|| Bitbake recipe parsing is currently single threaded. I want to make this multithreaded as the speedup would be nice. If I can only take a single task for myself for 1.0, I'm nominating this one as I enjoy this kind of thing and I have ideas on how to do it. || 1|| Done || Richard|| rpurdie|| Enhancement<br />
|-<br />
|| Distribution / components|| Lock in Kernel/Toolchain version|| Locked in 2.6.37 and gcc 4.5.1. Pending decision to move to 4.5.2 and Linaro || || Done || || Richard|| || <br />
|-<br />
|| Distribution / components|| License Update|| For each of the licences we support, I'd really like to have a licences directory with a copy of that license contained within. When it comes to deciding what a given LICENSE field means, this would be the reference. It also means we can include the licences a given image includes with the image. This continues to make our license handling world class and ahead of the field. || 2|| Done || Beth|| rpurdie|| Hygiene<br />
|-<br />
|| Tool Development and SDK Features|| Qemu configuration change|| Provice edit box for advanced user to specify qemu configurations|| 2|| Done || Jessica|| criping|| <br />
|-<br />
|| Tool Development and SDK Features|| Lock down Eclipse+CDT+TCF version|| Will use Eclipse Halo 3.6 || 1|| Done || Jessica|| || <br />
|-<br />
|| Demo|| Finalize on demo plans for v1.0 launch || || 1|| Done || Dave || || <br />
|-<br />
|| Release || Release plans for v1.0 launch || Fill out the M4 plan with the necessary release activities and timings || 1|| Done || Beth || || <br />
|-<br />
|| Poky Features || Basic image creator GUI || Functional UI missing some Advanced features || 1 || In replan || Joshua || || <br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer for SDK Generator Installation functions support||Detailed feature request can be found at: http://bugzilla.pokylinux.org/show_bug.cgi?id=589|| 1|| Done || Jessica|| rpurdie|| Enhancement<br />
|-<br />
|| Kernel || Tracing: trace-cmd python binding cleanup || || 3 || Done || Darren || dvhart ||<br />
|}<br />
<br />
=== Sprint C (closes Jan 14, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || kernel development layer|| The (correct) poky behaviour of building known revisions coupled with the fetcher requiring a BSP branch to already be present means that local modifications (and kernel source tree) are required for kernel development. I already have a layer that overrides/modifies the behaviour when added to the bblayers.conf and configured into an environment. This seems useful for more people to use. || 2|| Done || Bruce|| bruceashfield|| Enhancement, was M2, Sprint C<br />
|-<br />
|| Distribution / components|| Zypper/RPM|| RPM Uprev / Zypper Uprev [lets get to the latest versions]|| 1|| pull request by Jan 19; || Mark/Qing|| || was M2, Sprint C<br />
|-<br />
|| Supported Targets|| Intel Platform Support|| JasperForest|| 2|| Basic support in place; DPDK evaluation in process, overall BSP plan still TBD || Tom|| davest|| Basic ECG support (Moved from Sprint A)<br />
|-<br />
|| Tool Development and SDK Features|| Eclipse poky tree interfacing (git support)|| Use Eclipse git capability to install poky tree from git repo and able to interact with git repo at file level within Poky tree || 2|| Done || Jessica|| jzhang|| Enhancement<br />
<br />
|-<br />
|| Poky Features || Poky Image Creator|| A standalone application you can run which asks you to select a distro and machine, then presents a list of packages you can select. Once the selection is made, it goes off and bakes you an image which is then presented to you. Implementation wise, it should use the sstate packages, be a bitbake UI and use the usual poky bbclass files to do the image construction behind the scenes. || 1|| Re-plan || Joshua|| rpurdie|| Enhancement<br />
|-<br />
|| Distribution / components|| LSB Sanity|| execute LSB Test and improve passing rate and document failures with clear understanding|| 2|| Done || MarkH/Saul|| sgw|| Hygiene<br />
|-<br />
|| Tool Development and SDK Features|| Image creator integration with Eclipse || || 2|| replan|| Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Kernel || Tracing: perf trace marker support || This is from feedback to the new trace command. Ingo appears to have this nearly complete already. || 3 || Done || Darren || dvhart ||<br />
|-<br />
|| Kernel || Tracing: perf trace scripting support || || 3 || Move to Sprint D; on track for Jan 21 || Tom || dvhart ||<br />
|-<br />
|| Cleanup || bitbake user experience error handling validation completed || || 2 || Done || Richard || ||<br />
|-<br />
|| Cleanup || variable scrub - ensure all metadata variables are documented || Script with a histogram of variable use done, identified 50 variables to document; Add task for actual documentation update is low on the list || 2 || Done || Scott/Darren || ||<br />
|-<br />
|| Distribution / components|| Zypper/RPM|| Integration based on design from Sprint B|| 1|| On track for Jan28 || Mark/Qing|| sgw|| Functionality, was M2, Sprint E<br />
|-<br />
|| Kernel || Tracing: package kernelshark || || 3 || Done || Darren || dvhart ||<br />
|-<br />
|| Kernel || Tracing: tuna, oscillosope recipes || || 3 || Tom to discuss plan with Darren et al || Tom || dvhart ||<br />
|- <br />
|| BSP || Beagleboard XM Support || || 3 || Move to Sprint D || Darren || dvhart ||<br />
|}<br />
<br />
=== Sprint D (closes Jan 21, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Swabber || Complete review of swabber outputs || Move to M3 Sprint D || 1 || Move to M3 Sprint D || Alex || ||<br />
|-<br />
|| Poky Features || Fetcher Overhaul Phase 2 - API reorg||<br />
* f) Add a generic unpack funciton to __init__.py based on the unpack task in Poky ;<br />
* g) Split go() methods into the following steps: i) download() - do whatever transfer is necessary to get the sources locally ii) build_mirror_data() - generate any data that would be needed to construct a source mirror iii) unpack() - takes a directory as an argument of where to place extracted sources;<br />
The existing go() methods should be replaced with a set of calls to the above sections of functionality as appropriate in the individual fetchers. Some of these categories of function make no sense in certain fetchers, in which case they shouldn't need to implement them. Functions are only executed if the method is present.<br />
* h) Change Poky's unpack to call an unpack method in the fetchers.<br />
* i) Change Poky's fetch task to call a "download" method in the fetcher instead of go().<br />
|| 1|| Will land with phase 3 in Jan 21 || Saul / Ke, RP|| rpurdie|| Enhancement<br />
|-<br />
|| Poky Features || Fetcher Overhaul Phase 3 - git enhancement||<br />
* j) Optimize git fetcher for the new layout so for a git checkout, we clone the repository in download(), then unpack just does a clone with references to the original repo. <br />
* k) Ensure that we only set __BB_DONT_CACHE when SRCREV = "AUTOREV". This may need a new method call for fetchers to tell whether they're "floating" or locked down. <br />
* l) Add a new "BB_NO_NETWORK" variable which the fetchers check before peforming an operation which hits anything remote. This means adding in error messages about why network access is needed at various points (e.g. SRCREV = "AUTOREV" for a given recipe) <br />
* m) Add multiple branch/srcrev support for git fetcher. These would be of the form: git://somelocation/somerepo.git;name=ref1;branch=foo;name=ref2;branch=bar SRCREV_ref1 = "hash1" SRCREV_ref2 = "hash2" which would ensure both hash1 and hash2 were in the final repo. <br />
* n) Change git fetcher to default to git protocol instead of rsync<br />
|| 1|| Slipped to Sprint D || Saul / Ke, RP|| rpurdie|| Enhancement<br />
|-<br />
|| Poky Features || DSO linking changes|| "By the default the gcc linker will automatically link any dependant objects/libraries. ""Inherited"" linkages can cause issues, for example, where a shared object changes its dependencies but a program has come to rely on symbols from an implicitly linked library. Fedora implemented this change in F13, seems like it would be useful to have in Poky too. "|| 2|| On track for Jan 21 || Saul / Nitin || josh|| bug#516<br />
|-<br />
|| Distribution / components|| Distro Audit Documentation Output|| Audit package documentation output || 2|| Move to Sprint D due to libtool work || Saul / ScottG || rpurdie|| Hygiene<br />
|-<br />
|| Distribution / components|| Review & Fix Standards Tests|| Review the results from LTP, POSIX and asses the result, fix as appropriate and clearly document failures.|| 2|| a Plan to resolve final items to be sent to the m.l. by Jan 14 || Saul/Kevin || sgw|| Hygiene<br />
|-<br />
|| Poky Features || libtool sysroot option|| libtool 2.4 has a sysroot option. We should try and use it, see how it works and whether we can ditch some of our libtool hacks. || 1|| On track for Jan 21 || Saul / ScottG || rpurdie|| Enhancement<br />
|-<br />
|| Distribution / components|| MACHINE or Recipe specific sysroots|| Each machine should have its own sysroot. We'll probably have to split do_populate_sysroot into a two step process, creation of the package and than installtion of the package, which the installation of the package being made machine specific (put ${MACHINE} into ${STAMP} and bitbake should do that). Also allowing this to work per recipe would be desireable|| 1|| On track 21 || Saul / Dongxiao || rpurdie|| Hygiene<br />
|-<br />
|| Distribution / components|| Toolchain Bootstrap Process|| The toolchain as it bootstraps overwrites files like libc.so and libgcc.so in the sysroot directory which causes issues if you just try and rebuild part of the toolchain. Each step of the bootstrap process should use a separate sysroot. Once this is once, sstate file overwriting detection can be added and enabled. || 1|| Patches submitted for comment, slip to Sprint D || Saul / Dexuan || rpurdie|| Hygiene<br />
|-<br />
|| Documentation Features|| Package report system|| move to public server [setup a package report system in an internal machine. We need push it publicly available. The basic features like search and report have been there. But there're still some enhancements in plan, to make it a fit place to feel Yocto metadata comfortably]|| 2|| Move to Sprint E|| KevinT|| ktian1|| enhancement<br />
|-<br />
|| Distribution / components||Add headers and libraries to qemu images ||Since we'll be using qemu images as target sysroot, need to create a set of qemu images for minimal, sato, LSB that contains target header and libraries.|| 2|| Pending a discussion on Jan 18 || Saul ||jzhang|| Enhancement<br />
|-<br />
|| Distribution / components|| push of all relevant Wind River patchs to Yocto (patch comparison)|| Update any additional patches needed since M2.|| 1|| May be done by Jan 21, pending RPM stuff || Mark|| Mark|| <br />
|-<br />
|| Distribution / components|| mklibs|| mklibs is a tool to optimize size of [e]glibc for a perticular root file system image. It is useful to save disk space on small devices. || 2|| Push to Sprint E || Saul|| Nitin Kamble|| enhancement<br />
|-<br />
|| Poky Features || Performance Enhancement || reduce disk space (hardlink) || 1 || On track for Jan 21, pending RP review || Saul / Qing, Dongxiao || rpurdie || Enhancement<br />
|-<br />
|| BSP || 2.6.37 Crown Bay Support || On Track for Jan 21 || 2 || || Tom || dvhart || <br />
|-<br />
|| BSP || 2.6.37 Emenlow Support || On track for Jan 21 || 2 || || Tom || dvhart || <br />
|}<br />
<br />
=== Sprint E (closes Jan 28, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| rootless X|| rootless x server has better security than x server launched by root. MeeGo already enable this feature. it would be nice for Yocto to also enable it. || 2|| On track for Jan 28 || Saul / Ke || yuke|| enhancement<br />
|-<br />
|| Documentation Features|| Package report system|| finish major feature development and internal review [setup a package report system in an internal machine. We need push it publicly available. The basic features like search and report have been there. But there're still some enhancements in plan, to make it a fit place to feel Yocto metadata comfortably]|| 2|| Move to Sprint E || Jonathan || ktian1|| enhancement, was M2, Sprint E<br />
|-<br />
|| Distribution / components|| perl upgrade|| perl is the most cross un-friendly recipe pending upgrade. || 2|| Slipping due to Linaro layer, moves to end of Sprint E || Nitin|| Nitin Kamble|| enhancement<br />
|-<br />
|| Supported Targets|| Intel Platform Support|| Sandybridge|| 2|| Accept|| Tom|| davest|| Basic ECG support<br />
|-<br />
|| Distribution / components|| performance indicators|| define some indicators (boot time, footprint, build time, power, component benchmarks, etc.) and then collect them for tracking purpose. The result could be posted on the wiki site, and the initial indicators can be easy ones which can be easily retrieved from autobuilder or weekly qa report). This way we have a clear track about the healthy of the Yocto project, and also identify weak areas. We can include qemu targets and several representational boards as the targets. || 2|| Review|| Beth/Jiajun|| ktian1|| enhancement<br />
|-<br />
|| Tool Development and SDK Features|| SDK user workshop|| Have some developers sit down and use our tools to develop demo software for Yocto. || 2|| Review|| Jessica|| josh|| Enhancement<br />
|-<br />
|| Kernel || Final linux-yocto_git.bb || With 2.6.37 kernel || 1 || || Bruce || dvhart ||<br />
|-<br />
|| Kernel || Final meta-linaro layer || || || || Darren || dvhart ||<br />
|-<br />
|| Kernel || Final meta-rt layer || || || || Darren || dvhart ||<br />
|-<br />
|| Kernel || Sandy Bridge || || 1 || || Tom || dvhart ||<br />
|}<br />
<br />
=== Sprint F (closes Feb 03 (THURSDAY), 11:59pm PDT -- pull request sent, initially reviewed) :: NOTE: China New Year Holiday ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Documentation|| ADT Reference Guide Draft out for review || Outline complete|| High|| WIP || Scott Rifenbark|| jzhang|| Documentation<br />
|-<br />
|| || || || || || || || <br />
|}<br />
<br />
== M4 (Feb 07 to Apr 15 -- Stabilize Complete Mar 18, Release Complete Apr 01, Contingency to Apr 15) ==<br />
<br />
This sprint is the [[Yocto Project v. 1.0 Release Cycle]].<br />
<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Documentation|| Migration chapter in the Poky Reference Manual|| This chapter would cover the four identified use-cases for migrating up to the most recent version of Yocto Project. Additionally, it would cover migration scenarios from other development systems. The chapter does not yet exist. The chapter has not been scoped outside of having a meeting that identified four use-cases that did not include migration from a development system outside of Yocto Project. It will take some more scoping time to cover those areas (a day or two). Again, I have no idea of the length. See earlier entries for standard industry writing estimates for software documentation|| Medium|| Not Started|| Scott Rifenbark|| 3-4 Weeks|| Documentation<br />
|-<br />
|| Documentation|| Yocto Project Development Guide|| This manual would be an over-arching document that frames the complete development cycle within Yocto Project. The idea here is that the document would be an umbrella document that spawned and referenced subsequent documents. The organization would be the first chapter overviewing the major development pieces such as recipe creation, building, debugging, publishing, fail-safing, back-door hook creation, etc. Scoping would be about two weeks and length would probably be about 40 pages. Overall development time would likely be a month of uniterruped time.|| Medium|| Not Started|| Scott Rifenbark|| 3 Weeks|| Documentation<br />
|-<br />
|| Validation|| Boottime/Performance Analysis|| Compare Yocto Project performance to other projects such as MeeGo|| 1|| Initial report on where we are by Feb 9 || Darren|| davest|| project commitment<br />
|-<br />
|| || Multilib Support|| Consider developing post-1.0 branch || 1|| to start in M4 || Richard|| ||<br />
|-<br />
|| Validation|| Alpha testing complete|| 4-5 internal developers unfamiliar with Yocto Project try to do a build and report on the experience and issues encountered|| 1|| Done by Feb 18 || Julie|| davest|| <br />
|-<br />
|| || || || || || || || <br />
|}<br />
<br />
== Features needed and to be put into sprints by assigned owners: ==<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || package config option enhancement|| there're several enhancements we may do here: * allow users setting specific config options (local or global) from external tool, such as poky image creator, instead of changing recipes manually. Need a mechanism to convert from variable assignments into exact config options (e.g. feature_${PN} = ""1"" -> ""--enable-feature""). Consequently dependency chain needs update with option status. * host contamination check. We have swabber to check host contamination, but I'm not sure whether it covers configuration phase. If not, this is one area to improve, as not ususually we see configure script checks host bits for available features * conditional option manipulation. In many recipes we enable/disable one option based on availability of other packages. Now this is done manually and not flexible. this should be made automatically though some new annotation to indicate condition, or just base_contains (not convenient: long line, need define distro features) || 2|| Review|| Richard/MarkH|| ktian1|| Enhancement<br />
|-<br />
|| Media|| Yocto Project Awareness Video|| This 2.5 minute video would introduce and describe the benefits of Yocto Project. The video would use entertaining animations that described concepts and benefits. The result would be suitable for YouTube, conferences, and the website. The production is called an "Epipheo" and will be created by Epipheo Studios. The engagement process has begun and the kick-off meeting will be soon. The PO is in place. Time for development is 10 weeks.|| High|| Kick-off Imminent|| Scott Rifenbark|| 10 Weeks|| Media<br />
|-<br />
|| Documentation|| Yocto Project Debugging Guide|| This would be a guide for the debugging and bug tracking process in Yocto Project. Originally, the thought was that we needed a Bugzilla User's Manual. However, since we don't own Bugzilla it doesn't make sense to produce documentation for it. Rather, we should document the process as it fits into the Yocto Project environment. Ideally, the manual would be a sub-manual that would be referenced and architected into the Yocto Project Development Guide. The manual has not been scoped and would take a week to scope. Again, I have no idea of the length. See the previous item for standard industry writing estimates for software documenation.|| Medium|| Not Started|| Scott Rifenbark|| 3-4 Weeks|| Documentation<br />
|-<br />
|| Website|| Yocto Project Website|| The 0.9 website is in place but needs updates. Items for consideration are the left-panel naviagation scheme, a contributions guidance page, color-scheming and theme (possibly).|| Medium|| Not Started|| Scott Rifenbark|| 1-2 Weeks|| Website<br />
|}<br />
<br />
== Features not believed to be needed in v1.0: ==<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || OpenEmbedded/Bitbake Upstreaming|| "We firstly need to review where we are and where OE is. We then need to make a plan about what we're going to push upstream and what we're not. I'd suggest when we're in PRC, we do a crash course in ""dealing with OE"" and then many dedicate a block of time (a week) where the distro team comes up with a patch set we then propose and get merged into OE. I'd like to find a couple of interested people to monitor OE more regularly and start a workflow of things between Poky/OE where appropriate. The key thing to remember is we need to keep the architectures compatible. The team is now at the point where I'm happy for them to actually try building OpenEmbedded and not worry about it tainting them! "|| 2|| Review|| || rpurdie|| Process<br />
|-<br />
|| Poky Features || Handle old versions in WORKDIR|| an incremental build directory may finally include many old versions WORKDIRS. It'll be good to have those old versions tracked in the cache, which can then either generate a report or allow selectively cleaning up an specific version WORKDIR. Or else it's difficult to figure it out when people want to keep the whole tmp directory but like to cleanup some old bits when disk usage is under pressure. If it's not easy to do in bitbake, perhaps some separate scripts would be also helpful || 3|| Review|| || ktian1|| Enhancement<br />
|-<br />
|| Poky Features || run bitbake w/o rebuilding the cache|| "sometimes it's useful to allow run bitbake w/o re-parsing recipes, if we know nothing metadata is changed. we can just allow reusing existing persistent cache. this is useful when people is debugging WORKDIR w/o metadata change. also sometimes ""bitbake -e"" is used frequently to check poky variable information. with existing cache, several seconds can be saved which are not negligible for a developer daily working on Yocto "|| 2|| Review|| || ktian1|| Enhancement<br />
|-<br />
|| Poky Features || parallel make improvement|| parallel make experience is not good, especially when bb threads and make threads are increased larger than 8. So far we either try to fix package makefile or mark the recipe as no parallel make, when build faiures are reported. But this greatly impacts user experience for a successfully continuous build process. Could we define a safe number we do want to support for 1.0 release? and then have our autobuilder, QA test, and developers cover that number immediately and fix any issues accordingly. Then the safe number can be suggested to the Yocto user || 2|| Review|| || ktian1|| Enhancement<br />
|-<br />
|| Poky Features || Dependency packages rebuild/clean|| It is a mechanism to rebulid or clean a package and all other packages which have build/runtime dependency on it. With this change, we can find potential influences of package upgrade to its related packages, which can make the incremental build more trustable. For example, if we upgrade a package to a new vesion which changes its API, this mechanism can easily find out the incompatibility to other packages which have dependency on it. || 2|| Review|| || dongxiao.xu|| Enhancement, replaced by checksum feature<br />
|-<br />
|| Distribution / components|| FOSSology|| This may be similar to License Update above, but start to use FOSSology to track licenses. || 2|| Review|| || sgw|| Hygiene<br />
|-<br />
|| Distribution / components|| Package Developer Tools|| Create a set of Init scripts template and then review our current init scripts and modify them to confirm to the template. || 2|| Review|| || sgw|| Easy of Use<br />
|-<br />
|| Distribution / components|| Package Website|| Complete the work the intern has started on generating the distro tracking information and get it out on the external site. || 2|| Review|| || sgw|| "Hygiene, duplicate of ""Package report system"""<br />
|-<br />
|| Distribution / components|| Bluetooth UI support|| Currently we have bluez package in poky, and we need to have a workable graphic user interface to connect/configure BT devices. One choice may be gnome-bluetooth-applet. || 3|| Review|| || dongxiao.xu|| enhancement<br />
|-<br />
|| Distribution / components|| Connman-gnome enhancement features|| Enable connman-gnome to support features like, WPA Enterprise connection, hidden SSID, etc. || 3|| Review|| || dongxiao.xu|| enhancement<br />
|-<br />
|| Distribution / components|| Java Running Environment support|| Since most embedded systems support java applications running in it, maybe we'd better consider supporting some kinds of JVMs(Embeded JVM). The JVM may not run by default, but user can launch it if running java applications. Compared with GTK/QT, java user number is not small too. || 3|| Review|| || criping|| enhancement<br />
|-<br />
|| Distribution / components|| create more use cases|| UPnP demo is one really good use case showing how Yocto is utilized to make real functionality. and we could create more to show how Yocto is easily adapted to real use cases. Those use cases can be either maintained as seperate demo layers in yocto repo, or in seperate branches for reference. We can also call for community's contribution on this which would make 1.0 full-fledged. Or else the newbies to Yocto may be in puzzle how our sample profiles can satisfy their requirements. || 2|| Review|| || ktian1|| enhancement<br />
|-<br />
|| Distribution / components|| i18n support || internationalization is an important system wide feature. Many component like font, locale affect the i18n. Yocto alreay has some i18n related package like pango, but so far did not consider i18n systematically. so this is place holder to systematically add i18n support. || 2|| Review|| || yuke/qing|| enhancement<br />
|-<br />
|| Distribution / components|| more demos || demos are a good way to educate, push the envelope, and at the same time tout the strengths of the platform. This item just records a current set of ideas from various sources which could/should be implemented: * face-recognition/face-finding, * robotic control/application of face-finding to 'camera-as-sensor' (hexbug demo), * others [tbd, add here]|| 2|| Review|| || tzanussi|| enhancement <br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer support for image-creator and needed yocto-metadata design||Come up design what need to be created as packages to support using "opkg install" for image-creator and needed yocto-metadata|| 2|| WIP, pending comments from RP regarding how to packaging metadata|| Jessica|| rpurdie|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer image-creator and needed poky-metadata support|| The poky build system will build packages for image-creator and needed poky-metadata, which the Yocto Installer will be able to use "opkg install" to install them|| 2|| Review|| Jessica|| rpurdie|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Provide qemu management UI|| In current eclipse plugin, QEMU settings are put together with project configuration. So we can only have limited settings. If we can have a separate QEMU management UI, the end user could firstly create a QEMU config, such as (env file of arch, image location, unfs or not, sato or lsb, mem size, disk size). And then he can launch a QEMU with a specific config. The dependency between project configuration and QEMU config will be resolved. After all QEMU has nothing to do project configuration. Need to careful review the UI to ensure minimal impact to testing matrix. || 3|| Review|| || criping|| "Enhancement, duplicate of ""Qemu mem/disk size can be adjusted"""<br />
|-<br />
|| Tool Development and SDK Features|| QT plugin For Eclipse|| Integrate QT Ecplise plugin and extend for Yocto Project || 3|| Review|| || jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Profiling/Trace GUI's|| We have a wealth of great tracing and profiling tools but the UI's for them are all extremely minimal and usually quite ugly. Would be great if we could compete with, or even better, Apple's offerings here. We have the technology! || 2|| Review|| || josh|| "Enhancement, duplicate of ""Tracing/Profiling Planning Complete"""<br />
|-<br />
|| Tool Development and SDK Features|| Other profiling tools|| Complete Tom's review of profiling tools and architecture || 2|| Review|| || josh|| "Enhancement, duplicate of ""Tracing/Profiling Planning Complete"""<br />
|-<br />
|| Tool Development and SDK Features|| Design next-gen tracing/profiling tools|| Yocto 1.0 will include all the essential existing tracing/profiling tools expected by users, and Josh has proposed a UI integration of all those tools as far as it's possible to do so. That level of integration, basically a 'plugin-level' integration is necessary and useful, but doesn't go far enough. A next-generation tracing tool would integrate at a much more fundamental level; if done properly, it would provide unmatched levels of power and usability to users, and would allow Yocto to distinguish itself in the embedded tracing/profiling space in a way also unmatched by any other distro/build-tool. The implementation would of course not be available for Yocto 1.0, but a coherent design, including prototypes, that could be taken to the community and implemented in a V 1.5 or 2.0 should be done in that time frame. || 1|| Review|| || tzanussi|| "Enhancement, duplicate of ""Tracing/Profiling Planning Complete"""<br />
|-<br />
|| Documentation Features|| Self Documentation of image contents|| "I'd like to see the -doc packages Poky builds being combined into some kind of large documentation index representing the collective API docs of the target being built. This can then be placed on a webserver and viewed over the web. We'd have a demonstration of this for a ""bitbake world"" target. Part of the idea here is to start making good use of the docs as if developers see this they might start writing better docs too. Aim is to lead the field :). There are a number of places poky packages disable doc generation due to missing tools so we'd need to add these so we can enable the doc generation. Many packages already have many docs though too. "|| 2|| Review|| || rpurdie|| enhancement<br />
|-<br />
|| Validation|| Testing Framework|| Add a framework for doing automated testing in the project|| 1|| Review|| || davest|| project commitment<br />
|-<br />
|| Validation|| more SDK builds on autobuilder|| enable more SDK related tests on autobuilder such as meta-ide-support, etc.|| 2|| Review|| || ktian1|| project commitment, addressed by test plan (?)<br />
|-<br />
|| Validation|| more people should try using SDK|| this may not be a feature, but a requirement. SDK including meta-toolchain is one key factor impacting user experience on Yocto. It's not enough to have only SDK team play with it|| 2|| Review|| || ktian1|| project commitment, addressed by test plan (?)<br />
|-<br />
|| Validation|| Unit Testing Framework|| Add a mechanism to bitbake to parse source packages that have unit tests and then execute them on the target|| 3|| Review|| || sgw|| "project commitment, duplicate of ""Testing Framework"""<br />
|-<br />
|| Validation|| Test Case open source|| Open source Yocto test cases with xml format|| 1|| Review|| || yyou|| "project commitment, duplicate of ""Testing Framework"""<br />
|}</div>Davesthttps://wiki.yoctoproject.org/wiki/index.php?title=Yocto_1.0_Schedule&diff=589Yocto 1.0 Schedule2011-01-25T01:32:25Z<p>Davest: /* Sprint C (closes Jan 14, 11:59pm PDT -- pull request sent, initially reviewed) */</p>
<hr />
<div>= v1.0 (release date: Apr 15, 2011) =<br />
----<br />
The detailed milestone map for v1.0 is as below. During the first week of each subsequent milestone past M1 we will have a demonstration of the previous milestone capabilities as well as a planning and design session for the current milestone.<br><br><br />
<br />
== M2 (Nov 08 to Dec 24 -- Dev Complete Dec 10, Stabilize Complete Dec 17, Release Complete Dec 24) ==<br />
=== Sprint A (closes Nov 12, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links''' <br />
|-<br />
|| Poky Features || Kernel interactive targets || To support incremental kernel development having the ability to run menuconfig (or xconfig, etc) directly is a common request. We'll need to add this for commercialization anyway. i.e. bitbake -c menuconfig. This fuctionality already exists. || 1 || Done || Richard || bruceashfield || Enhancement <br />
|-<br />
|| Distribution / components || Distro Audit: Upgrades Planned (Phase 1) || Complete plan for package upgrades in M2 || 1 || Done || Saul || || Continual Maintenance<br />
|-<br />
|| Validation || Runtime testing || Runtime testing of images as part of the autobuilder || 1 || Done || Jiajun/ScottG || rpurdie || project commitment<br />
|- <br />
|| || Poky Image Creator Wireframe/Interaction Plans Complete || || 1 || Done || Josh || ||<br />
|-<br />
|| || SDK Generator Interaction: Plans Complete || || 1 || Done || Jessica || ||<br />
|-<br />
|| || Tracing/Profiling Planning Complete || This needs to cover where we're at now, what we're missing and also propose the future enhancements that may be needed. M2 targets getting existing tools integrated and documented. F2f discussion n the future enhancements || || Done || Tom || ||<br />
|-<br />
|| || Swabber. (Still needs to be integrated into weekly build by default) || || 1 || Done || Josh || ||<br />
|-<br />
|| Build/Release || Release process documentation || || || Done || Beth || ||<br />
|-<br />
|| Validation || Test plan for v1.0 (to address any deficiencies in coverage from v0.9)|| || 1 || Done || Jiajun || ||<br />
|}<br />
<br />
=== Sprint B (closes Nov 19, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| Distro Audit: World Packages|| Audit world packages making sure it all build, making sure all are packages are required || 2|| Done || Saul|| sgw|| Hygiene<br />
|-<br />
|| Tool Development and SDK Features|| SDK Generator Installer UI|| Look at different ways of Installer UI (GTK+ and ncurses) seems none of them is the right choice, decide to go with script to implement all the functionalities of installer and later add UI part on top of it || 1||Done|| Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Customize sysroot setup || Add and test out "--sysroot" config option to cross compiler within Eclipse IDE || 1|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| SDK Generator Installer design revision|| Close all open questions regarding Yocto SDK Generator Installer function design and come up HLD || 1|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Distribution / components|| kernel version|| keeping 2.6.34 as a -stable kernel is the best option. I've also got a newer -devel tree that can be made available or made the default. || 3|| Done || Bruce|| bruceashfield|| enhancement<br />
|-<br />
|| || assign Yocto Project PM|| acquire and assign a program manager for Yocto Project|| || Done || DaveST|| || <br />
|-<br />
|| || assign Yocto Project Sys Admin|| || || Done || Saul|| || <br />
|-<br />
|| Tool Development and SDK Features|| oprofileUI|| Fixing various bugs of the oprofileUI to make it workable on big endian host.(i.e. ppc, mips) || 2 || Done || Jessica || lianhao.lu || Bug #382 / Bug #493<br />
|-<br />
|| Poky Feature|| SDK Version Control|| If we can expect that yocto SDK has lots of release in the future, we might need to consider SDK version control. Currently, every thing installed under /opt/poky which leads to things be overriden, we need to be able to use a scheme like /opt/poky-1.0, /opt/poky-2.0 to distiguish things. || 2|| Done || Josh|| jzhang|| Enhancement<br />
|-<br />
|| Kernel || Kernel plan complete || Flesh our kernel deliverables and add to Yocto 1.0 schedule || || Done|| Darren || dvhart ||<br />
|}<br />
<br />
=== Sprint C (closes Nov 26, 11:59pm PDT -- pull request sent, initially reviewed) :: NOTE: this is US Thanksgiving week ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| Distro Audit: Licence Checksums|| licence checksums || 1|| Done || Saul|| rpurdie|| Hygiene<br />
|-<br />
|| Poky Features || Performance Analysis Completed|| "I'd like someone to instrument a green release build, see where it spends time (hot/cold parsing time, individual task building time) and then compare this with our 0.9 release build. I'd also like to compare the disk usage between the two. Once we have a blame list we can then set about fixing it. Some things I know will come up: a) pseudo, b) checksums/signature code, c) exec() vs fork for executing tasks, d) task based prebuilds increasing disk usage, e) rpm dependency calculations, f) using rpm vs. ipk but I may be wrong and there may be others. We need numbers. "|| 1|| Done || Saul / Qing, Dongxiao|| rpurdie|| Enhancement<br />
|-<br />
|| Poky Features || environment variables for kernel builds|| switching a branch, or adding a configuration feature (and even changing the kernel repo) is often done during development of a BSP. Having some additional variables that are pass the bitbake environment scrub would be useful. i.e. KBRANCH=foo bitbake -c configure linux-yocto. This goes along with the other BSP bootstrapping suggestions. || 2|| Done || Bruce|| bruceashfield|| Enhancement<br />
|-<br />
|| Supported Targets|| ARM Platform Support|| Replace beagleboard with Beagleboard XM - decision || 2|| Done || Bruce|| alex|| Basic Yocto hardware support <br />
|-<br />
|| Distribution / components|| Security Process|| We need a dedicated person to scan and apply critical security updates to the distro. The MeeGo team already has a similar process with some scripts which may be leveraged. To complete the task, the process should be documented and a first pass over the metadata made to establish the current position on security. Any upgrades needed should be identified and a plan to address them should be in place but doesn't have to be implemented by this point.|| 1|| Done || ScottG|| ktian1|| enhancement<br />
|-<br />
|| Tool Development and SDK Features|| SDK Generator Installer Opkg repo design|| Come up a opkg repo design that will mimic the final Yocto package repo layout to be used by SDK Generator Installer to test against|| 2 || Done || Jessica || jzhang || <br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer tar creaion|| Create a Yocto Installer tar ball which contains Installer script and supported opkg component that will be used for installing other Yocto components|| 2 || Done || Jessica || jzhang || <br />
|-<br />
|| Documentation|| Kernel Framework Paper from WR|| The paper from WR needs to be re-written and then posted somewhere on the Yocto Project site. This will involve examiniation of the text and re-writing and formatting for presentation. Currently it is simply a text document. Completion time assuming uninterrupted time is one week.|| High|| Done || Scott Rifenbark|| 1 Week|| Documentation<br />
|-<br />
|| Documentation|| Poky Reference Manual|| This guide exists in the 0.9 form. The re-write of the text needs to be completed. So far, all the chapters have been rewritten but not re-posted on the site. Only the appendices remain for a text scrub. Time to complete this would be a week of uninterrupted time. Ideally, the manual would be a sub-manual that would be referenced and architected into the Yocto Project Development Guide.|| Medium|| Done|| Scott Rifenbark|| 1 Week|| Documentation<br />
|-<br />
|| Kernel || Initial meta-linaro layer || meta-linaro layer providing a kernel, tool-chain, and uboot loader. This deliverable is primarily to get the infrastructure in place and have a buildable kernel. Toolchain on best effort basis. || || Done || Darren || dvhart || Moderate risk of slippage due to holidays.<br />
|-<br />
|| Kernel || Tracing: blktrace and sysprof recipes || || || Done || Tom || dvhart ||<br />
|}<br />
<br />
=== Sprint D (closes Dec 3, 11:59pm PDT -- pull request sent, initially reviewed) :: NOTE: week of the F2F planning meeting ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Kernel || Kernel git branching structure revamped || || 1 || Done || Bruce || dvhart ||<br />
|-<br />
|| Kernel || Tunnel Creek (Crown Bay) || || 1 || Done || Tom || dvhart ||<br />
|}<br />
<br />
=== Sprint E (closes Dec 9 (THURSDAY), 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| Distro Audit: Upgrades Completed (Phase 1)|| Update to new versions as per the agreed plan for M2 from Sprint A|| 1|| Done || Saul|| rpurdie|| Continual Maintenance<br />
|-<br />
|| Distribution / components|| Distro Audit: Src Checksums|| Make sure all SRC_URI components have checksums too || 1|| Done || Saul|| rpurdie|| Hygiene<br />
|-<br />
|| Poky Features || enable KVM with qemu|| today all new Intel processors support VT, which are enabled on most desktop machines which are most frequently used build machine. with VT support, x86/x86-64 qemu target runs faster which is a good thing for emulation environment. This may require some qemu option tweaks and also poky-qemu script enhancement. || 2|| Done || Saul / Edwin|| ktian1|| Enhancement<br />
|-<br />
|| Kernel || New kernel recipes || dev, -devel, -custom || 3 || Done || Bruce || dvhart ||<br />
|-<br />
|| Swabber || Documentation for swabber || || 1 || Done || Alex || ||<br />
|-<br />
|| CCB || Defect triage process in public documented and implemented || || 1 || Done. Triage process is documented, out for review. || Saul || ||<br />
|}<br />
<br />
== M3 (Dec 20 to Feb 08 -- Dev Complete Feb 04, Stabilize Complete Feb 11, Release Complete Feb 18) ==<br />
=== Sprint A (closes Dec 24, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Kernel || Initial meta-rt layer || PREEMPT_RT kernel and related test-cases and benchmarks || 2 || Done by Jan 21 || Darren || dvhart || slipped out from M2<br />
|-<br />
|| Poky Features || Fetcher Overhaul Phase 1 - SRC_REV enhancement||<br />
* a) Add code in FetchData::__init__() which will check if the selected fetcher supports srcrev and the automatically call a function to set the src rev value instead of each fetcher doing this.\n <br />
* e) Break SRCREVINACTION deadlock. To do this, we need to start using a keyword for automatically increasing SRCREV, e.g. SRCREV = "AUTOINC". The actual revision can be injected into PV using SRCPV. If we do this there should no longer be a need of the deadlock; <br />
* k) Ensure that we only set __BB_DONT_CACHE when SRCREV = "AUTOREV". This may need a new method call for fetchers to tell whether they're "floating" or locked down.<br />
|| 1|| Done || Saul / Ke, RP|| rpurdie|| Enhancement, slipped out from M2<br />
|-<br />
|| Distribution / components|| Distro Audit Upgrades Planned (Phase 2)|| Complete plan for package upgrades in M2|| 1|| Done || Saul|| || Continual Maintenance<br />
|-<br />
|| Poky Features || Pseudo Performance || Implement the changes to bitbake based on pseudo's enable/disable switch|| 1|| done || Saul / Qing, Dongxiao || rpurdie|| Enhancement, slipped from M2 due to risk and not having Pseudo's change yet.<br />
|-<br />
|| Tool Development and SDK Features|| Fix the issue user target sysroot is owned by root || The ADT installer will use pseudo to extract user target sysroot which ended up owned by root, this need to be fixed || 1|| done || Jessica|| jzhang|| Cleanup <br />
|-<br />
|| Tool Development and SDK Features|| Eclipse poky tree interfacing (metadata file editor)|| Provide a metadata file editor with some syntax checking and keywords highlight capabilities|| 2|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| IDE Project templates|| Templates for various project types: Clutter GUI, Gtk+ GUI, to help developers get started quickly || 2|| Done || Jessica|| josh|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| push TCF/RSE patches upstream|| work with community to finish up our TCF terminal service, TCF/RSE integration remaining patches taken by upstream. Blocking issues including Eclipse Bug #327865 || 1|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Pseudo || Pseudo enhancement to enable on/off switch || || 1 || done || Mark || ||<br />
|-<br />
|| Pseudo || Bitbake enhancement for pseudo on/off switch || || 1 || done || Richard || ||<br />
|-<br />
|| bugzilla || Complete restructure of bugzilla categories || || 1 || done || Saul || ||<br />
|-<br />
|| Poky Features || Image creator ground work || Nomenclature determined, existing gui's bug fixed and backend work implemented || 1 || Done || Joshua || ||<br />
|-<br />
|| Kernel || Tracing: Initial SystemTap recipe || Works on x86 || 3 || Done || Tom || dvhart ||<br />
|-<br />
|| Distribution / components|| Distro Audit: Package Description/Summary completed|| Ensure DESCRIPTION/SUMMARY fields are all audited|| 2|| Done || Mark|| Mark|| Hygiene, was M2, Sprint B but missed window<br />
|-<br />
|| Distribution / components|| Zypper/RPM|| Small write-up of the problems we're having w/ Zypper and what we plan to do. (i.e. create a roadmap/design) - Includes rootfs generation - Package uprev/install/removal || 1 || Done || Mark/Qing || || was M2, Sprint B<br />
|-<br />
|| Distribution / components|| Distro Audit: Licence Checksums|| Make the licence checksums fatal if not present || 1|| Done || Saul|| rpurdie|| Hygiene, was M2, Sprint C<br />
|-<br />
|| Distribution / components|| push of all relevant Wind River patchs to Yocto (patch comparison)|| Ensure patches present to packages in WRS are also in Poky|| 1|| Done || Mark|| Mark|| was M2, Sprint C<br />
|-<br />
|| Poky Features || Performance Enhancement Completed || Initial changes to reduce disk space (sstate-build-*) || 1|| Done || Saul / Qing, Dongxiao || rpurdie|| Enhancement, was M2, Sprint E<br />
|-<br />
|| Distribution / components|| User specified qemu config support|| We'll provide user an edit box which allows advanced qemu user to specify arbitrary qemu configuration to meet their needs, which the poky-qemu scrip will just append the config list towards the end of the list of parameters to bring up qemu, it also expect the poky-qemu script to do some basic sanity check on the user specifications to catch the obvious mistake || 2|| Done || Saul / criping || criping|| enhancement, was M2, Sprint E<br />
|-<br />
|| Tool Development and SDK Features|| SDK Version Control support in SDK generator installer|| If we can expect that yocto SDK has lots of release in the future, we might need to consider SDK version control. Currently, if we un-tar the sdk, it will override the older version. It's not good for app developers since they might need the old version to do something. And also, maybe a finer installer than untar is preferred. Installer will tied to certain SDK version and the installation will go under /opt/poky-versionNo.|| 1|| Done || Jessica|| criping|| Enhancement-expect planning process by Jessica to handle this task. Was M2, Sprint E.<br />
|}<br />
<br />
=== Sprint B (closes Jan 07, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || Bitbake multi-threaded parsing|| Bitbake recipe parsing is currently single threaded. I want to make this multithreaded as the speedup would be nice. If I can only take a single task for myself for 1.0, I'm nominating this one as I enjoy this kind of thing and I have ideas on how to do it. || 1|| Done || Richard|| rpurdie|| Enhancement<br />
|-<br />
|| Distribution / components|| Lock in Kernel/Toolchain version|| Locked in 2.6.37 and gcc 4.5.1. Pending decision to move to 4.5.2 and Linaro || || Done || || Richard|| || <br />
|-<br />
|| Distribution / components|| License Update|| For each of the licences we support, I'd really like to have a licences directory with a copy of that license contained within. When it comes to deciding what a given LICENSE field means, this would be the reference. It also means we can include the licences a given image includes with the image. This continues to make our license handling world class and ahead of the field. || 2|| Done || Beth|| rpurdie|| Hygiene<br />
|-<br />
|| Tool Development and SDK Features|| Qemu configuration change|| Provice edit box for advanced user to specify qemu configurations|| 2|| Done || Jessica|| criping|| <br />
|-<br />
|| Tool Development and SDK Features|| Lock down Eclipse+CDT+TCF version|| Will use Eclipse Halo 3.6 || 1|| Done || Jessica|| || <br />
|-<br />
|| Demo|| Finalize on demo plans for v1.0 launch || || 1|| Done || Dave || || <br />
|-<br />
|| Release || Release plans for v1.0 launch || Fill out the M4 plan with the necessary release activities and timings || 1|| Done || Beth || || <br />
|-<br />
|| Poky Features || Basic image creator GUI || Functional UI missing some Advanced features || 1 || In replan || Joshua || || <br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer for SDK Generator Installation functions support||Detailed feature request can be found at: http://bugzilla.pokylinux.org/show_bug.cgi?id=589|| 1|| Done || Jessica|| rpurdie|| Enhancement<br />
|-<br />
|| Kernel || Tracing: trace-cmd python binding cleanup || || 3 || Done || Darren || dvhart ||<br />
|}<br />
<br />
=== Sprint C (closes Jan 14, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || kernel development layer|| The (correct) poky behaviour of building known revisions coupled with the fetcher requiring a BSP branch to already be present means that local modifications (and kernel source tree) are required for kernel development. I already have a layer that overrides/modifies the behaviour when added to the bblayers.conf and configured into an environment. This seems useful for more people to use. || 2|| Done || Bruce|| bruceashfield|| Enhancement, was M2, Sprint C<br />
|-<br />
|| Distribution / components|| Zypper/RPM|| RPM Uprev / Zypper Uprev [lets get to the latest versions]|| 1|| pull request by Jan 19; || Mark/Qing|| || was M2, Sprint C<br />
|-<br />
|| Supported Targets|| Intel Platform Support|| JasperForest|| 2|| Basic support in place; DPDK evaluation in process, overall BSP plan still TBD || Tom|| davest|| Basic ECG support (Moved from Sprint A)<br />
|-<br />
|| Tool Development and SDK Features|| Eclipse poky tree interfacing (git support)|| Use Eclipse git capability to install poky tree from git repo and able to interact with git repo at file level within Poky tree || 2|| Done || Jessica|| jzhang|| Enhancement<br />
<br />
|-<br />
|| Poky Features || Poky Image Creator|| A standalone application you can run which asks you to select a distro and machine, then presents a list of packages you can select. Once the selection is made, it goes off and bakes you an image which is then presented to you. Implementation wise, it should use the sstate packages, be a bitbake UI and use the usual poky bbclass files to do the image construction behind the scenes. || 1|| Re-plan || Joshua|| rpurdie|| Enhancement<br />
|-<br />
|| Distribution / components|| LSB Sanity|| execute LSB Test and improve passing rate and document failures with clear understanding|| 2|| Done || MarkH/Saul|| sgw|| Hygiene<br />
|-<br />
|| Tool Development and SDK Features|| Image creator integration with Eclipse || || 2|| replan|| Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Kernel || Tracing: perf trace marker support || This is from feedback to the new trace command. Ingo appears to have this nearly complete already. || 3 || Done || Darren || dvhart ||<br />
|-<br />
|| Kernel || Tracing: perf trace scripting support || || 3 || Move to Sprint D; on track for Jan 21 || Tom || dvhart ||<br />
|-<br />
|| Cleanup || bitbake user experience error handling validation completed || || 2 || Done || Richard || ||<br />
|-<br />
|| Cleanup || variable scrub - ensure all metadata variables are documented || Script with a histogram of variable use done, identified 50 variables to document; Add task for actual documentation update is low on the list || 2 || Done || Scott/Darren || ||<br />
|-<br />
|| Distribution / components|| Zypper/RPM|| Integration based on design from Sprint B|| 1|| On track for Jan28 || Mark/Qing|| sgw|| Functionality, was M2, Sprint E<br />
|-<br />
|| Kernel || Tracing: package kernelshark || || 3 || Done || Darren || dvhart ||<br />
|-<br />
|| Kernel || Tracing: tuna, oscillosope recipes || || 3 || Tom to discuss plan with Darren et al || Tom || dvhart ||<br />
|- <br />
|| BSP || Beagleboard XM Support || || 3 || Move to Sprint D || Darren || dvhart ||<br />
|}<br />
<br />
=== Sprint D (closes Jan 21, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Swabber || Complete review of swabber outputs || Move to M3 Sprint D || 1 || Move to M3 Sprint D || Alex || ||<br />
|-<br />
|| Poky Features || Fetcher Overhaul Phase 2 - API reorg||<br />
* f) Add a generic unpack funciton to __init__.py based on the unpack task in Poky ;<br />
* g) Split go() methods into the following steps: i) download() - do whatever transfer is necessary to get the sources locally ii) build_mirror_data() - generate any data that would be needed to construct a source mirror iii) unpack() - takes a directory as an argument of where to place extracted sources;<br />
The existing go() methods should be replaced with a set of calls to the above sections of functionality as appropriate in the individual fetchers. Some of these categories of function make no sense in certain fetchers, in which case they shouldn't need to implement them. Functions are only executed if the method is present.<br />
* h) Change Poky's unpack to call an unpack method in the fetchers.<br />
* i) Change Poky's fetch task to call a "download" method in the fetcher instead of go().<br />
|| 1|| Will land with phase 3 in Jan 21 || Saul / Ke, RP|| rpurdie|| Enhancement<br />
|-<br />
|| Poky Features || Fetcher Overhaul Phase 3 - git enhancement||<br />
* j) Optimize git fetcher for the new layout so for a git checkout, we clone the repository in download(), then unpack just does a clone with references to the original repo. <br />
* k) Ensure that we only set __BB_DONT_CACHE when SRCREV = "AUTOREV". This may need a new method call for fetchers to tell whether they're "floating" or locked down. <br />
* l) Add a new "BB_NO_NETWORK" variable which the fetchers check before peforming an operation which hits anything remote. This means adding in error messages about why network access is needed at various points (e.g. SRCREV = "AUTOREV" for a given recipe) <br />
* m) Add multiple branch/srcrev support for git fetcher. These would be of the form: git://somelocation/somerepo.git;name=ref1;branch=foo;name=ref2;branch=bar SRCREV_ref1 = "hash1" SRCREV_ref2 = "hash2" which would ensure both hash1 and hash2 were in the final repo. <br />
* n) Change git fetcher to default to git protocol instead of rsync<br />
|| 1|| Slipped to Sprint D || Saul / Ke, RP|| rpurdie|| Enhancement<br />
|-<br />
|| Poky Features || DSO linking changes|| "By the default the gcc linker will automatically link any dependant objects/libraries. ""Inherited"" linkages can cause issues, for example, where a shared object changes its dependencies but a program has come to rely on symbols from an implicitly linked library. Fedora implemented this change in F13, seems like it would be useful to have in Poky too. "|| 2|| On track for Jan 21 || Saul / Nitin || josh|| bug#516<br />
|-<br />
|| Distribution / components|| Distro Audit Documentation Output|| Audit package documentation output || 2|| Move to Sprint D due to libtool work || Saul / ScottG || rpurdie|| Hygiene<br />
|-<br />
|| Poky Features || libtool sysroot option|| libtool 2.4 has a sysroot option. We should try and use it, see how it works and whether we can ditch some of our libtool hacks. || 1|| On track for Jan 21 || Saul / ScottG || rpurdie|| Enhancement<br />
|-<br />
|| Distribution / components|| MACHINE or Recipe specific sysroots|| Each machine should have its own sysroot. We'll probably have to split do_populate_sysroot into a two step process, creation of the package and than installtion of the package, which the installation of the package being made machine specific (put ${MACHINE} into ${STAMP} and bitbake should do that). Also allowing this to work per recipe would be desireable|| 1|| On track 21 || Saul / Dongxiao || rpurdie|| Hygiene<br />
|-<br />
|| Distribution / components|| Toolchain Bootstrap Process|| The toolchain as it bootstraps overwrites files like libc.so and libgcc.so in the sysroot directory which causes issues if you just try and rebuild part of the toolchain. Each step of the bootstrap process should use a separate sysroot. Once this is once, sstate file overwriting detection can be added and enabled. || 1|| Patches submitted for comment, slip to Sprint D || Saul / Dexuan || rpurdie|| Hygiene<br />
|-<br />
|| Documentation Features|| Package report system|| move to public server [setup a package report system in an internal machine. We need push it publicly available. The basic features like search and report have been there. But there're still some enhancements in plan, to make it a fit place to feel Yocto metadata comfortably]|| 2|| Move to Sprint E|| KevinT|| ktian1|| enhancement<br />
|-<br />
|| Distribution / components||Add headers and libraries to qemu images ||Since we'll be using qemu images as target sysroot, need to create a set of qemu images for minimal, sato, LSB that contains target header and libraries.|| 2|| Pending a discussion on Jan 18 || Saul ||jzhang|| Enhancement<br />
|-<br />
|| Distribution / components|| push of all relevant Wind River patchs to Yocto (patch comparison)|| Update any additional patches needed since M2.|| 1|| May be done by Jan 21, pending RPM stuff || Mark|| Mark|| <br />
|-<br />
|| Distribution / components|| mklibs|| mklibs is a tool to optimize size of [e]glibc for a perticular root file system image. It is useful to save disk space on small devices. || 2|| Push to Sprint E || Saul|| Nitin Kamble|| enhancement<br />
|-<br />
|| Poky Features || Performance Enhancement || reduce disk space (hardlink) || 1 || On track for Jan 21, pending RP review || Saul / Qing, Dongxiao || rpurdie || Enhancement<br />
|-<br />
|| BSP || 2.6.37 Crown Bay Support || On Track for Jan 21 || 2 || || Tom || dvhart || <br />
|-<br />
|| BSP || 2.6.37 Emenlow Support || On track for Jan 21 || 2 || || Tom || dvhart || <br />
|}<br />
<br />
=== Sprint E (closes Jan 28, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| rootless X|| rootless x server has better security than x server launched by root. MeeGo already enable this feature. it would be nice for Yocto to also enable it. || 2|| On track for Jan 28 || Saul / Ke || yuke|| enhancement<br />
|-<br />
|| Documentation Features|| Package report system|| finish major feature development and internal review [setup a package report system in an internal machine. We need push it publicly available. The basic features like search and report have been there. But there're still some enhancements in plan, to make it a fit place to feel Yocto metadata comfortably]|| 2|| Move to Sprint E || Jonathan || ktian1|| enhancement, was M2, Sprint E<br />
|-<br />
|| Distribution / components|| perl upgrade|| perl is the most cross un-friendly recipe pending upgrade. || 2|| Slipping due to Linaro layer, moves to end of Sprint E || Nitin|| Nitin Kamble|| enhancement<br />
|-<br />
|| Supported Targets|| Intel Platform Support|| Sandybridge|| 2|| Accept|| Tom|| davest|| Basic ECG support<br />
|-<br />
|| Distribution / components|| performance indicators|| define some indicators (boot time, footprint, build time, power, component benchmarks, etc.) and then collect them for tracking purpose. The result could be posted on the wiki site, and the initial indicators can be easy ones which can be easily retrieved from autobuilder or weekly qa report). This way we have a clear track about the healthy of the Yocto project, and also identify weak areas. We can include qemu targets and several representational boards as the targets. || 2|| Review|| Beth/Jiajun|| ktian1|| enhancement<br />
|-<br />
|| Tool Development and SDK Features|| SDK user workshop|| Have some developers sit down and use our tools to develop demo software for Yocto. || 2|| Review|| Jessica|| josh|| Enhancement<br />
|-<br />
|| Kernel || Final linux-yocto_git.bb || With 2.6.37 kernel || 1 || || Bruce || dvhart ||<br />
|-<br />
|| Kernel || Final meta-linaro layer || || || || Darren || dvhart ||<br />
|-<br />
|| Kernel || Final meta-rt layer || || || || Darren || dvhart ||<br />
|-<br />
|| Kernel || Sandy Bridge || || 1 || || Tom || dvhart ||<br />
|}<br />
<br />
=== Sprint F (closes Feb 03 (THURSDAY), 11:59pm PDT -- pull request sent, initially reviewed) :: NOTE: China New Year Holiday ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Documentation|| ADT Reference Guide Draft out for review || Outline complete|| High|| WIP || Scott Rifenbark|| jzhang|| Documentation<br />
|-<br />
|| || || || || || || || <br />
|}<br />
<br />
== M4 (Feb 07 to Apr 15 -- Stabilize Complete Mar 18, Release Complete Apr 01, Contingency to Apr 15) ==<br />
<br />
This sprint is the [[Yocto Project v. 1.0 Release Cycle]].<br />
<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Documentation|| Migration chapter in the Poky Reference Manual|| This chapter would cover the four identified use-cases for migrating up to the most recent version of Yocto Project. Additionally, it would cover migration scenarios from other development systems. The chapter does not yet exist. The chapter has not been scoped outside of having a meeting that identified four use-cases that did not include migration from a development system outside of Yocto Project. It will take some more scoping time to cover those areas (a day or two). Again, I have no idea of the length. See earlier entries for standard industry writing estimates for software documentation|| Medium|| Not Started|| Scott Rifenbark|| 3-4 Weeks|| Documentation<br />
|-<br />
|| Documentation|| Yocto Project Development Guide|| This manual would be an over-arching document that frames the complete development cycle within Yocto Project. The idea here is that the document would be an umbrella document that spawned and referenced subsequent documents. The organization would be the first chapter overviewing the major development pieces such as recipe creation, building, debugging, publishing, fail-safing, back-door hook creation, etc. Scoping would be about two weeks and length would probably be about 40 pages. Overall development time would likely be a month of uniterruped time.|| Medium|| Not Started|| Scott Rifenbark|| 3 Weeks|| Documentation<br />
|-<br />
|| Validation|| Boottime/Performance Analysis|| Compare Yocto Project performance to other projects such as MeeGo|| 1|| Initial report on where we are by Feb 9 || Darren|| davest|| project commitment<br />
|-<br />
|| || Multilib Support|| Consider developing post-1.0 branch || 1|| to start in M4 || Richard|| ||<br />
|-<br />
|| Validation|| Alpha testing complete|| 4-5 internal developers unfamiliar with Yocto Project try to do a build and report on the experience and issues encountered|| 1|| Done by Feb 18 || Julie|| davest|| <br />
|-<br />
|| || || || || || || || <br />
|}<br />
<br />
== Features needed and to be put into sprints by assigned owners: ==<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || package config option enhancement|| there're several enhancements we may do here: * allow users setting specific config options (local or global) from external tool, such as poky image creator, instead of changing recipes manually. Need a mechanism to convert from variable assignments into exact config options (e.g. feature_${PN} = ""1"" -> ""--enable-feature""). Consequently dependency chain needs update with option status. * host contamination check. We have swabber to check host contamination, but I'm not sure whether it covers configuration phase. If not, this is one area to improve, as not ususually we see configure script checks host bits for available features * conditional option manipulation. In many recipes we enable/disable one option based on availability of other packages. Now this is done manually and not flexible. this should be made automatically though some new annotation to indicate condition, or just base_contains (not convenient: long line, need define distro features) || 2|| Review|| Richard/MarkH|| ktian1|| Enhancement<br />
|-<br />
|| Media|| Yocto Project Awareness Video|| This 2.5 minute video would introduce and describe the benefits of Yocto Project. The video would use entertaining animations that described concepts and benefits. The result would be suitable for YouTube, conferences, and the website. The production is called an "Epipheo" and will be created by Epipheo Studios. The engagement process has begun and the kick-off meeting will be soon. The PO is in place. Time for development is 10 weeks.|| High|| Kick-off Imminent|| Scott Rifenbark|| 10 Weeks|| Media<br />
|-<br />
|| Documentation|| Yocto Project Debugging Guide|| This would be a guide for the debugging and bug tracking process in Yocto Project. Originally, the thought was that we needed a Bugzilla User's Manual. However, since we don't own Bugzilla it doesn't make sense to produce documentation for it. Rather, we should document the process as it fits into the Yocto Project environment. Ideally, the manual would be a sub-manual that would be referenced and architected into the Yocto Project Development Guide. The manual has not been scoped and would take a week to scope. Again, I have no idea of the length. See the previous item for standard industry writing estimates for software documenation.|| Medium|| Not Started|| Scott Rifenbark|| 3-4 Weeks|| Documentation<br />
|-<br />
|| Website|| Yocto Project Website|| The 0.9 website is in place but needs updates. Items for consideration are the left-panel naviagation scheme, a contributions guidance page, color-scheming and theme (possibly).|| Medium|| Not Started|| Scott Rifenbark|| 1-2 Weeks|| Website<br />
|}<br />
<br />
== Features not believed to be needed in v1.0: ==<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || OpenEmbedded/Bitbake Upstreaming|| "We firstly need to review where we are and where OE is. We then need to make a plan about what we're going to push upstream and what we're not. I'd suggest when we're in PRC, we do a crash course in ""dealing with OE"" and then many dedicate a block of time (a week) where the distro team comes up with a patch set we then propose and get merged into OE. I'd like to find a couple of interested people to monitor OE more regularly and start a workflow of things between Poky/OE where appropriate. The key thing to remember is we need to keep the architectures compatible. The team is now at the point where I'm happy for them to actually try building OpenEmbedded and not worry about it tainting them! "|| 2|| Review|| || rpurdie|| Process<br />
|-<br />
|| Poky Features || Handle old versions in WORKDIR|| an incremental build directory may finally include many old versions WORKDIRS. It'll be good to have those old versions tracked in the cache, which can then either generate a report or allow selectively cleaning up an specific version WORKDIR. Or else it's difficult to figure it out when people want to keep the whole tmp directory but like to cleanup some old bits when disk usage is under pressure. If it's not easy to do in bitbake, perhaps some separate scripts would be also helpful || 3|| Review|| || ktian1|| Enhancement<br />
|-<br />
|| Poky Features || run bitbake w/o rebuilding the cache|| "sometimes it's useful to allow run bitbake w/o re-parsing recipes, if we know nothing metadata is changed. we can just allow reusing existing persistent cache. this is useful when people is debugging WORKDIR w/o metadata change. also sometimes ""bitbake -e"" is used frequently to check poky variable information. with existing cache, several seconds can be saved which are not negligible for a developer daily working on Yocto "|| 2|| Review|| || ktian1|| Enhancement<br />
|-<br />
|| Poky Features || parallel make improvement|| parallel make experience is not good, especially when bb threads and make threads are increased larger than 8. So far we either try to fix package makefile or mark the recipe as no parallel make, when build faiures are reported. But this greatly impacts user experience for a successfully continuous build process. Could we define a safe number we do want to support for 1.0 release? and then have our autobuilder, QA test, and developers cover that number immediately and fix any issues accordingly. Then the safe number can be suggested to the Yocto user || 2|| Review|| || ktian1|| Enhancement<br />
|-<br />
|| Poky Features || Dependency packages rebuild/clean|| It is a mechanism to rebulid or clean a package and all other packages which have build/runtime dependency on it. With this change, we can find potential influences of package upgrade to its related packages, which can make the incremental build more trustable. For example, if we upgrade a package to a new vesion which changes its API, this mechanism can easily find out the incompatibility to other packages which have dependency on it. || 2|| Review|| || dongxiao.xu|| Enhancement, replaced by checksum feature<br />
|-<br />
|| Distribution / components|| FOSSology|| This may be similar to License Update above, but start to use FOSSology to track licenses. || 2|| Review|| || sgw|| Hygiene<br />
|-<br />
|| Distribution / components|| Package Developer Tools|| Create a set of Init scripts template and then review our current init scripts and modify them to confirm to the template. || 2|| Review|| || sgw|| Easy of Use<br />
|-<br />
|| Distribution / components|| Package Website|| Complete the work the intern has started on generating the distro tracking information and get it out on the external site. || 2|| Review|| || sgw|| "Hygiene, duplicate of ""Package report system"""<br />
|-<br />
|| Distribution / components|| Bluetooth UI support|| Currently we have bluez package in poky, and we need to have a workable graphic user interface to connect/configure BT devices. One choice may be gnome-bluetooth-applet. || 3|| Review|| || dongxiao.xu|| enhancement<br />
|-<br />
|| Distribution / components|| Connman-gnome enhancement features|| Enable connman-gnome to support features like, WPA Enterprise connection, hidden SSID, etc. || 3|| Review|| || dongxiao.xu|| enhancement<br />
|-<br />
|| Distribution / components|| Java Running Environment support|| Since most embedded systems support java applications running in it, maybe we'd better consider supporting some kinds of JVMs(Embeded JVM). The JVM may not run by default, but user can launch it if running java applications. Compared with GTK/QT, java user number is not small too. || 3|| Review|| || criping|| enhancement<br />
|-<br />
|| Distribution / components|| create more use cases|| UPnP demo is one really good use case showing how Yocto is utilized to make real functionality. and we could create more to show how Yocto is easily adapted to real use cases. Those use cases can be either maintained as seperate demo layers in yocto repo, or in seperate branches for reference. We can also call for community's contribution on this which would make 1.0 full-fledged. Or else the newbies to Yocto may be in puzzle how our sample profiles can satisfy their requirements. || 2|| Review|| || ktian1|| enhancement<br />
|-<br />
|| Distribution / components|| i18n support || internationalization is an important system wide feature. Many component like font, locale affect the i18n. Yocto alreay has some i18n related package like pango, but so far did not consider i18n systematically. so this is place holder to systematically add i18n support. || 2|| Review|| || yuke/qing|| enhancement<br />
|-<br />
|| Distribution / components|| more demos || demos are a good way to educate, push the envelope, and at the same time tout the strengths of the platform. This item just records a current set of ideas from various sources which could/should be implemented: * face-recognition/face-finding, * robotic control/application of face-finding to 'camera-as-sensor' (hexbug demo), * others [tbd, add here]|| 2|| Review|| || tzanussi|| enhancement <br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer support for image-creator and needed yocto-metadata design||Come up design what need to be created as packages to support using "opkg install" for image-creator and needed yocto-metadata|| 2|| WIP, pending comments from RP regarding how to packaging metadata|| Jessica|| rpurdie|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer image-creator and needed poky-metadata support|| The poky build system will build packages for image-creator and needed poky-metadata, which the Yocto Installer will be able to use "opkg install" to install them|| 2|| Review|| Jessica|| rpurdie|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Provide qemu management UI|| In current eclipse plugin, QEMU settings are put together with project configuration. So we can only have limited settings. If we can have a separate QEMU management UI, the end user could firstly create a QEMU config, such as (env file of arch, image location, unfs or not, sato or lsb, mem size, disk size). And then he can launch a QEMU with a specific config. The dependency between project configuration and QEMU config will be resolved. After all QEMU has nothing to do project configuration. Need to careful review the UI to ensure minimal impact to testing matrix. || 3|| Review|| || criping|| "Enhancement, duplicate of ""Qemu mem/disk size can be adjusted"""<br />
|-<br />
|| Tool Development and SDK Features|| QT plugin For Eclipse|| Integrate QT Ecplise plugin and extend for Yocto Project || 3|| Review|| || jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Profiling/Trace GUI's|| We have a wealth of great tracing and profiling tools but the UI's for them are all extremely minimal and usually quite ugly. Would be great if we could compete with, or even better, Apple's offerings here. We have the technology! || 2|| Review|| || josh|| "Enhancement, duplicate of ""Tracing/Profiling Planning Complete"""<br />
|-<br />
|| Tool Development and SDK Features|| Other profiling tools|| Complete Tom's review of profiling tools and architecture || 2|| Review|| || josh|| "Enhancement, duplicate of ""Tracing/Profiling Planning Complete"""<br />
|-<br />
|| Tool Development and SDK Features|| Design next-gen tracing/profiling tools|| Yocto 1.0 will include all the essential existing tracing/profiling tools expected by users, and Josh has proposed a UI integration of all those tools as far as it's possible to do so. That level of integration, basically a 'plugin-level' integration is necessary and useful, but doesn't go far enough. A next-generation tracing tool would integrate at a much more fundamental level; if done properly, it would provide unmatched levels of power and usability to users, and would allow Yocto to distinguish itself in the embedded tracing/profiling space in a way also unmatched by any other distro/build-tool. The implementation would of course not be available for Yocto 1.0, but a coherent design, including prototypes, that could be taken to the community and implemented in a V 1.5 or 2.0 should be done in that time frame. || 1|| Review|| || tzanussi|| "Enhancement, duplicate of ""Tracing/Profiling Planning Complete"""<br />
|-<br />
|| Documentation Features|| Self Documentation of image contents|| "I'd like to see the -doc packages Poky builds being combined into some kind of large documentation index representing the collective API docs of the target being built. This can then be placed on a webserver and viewed over the web. We'd have a demonstration of this for a ""bitbake world"" target. Part of the idea here is to start making good use of the docs as if developers see this they might start writing better docs too. Aim is to lead the field :). There are a number of places poky packages disable doc generation due to missing tools so we'd need to add these so we can enable the doc generation. Many packages already have many docs though too. "|| 2|| Review|| || rpurdie|| enhancement<br />
|-<br />
|| Validation|| Testing Framework|| Add a framework for doing automated testing in the project|| 1|| Review|| || davest|| project commitment<br />
|-<br />
|| Validation|| more SDK builds on autobuilder|| enable more SDK related tests on autobuilder such as meta-ide-support, etc.|| 2|| Review|| || ktian1|| project commitment, addressed by test plan (?)<br />
|-<br />
|| Validation|| more people should try using SDK|| this may not be a feature, but a requirement. SDK including meta-toolchain is one key factor impacting user experience on Yocto. It's not enough to have only SDK team play with it|| 2|| Review|| || ktian1|| project commitment, addressed by test plan (?)<br />
|-<br />
|| Validation|| Unit Testing Framework|| Add a mechanism to bitbake to parse source packages that have unit tests and then execute them on the target|| 3|| Review|| || sgw|| "project commitment, duplicate of ""Testing Framework"""<br />
|-<br />
|| Validation|| Test Case open source|| Open source Yocto test cases with xml format|| 1|| Review|| || yyou|| "project commitment, duplicate of ""Testing Framework"""<br />
|}</div>Davesthttps://wiki.yoctoproject.org/wiki/index.php?title=Yocto_1.0_Schedule&diff=588Yocto 1.0 Schedule2011-01-25T01:30:16Z<p>Davest: /* M4 (Feb 07 to Apr 15 -- Stabilize Complete Mar 18, Release Complete Apr 01, Contingency to Apr 15) */</p>
<hr />
<div>= v1.0 (release date: Apr 15, 2011) =<br />
----<br />
The detailed milestone map for v1.0 is as below. During the first week of each subsequent milestone past M1 we will have a demonstration of the previous milestone capabilities as well as a planning and design session for the current milestone.<br><br><br />
<br />
== M2 (Nov 08 to Dec 24 -- Dev Complete Dec 10, Stabilize Complete Dec 17, Release Complete Dec 24) ==<br />
=== Sprint A (closes Nov 12, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links''' <br />
|-<br />
|| Poky Features || Kernel interactive targets || To support incremental kernel development having the ability to run menuconfig (or xconfig, etc) directly is a common request. We'll need to add this for commercialization anyway. i.e. bitbake -c menuconfig. This fuctionality already exists. || 1 || Done || Richard || bruceashfield || Enhancement <br />
|-<br />
|| Distribution / components || Distro Audit: Upgrades Planned (Phase 1) || Complete plan for package upgrades in M2 || 1 || Done || Saul || || Continual Maintenance<br />
|-<br />
|| Validation || Runtime testing || Runtime testing of images as part of the autobuilder || 1 || Done || Jiajun/ScottG || rpurdie || project commitment<br />
|- <br />
|| || Poky Image Creator Wireframe/Interaction Plans Complete || || 1 || Done || Josh || ||<br />
|-<br />
|| || SDK Generator Interaction: Plans Complete || || 1 || Done || Jessica || ||<br />
|-<br />
|| || Tracing/Profiling Planning Complete || This needs to cover where we're at now, what we're missing and also propose the future enhancements that may be needed. M2 targets getting existing tools integrated and documented. F2f discussion n the future enhancements || || Done || Tom || ||<br />
|-<br />
|| || Swabber. (Still needs to be integrated into weekly build by default) || || 1 || Done || Josh || ||<br />
|-<br />
|| Build/Release || Release process documentation || || || Done || Beth || ||<br />
|-<br />
|| Validation || Test plan for v1.0 (to address any deficiencies in coverage from v0.9)|| || 1 || Done || Jiajun || ||<br />
|}<br />
<br />
=== Sprint B (closes Nov 19, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| Distro Audit: World Packages|| Audit world packages making sure it all build, making sure all are packages are required || 2|| Done || Saul|| sgw|| Hygiene<br />
|-<br />
|| Tool Development and SDK Features|| SDK Generator Installer UI|| Look at different ways of Installer UI (GTK+ and ncurses) seems none of them is the right choice, decide to go with script to implement all the functionalities of installer and later add UI part on top of it || 1||Done|| Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Customize sysroot setup || Add and test out "--sysroot" config option to cross compiler within Eclipse IDE || 1|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| SDK Generator Installer design revision|| Close all open questions regarding Yocto SDK Generator Installer function design and come up HLD || 1|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Distribution / components|| kernel version|| keeping 2.6.34 as a -stable kernel is the best option. I've also got a newer -devel tree that can be made available or made the default. || 3|| Done || Bruce|| bruceashfield|| enhancement<br />
|-<br />
|| || assign Yocto Project PM|| acquire and assign a program manager for Yocto Project|| || Done || DaveST|| || <br />
|-<br />
|| || assign Yocto Project Sys Admin|| || || Done || Saul|| || <br />
|-<br />
|| Tool Development and SDK Features|| oprofileUI|| Fixing various bugs of the oprofileUI to make it workable on big endian host.(i.e. ppc, mips) || 2 || Done || Jessica || lianhao.lu || Bug #382 / Bug #493<br />
|-<br />
|| Poky Feature|| SDK Version Control|| If we can expect that yocto SDK has lots of release in the future, we might need to consider SDK version control. Currently, every thing installed under /opt/poky which leads to things be overriden, we need to be able to use a scheme like /opt/poky-1.0, /opt/poky-2.0 to distiguish things. || 2|| Done || Josh|| jzhang|| Enhancement<br />
|-<br />
|| Kernel || Kernel plan complete || Flesh our kernel deliverables and add to Yocto 1.0 schedule || || Done|| Darren || dvhart ||<br />
|}<br />
<br />
=== Sprint C (closes Nov 26, 11:59pm PDT -- pull request sent, initially reviewed) :: NOTE: this is US Thanksgiving week ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| Distro Audit: Licence Checksums|| licence checksums || 1|| Done || Saul|| rpurdie|| Hygiene<br />
|-<br />
|| Poky Features || Performance Analysis Completed|| "I'd like someone to instrument a green release build, see where it spends time (hot/cold parsing time, individual task building time) and then compare this with our 0.9 release build. I'd also like to compare the disk usage between the two. Once we have a blame list we can then set about fixing it. Some things I know will come up: a) pseudo, b) checksums/signature code, c) exec() vs fork for executing tasks, d) task based prebuilds increasing disk usage, e) rpm dependency calculations, f) using rpm vs. ipk but I may be wrong and there may be others. We need numbers. "|| 1|| Done || Saul / Qing, Dongxiao|| rpurdie|| Enhancement<br />
|-<br />
|| Poky Features || environment variables for kernel builds|| switching a branch, or adding a configuration feature (and even changing the kernel repo) is often done during development of a BSP. Having some additional variables that are pass the bitbake environment scrub would be useful. i.e. KBRANCH=foo bitbake -c configure linux-yocto. This goes along with the other BSP bootstrapping suggestions. || 2|| Done || Bruce|| bruceashfield|| Enhancement<br />
|-<br />
|| Supported Targets|| ARM Platform Support|| Replace beagleboard with Beagleboard XM - decision || 2|| Done || Bruce|| alex|| Basic Yocto hardware support <br />
|-<br />
|| Distribution / components|| Security Process|| We need a dedicated person to scan and apply critical security updates to the distro. The MeeGo team already has a similar process with some scripts which may be leveraged. To complete the task, the process should be documented and a first pass over the metadata made to establish the current position on security. Any upgrades needed should be identified and a plan to address them should be in place but doesn't have to be implemented by this point.|| 1|| Done || ScottG|| ktian1|| enhancement<br />
|-<br />
|| Tool Development and SDK Features|| SDK Generator Installer Opkg repo design|| Come up a opkg repo design that will mimic the final Yocto package repo layout to be used by SDK Generator Installer to test against|| 2 || Done || Jessica || jzhang || <br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer tar creaion|| Create a Yocto Installer tar ball which contains Installer script and supported opkg component that will be used for installing other Yocto components|| 2 || Done || Jessica || jzhang || <br />
|-<br />
|| Documentation|| Kernel Framework Paper from WR|| The paper from WR needs to be re-written and then posted somewhere on the Yocto Project site. This will involve examiniation of the text and re-writing and formatting for presentation. Currently it is simply a text document. Completion time assuming uninterrupted time is one week.|| High|| Done || Scott Rifenbark|| 1 Week|| Documentation<br />
|-<br />
|| Documentation|| Poky Reference Manual|| This guide exists in the 0.9 form. The re-write of the text needs to be completed. So far, all the chapters have been rewritten but not re-posted on the site. Only the appendices remain for a text scrub. Time to complete this would be a week of uninterrupted time. Ideally, the manual would be a sub-manual that would be referenced and architected into the Yocto Project Development Guide.|| Medium|| Done|| Scott Rifenbark|| 1 Week|| Documentation<br />
|-<br />
|| Kernel || Initial meta-linaro layer || meta-linaro layer providing a kernel, tool-chain, and uboot loader. This deliverable is primarily to get the infrastructure in place and have a buildable kernel. Toolchain on best effort basis. || || Done || Darren || dvhart || Moderate risk of slippage due to holidays.<br />
|-<br />
|| Kernel || Tracing: blktrace and sysprof recipes || || || Done || Tom || dvhart ||<br />
|}<br />
<br />
=== Sprint D (closes Dec 3, 11:59pm PDT -- pull request sent, initially reviewed) :: NOTE: week of the F2F planning meeting ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Kernel || Kernel git branching structure revamped || || 1 || Done || Bruce || dvhart ||<br />
|-<br />
|| Kernel || Tunnel Creek (Crown Bay) || || 1 || Done || Tom || dvhart ||<br />
|}<br />
<br />
=== Sprint E (closes Dec 9 (THURSDAY), 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| Distro Audit: Upgrades Completed (Phase 1)|| Update to new versions as per the agreed plan for M2 from Sprint A|| 1|| Done || Saul|| rpurdie|| Continual Maintenance<br />
|-<br />
|| Distribution / components|| Distro Audit: Src Checksums|| Make sure all SRC_URI components have checksums too || 1|| Done || Saul|| rpurdie|| Hygiene<br />
|-<br />
|| Poky Features || enable KVM with qemu|| today all new Intel processors support VT, which are enabled on most desktop machines which are most frequently used build machine. with VT support, x86/x86-64 qemu target runs faster which is a good thing for emulation environment. This may require some qemu option tweaks and also poky-qemu script enhancement. || 2|| Done || Saul / Edwin|| ktian1|| Enhancement<br />
|-<br />
|| Kernel || New kernel recipes || dev, -devel, -custom || 3 || Done || Bruce || dvhart ||<br />
|-<br />
|| Swabber || Documentation for swabber || || 1 || Done || Alex || ||<br />
|-<br />
|| CCB || Defect triage process in public documented and implemented || || 1 || Done. Triage process is documented, out for review. || Saul || ||<br />
|}<br />
<br />
== M3 (Dec 20 to Feb 08 -- Dev Complete Feb 04, Stabilize Complete Feb 11, Release Complete Feb 18) ==<br />
=== Sprint A (closes Dec 24, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Kernel || Initial meta-rt layer || PREEMPT_RT kernel and related test-cases and benchmarks || 2 || Done by Jan 21 || Darren || dvhart || slipped out from M2<br />
|-<br />
|| Poky Features || Fetcher Overhaul Phase 1 - SRC_REV enhancement||<br />
* a) Add code in FetchData::__init__() which will check if the selected fetcher supports srcrev and the automatically call a function to set the src rev value instead of each fetcher doing this.\n <br />
* e) Break SRCREVINACTION deadlock. To do this, we need to start using a keyword for automatically increasing SRCREV, e.g. SRCREV = "AUTOINC". The actual revision can be injected into PV using SRCPV. If we do this there should no longer be a need of the deadlock; <br />
* k) Ensure that we only set __BB_DONT_CACHE when SRCREV = "AUTOREV". This may need a new method call for fetchers to tell whether they're "floating" or locked down.<br />
|| 1|| Done || Saul / Ke, RP|| rpurdie|| Enhancement, slipped out from M2<br />
|-<br />
|| Distribution / components|| Distro Audit Upgrades Planned (Phase 2)|| Complete plan for package upgrades in M2|| 1|| Done || Saul|| || Continual Maintenance<br />
|-<br />
|| Poky Features || Pseudo Performance || Implement the changes to bitbake based on pseudo's enable/disable switch|| 1|| done || Saul / Qing, Dongxiao || rpurdie|| Enhancement, slipped from M2 due to risk and not having Pseudo's change yet.<br />
|-<br />
|| Tool Development and SDK Features|| Fix the issue user target sysroot is owned by root || The ADT installer will use pseudo to extract user target sysroot which ended up owned by root, this need to be fixed || 1|| done || Jessica|| jzhang|| Cleanup <br />
|-<br />
|| Tool Development and SDK Features|| Eclipse poky tree interfacing (metadata file editor)|| Provide a metadata file editor with some syntax checking and keywords highlight capabilities|| 2|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| IDE Project templates|| Templates for various project types: Clutter GUI, Gtk+ GUI, to help developers get started quickly || 2|| Done || Jessica|| josh|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| push TCF/RSE patches upstream|| work with community to finish up our TCF terminal service, TCF/RSE integration remaining patches taken by upstream. Blocking issues including Eclipse Bug #327865 || 1|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Pseudo || Pseudo enhancement to enable on/off switch || || 1 || done || Mark || ||<br />
|-<br />
|| Pseudo || Bitbake enhancement for pseudo on/off switch || || 1 || done || Richard || ||<br />
|-<br />
|| bugzilla || Complete restructure of bugzilla categories || || 1 || done || Saul || ||<br />
|-<br />
|| Poky Features || Image creator ground work || Nomenclature determined, existing gui's bug fixed and backend work implemented || 1 || Done || Joshua || ||<br />
|-<br />
|| Kernel || Tracing: Initial SystemTap recipe || Works on x86 || 3 || Done || Tom || dvhart ||<br />
|-<br />
|| Distribution / components|| Distro Audit: Package Description/Summary completed|| Ensure DESCRIPTION/SUMMARY fields are all audited|| 2|| Done || Mark|| Mark|| Hygiene, was M2, Sprint B but missed window<br />
|-<br />
|| Distribution / components|| Zypper/RPM|| Small write-up of the problems we're having w/ Zypper and what we plan to do. (i.e. create a roadmap/design) - Includes rootfs generation - Package uprev/install/removal || 1 || Done || Mark/Qing || || was M2, Sprint B<br />
|-<br />
|| Distribution / components|| Distro Audit: Licence Checksums|| Make the licence checksums fatal if not present || 1|| Done || Saul|| rpurdie|| Hygiene, was M2, Sprint C<br />
|-<br />
|| Distribution / components|| push of all relevant Wind River patchs to Yocto (patch comparison)|| Ensure patches present to packages in WRS are also in Poky|| 1|| Done || Mark|| Mark|| was M2, Sprint C<br />
|-<br />
|| Poky Features || Performance Enhancement Completed || Initial changes to reduce disk space (sstate-build-*) || 1|| Done || Saul / Qing, Dongxiao || rpurdie|| Enhancement, was M2, Sprint E<br />
|-<br />
|| Distribution / components|| User specified qemu config support|| We'll provide user an edit box which allows advanced qemu user to specify arbitrary qemu configuration to meet their needs, which the poky-qemu scrip will just append the config list towards the end of the list of parameters to bring up qemu, it also expect the poky-qemu script to do some basic sanity check on the user specifications to catch the obvious mistake || 2|| Done || Saul / criping || criping|| enhancement, was M2, Sprint E<br />
|-<br />
|| Tool Development and SDK Features|| SDK Version Control support in SDK generator installer|| If we can expect that yocto SDK has lots of release in the future, we might need to consider SDK version control. Currently, if we un-tar the sdk, it will override the older version. It's not good for app developers since they might need the old version to do something. And also, maybe a finer installer than untar is preferred. Installer will tied to certain SDK version and the installation will go under /opt/poky-versionNo.|| 1|| Done || Jessica|| criping|| Enhancement-expect planning process by Jessica to handle this task. Was M2, Sprint E.<br />
|}<br />
<br />
=== Sprint B (closes Jan 07, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || Bitbake multi-threaded parsing|| Bitbake recipe parsing is currently single threaded. I want to make this multithreaded as the speedup would be nice. If I can only take a single task for myself for 1.0, I'm nominating this one as I enjoy this kind of thing and I have ideas on how to do it. || 1|| Done || Richard|| rpurdie|| Enhancement<br />
|-<br />
|| Distribution / components|| Lock in Kernel/Toolchain version|| Locked in 2.6.37 and gcc 4.5.1. Pending decision to move to 4.5.2 and Linaro || || Done || || Richard|| || <br />
|-<br />
|| Distribution / components|| License Update|| For each of the licences we support, I'd really like to have a licences directory with a copy of that license contained within. When it comes to deciding what a given LICENSE field means, this would be the reference. It also means we can include the licences a given image includes with the image. This continues to make our license handling world class and ahead of the field. || 2|| Done || Beth|| rpurdie|| Hygiene<br />
|-<br />
|| Tool Development and SDK Features|| Qemu configuration change|| Provice edit box for advanced user to specify qemu configurations|| 2|| Done || Jessica|| criping|| <br />
|-<br />
|| Tool Development and SDK Features|| Lock down Eclipse+CDT+TCF version|| Will use Eclipse Halo 3.6 || 1|| Done || Jessica|| || <br />
|-<br />
|| Demo|| Finalize on demo plans for v1.0 launch || || 1|| Done || Dave || || <br />
|-<br />
|| Release || Release plans for v1.0 launch || Fill out the M4 plan with the necessary release activities and timings || 1|| Done || Beth || || <br />
|-<br />
|| Poky Features || Basic image creator GUI || Functional UI missing some Advanced features || 1 || In replan || Joshua || || <br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer for SDK Generator Installation functions support||Detailed feature request can be found at: http://bugzilla.pokylinux.org/show_bug.cgi?id=589|| 1|| Done || Jessica|| rpurdie|| Enhancement<br />
|-<br />
|| Kernel || Tracing: trace-cmd python binding cleanup || || 3 || Done || Darren || dvhart ||<br />
|}<br />
<br />
=== Sprint C (closes Jan 14, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || kernel development layer|| The (correct) poky behaviour of building known revisions coupled with the fetcher requiring a BSP branch to already be present means that local modifications (and kernel source tree) are required for kernel development. I already have a layer that overrides/modifies the behaviour when added to the bblayers.conf and configured into an environment. This seems useful for more people to use. || 2|| Done || Bruce|| bruceashfield|| Enhancement, was M2, Sprint C<br />
|-<br />
|| Distribution / components|| Zypper/RPM|| RPM Uprev / Zypper Uprev [lets get to the latest versions]|| 1|| pull request by Jan 19; || Mark/Qing|| || was M2, Sprint C<br />
|-<br />
|| Supported Targets|| Intel Platform Support|| JasperForest|| 2|| Basic support in place; DPDK evaluation in process, overall BSP plan still TBD || Tom|| davest|| Basic ECG support (Moved from Sprint A)<br />
|-<br />
|| Tool Development and SDK Features|| Eclipse poky tree interfacing (git support)|| Use Eclipse git capability to install poky tree from git repo and able to interact with git repo at file level within Poky tree || 2|| Done || Jessica|| jzhang|| Enhancement<br />
<br />
|-<br />
|| Poky Features || Poky Image Creator|| A standalone application you can run which asks you to select a distro and machine, then presents a list of packages you can select. Once the selection is made, it goes off and bakes you an image which is then presented to you. Implementation wise, it should use the sstate packages, be a bitbake UI and use the usual poky bbclass files to do the image construction behind the scenes. || 1|| Re-plan || Joshua|| rpurdie|| Enhancement<br />
|-<br />
|| Distribution / components|| LSB Sanity|| execute LSB Test and improve passing rate and document failures with clear understanding|| 2|| Done || MarkH/Saul|| sgw|| Hygiene<br />
|-<br />
|| Distribution / components|| Review & Fix Standards Tests|| Review the results from LTP, POSIX and asses the result, fix as appropriate and clearly document failures.|| 2|| a Plan to resolve final items to be sent to the m.l. by Jan 14 || Saul/Kevin || sgw|| Hygiene<br />
|-<br />
|| Tool Development and SDK Features|| Image creator integration with Eclipse || || 2|| replan|| Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Kernel || Tracing: perf trace marker support || This is from feedback to the new trace command. Ingo appears to have this nearly complete already. || 3 || Done || Darren || dvhart ||<br />
|-<br />
|| Kernel || Tracing: perf trace scripting support || || 3 || Move to Sprint D; on track for Jan 21 || Tom || dvhart ||<br />
|-<br />
|| Cleanup || bitbake user experience error handling validation completed || || 2 || Done || Richard || ||<br />
|-<br />
|| Cleanup || variable scrub - ensure all metadata variables are documented || Script with a histogram of variable use done, identified 50 variables to document; Add task for actual documentation update is low on the list || 2 || Done || Scott/Darren || ||<br />
|-<br />
|| Distribution / components|| Zypper/RPM|| Integration based on design from Sprint B|| 1|| On track for Jan28 || Mark/Qing|| sgw|| Functionality, was M2, Sprint E<br />
|-<br />
|| Kernel || Tracing: package kernelshark || || 3 || Done || Darren || dvhart ||<br />
|-<br />
|| Kernel || Tracing: tuna, oscillosope recipes || || 3 || Tom to discuss plan with Darren et al || Tom || dvhart ||<br />
|- <br />
|| BSP || Beagleboard XM Support || || 3 || Move to Sprint D || Darren || dvhart ||<br />
|}<br />
<br />
=== Sprint D (closes Jan 21, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Swabber || Complete review of swabber outputs || Move to M3 Sprint D || 1 || Move to M3 Sprint D || Alex || ||<br />
|-<br />
|| Poky Features || Fetcher Overhaul Phase 2 - API reorg||<br />
* f) Add a generic unpack funciton to __init__.py based on the unpack task in Poky ;<br />
* g) Split go() methods into the following steps: i) download() - do whatever transfer is necessary to get the sources locally ii) build_mirror_data() - generate any data that would be needed to construct a source mirror iii) unpack() - takes a directory as an argument of where to place extracted sources;<br />
The existing go() methods should be replaced with a set of calls to the above sections of functionality as appropriate in the individual fetchers. Some of these categories of function make no sense in certain fetchers, in which case they shouldn't need to implement them. Functions are only executed if the method is present.<br />
* h) Change Poky's unpack to call an unpack method in the fetchers.<br />
* i) Change Poky's fetch task to call a "download" method in the fetcher instead of go().<br />
|| 1|| Will land with phase 3 in Jan 21 || Saul / Ke, RP|| rpurdie|| Enhancement<br />
|-<br />
|| Poky Features || Fetcher Overhaul Phase 3 - git enhancement||<br />
* j) Optimize git fetcher for the new layout so for a git checkout, we clone the repository in download(), then unpack just does a clone with references to the original repo. <br />
* k) Ensure that we only set __BB_DONT_CACHE when SRCREV = "AUTOREV". This may need a new method call for fetchers to tell whether they're "floating" or locked down. <br />
* l) Add a new "BB_NO_NETWORK" variable which the fetchers check before peforming an operation which hits anything remote. This means adding in error messages about why network access is needed at various points (e.g. SRCREV = "AUTOREV" for a given recipe) <br />
* m) Add multiple branch/srcrev support for git fetcher. These would be of the form: git://somelocation/somerepo.git;name=ref1;branch=foo;name=ref2;branch=bar SRCREV_ref1 = "hash1" SRCREV_ref2 = "hash2" which would ensure both hash1 and hash2 were in the final repo. <br />
* n) Change git fetcher to default to git protocol instead of rsync<br />
|| 1|| Slipped to Sprint D || Saul / Ke, RP|| rpurdie|| Enhancement<br />
|-<br />
|| Poky Features || DSO linking changes|| "By the default the gcc linker will automatically link any dependant objects/libraries. ""Inherited"" linkages can cause issues, for example, where a shared object changes its dependencies but a program has come to rely on symbols from an implicitly linked library. Fedora implemented this change in F13, seems like it would be useful to have in Poky too. "|| 2|| On track for Jan 21 || Saul / Nitin || josh|| bug#516<br />
|-<br />
|| Distribution / components|| Distro Audit Documentation Output|| Audit package documentation output || 2|| Move to Sprint D due to libtool work || Saul / ScottG || rpurdie|| Hygiene<br />
|-<br />
|| Poky Features || libtool sysroot option|| libtool 2.4 has a sysroot option. We should try and use it, see how it works and whether we can ditch some of our libtool hacks. || 1|| On track for Jan 21 || Saul / ScottG || rpurdie|| Enhancement<br />
|-<br />
|| Distribution / components|| MACHINE or Recipe specific sysroots|| Each machine should have its own sysroot. We'll probably have to split do_populate_sysroot into a two step process, creation of the package and than installtion of the package, which the installation of the package being made machine specific (put ${MACHINE} into ${STAMP} and bitbake should do that). Also allowing this to work per recipe would be desireable|| 1|| On track 21 || Saul / Dongxiao || rpurdie|| Hygiene<br />
|-<br />
|| Distribution / components|| Toolchain Bootstrap Process|| The toolchain as it bootstraps overwrites files like libc.so and libgcc.so in the sysroot directory which causes issues if you just try and rebuild part of the toolchain. Each step of the bootstrap process should use a separate sysroot. Once this is once, sstate file overwriting detection can be added and enabled. || 1|| Patches submitted for comment, slip to Sprint D || Saul / Dexuan || rpurdie|| Hygiene<br />
|-<br />
|| Documentation Features|| Package report system|| move to public server [setup a package report system in an internal machine. We need push it publicly available. The basic features like search and report have been there. But there're still some enhancements in plan, to make it a fit place to feel Yocto metadata comfortably]|| 2|| Move to Sprint E|| KevinT|| ktian1|| enhancement<br />
|-<br />
|| Distribution / components||Add headers and libraries to qemu images ||Since we'll be using qemu images as target sysroot, need to create a set of qemu images for minimal, sato, LSB that contains target header and libraries.|| 2|| Pending a discussion on Jan 18 || Saul ||jzhang|| Enhancement<br />
|-<br />
|| Distribution / components|| push of all relevant Wind River patchs to Yocto (patch comparison)|| Update any additional patches needed since M2.|| 1|| May be done by Jan 21, pending RPM stuff || Mark|| Mark|| <br />
|-<br />
|| Distribution / components|| mklibs|| mklibs is a tool to optimize size of [e]glibc for a perticular root file system image. It is useful to save disk space on small devices. || 2|| Push to Sprint E || Saul|| Nitin Kamble|| enhancement<br />
|-<br />
|| Poky Features || Performance Enhancement || reduce disk space (hardlink) || 1 || On track for Jan 21, pending RP review || Saul / Qing, Dongxiao || rpurdie || Enhancement<br />
|-<br />
|| BSP || 2.6.37 Crown Bay Support || On Track for Jan 21 || 2 || || Tom || dvhart || <br />
|-<br />
|| BSP || 2.6.37 Emenlow Support || On track for Jan 21 || 2 || || Tom || dvhart || <br />
|}<br />
<br />
=== Sprint E (closes Jan 28, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| rootless X|| rootless x server has better security than x server launched by root. MeeGo already enable this feature. it would be nice for Yocto to also enable it. || 2|| On track for Jan 28 || Saul / Ke || yuke|| enhancement<br />
|-<br />
|| Documentation Features|| Package report system|| finish major feature development and internal review [setup a package report system in an internal machine. We need push it publicly available. The basic features like search and report have been there. But there're still some enhancements in plan, to make it a fit place to feel Yocto metadata comfortably]|| 2|| Move to Sprint E || Jonathan || ktian1|| enhancement, was M2, Sprint E<br />
|-<br />
|| Distribution / components|| perl upgrade|| perl is the most cross un-friendly recipe pending upgrade. || 2|| Slipping due to Linaro layer, moves to end of Sprint E || Nitin|| Nitin Kamble|| enhancement<br />
|-<br />
|| Supported Targets|| Intel Platform Support|| Sandybridge|| 2|| Accept|| Tom|| davest|| Basic ECG support<br />
|-<br />
|| Distribution / components|| performance indicators|| define some indicators (boot time, footprint, build time, power, component benchmarks, etc.) and then collect them for tracking purpose. The result could be posted on the wiki site, and the initial indicators can be easy ones which can be easily retrieved from autobuilder or weekly qa report). This way we have a clear track about the healthy of the Yocto project, and also identify weak areas. We can include qemu targets and several representational boards as the targets. || 2|| Review|| Beth/Jiajun|| ktian1|| enhancement<br />
|-<br />
|| Tool Development and SDK Features|| SDK user workshop|| Have some developers sit down and use our tools to develop demo software for Yocto. || 2|| Review|| Jessica|| josh|| Enhancement<br />
|-<br />
|| Kernel || Final linux-yocto_git.bb || With 2.6.37 kernel || 1 || || Bruce || dvhart ||<br />
|-<br />
|| Kernel || Final meta-linaro layer || || || || Darren || dvhart ||<br />
|-<br />
|| Kernel || Final meta-rt layer || || || || Darren || dvhart ||<br />
|-<br />
|| Kernel || Sandy Bridge || || 1 || || Tom || dvhart ||<br />
|}<br />
<br />
=== Sprint F (closes Feb 03 (THURSDAY), 11:59pm PDT -- pull request sent, initially reviewed) :: NOTE: China New Year Holiday ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Documentation|| ADT Reference Guide Draft out for review || Outline complete|| High|| WIP || Scott Rifenbark|| jzhang|| Documentation<br />
|-<br />
|| || || || || || || || <br />
|}<br />
<br />
== M4 (Feb 07 to Apr 15 -- Stabilize Complete Mar 18, Release Complete Apr 01, Contingency to Apr 15) ==<br />
<br />
This sprint is the [[Yocto Project v. 1.0 Release Cycle]].<br />
<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Documentation|| Migration chapter in the Poky Reference Manual|| This chapter would cover the four identified use-cases for migrating up to the most recent version of Yocto Project. Additionally, it would cover migration scenarios from other development systems. The chapter does not yet exist. The chapter has not been scoped outside of having a meeting that identified four use-cases that did not include migration from a development system outside of Yocto Project. It will take some more scoping time to cover those areas (a day or two). Again, I have no idea of the length. See earlier entries for standard industry writing estimates for software documentation|| Medium|| Not Started|| Scott Rifenbark|| 3-4 Weeks|| Documentation<br />
|-<br />
|| Documentation|| Yocto Project Development Guide|| This manual would be an over-arching document that frames the complete development cycle within Yocto Project. The idea here is that the document would be an umbrella document that spawned and referenced subsequent documents. The organization would be the first chapter overviewing the major development pieces such as recipe creation, building, debugging, publishing, fail-safing, back-door hook creation, etc. Scoping would be about two weeks and length would probably be about 40 pages. Overall development time would likely be a month of uniterruped time.|| Medium|| Not Started|| Scott Rifenbark|| 3 Weeks|| Documentation<br />
|-<br />
|| Validation|| Boottime/Performance Analysis|| Compare Yocto Project performance to other projects such as MeeGo|| 1|| Initial report on where we are by Feb 9 || Darren|| davest|| project commitment<br />
|-<br />
|| || Multilib Support|| Consider developing post-1.0 branch || 1|| to start in M4 || Richard|| ||<br />
|-<br />
|| Validation|| Alpha testing complete|| 4-5 internal developers unfamiliar with Yocto Project try to do a build and report on the experience and issues encountered|| 1|| Done by Feb 18 || Julie|| davest|| <br />
|-<br />
|| || || || || || || || <br />
|}<br />
<br />
== Features needed and to be put into sprints by assigned owners: ==<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || package config option enhancement|| there're several enhancements we may do here: * allow users setting specific config options (local or global) from external tool, such as poky image creator, instead of changing recipes manually. Need a mechanism to convert from variable assignments into exact config options (e.g. feature_${PN} = ""1"" -> ""--enable-feature""). Consequently dependency chain needs update with option status. * host contamination check. We have swabber to check host contamination, but I'm not sure whether it covers configuration phase. If not, this is one area to improve, as not ususually we see configure script checks host bits for available features * conditional option manipulation. In many recipes we enable/disable one option based on availability of other packages. Now this is done manually and not flexible. this should be made automatically though some new annotation to indicate condition, or just base_contains (not convenient: long line, need define distro features) || 2|| Review|| Richard/MarkH|| ktian1|| Enhancement<br />
|-<br />
|| Media|| Yocto Project Awareness Video|| This 2.5 minute video would introduce and describe the benefits of Yocto Project. The video would use entertaining animations that described concepts and benefits. The result would be suitable for YouTube, conferences, and the website. The production is called an "Epipheo" and will be created by Epipheo Studios. The engagement process has begun and the kick-off meeting will be soon. The PO is in place. Time for development is 10 weeks.|| High|| Kick-off Imminent|| Scott Rifenbark|| 10 Weeks|| Media<br />
|-<br />
|| Documentation|| Yocto Project Debugging Guide|| This would be a guide for the debugging and bug tracking process in Yocto Project. Originally, the thought was that we needed a Bugzilla User's Manual. However, since we don't own Bugzilla it doesn't make sense to produce documentation for it. Rather, we should document the process as it fits into the Yocto Project environment. Ideally, the manual would be a sub-manual that would be referenced and architected into the Yocto Project Development Guide. The manual has not been scoped and would take a week to scope. Again, I have no idea of the length. See the previous item for standard industry writing estimates for software documenation.|| Medium|| Not Started|| Scott Rifenbark|| 3-4 Weeks|| Documentation<br />
|-<br />
|| Website|| Yocto Project Website|| The 0.9 website is in place but needs updates. Items for consideration are the left-panel naviagation scheme, a contributions guidance page, color-scheming and theme (possibly).|| Medium|| Not Started|| Scott Rifenbark|| 1-2 Weeks|| Website<br />
|}<br />
<br />
== Features not believed to be needed in v1.0: ==<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || OpenEmbedded/Bitbake Upstreaming|| "We firstly need to review where we are and where OE is. We then need to make a plan about what we're going to push upstream and what we're not. I'd suggest when we're in PRC, we do a crash course in ""dealing with OE"" and then many dedicate a block of time (a week) where the distro team comes up with a patch set we then propose and get merged into OE. I'd like to find a couple of interested people to monitor OE more regularly and start a workflow of things between Poky/OE where appropriate. The key thing to remember is we need to keep the architectures compatible. The team is now at the point where I'm happy for them to actually try building OpenEmbedded and not worry about it tainting them! "|| 2|| Review|| || rpurdie|| Process<br />
|-<br />
|| Poky Features || Handle old versions in WORKDIR|| an incremental build directory may finally include many old versions WORKDIRS. It'll be good to have those old versions tracked in the cache, which can then either generate a report or allow selectively cleaning up an specific version WORKDIR. Or else it's difficult to figure it out when people want to keep the whole tmp directory but like to cleanup some old bits when disk usage is under pressure. If it's not easy to do in bitbake, perhaps some separate scripts would be also helpful || 3|| Review|| || ktian1|| Enhancement<br />
|-<br />
|| Poky Features || run bitbake w/o rebuilding the cache|| "sometimes it's useful to allow run bitbake w/o re-parsing recipes, if we know nothing metadata is changed. we can just allow reusing existing persistent cache. this is useful when people is debugging WORKDIR w/o metadata change. also sometimes ""bitbake -e"" is used frequently to check poky variable information. with existing cache, several seconds can be saved which are not negligible for a developer daily working on Yocto "|| 2|| Review|| || ktian1|| Enhancement<br />
|-<br />
|| Poky Features || parallel make improvement|| parallel make experience is not good, especially when bb threads and make threads are increased larger than 8. So far we either try to fix package makefile or mark the recipe as no parallel make, when build faiures are reported. But this greatly impacts user experience for a successfully continuous build process. Could we define a safe number we do want to support for 1.0 release? and then have our autobuilder, QA test, and developers cover that number immediately and fix any issues accordingly. Then the safe number can be suggested to the Yocto user || 2|| Review|| || ktian1|| Enhancement<br />
|-<br />
|| Poky Features || Dependency packages rebuild/clean|| It is a mechanism to rebulid or clean a package and all other packages which have build/runtime dependency on it. With this change, we can find potential influences of package upgrade to its related packages, which can make the incremental build more trustable. For example, if we upgrade a package to a new vesion which changes its API, this mechanism can easily find out the incompatibility to other packages which have dependency on it. || 2|| Review|| || dongxiao.xu|| Enhancement, replaced by checksum feature<br />
|-<br />
|| Distribution / components|| FOSSology|| This may be similar to License Update above, but start to use FOSSology to track licenses. || 2|| Review|| || sgw|| Hygiene<br />
|-<br />
|| Distribution / components|| Package Developer Tools|| Create a set of Init scripts template and then review our current init scripts and modify them to confirm to the template. || 2|| Review|| || sgw|| Easy of Use<br />
|-<br />
|| Distribution / components|| Package Website|| Complete the work the intern has started on generating the distro tracking information and get it out on the external site. || 2|| Review|| || sgw|| "Hygiene, duplicate of ""Package report system"""<br />
|-<br />
|| Distribution / components|| Bluetooth UI support|| Currently we have bluez package in poky, and we need to have a workable graphic user interface to connect/configure BT devices. One choice may be gnome-bluetooth-applet. || 3|| Review|| || dongxiao.xu|| enhancement<br />
|-<br />
|| Distribution / components|| Connman-gnome enhancement features|| Enable connman-gnome to support features like, WPA Enterprise connection, hidden SSID, etc. || 3|| Review|| || dongxiao.xu|| enhancement<br />
|-<br />
|| Distribution / components|| Java Running Environment support|| Since most embedded systems support java applications running in it, maybe we'd better consider supporting some kinds of JVMs(Embeded JVM). The JVM may not run by default, but user can launch it if running java applications. Compared with GTK/QT, java user number is not small too. || 3|| Review|| || criping|| enhancement<br />
|-<br />
|| Distribution / components|| create more use cases|| UPnP demo is one really good use case showing how Yocto is utilized to make real functionality. and we could create more to show how Yocto is easily adapted to real use cases. Those use cases can be either maintained as seperate demo layers in yocto repo, or in seperate branches for reference. We can also call for community's contribution on this which would make 1.0 full-fledged. Or else the newbies to Yocto may be in puzzle how our sample profiles can satisfy their requirements. || 2|| Review|| || ktian1|| enhancement<br />
|-<br />
|| Distribution / components|| i18n support || internationalization is an important system wide feature. Many component like font, locale affect the i18n. Yocto alreay has some i18n related package like pango, but so far did not consider i18n systematically. so this is place holder to systematically add i18n support. || 2|| Review|| || yuke/qing|| enhancement<br />
|-<br />
|| Distribution / components|| more demos || demos are a good way to educate, push the envelope, and at the same time tout the strengths of the platform. This item just records a current set of ideas from various sources which could/should be implemented: * face-recognition/face-finding, * robotic control/application of face-finding to 'camera-as-sensor' (hexbug demo), * others [tbd, add here]|| 2|| Review|| || tzanussi|| enhancement <br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer support for image-creator and needed yocto-metadata design||Come up design what need to be created as packages to support using "opkg install" for image-creator and needed yocto-metadata|| 2|| WIP, pending comments from RP regarding how to packaging metadata|| Jessica|| rpurdie|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer image-creator and needed poky-metadata support|| The poky build system will build packages for image-creator and needed poky-metadata, which the Yocto Installer will be able to use "opkg install" to install them|| 2|| Review|| Jessica|| rpurdie|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Provide qemu management UI|| In current eclipse plugin, QEMU settings are put together with project configuration. So we can only have limited settings. If we can have a separate QEMU management UI, the end user could firstly create a QEMU config, such as (env file of arch, image location, unfs or not, sato or lsb, mem size, disk size). And then he can launch a QEMU with a specific config. The dependency between project configuration and QEMU config will be resolved. After all QEMU has nothing to do project configuration. Need to careful review the UI to ensure minimal impact to testing matrix. || 3|| Review|| || criping|| "Enhancement, duplicate of ""Qemu mem/disk size can be adjusted"""<br />
|-<br />
|| Tool Development and SDK Features|| QT plugin For Eclipse|| Integrate QT Ecplise plugin and extend for Yocto Project || 3|| Review|| || jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Profiling/Trace GUI's|| We have a wealth of great tracing and profiling tools but the UI's for them are all extremely minimal and usually quite ugly. Would be great if we could compete with, or even better, Apple's offerings here. We have the technology! || 2|| Review|| || josh|| "Enhancement, duplicate of ""Tracing/Profiling Planning Complete"""<br />
|-<br />
|| Tool Development and SDK Features|| Other profiling tools|| Complete Tom's review of profiling tools and architecture || 2|| Review|| || josh|| "Enhancement, duplicate of ""Tracing/Profiling Planning Complete"""<br />
|-<br />
|| Tool Development and SDK Features|| Design next-gen tracing/profiling tools|| Yocto 1.0 will include all the essential existing tracing/profiling tools expected by users, and Josh has proposed a UI integration of all those tools as far as it's possible to do so. That level of integration, basically a 'plugin-level' integration is necessary and useful, but doesn't go far enough. A next-generation tracing tool would integrate at a much more fundamental level; if done properly, it would provide unmatched levels of power and usability to users, and would allow Yocto to distinguish itself in the embedded tracing/profiling space in a way also unmatched by any other distro/build-tool. The implementation would of course not be available for Yocto 1.0, but a coherent design, including prototypes, that could be taken to the community and implemented in a V 1.5 or 2.0 should be done in that time frame. || 1|| Review|| || tzanussi|| "Enhancement, duplicate of ""Tracing/Profiling Planning Complete"""<br />
|-<br />
|| Documentation Features|| Self Documentation of image contents|| "I'd like to see the -doc packages Poky builds being combined into some kind of large documentation index representing the collective API docs of the target being built. This can then be placed on a webserver and viewed over the web. We'd have a demonstration of this for a ""bitbake world"" target. Part of the idea here is to start making good use of the docs as if developers see this they might start writing better docs too. Aim is to lead the field :). There are a number of places poky packages disable doc generation due to missing tools so we'd need to add these so we can enable the doc generation. Many packages already have many docs though too. "|| 2|| Review|| || rpurdie|| enhancement<br />
|-<br />
|| Validation|| Testing Framework|| Add a framework for doing automated testing in the project|| 1|| Review|| || davest|| project commitment<br />
|-<br />
|| Validation|| more SDK builds on autobuilder|| enable more SDK related tests on autobuilder such as meta-ide-support, etc.|| 2|| Review|| || ktian1|| project commitment, addressed by test plan (?)<br />
|-<br />
|| Validation|| more people should try using SDK|| this may not be a feature, but a requirement. SDK including meta-toolchain is one key factor impacting user experience on Yocto. It's not enough to have only SDK team play with it|| 2|| Review|| || ktian1|| project commitment, addressed by test plan (?)<br />
|-<br />
|| Validation|| Unit Testing Framework|| Add a mechanism to bitbake to parse source packages that have unit tests and then execute them on the target|| 3|| Review|| || sgw|| "project commitment, duplicate of ""Testing Framework"""<br />
|-<br />
|| Validation|| Test Case open source|| Open source Yocto test cases with xml format|| 1|| Review|| || yyou|| "project commitment, duplicate of ""Testing Framework"""<br />
|}</div>Davesthttps://wiki.yoctoproject.org/wiki/index.php?title=Yocto_1.0_Schedule&diff=587Yocto 1.0 Schedule2011-01-25T01:29:43Z<p>Davest: /* Sprint C (closes Jan 14, 11:59pm PDT -- pull request sent, initially reviewed) */</p>
<hr />
<div>= v1.0 (release date: Apr 15, 2011) =<br />
----<br />
The detailed milestone map for v1.0 is as below. During the first week of each subsequent milestone past M1 we will have a demonstration of the previous milestone capabilities as well as a planning and design session for the current milestone.<br><br><br />
<br />
== M2 (Nov 08 to Dec 24 -- Dev Complete Dec 10, Stabilize Complete Dec 17, Release Complete Dec 24) ==<br />
=== Sprint A (closes Nov 12, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links''' <br />
|-<br />
|| Poky Features || Kernel interactive targets || To support incremental kernel development having the ability to run menuconfig (or xconfig, etc) directly is a common request. We'll need to add this for commercialization anyway. i.e. bitbake -c menuconfig. This fuctionality already exists. || 1 || Done || Richard || bruceashfield || Enhancement <br />
|-<br />
|| Distribution / components || Distro Audit: Upgrades Planned (Phase 1) || Complete plan for package upgrades in M2 || 1 || Done || Saul || || Continual Maintenance<br />
|-<br />
|| Validation || Runtime testing || Runtime testing of images as part of the autobuilder || 1 || Done || Jiajun/ScottG || rpurdie || project commitment<br />
|- <br />
|| || Poky Image Creator Wireframe/Interaction Plans Complete || || 1 || Done || Josh || ||<br />
|-<br />
|| || SDK Generator Interaction: Plans Complete || || 1 || Done || Jessica || ||<br />
|-<br />
|| || Tracing/Profiling Planning Complete || This needs to cover where we're at now, what we're missing and also propose the future enhancements that may be needed. M2 targets getting existing tools integrated and documented. F2f discussion n the future enhancements || || Done || Tom || ||<br />
|-<br />
|| || Swabber. (Still needs to be integrated into weekly build by default) || || 1 || Done || Josh || ||<br />
|-<br />
|| Build/Release || Release process documentation || || || Done || Beth || ||<br />
|-<br />
|| Validation || Test plan for v1.0 (to address any deficiencies in coverage from v0.9)|| || 1 || Done || Jiajun || ||<br />
|}<br />
<br />
=== Sprint B (closes Nov 19, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| Distro Audit: World Packages|| Audit world packages making sure it all build, making sure all are packages are required || 2|| Done || Saul|| sgw|| Hygiene<br />
|-<br />
|| Tool Development and SDK Features|| SDK Generator Installer UI|| Look at different ways of Installer UI (GTK+ and ncurses) seems none of them is the right choice, decide to go with script to implement all the functionalities of installer and later add UI part on top of it || 1||Done|| Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Customize sysroot setup || Add and test out "--sysroot" config option to cross compiler within Eclipse IDE || 1|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| SDK Generator Installer design revision|| Close all open questions regarding Yocto SDK Generator Installer function design and come up HLD || 1|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Distribution / components|| kernel version|| keeping 2.6.34 as a -stable kernel is the best option. I've also got a newer -devel tree that can be made available or made the default. || 3|| Done || Bruce|| bruceashfield|| enhancement<br />
|-<br />
|| || assign Yocto Project PM|| acquire and assign a program manager for Yocto Project|| || Done || DaveST|| || <br />
|-<br />
|| || assign Yocto Project Sys Admin|| || || Done || Saul|| || <br />
|-<br />
|| Tool Development and SDK Features|| oprofileUI|| Fixing various bugs of the oprofileUI to make it workable on big endian host.(i.e. ppc, mips) || 2 || Done || Jessica || lianhao.lu || Bug #382 / Bug #493<br />
|-<br />
|| Poky Feature|| SDK Version Control|| If we can expect that yocto SDK has lots of release in the future, we might need to consider SDK version control. Currently, every thing installed under /opt/poky which leads to things be overriden, we need to be able to use a scheme like /opt/poky-1.0, /opt/poky-2.0 to distiguish things. || 2|| Done || Josh|| jzhang|| Enhancement<br />
|-<br />
|| Kernel || Kernel plan complete || Flesh our kernel deliverables and add to Yocto 1.0 schedule || || Done|| Darren || dvhart ||<br />
|}<br />
<br />
=== Sprint C (closes Nov 26, 11:59pm PDT -- pull request sent, initially reviewed) :: NOTE: this is US Thanksgiving week ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| Distro Audit: Licence Checksums|| licence checksums || 1|| Done || Saul|| rpurdie|| Hygiene<br />
|-<br />
|| Poky Features || Performance Analysis Completed|| "I'd like someone to instrument a green release build, see where it spends time (hot/cold parsing time, individual task building time) and then compare this with our 0.9 release build. I'd also like to compare the disk usage between the two. Once we have a blame list we can then set about fixing it. Some things I know will come up: a) pseudo, b) checksums/signature code, c) exec() vs fork for executing tasks, d) task based prebuilds increasing disk usage, e) rpm dependency calculations, f) using rpm vs. ipk but I may be wrong and there may be others. We need numbers. "|| 1|| Done || Saul / Qing, Dongxiao|| rpurdie|| Enhancement<br />
|-<br />
|| Poky Features || environment variables for kernel builds|| switching a branch, or adding a configuration feature (and even changing the kernel repo) is often done during development of a BSP. Having some additional variables that are pass the bitbake environment scrub would be useful. i.e. KBRANCH=foo bitbake -c configure linux-yocto. This goes along with the other BSP bootstrapping suggestions. || 2|| Done || Bruce|| bruceashfield|| Enhancement<br />
|-<br />
|| Supported Targets|| ARM Platform Support|| Replace beagleboard with Beagleboard XM - decision || 2|| Done || Bruce|| alex|| Basic Yocto hardware support <br />
|-<br />
|| Distribution / components|| Security Process|| We need a dedicated person to scan and apply critical security updates to the distro. The MeeGo team already has a similar process with some scripts which may be leveraged. To complete the task, the process should be documented and a first pass over the metadata made to establish the current position on security. Any upgrades needed should be identified and a plan to address them should be in place but doesn't have to be implemented by this point.|| 1|| Done || ScottG|| ktian1|| enhancement<br />
|-<br />
|| Tool Development and SDK Features|| SDK Generator Installer Opkg repo design|| Come up a opkg repo design that will mimic the final Yocto package repo layout to be used by SDK Generator Installer to test against|| 2 || Done || Jessica || jzhang || <br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer tar creaion|| Create a Yocto Installer tar ball which contains Installer script and supported opkg component that will be used for installing other Yocto components|| 2 || Done || Jessica || jzhang || <br />
|-<br />
|| Documentation|| Kernel Framework Paper from WR|| The paper from WR needs to be re-written and then posted somewhere on the Yocto Project site. This will involve examiniation of the text and re-writing and formatting for presentation. Currently it is simply a text document. Completion time assuming uninterrupted time is one week.|| High|| Done || Scott Rifenbark|| 1 Week|| Documentation<br />
|-<br />
|| Documentation|| Poky Reference Manual|| This guide exists in the 0.9 form. The re-write of the text needs to be completed. So far, all the chapters have been rewritten but not re-posted on the site. Only the appendices remain for a text scrub. Time to complete this would be a week of uninterrupted time. Ideally, the manual would be a sub-manual that would be referenced and architected into the Yocto Project Development Guide.|| Medium|| Done|| Scott Rifenbark|| 1 Week|| Documentation<br />
|-<br />
|| Kernel || Initial meta-linaro layer || meta-linaro layer providing a kernel, tool-chain, and uboot loader. This deliverable is primarily to get the infrastructure in place and have a buildable kernel. Toolchain on best effort basis. || || Done || Darren || dvhart || Moderate risk of slippage due to holidays.<br />
|-<br />
|| Kernel || Tracing: blktrace and sysprof recipes || || || Done || Tom || dvhart ||<br />
|}<br />
<br />
=== Sprint D (closes Dec 3, 11:59pm PDT -- pull request sent, initially reviewed) :: NOTE: week of the F2F planning meeting ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Kernel || Kernel git branching structure revamped || || 1 || Done || Bruce || dvhart ||<br />
|-<br />
|| Kernel || Tunnel Creek (Crown Bay) || || 1 || Done || Tom || dvhart ||<br />
|}<br />
<br />
=== Sprint E (closes Dec 9 (THURSDAY), 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| Distro Audit: Upgrades Completed (Phase 1)|| Update to new versions as per the agreed plan for M2 from Sprint A|| 1|| Done || Saul|| rpurdie|| Continual Maintenance<br />
|-<br />
|| Distribution / components|| Distro Audit: Src Checksums|| Make sure all SRC_URI components have checksums too || 1|| Done || Saul|| rpurdie|| Hygiene<br />
|-<br />
|| Poky Features || enable KVM with qemu|| today all new Intel processors support VT, which are enabled on most desktop machines which are most frequently used build machine. with VT support, x86/x86-64 qemu target runs faster which is a good thing for emulation environment. This may require some qemu option tweaks and also poky-qemu script enhancement. || 2|| Done || Saul / Edwin|| ktian1|| Enhancement<br />
|-<br />
|| Kernel || New kernel recipes || dev, -devel, -custom || 3 || Done || Bruce || dvhart ||<br />
|-<br />
|| Swabber || Documentation for swabber || || 1 || Done || Alex || ||<br />
|-<br />
|| CCB || Defect triage process in public documented and implemented || || 1 || Done. Triage process is documented, out for review. || Saul || ||<br />
|}<br />
<br />
== M3 (Dec 20 to Feb 08 -- Dev Complete Feb 04, Stabilize Complete Feb 11, Release Complete Feb 18) ==<br />
=== Sprint A (closes Dec 24, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Kernel || Initial meta-rt layer || PREEMPT_RT kernel and related test-cases and benchmarks || 2 || Done by Jan 21 || Darren || dvhart || slipped out from M2<br />
|-<br />
|| Poky Features || Fetcher Overhaul Phase 1 - SRC_REV enhancement||<br />
* a) Add code in FetchData::__init__() which will check if the selected fetcher supports srcrev and the automatically call a function to set the src rev value instead of each fetcher doing this.\n <br />
* e) Break SRCREVINACTION deadlock. To do this, we need to start using a keyword for automatically increasing SRCREV, e.g. SRCREV = "AUTOINC". The actual revision can be injected into PV using SRCPV. If we do this there should no longer be a need of the deadlock; <br />
* k) Ensure that we only set __BB_DONT_CACHE when SRCREV = "AUTOREV". This may need a new method call for fetchers to tell whether they're "floating" or locked down.<br />
|| 1|| Done || Saul / Ke, RP|| rpurdie|| Enhancement, slipped out from M2<br />
|-<br />
|| Distribution / components|| Distro Audit Upgrades Planned (Phase 2)|| Complete plan for package upgrades in M2|| 1|| Done || Saul|| || Continual Maintenance<br />
|-<br />
|| Poky Features || Pseudo Performance || Implement the changes to bitbake based on pseudo's enable/disable switch|| 1|| done || Saul / Qing, Dongxiao || rpurdie|| Enhancement, slipped from M2 due to risk and not having Pseudo's change yet.<br />
|-<br />
|| Tool Development and SDK Features|| Fix the issue user target sysroot is owned by root || The ADT installer will use pseudo to extract user target sysroot which ended up owned by root, this need to be fixed || 1|| done || Jessica|| jzhang|| Cleanup <br />
|-<br />
|| Tool Development and SDK Features|| Eclipse poky tree interfacing (metadata file editor)|| Provide a metadata file editor with some syntax checking and keywords highlight capabilities|| 2|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| IDE Project templates|| Templates for various project types: Clutter GUI, Gtk+ GUI, to help developers get started quickly || 2|| Done || Jessica|| josh|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| push TCF/RSE patches upstream|| work with community to finish up our TCF terminal service, TCF/RSE integration remaining patches taken by upstream. Blocking issues including Eclipse Bug #327865 || 1|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Pseudo || Pseudo enhancement to enable on/off switch || || 1 || done || Mark || ||<br />
|-<br />
|| Pseudo || Bitbake enhancement for pseudo on/off switch || || 1 || done || Richard || ||<br />
|-<br />
|| bugzilla || Complete restructure of bugzilla categories || || 1 || done || Saul || ||<br />
|-<br />
|| Poky Features || Image creator ground work || Nomenclature determined, existing gui's bug fixed and backend work implemented || 1 || Done || Joshua || ||<br />
|-<br />
|| Kernel || Tracing: Initial SystemTap recipe || Works on x86 || 3 || Done || Tom || dvhart ||<br />
|-<br />
|| Distribution / components|| Distro Audit: Package Description/Summary completed|| Ensure DESCRIPTION/SUMMARY fields are all audited|| 2|| Done || Mark|| Mark|| Hygiene, was M2, Sprint B but missed window<br />
|-<br />
|| Distribution / components|| Zypper/RPM|| Small write-up of the problems we're having w/ Zypper and what we plan to do. (i.e. create a roadmap/design) - Includes rootfs generation - Package uprev/install/removal || 1 || Done || Mark/Qing || || was M2, Sprint B<br />
|-<br />
|| Distribution / components|| Distro Audit: Licence Checksums|| Make the licence checksums fatal if not present || 1|| Done || Saul|| rpurdie|| Hygiene, was M2, Sprint C<br />
|-<br />
|| Distribution / components|| push of all relevant Wind River patchs to Yocto (patch comparison)|| Ensure patches present to packages in WRS are also in Poky|| 1|| Done || Mark|| Mark|| was M2, Sprint C<br />
|-<br />
|| Poky Features || Performance Enhancement Completed || Initial changes to reduce disk space (sstate-build-*) || 1|| Done || Saul / Qing, Dongxiao || rpurdie|| Enhancement, was M2, Sprint E<br />
|-<br />
|| Distribution / components|| User specified qemu config support|| We'll provide user an edit box which allows advanced qemu user to specify arbitrary qemu configuration to meet their needs, which the poky-qemu scrip will just append the config list towards the end of the list of parameters to bring up qemu, it also expect the poky-qemu script to do some basic sanity check on the user specifications to catch the obvious mistake || 2|| Done || Saul / criping || criping|| enhancement, was M2, Sprint E<br />
|-<br />
|| Tool Development and SDK Features|| SDK Version Control support in SDK generator installer|| If we can expect that yocto SDK has lots of release in the future, we might need to consider SDK version control. Currently, if we un-tar the sdk, it will override the older version. It's not good for app developers since they might need the old version to do something. And also, maybe a finer installer than untar is preferred. Installer will tied to certain SDK version and the installation will go under /opt/poky-versionNo.|| 1|| Done || Jessica|| criping|| Enhancement-expect planning process by Jessica to handle this task. Was M2, Sprint E.<br />
|}<br />
<br />
=== Sprint B (closes Jan 07, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || Bitbake multi-threaded parsing|| Bitbake recipe parsing is currently single threaded. I want to make this multithreaded as the speedup would be nice. If I can only take a single task for myself for 1.0, I'm nominating this one as I enjoy this kind of thing and I have ideas on how to do it. || 1|| Done || Richard|| rpurdie|| Enhancement<br />
|-<br />
|| Distribution / components|| Lock in Kernel/Toolchain version|| Locked in 2.6.37 and gcc 4.5.1. Pending decision to move to 4.5.2 and Linaro || || Done || || Richard|| || <br />
|-<br />
|| Distribution / components|| License Update|| For each of the licences we support, I'd really like to have a licences directory with a copy of that license contained within. When it comes to deciding what a given LICENSE field means, this would be the reference. It also means we can include the licences a given image includes with the image. This continues to make our license handling world class and ahead of the field. || 2|| Done || Beth|| rpurdie|| Hygiene<br />
|-<br />
|| Tool Development and SDK Features|| Qemu configuration change|| Provice edit box for advanced user to specify qemu configurations|| 2|| Done || Jessica|| criping|| <br />
|-<br />
|| Tool Development and SDK Features|| Lock down Eclipse+CDT+TCF version|| Will use Eclipse Halo 3.6 || 1|| Done || Jessica|| || <br />
|-<br />
|| Demo|| Finalize on demo plans for v1.0 launch || || 1|| Done || Dave || || <br />
|-<br />
|| Release || Release plans for v1.0 launch || Fill out the M4 plan with the necessary release activities and timings || 1|| Done || Beth || || <br />
|-<br />
|| Poky Features || Basic image creator GUI || Functional UI missing some Advanced features || 1 || In replan || Joshua || || <br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer for SDK Generator Installation functions support||Detailed feature request can be found at: http://bugzilla.pokylinux.org/show_bug.cgi?id=589|| 1|| Done || Jessica|| rpurdie|| Enhancement<br />
|-<br />
|| Kernel || Tracing: trace-cmd python binding cleanup || || 3 || Done || Darren || dvhart ||<br />
|}<br />
<br />
=== Sprint C (closes Jan 14, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || kernel development layer|| The (correct) poky behaviour of building known revisions coupled with the fetcher requiring a BSP branch to already be present means that local modifications (and kernel source tree) are required for kernel development. I already have a layer that overrides/modifies the behaviour when added to the bblayers.conf and configured into an environment. This seems useful for more people to use. || 2|| Done || Bruce|| bruceashfield|| Enhancement, was M2, Sprint C<br />
|-<br />
|| Distribution / components|| Zypper/RPM|| RPM Uprev / Zypper Uprev [lets get to the latest versions]|| 1|| pull request by Jan 19; || Mark/Qing|| || was M2, Sprint C<br />
|-<br />
|| Supported Targets|| Intel Platform Support|| JasperForest|| 2|| Basic support in place; DPDK evaluation in process, overall BSP plan still TBD || Tom|| davest|| Basic ECG support (Moved from Sprint A)<br />
|-<br />
|| Tool Development and SDK Features|| Eclipse poky tree interfacing (git support)|| Use Eclipse git capability to install poky tree from git repo and able to interact with git repo at file level within Poky tree || 2|| Done || Jessica|| jzhang|| Enhancement<br />
<br />
|-<br />
|| Poky Features || Poky Image Creator|| A standalone application you can run which asks you to select a distro and machine, then presents a list of packages you can select. Once the selection is made, it goes off and bakes you an image which is then presented to you. Implementation wise, it should use the sstate packages, be a bitbake UI and use the usual poky bbclass files to do the image construction behind the scenes. || 1|| Re-plan || Joshua|| rpurdie|| Enhancement<br />
|-<br />
|| Distribution / components|| LSB Sanity|| execute LSB Test and improve passing rate and document failures with clear understanding|| 2|| Done || MarkH/Saul|| sgw|| Hygiene<br />
|-<br />
|| Distribution / components|| Review & Fix Standards Tests|| Review the results from LTP, POSIX and asses the result, fix as appropriate and clearly document failures.|| 2|| a Plan to resolve final items to be sent to the m.l. by Jan 14 || Saul/Kevin || sgw|| Hygiene<br />
|-<br />
|| Tool Development and SDK Features|| Image creator integration with Eclipse || || 2|| replan|| Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Kernel || Tracing: perf trace marker support || This is from feedback to the new trace command. Ingo appears to have this nearly complete already. || 3 || Done || Darren || dvhart ||<br />
|-<br />
|| Kernel || Tracing: perf trace scripting support || || 3 || Move to Sprint D; on track for Jan 21 || Tom || dvhart ||<br />
|-<br />
|| Cleanup || bitbake user experience error handling validation completed || || 2 || Done || Richard || ||<br />
|-<br />
|| Cleanup || variable scrub - ensure all metadata variables are documented || Script with a histogram of variable use done, identified 50 variables to document; Add task for actual documentation update is low on the list || 2 || Done || Scott/Darren || ||<br />
|-<br />
|| Distribution / components|| Zypper/RPM|| Integration based on design from Sprint B|| 1|| On track for Jan28 || Mark/Qing|| sgw|| Functionality, was M2, Sprint E<br />
|-<br />
|| Kernel || Tracing: package kernelshark || || 3 || Done || Darren || dvhart ||<br />
|-<br />
|| Kernel || Tracing: tuna, oscillosope recipes || || 3 || Tom to discuss plan with Darren et al || Tom || dvhart ||<br />
|- <br />
|| BSP || Beagleboard XM Support || || 3 || Move to Sprint D || Darren || dvhart ||<br />
|}<br />
<br />
=== Sprint D (closes Jan 21, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Swabber || Complete review of swabber outputs || Move to M3 Sprint D || 1 || Move to M3 Sprint D || Alex || ||<br />
|-<br />
|| Poky Features || Fetcher Overhaul Phase 2 - API reorg||<br />
* f) Add a generic unpack funciton to __init__.py based on the unpack task in Poky ;<br />
* g) Split go() methods into the following steps: i) download() - do whatever transfer is necessary to get the sources locally ii) build_mirror_data() - generate any data that would be needed to construct a source mirror iii) unpack() - takes a directory as an argument of where to place extracted sources;<br />
The existing go() methods should be replaced with a set of calls to the above sections of functionality as appropriate in the individual fetchers. Some of these categories of function make no sense in certain fetchers, in which case they shouldn't need to implement them. Functions are only executed if the method is present.<br />
* h) Change Poky's unpack to call an unpack method in the fetchers.<br />
* i) Change Poky's fetch task to call a "download" method in the fetcher instead of go().<br />
|| 1|| Will land with phase 3 in Jan 21 || Saul / Ke, RP|| rpurdie|| Enhancement<br />
|-<br />
|| Poky Features || Fetcher Overhaul Phase 3 - git enhancement||<br />
* j) Optimize git fetcher for the new layout so for a git checkout, we clone the repository in download(), then unpack just does a clone with references to the original repo. <br />
* k) Ensure that we only set __BB_DONT_CACHE when SRCREV = "AUTOREV". This may need a new method call for fetchers to tell whether they're "floating" or locked down. <br />
* l) Add a new "BB_NO_NETWORK" variable which the fetchers check before peforming an operation which hits anything remote. This means adding in error messages about why network access is needed at various points (e.g. SRCREV = "AUTOREV" for a given recipe) <br />
* m) Add multiple branch/srcrev support for git fetcher. These would be of the form: git://somelocation/somerepo.git;name=ref1;branch=foo;name=ref2;branch=bar SRCREV_ref1 = "hash1" SRCREV_ref2 = "hash2" which would ensure both hash1 and hash2 were in the final repo. <br />
* n) Change git fetcher to default to git protocol instead of rsync<br />
|| 1|| Slipped to Sprint D || Saul / Ke, RP|| rpurdie|| Enhancement<br />
|-<br />
|| Poky Features || DSO linking changes|| "By the default the gcc linker will automatically link any dependant objects/libraries. ""Inherited"" linkages can cause issues, for example, where a shared object changes its dependencies but a program has come to rely on symbols from an implicitly linked library. Fedora implemented this change in F13, seems like it would be useful to have in Poky too. "|| 2|| On track for Jan 21 || Saul / Nitin || josh|| bug#516<br />
|-<br />
|| Distribution / components|| Distro Audit Documentation Output|| Audit package documentation output || 2|| Move to Sprint D due to libtool work || Saul / ScottG || rpurdie|| Hygiene<br />
|-<br />
|| Poky Features || libtool sysroot option|| libtool 2.4 has a sysroot option. We should try and use it, see how it works and whether we can ditch some of our libtool hacks. || 1|| On track for Jan 21 || Saul / ScottG || rpurdie|| Enhancement<br />
|-<br />
|| Distribution / components|| MACHINE or Recipe specific sysroots|| Each machine should have its own sysroot. We'll probably have to split do_populate_sysroot into a two step process, creation of the package and than installtion of the package, which the installation of the package being made machine specific (put ${MACHINE} into ${STAMP} and bitbake should do that). Also allowing this to work per recipe would be desireable|| 1|| On track 21 || Saul / Dongxiao || rpurdie|| Hygiene<br />
|-<br />
|| Distribution / components|| Toolchain Bootstrap Process|| The toolchain as it bootstraps overwrites files like libc.so and libgcc.so in the sysroot directory which causes issues if you just try and rebuild part of the toolchain. Each step of the bootstrap process should use a separate sysroot. Once this is once, sstate file overwriting detection can be added and enabled. || 1|| Patches submitted for comment, slip to Sprint D || Saul / Dexuan || rpurdie|| Hygiene<br />
|-<br />
|| Documentation Features|| Package report system|| move to public server [setup a package report system in an internal machine. We need push it publicly available. The basic features like search and report have been there. But there're still some enhancements in plan, to make it a fit place to feel Yocto metadata comfortably]|| 2|| Move to Sprint E|| KevinT|| ktian1|| enhancement<br />
|-<br />
|| Distribution / components||Add headers and libraries to qemu images ||Since we'll be using qemu images as target sysroot, need to create a set of qemu images for minimal, sato, LSB that contains target header and libraries.|| 2|| Pending a discussion on Jan 18 || Saul ||jzhang|| Enhancement<br />
|-<br />
|| Distribution / components|| push of all relevant Wind River patchs to Yocto (patch comparison)|| Update any additional patches needed since M2.|| 1|| May be done by Jan 21, pending RPM stuff || Mark|| Mark|| <br />
|-<br />
|| Distribution / components|| mklibs|| mklibs is a tool to optimize size of [e]glibc for a perticular root file system image. It is useful to save disk space on small devices. || 2|| Push to Sprint E || Saul|| Nitin Kamble|| enhancement<br />
|-<br />
|| Poky Features || Performance Enhancement || reduce disk space (hardlink) || 1 || On track for Jan 21, pending RP review || Saul / Qing, Dongxiao || rpurdie || Enhancement<br />
|-<br />
|| BSP || 2.6.37 Crown Bay Support || On Track for Jan 21 || 2 || || Tom || dvhart || <br />
|-<br />
|| BSP || 2.6.37 Emenlow Support || On track for Jan 21 || 2 || || Tom || dvhart || <br />
|}<br />
<br />
=== Sprint E (closes Jan 28, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| rootless X|| rootless x server has better security than x server launched by root. MeeGo already enable this feature. it would be nice for Yocto to also enable it. || 2|| On track for Jan 28 || Saul / Ke || yuke|| enhancement<br />
|-<br />
|| Documentation Features|| Package report system|| finish major feature development and internal review [setup a package report system in an internal machine. We need push it publicly available. The basic features like search and report have been there. But there're still some enhancements in plan, to make it a fit place to feel Yocto metadata comfortably]|| 2|| Move to Sprint E || Jonathan || ktian1|| enhancement, was M2, Sprint E<br />
|-<br />
|| Distribution / components|| perl upgrade|| perl is the most cross un-friendly recipe pending upgrade. || 2|| Slipping due to Linaro layer, moves to end of Sprint E || Nitin|| Nitin Kamble|| enhancement<br />
|-<br />
|| Supported Targets|| Intel Platform Support|| Sandybridge|| 2|| Accept|| Tom|| davest|| Basic ECG support<br />
|-<br />
|| Distribution / components|| performance indicators|| define some indicators (boot time, footprint, build time, power, component benchmarks, etc.) and then collect them for tracking purpose. The result could be posted on the wiki site, and the initial indicators can be easy ones which can be easily retrieved from autobuilder or weekly qa report). This way we have a clear track about the healthy of the Yocto project, and also identify weak areas. We can include qemu targets and several representational boards as the targets. || 2|| Review|| Beth/Jiajun|| ktian1|| enhancement<br />
|-<br />
|| Tool Development and SDK Features|| SDK user workshop|| Have some developers sit down and use our tools to develop demo software for Yocto. || 2|| Review|| Jessica|| josh|| Enhancement<br />
|-<br />
|| Kernel || Final linux-yocto_git.bb || With 2.6.37 kernel || 1 || || Bruce || dvhart ||<br />
|-<br />
|| Kernel || Final meta-linaro layer || || || || Darren || dvhart ||<br />
|-<br />
|| Kernel || Final meta-rt layer || || || || Darren || dvhart ||<br />
|-<br />
|| Kernel || Sandy Bridge || || 1 || || Tom || dvhart ||<br />
|}<br />
<br />
=== Sprint F (closes Feb 03 (THURSDAY), 11:59pm PDT -- pull request sent, initially reviewed) :: NOTE: China New Year Holiday ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Documentation|| ADT Reference Guide Draft out for review || Outline complete|| High|| WIP || Scott Rifenbark|| jzhang|| Documentation<br />
|-<br />
|| || || || || || || || <br />
|}<br />
<br />
== M4 (Feb 07 to Apr 15 -- Stabilize Complete Mar 18, Release Complete Apr 01, Contingency to Apr 15) ==<br />
<br />
This sprint is the [[Yocto Project v. 1.0 Release Cycle]].<br />
<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Documentation|| Migration chapter in the Poky Reference Manual|| This chapter would cover the four identified use-cases for migrating up to the most recent version of Yocto Project. Additionally, it would cover migration scenarios from other development systems. The chapter does not yet exist. The chapter has not been scoped outside of having a meeting that identified four use-cases that did not include migration from a development system outside of Yocto Project. It will take some more scoping time to cover those areas (a day or two). Again, I have no idea of the length. See earlier entries for standard industry writing estimates for software documentation|| Medium|| Not Started|| Scott Rifenbark|| 3-4 Weeks|| Documentation<br />
|-<br />
|| Documentation|| Yocto Project Development Guide|| This manual would be an over-arching document that frames the complete development cycle within Yocto Project. The idea here is that the document would be an umbrella document that spawned and referenced subsequent documents. The organization would be the first chapter overviewing the major development pieces such as recipe creation, building, debugging, publishing, fail-safing, back-door hook creation, etc. Scoping would be about two weeks and length would probably be about 40 pages. Overall development time would likely be a month of uniterruped time.|| Medium|| Not Started|| Scott Rifenbark|| 3 Weeks|| Documentation<br />
|-<br />
|| || Multilib Support|| Consider developing post-1.0 branch || 1|| to start in M4 || Richard|| ||<br />
|-<br />
|| Validation|| Alpha testing complete|| 4-5 internal developers unfamiliar with Yocto Project try to do a build and report on the experience and issues encountered|| 1|| Done by Feb 18 || Julie|| davest|| <br />
|-<br />
|| || || || || || || || <br />
|}<br />
<br />
== Features needed and to be put into sprints by assigned owners: ==<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || package config option enhancement|| there're several enhancements we may do here: * allow users setting specific config options (local or global) from external tool, such as poky image creator, instead of changing recipes manually. Need a mechanism to convert from variable assignments into exact config options (e.g. feature_${PN} = ""1"" -> ""--enable-feature""). Consequently dependency chain needs update with option status. * host contamination check. We have swabber to check host contamination, but I'm not sure whether it covers configuration phase. If not, this is one area to improve, as not ususually we see configure script checks host bits for available features * conditional option manipulation. In many recipes we enable/disable one option based on availability of other packages. Now this is done manually and not flexible. this should be made automatically though some new annotation to indicate condition, or just base_contains (not convenient: long line, need define distro features) || 2|| Review|| Richard/MarkH|| ktian1|| Enhancement<br />
|-<br />
|| Media|| Yocto Project Awareness Video|| This 2.5 minute video would introduce and describe the benefits of Yocto Project. The video would use entertaining animations that described concepts and benefits. The result would be suitable for YouTube, conferences, and the website. The production is called an "Epipheo" and will be created by Epipheo Studios. The engagement process has begun and the kick-off meeting will be soon. The PO is in place. Time for development is 10 weeks.|| High|| Kick-off Imminent|| Scott Rifenbark|| 10 Weeks|| Media<br />
|-<br />
|| Documentation|| Yocto Project Debugging Guide|| This would be a guide for the debugging and bug tracking process in Yocto Project. Originally, the thought was that we needed a Bugzilla User's Manual. However, since we don't own Bugzilla it doesn't make sense to produce documentation for it. Rather, we should document the process as it fits into the Yocto Project environment. Ideally, the manual would be a sub-manual that would be referenced and architected into the Yocto Project Development Guide. The manual has not been scoped and would take a week to scope. Again, I have no idea of the length. See the previous item for standard industry writing estimates for software documenation.|| Medium|| Not Started|| Scott Rifenbark|| 3-4 Weeks|| Documentation<br />
|-<br />
|| Website|| Yocto Project Website|| The 0.9 website is in place but needs updates. Items for consideration are the left-panel naviagation scheme, a contributions guidance page, color-scheming and theme (possibly).|| Medium|| Not Started|| Scott Rifenbark|| 1-2 Weeks|| Website<br />
|}<br />
<br />
== Features not believed to be needed in v1.0: ==<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || OpenEmbedded/Bitbake Upstreaming|| "We firstly need to review where we are and where OE is. We then need to make a plan about what we're going to push upstream and what we're not. I'd suggest when we're in PRC, we do a crash course in ""dealing with OE"" and then many dedicate a block of time (a week) where the distro team comes up with a patch set we then propose and get merged into OE. I'd like to find a couple of interested people to monitor OE more regularly and start a workflow of things between Poky/OE where appropriate. The key thing to remember is we need to keep the architectures compatible. The team is now at the point where I'm happy for them to actually try building OpenEmbedded and not worry about it tainting them! "|| 2|| Review|| || rpurdie|| Process<br />
|-<br />
|| Poky Features || Handle old versions in WORKDIR|| an incremental build directory may finally include many old versions WORKDIRS. It'll be good to have those old versions tracked in the cache, which can then either generate a report or allow selectively cleaning up an specific version WORKDIR. Or else it's difficult to figure it out when people want to keep the whole tmp directory but like to cleanup some old bits when disk usage is under pressure. If it's not easy to do in bitbake, perhaps some separate scripts would be also helpful || 3|| Review|| || ktian1|| Enhancement<br />
|-<br />
|| Poky Features || run bitbake w/o rebuilding the cache|| "sometimes it's useful to allow run bitbake w/o re-parsing recipes, if we know nothing metadata is changed. we can just allow reusing existing persistent cache. this is useful when people is debugging WORKDIR w/o metadata change. also sometimes ""bitbake -e"" is used frequently to check poky variable information. with existing cache, several seconds can be saved which are not negligible for a developer daily working on Yocto "|| 2|| Review|| || ktian1|| Enhancement<br />
|-<br />
|| Poky Features || parallel make improvement|| parallel make experience is not good, especially when bb threads and make threads are increased larger than 8. So far we either try to fix package makefile or mark the recipe as no parallel make, when build faiures are reported. But this greatly impacts user experience for a successfully continuous build process. Could we define a safe number we do want to support for 1.0 release? and then have our autobuilder, QA test, and developers cover that number immediately and fix any issues accordingly. Then the safe number can be suggested to the Yocto user || 2|| Review|| || ktian1|| Enhancement<br />
|-<br />
|| Poky Features || Dependency packages rebuild/clean|| It is a mechanism to rebulid or clean a package and all other packages which have build/runtime dependency on it. With this change, we can find potential influences of package upgrade to its related packages, which can make the incremental build more trustable. For example, if we upgrade a package to a new vesion which changes its API, this mechanism can easily find out the incompatibility to other packages which have dependency on it. || 2|| Review|| || dongxiao.xu|| Enhancement, replaced by checksum feature<br />
|-<br />
|| Distribution / components|| FOSSology|| This may be similar to License Update above, but start to use FOSSology to track licenses. || 2|| Review|| || sgw|| Hygiene<br />
|-<br />
|| Distribution / components|| Package Developer Tools|| Create a set of Init scripts template and then review our current init scripts and modify them to confirm to the template. || 2|| Review|| || sgw|| Easy of Use<br />
|-<br />
|| Distribution / components|| Package Website|| Complete the work the intern has started on generating the distro tracking information and get it out on the external site. || 2|| Review|| || sgw|| "Hygiene, duplicate of ""Package report system"""<br />
|-<br />
|| Distribution / components|| Bluetooth UI support|| Currently we have bluez package in poky, and we need to have a workable graphic user interface to connect/configure BT devices. One choice may be gnome-bluetooth-applet. || 3|| Review|| || dongxiao.xu|| enhancement<br />
|-<br />
|| Distribution / components|| Connman-gnome enhancement features|| Enable connman-gnome to support features like, WPA Enterprise connection, hidden SSID, etc. || 3|| Review|| || dongxiao.xu|| enhancement<br />
|-<br />
|| Distribution / components|| Java Running Environment support|| Since most embedded systems support java applications running in it, maybe we'd better consider supporting some kinds of JVMs(Embeded JVM). The JVM may not run by default, but user can launch it if running java applications. Compared with GTK/QT, java user number is not small too. || 3|| Review|| || criping|| enhancement<br />
|-<br />
|| Distribution / components|| create more use cases|| UPnP demo is one really good use case showing how Yocto is utilized to make real functionality. and we could create more to show how Yocto is easily adapted to real use cases. Those use cases can be either maintained as seperate demo layers in yocto repo, or in seperate branches for reference. We can also call for community's contribution on this which would make 1.0 full-fledged. Or else the newbies to Yocto may be in puzzle how our sample profiles can satisfy their requirements. || 2|| Review|| || ktian1|| enhancement<br />
|-<br />
|| Distribution / components|| i18n support || internationalization is an important system wide feature. Many component like font, locale affect the i18n. Yocto alreay has some i18n related package like pango, but so far did not consider i18n systematically. so this is place holder to systematically add i18n support. || 2|| Review|| || yuke/qing|| enhancement<br />
|-<br />
|| Distribution / components|| more demos || demos are a good way to educate, push the envelope, and at the same time tout the strengths of the platform. This item just records a current set of ideas from various sources which could/should be implemented: * face-recognition/face-finding, * robotic control/application of face-finding to 'camera-as-sensor' (hexbug demo), * others [tbd, add here]|| 2|| Review|| || tzanussi|| enhancement <br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer support for image-creator and needed yocto-metadata design||Come up design what need to be created as packages to support using "opkg install" for image-creator and needed yocto-metadata|| 2|| WIP, pending comments from RP regarding how to packaging metadata|| Jessica|| rpurdie|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer image-creator and needed poky-metadata support|| The poky build system will build packages for image-creator and needed poky-metadata, which the Yocto Installer will be able to use "opkg install" to install them|| 2|| Review|| Jessica|| rpurdie|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Provide qemu management UI|| In current eclipse plugin, QEMU settings are put together with project configuration. So we can only have limited settings. If we can have a separate QEMU management UI, the end user could firstly create a QEMU config, such as (env file of arch, image location, unfs or not, sato or lsb, mem size, disk size). And then he can launch a QEMU with a specific config. The dependency between project configuration and QEMU config will be resolved. After all QEMU has nothing to do project configuration. Need to careful review the UI to ensure minimal impact to testing matrix. || 3|| Review|| || criping|| "Enhancement, duplicate of ""Qemu mem/disk size can be adjusted"""<br />
|-<br />
|| Tool Development and SDK Features|| QT plugin For Eclipse|| Integrate QT Ecplise plugin and extend for Yocto Project || 3|| Review|| || jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Profiling/Trace GUI's|| We have a wealth of great tracing and profiling tools but the UI's for them are all extremely minimal and usually quite ugly. Would be great if we could compete with, or even better, Apple's offerings here. We have the technology! || 2|| Review|| || josh|| "Enhancement, duplicate of ""Tracing/Profiling Planning Complete"""<br />
|-<br />
|| Tool Development and SDK Features|| Other profiling tools|| Complete Tom's review of profiling tools and architecture || 2|| Review|| || josh|| "Enhancement, duplicate of ""Tracing/Profiling Planning Complete"""<br />
|-<br />
|| Tool Development and SDK Features|| Design next-gen tracing/profiling tools|| Yocto 1.0 will include all the essential existing tracing/profiling tools expected by users, and Josh has proposed a UI integration of all those tools as far as it's possible to do so. That level of integration, basically a 'plugin-level' integration is necessary and useful, but doesn't go far enough. A next-generation tracing tool would integrate at a much more fundamental level; if done properly, it would provide unmatched levels of power and usability to users, and would allow Yocto to distinguish itself in the embedded tracing/profiling space in a way also unmatched by any other distro/build-tool. The implementation would of course not be available for Yocto 1.0, but a coherent design, including prototypes, that could be taken to the community and implemented in a V 1.5 or 2.0 should be done in that time frame. || 1|| Review|| || tzanussi|| "Enhancement, duplicate of ""Tracing/Profiling Planning Complete"""<br />
|-<br />
|| Documentation Features|| Self Documentation of image contents|| "I'd like to see the -doc packages Poky builds being combined into some kind of large documentation index representing the collective API docs of the target being built. This can then be placed on a webserver and viewed over the web. We'd have a demonstration of this for a ""bitbake world"" target. Part of the idea here is to start making good use of the docs as if developers see this they might start writing better docs too. Aim is to lead the field :). There are a number of places poky packages disable doc generation due to missing tools so we'd need to add these so we can enable the doc generation. Many packages already have many docs though too. "|| 2|| Review|| || rpurdie|| enhancement<br />
|-<br />
|| Validation|| Testing Framework|| Add a framework for doing automated testing in the project|| 1|| Review|| || davest|| project commitment<br />
|-<br />
|| Validation|| more SDK builds on autobuilder|| enable more SDK related tests on autobuilder such as meta-ide-support, etc.|| 2|| Review|| || ktian1|| project commitment, addressed by test plan (?)<br />
|-<br />
|| Validation|| more people should try using SDK|| this may not be a feature, but a requirement. SDK including meta-toolchain is one key factor impacting user experience on Yocto. It's not enough to have only SDK team play with it|| 2|| Review|| || ktian1|| project commitment, addressed by test plan (?)<br />
|-<br />
|| Validation|| Unit Testing Framework|| Add a mechanism to bitbake to parse source packages that have unit tests and then execute them on the target|| 3|| Review|| || sgw|| "project commitment, duplicate of ""Testing Framework"""<br />
|-<br />
|| Validation|| Test Case open source|| Open source Yocto test cases with xml format|| 1|| Review|| || yyou|| "project commitment, duplicate of ""Testing Framework"""<br />
|}</div>Davesthttps://wiki.yoctoproject.org/wiki/index.php?title=Yocto_1.0_Schedule&diff=586Yocto 1.0 Schedule2011-01-25T01:28:54Z<p>Davest: /* Sprint D (closes Jan 21, 11:59pm PDT -- pull request sent, initially reviewed) */</p>
<hr />
<div>= v1.0 (release date: Apr 15, 2011) =<br />
----<br />
The detailed milestone map for v1.0 is as below. During the first week of each subsequent milestone past M1 we will have a demonstration of the previous milestone capabilities as well as a planning and design session for the current milestone.<br><br><br />
<br />
== M2 (Nov 08 to Dec 24 -- Dev Complete Dec 10, Stabilize Complete Dec 17, Release Complete Dec 24) ==<br />
=== Sprint A (closes Nov 12, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links''' <br />
|-<br />
|| Poky Features || Kernel interactive targets || To support incremental kernel development having the ability to run menuconfig (or xconfig, etc) directly is a common request. We'll need to add this for commercialization anyway. i.e. bitbake -c menuconfig. This fuctionality already exists. || 1 || Done || Richard || bruceashfield || Enhancement <br />
|-<br />
|| Distribution / components || Distro Audit: Upgrades Planned (Phase 1) || Complete plan for package upgrades in M2 || 1 || Done || Saul || || Continual Maintenance<br />
|-<br />
|| Validation || Runtime testing || Runtime testing of images as part of the autobuilder || 1 || Done || Jiajun/ScottG || rpurdie || project commitment<br />
|- <br />
|| || Poky Image Creator Wireframe/Interaction Plans Complete || || 1 || Done || Josh || ||<br />
|-<br />
|| || SDK Generator Interaction: Plans Complete || || 1 || Done || Jessica || ||<br />
|-<br />
|| || Tracing/Profiling Planning Complete || This needs to cover where we're at now, what we're missing and also propose the future enhancements that may be needed. M2 targets getting existing tools integrated and documented. F2f discussion n the future enhancements || || Done || Tom || ||<br />
|-<br />
|| || Swabber. (Still needs to be integrated into weekly build by default) || || 1 || Done || Josh || ||<br />
|-<br />
|| Build/Release || Release process documentation || || || Done || Beth || ||<br />
|-<br />
|| Validation || Test plan for v1.0 (to address any deficiencies in coverage from v0.9)|| || 1 || Done || Jiajun || ||<br />
|}<br />
<br />
=== Sprint B (closes Nov 19, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| Distro Audit: World Packages|| Audit world packages making sure it all build, making sure all are packages are required || 2|| Done || Saul|| sgw|| Hygiene<br />
|-<br />
|| Tool Development and SDK Features|| SDK Generator Installer UI|| Look at different ways of Installer UI (GTK+ and ncurses) seems none of them is the right choice, decide to go with script to implement all the functionalities of installer and later add UI part on top of it || 1||Done|| Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Customize sysroot setup || Add and test out "--sysroot" config option to cross compiler within Eclipse IDE || 1|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| SDK Generator Installer design revision|| Close all open questions regarding Yocto SDK Generator Installer function design and come up HLD || 1|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Distribution / components|| kernel version|| keeping 2.6.34 as a -stable kernel is the best option. I've also got a newer -devel tree that can be made available or made the default. || 3|| Done || Bruce|| bruceashfield|| enhancement<br />
|-<br />
|| || assign Yocto Project PM|| acquire and assign a program manager for Yocto Project|| || Done || DaveST|| || <br />
|-<br />
|| || assign Yocto Project Sys Admin|| || || Done || Saul|| || <br />
|-<br />
|| Tool Development and SDK Features|| oprofileUI|| Fixing various bugs of the oprofileUI to make it workable on big endian host.(i.e. ppc, mips) || 2 || Done || Jessica || lianhao.lu || Bug #382 / Bug #493<br />
|-<br />
|| Poky Feature|| SDK Version Control|| If we can expect that yocto SDK has lots of release in the future, we might need to consider SDK version control. Currently, every thing installed under /opt/poky which leads to things be overriden, we need to be able to use a scheme like /opt/poky-1.0, /opt/poky-2.0 to distiguish things. || 2|| Done || Josh|| jzhang|| Enhancement<br />
|-<br />
|| Kernel || Kernel plan complete || Flesh our kernel deliverables and add to Yocto 1.0 schedule || || Done|| Darren || dvhart ||<br />
|}<br />
<br />
=== Sprint C (closes Nov 26, 11:59pm PDT -- pull request sent, initially reviewed) :: NOTE: this is US Thanksgiving week ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| Distro Audit: Licence Checksums|| licence checksums || 1|| Done || Saul|| rpurdie|| Hygiene<br />
|-<br />
|| Poky Features || Performance Analysis Completed|| "I'd like someone to instrument a green release build, see where it spends time (hot/cold parsing time, individual task building time) and then compare this with our 0.9 release build. I'd also like to compare the disk usage between the two. Once we have a blame list we can then set about fixing it. Some things I know will come up: a) pseudo, b) checksums/signature code, c) exec() vs fork for executing tasks, d) task based prebuilds increasing disk usage, e) rpm dependency calculations, f) using rpm vs. ipk but I may be wrong and there may be others. We need numbers. "|| 1|| Done || Saul / Qing, Dongxiao|| rpurdie|| Enhancement<br />
|-<br />
|| Poky Features || environment variables for kernel builds|| switching a branch, or adding a configuration feature (and even changing the kernel repo) is often done during development of a BSP. Having some additional variables that are pass the bitbake environment scrub would be useful. i.e. KBRANCH=foo bitbake -c configure linux-yocto. This goes along with the other BSP bootstrapping suggestions. || 2|| Done || Bruce|| bruceashfield|| Enhancement<br />
|-<br />
|| Supported Targets|| ARM Platform Support|| Replace beagleboard with Beagleboard XM - decision || 2|| Done || Bruce|| alex|| Basic Yocto hardware support <br />
|-<br />
|| Distribution / components|| Security Process|| We need a dedicated person to scan and apply critical security updates to the distro. The MeeGo team already has a similar process with some scripts which may be leveraged. To complete the task, the process should be documented and a first pass over the metadata made to establish the current position on security. Any upgrades needed should be identified and a plan to address them should be in place but doesn't have to be implemented by this point.|| 1|| Done || ScottG|| ktian1|| enhancement<br />
|-<br />
|| Tool Development and SDK Features|| SDK Generator Installer Opkg repo design|| Come up a opkg repo design that will mimic the final Yocto package repo layout to be used by SDK Generator Installer to test against|| 2 || Done || Jessica || jzhang || <br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer tar creaion|| Create a Yocto Installer tar ball which contains Installer script and supported opkg component that will be used for installing other Yocto components|| 2 || Done || Jessica || jzhang || <br />
|-<br />
|| Documentation|| Kernel Framework Paper from WR|| The paper from WR needs to be re-written and then posted somewhere on the Yocto Project site. This will involve examiniation of the text and re-writing and formatting for presentation. Currently it is simply a text document. Completion time assuming uninterrupted time is one week.|| High|| Done || Scott Rifenbark|| 1 Week|| Documentation<br />
|-<br />
|| Documentation|| Poky Reference Manual|| This guide exists in the 0.9 form. The re-write of the text needs to be completed. So far, all the chapters have been rewritten but not re-posted on the site. Only the appendices remain for a text scrub. Time to complete this would be a week of uninterrupted time. Ideally, the manual would be a sub-manual that would be referenced and architected into the Yocto Project Development Guide.|| Medium|| Done|| Scott Rifenbark|| 1 Week|| Documentation<br />
|-<br />
|| Kernel || Initial meta-linaro layer || meta-linaro layer providing a kernel, tool-chain, and uboot loader. This deliverable is primarily to get the infrastructure in place and have a buildable kernel. Toolchain on best effort basis. || || Done || Darren || dvhart || Moderate risk of slippage due to holidays.<br />
|-<br />
|| Kernel || Tracing: blktrace and sysprof recipes || || || Done || Tom || dvhart ||<br />
|}<br />
<br />
=== Sprint D (closes Dec 3, 11:59pm PDT -- pull request sent, initially reviewed) :: NOTE: week of the F2F planning meeting ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Kernel || Kernel git branching structure revamped || || 1 || Done || Bruce || dvhart ||<br />
|-<br />
|| Kernel || Tunnel Creek (Crown Bay) || || 1 || Done || Tom || dvhart ||<br />
|}<br />
<br />
=== Sprint E (closes Dec 9 (THURSDAY), 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| Distro Audit: Upgrades Completed (Phase 1)|| Update to new versions as per the agreed plan for M2 from Sprint A|| 1|| Done || Saul|| rpurdie|| Continual Maintenance<br />
|-<br />
|| Distribution / components|| Distro Audit: Src Checksums|| Make sure all SRC_URI components have checksums too || 1|| Done || Saul|| rpurdie|| Hygiene<br />
|-<br />
|| Poky Features || enable KVM with qemu|| today all new Intel processors support VT, which are enabled on most desktop machines which are most frequently used build machine. with VT support, x86/x86-64 qemu target runs faster which is a good thing for emulation environment. This may require some qemu option tweaks and also poky-qemu script enhancement. || 2|| Done || Saul / Edwin|| ktian1|| Enhancement<br />
|-<br />
|| Kernel || New kernel recipes || dev, -devel, -custom || 3 || Done || Bruce || dvhart ||<br />
|-<br />
|| Swabber || Documentation for swabber || || 1 || Done || Alex || ||<br />
|-<br />
|| CCB || Defect triage process in public documented and implemented || || 1 || Done. Triage process is documented, out for review. || Saul || ||<br />
|}<br />
<br />
== M3 (Dec 20 to Feb 08 -- Dev Complete Feb 04, Stabilize Complete Feb 11, Release Complete Feb 18) ==<br />
=== Sprint A (closes Dec 24, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Kernel || Initial meta-rt layer || PREEMPT_RT kernel and related test-cases and benchmarks || 2 || Done by Jan 21 || Darren || dvhart || slipped out from M2<br />
|-<br />
|| Poky Features || Fetcher Overhaul Phase 1 - SRC_REV enhancement||<br />
* a) Add code in FetchData::__init__() which will check if the selected fetcher supports srcrev and the automatically call a function to set the src rev value instead of each fetcher doing this.\n <br />
* e) Break SRCREVINACTION deadlock. To do this, we need to start using a keyword for automatically increasing SRCREV, e.g. SRCREV = "AUTOINC". The actual revision can be injected into PV using SRCPV. If we do this there should no longer be a need of the deadlock; <br />
* k) Ensure that we only set __BB_DONT_CACHE when SRCREV = "AUTOREV". This may need a new method call for fetchers to tell whether they're "floating" or locked down.<br />
|| 1|| Done || Saul / Ke, RP|| rpurdie|| Enhancement, slipped out from M2<br />
|-<br />
|| Distribution / components|| Distro Audit Upgrades Planned (Phase 2)|| Complete plan for package upgrades in M2|| 1|| Done || Saul|| || Continual Maintenance<br />
|-<br />
|| Poky Features || Pseudo Performance || Implement the changes to bitbake based on pseudo's enable/disable switch|| 1|| done || Saul / Qing, Dongxiao || rpurdie|| Enhancement, slipped from M2 due to risk and not having Pseudo's change yet.<br />
|-<br />
|| Tool Development and SDK Features|| Fix the issue user target sysroot is owned by root || The ADT installer will use pseudo to extract user target sysroot which ended up owned by root, this need to be fixed || 1|| done || Jessica|| jzhang|| Cleanup <br />
|-<br />
|| Tool Development and SDK Features|| Eclipse poky tree interfacing (metadata file editor)|| Provide a metadata file editor with some syntax checking and keywords highlight capabilities|| 2|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| IDE Project templates|| Templates for various project types: Clutter GUI, Gtk+ GUI, to help developers get started quickly || 2|| Done || Jessica|| josh|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| push TCF/RSE patches upstream|| work with community to finish up our TCF terminal service, TCF/RSE integration remaining patches taken by upstream. Blocking issues including Eclipse Bug #327865 || 1|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Pseudo || Pseudo enhancement to enable on/off switch || || 1 || done || Mark || ||<br />
|-<br />
|| Pseudo || Bitbake enhancement for pseudo on/off switch || || 1 || done || Richard || ||<br />
|-<br />
|| bugzilla || Complete restructure of bugzilla categories || || 1 || done || Saul || ||<br />
|-<br />
|| Poky Features || Image creator ground work || Nomenclature determined, existing gui's bug fixed and backend work implemented || 1 || Done || Joshua || ||<br />
|-<br />
|| Kernel || Tracing: Initial SystemTap recipe || Works on x86 || 3 || Done || Tom || dvhart ||<br />
|-<br />
|| Distribution / components|| Distro Audit: Package Description/Summary completed|| Ensure DESCRIPTION/SUMMARY fields are all audited|| 2|| Done || Mark|| Mark|| Hygiene, was M2, Sprint B but missed window<br />
|-<br />
|| Distribution / components|| Zypper/RPM|| Small write-up of the problems we're having w/ Zypper and what we plan to do. (i.e. create a roadmap/design) - Includes rootfs generation - Package uprev/install/removal || 1 || Done || Mark/Qing || || was M2, Sprint B<br />
|-<br />
|| Distribution / components|| Distro Audit: Licence Checksums|| Make the licence checksums fatal if not present || 1|| Done || Saul|| rpurdie|| Hygiene, was M2, Sprint C<br />
|-<br />
|| Distribution / components|| push of all relevant Wind River patchs to Yocto (patch comparison)|| Ensure patches present to packages in WRS are also in Poky|| 1|| Done || Mark|| Mark|| was M2, Sprint C<br />
|-<br />
|| Poky Features || Performance Enhancement Completed || Initial changes to reduce disk space (sstate-build-*) || 1|| Done || Saul / Qing, Dongxiao || rpurdie|| Enhancement, was M2, Sprint E<br />
|-<br />
|| Distribution / components|| User specified qemu config support|| We'll provide user an edit box which allows advanced qemu user to specify arbitrary qemu configuration to meet their needs, which the poky-qemu scrip will just append the config list towards the end of the list of parameters to bring up qemu, it also expect the poky-qemu script to do some basic sanity check on the user specifications to catch the obvious mistake || 2|| Done || Saul / criping || criping|| enhancement, was M2, Sprint E<br />
|-<br />
|| Tool Development and SDK Features|| SDK Version Control support in SDK generator installer|| If we can expect that yocto SDK has lots of release in the future, we might need to consider SDK version control. Currently, if we un-tar the sdk, it will override the older version. It's not good for app developers since they might need the old version to do something. And also, maybe a finer installer than untar is preferred. Installer will tied to certain SDK version and the installation will go under /opt/poky-versionNo.|| 1|| Done || Jessica|| criping|| Enhancement-expect planning process by Jessica to handle this task. Was M2, Sprint E.<br />
|}<br />
<br />
=== Sprint B (closes Jan 07, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || Bitbake multi-threaded parsing|| Bitbake recipe parsing is currently single threaded. I want to make this multithreaded as the speedup would be nice. If I can only take a single task for myself for 1.0, I'm nominating this one as I enjoy this kind of thing and I have ideas on how to do it. || 1|| Done || Richard|| rpurdie|| Enhancement<br />
|-<br />
|| Distribution / components|| Lock in Kernel/Toolchain version|| Locked in 2.6.37 and gcc 4.5.1. Pending decision to move to 4.5.2 and Linaro || || Done || || Richard|| || <br />
|-<br />
|| Distribution / components|| License Update|| For each of the licences we support, I'd really like to have a licences directory with a copy of that license contained within. When it comes to deciding what a given LICENSE field means, this would be the reference. It also means we can include the licences a given image includes with the image. This continues to make our license handling world class and ahead of the field. || 2|| Done || Beth|| rpurdie|| Hygiene<br />
|-<br />
|| Tool Development and SDK Features|| Qemu configuration change|| Provice edit box for advanced user to specify qemu configurations|| 2|| Done || Jessica|| criping|| <br />
|-<br />
|| Tool Development and SDK Features|| Lock down Eclipse+CDT+TCF version|| Will use Eclipse Halo 3.6 || 1|| Done || Jessica|| || <br />
|-<br />
|| Demo|| Finalize on demo plans for v1.0 launch || || 1|| Done || Dave || || <br />
|-<br />
|| Release || Release plans for v1.0 launch || Fill out the M4 plan with the necessary release activities and timings || 1|| Done || Beth || || <br />
|-<br />
|| Poky Features || Basic image creator GUI || Functional UI missing some Advanced features || 1 || In replan || Joshua || || <br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer for SDK Generator Installation functions support||Detailed feature request can be found at: http://bugzilla.pokylinux.org/show_bug.cgi?id=589|| 1|| Done || Jessica|| rpurdie|| Enhancement<br />
|-<br />
|| Kernel || Tracing: trace-cmd python binding cleanup || || 3 || Done || Darren || dvhart ||<br />
|}<br />
<br />
=== Sprint C (closes Jan 14, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || kernel development layer|| The (correct) poky behaviour of building known revisions coupled with the fetcher requiring a BSP branch to already be present means that local modifications (and kernel source tree) are required for kernel development. I already have a layer that overrides/modifies the behaviour when added to the bblayers.conf and configured into an environment. This seems useful for more people to use. || 2|| Done || Bruce|| bruceashfield|| Enhancement, was M2, Sprint C<br />
|-<br />
|| Distribution / components|| Zypper/RPM|| RPM Uprev / Zypper Uprev [lets get to the latest versions]|| 1|| pull request by Jan 19; || Mark/Qing|| || was M2, Sprint C<br />
|-<br />
|| Supported Targets|| Intel Platform Support|| JasperForest|| 2|| Basic support in place; DPDK evaluation in process, overall BSP plan still TBD || Tom|| davest|| Basic ECG support (Moved from Sprint A)<br />
|-<br />
|| Tool Development and SDK Features|| Eclipse poky tree interfacing (git support)|| Use Eclipse git capability to install poky tree from git repo and able to interact with git repo at file level within Poky tree || 2|| Done || Jessica|| jzhang|| Enhancement<br />
<br />
|-<br />
|| Poky Features || Poky Image Creator|| A standalone application you can run which asks you to select a distro and machine, then presents a list of packages you can select. Once the selection is made, it goes off and bakes you an image which is then presented to you. Implementation wise, it should use the sstate packages, be a bitbake UI and use the usual poky bbclass files to do the image construction behind the scenes. || 1|| Re-plan || Joshua|| rpurdie|| Enhancement<br />
|-<br />
|| Validation|| Boottime/Performance Analysis|| Compare Yocto Project performance to other projects such as MeeGo|| 1|| Initial report on where we are by Feb 9 || Darren|| davest|| project commitment <br />
|-<br />
|| Distribution / components|| LSB Sanity|| execute LSB Test and improve passing rate and document failures with clear understanding|| 2|| Done || MarkH/Saul|| sgw|| Hygiene<br />
|-<br />
|| Distribution / components|| Review & Fix Standards Tests|| Review the results from LTP, POSIX and asses the result, fix as appropriate and clearly document failures.|| 2|| a Plan to resolve final items to be sent to the m.l. by Jan 14 || Saul/Kevin || sgw|| Hygiene<br />
|-<br />
|| Tool Development and SDK Features|| Image creator integration with Eclipse || || 2|| replan|| Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Kernel || Tracing: perf trace marker support || This is from feedback to the new trace command. Ingo appears to have this nearly complete already. || 3 || Done || Darren || dvhart ||<br />
|-<br />
|| Kernel || Tracing: perf trace scripting support || || 3 || Move to Sprint D; on track for Jan 21 || Tom || dvhart ||<br />
|-<br />
|| Cleanup || bitbake user experience error handling validation completed || || 2 || Done || Richard || ||<br />
|-<br />
|| Cleanup || variable scrub - ensure all metadata variables are documented || Script with a histogram of variable use done, identified 50 variables to document; Add task for actual documentation update is low on the list || 2 || Done || Scott/Darren || ||<br />
|-<br />
|| Distribution / components|| Zypper/RPM|| Integration based on design from Sprint B|| 1|| On track for Jan28 || Mark/Qing|| sgw|| Functionality, was M2, Sprint E<br />
|-<br />
|| Kernel || Tracing: package kernelshark || || 3 || Done || Darren || dvhart ||<br />
|-<br />
|| Kernel || Tracing: tuna, oscillosope recipes || || 3 || Tom to discuss plan with Darren et al || Tom || dvhart ||<br />
|- <br />
|| BSP || Beagleboard XM Support || || 3 || Move to Sprint D || Darren || dvhart ||<br />
|}<br />
<br />
=== Sprint D (closes Jan 21, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Swabber || Complete review of swabber outputs || Move to M3 Sprint D || 1 || Move to M3 Sprint D || Alex || ||<br />
|-<br />
|| Poky Features || Fetcher Overhaul Phase 2 - API reorg||<br />
* f) Add a generic unpack funciton to __init__.py based on the unpack task in Poky ;<br />
* g) Split go() methods into the following steps: i) download() - do whatever transfer is necessary to get the sources locally ii) build_mirror_data() - generate any data that would be needed to construct a source mirror iii) unpack() - takes a directory as an argument of where to place extracted sources;<br />
The existing go() methods should be replaced with a set of calls to the above sections of functionality as appropriate in the individual fetchers. Some of these categories of function make no sense in certain fetchers, in which case they shouldn't need to implement them. Functions are only executed if the method is present.<br />
* h) Change Poky's unpack to call an unpack method in the fetchers.<br />
* i) Change Poky's fetch task to call a "download" method in the fetcher instead of go().<br />
|| 1|| Will land with phase 3 in Jan 21 || Saul / Ke, RP|| rpurdie|| Enhancement<br />
|-<br />
|| Poky Features || Fetcher Overhaul Phase 3 - git enhancement||<br />
* j) Optimize git fetcher for the new layout so for a git checkout, we clone the repository in download(), then unpack just does a clone with references to the original repo. <br />
* k) Ensure that we only set __BB_DONT_CACHE when SRCREV = "AUTOREV". This may need a new method call for fetchers to tell whether they're "floating" or locked down. <br />
* l) Add a new "BB_NO_NETWORK" variable which the fetchers check before peforming an operation which hits anything remote. This means adding in error messages about why network access is needed at various points (e.g. SRCREV = "AUTOREV" for a given recipe) <br />
* m) Add multiple branch/srcrev support for git fetcher. These would be of the form: git://somelocation/somerepo.git;name=ref1;branch=foo;name=ref2;branch=bar SRCREV_ref1 = "hash1" SRCREV_ref2 = "hash2" which would ensure both hash1 and hash2 were in the final repo. <br />
* n) Change git fetcher to default to git protocol instead of rsync<br />
|| 1|| Slipped to Sprint D || Saul / Ke, RP|| rpurdie|| Enhancement<br />
|-<br />
|| Poky Features || DSO linking changes|| "By the default the gcc linker will automatically link any dependant objects/libraries. ""Inherited"" linkages can cause issues, for example, where a shared object changes its dependencies but a program has come to rely on symbols from an implicitly linked library. Fedora implemented this change in F13, seems like it would be useful to have in Poky too. "|| 2|| On track for Jan 21 || Saul / Nitin || josh|| bug#516<br />
|-<br />
|| Distribution / components|| Distro Audit Documentation Output|| Audit package documentation output || 2|| Move to Sprint D due to libtool work || Saul / ScottG || rpurdie|| Hygiene<br />
|-<br />
|| Poky Features || libtool sysroot option|| libtool 2.4 has a sysroot option. We should try and use it, see how it works and whether we can ditch some of our libtool hacks. || 1|| On track for Jan 21 || Saul / ScottG || rpurdie|| Enhancement<br />
|-<br />
|| Distribution / components|| MACHINE or Recipe specific sysroots|| Each machine should have its own sysroot. We'll probably have to split do_populate_sysroot into a two step process, creation of the package and than installtion of the package, which the installation of the package being made machine specific (put ${MACHINE} into ${STAMP} and bitbake should do that). Also allowing this to work per recipe would be desireable|| 1|| On track 21 || Saul / Dongxiao || rpurdie|| Hygiene<br />
|-<br />
|| Distribution / components|| Toolchain Bootstrap Process|| The toolchain as it bootstraps overwrites files like libc.so and libgcc.so in the sysroot directory which causes issues if you just try and rebuild part of the toolchain. Each step of the bootstrap process should use a separate sysroot. Once this is once, sstate file overwriting detection can be added and enabled. || 1|| Patches submitted for comment, slip to Sprint D || Saul / Dexuan || rpurdie|| Hygiene<br />
|-<br />
|| Documentation Features|| Package report system|| move to public server [setup a package report system in an internal machine. We need push it publicly available. The basic features like search and report have been there. But there're still some enhancements in plan, to make it a fit place to feel Yocto metadata comfortably]|| 2|| Move to Sprint E|| KevinT|| ktian1|| enhancement<br />
|-<br />
|| Distribution / components||Add headers and libraries to qemu images ||Since we'll be using qemu images as target sysroot, need to create a set of qemu images for minimal, sato, LSB that contains target header and libraries.|| 2|| Pending a discussion on Jan 18 || Saul ||jzhang|| Enhancement<br />
|-<br />
|| Distribution / components|| push of all relevant Wind River patchs to Yocto (patch comparison)|| Update any additional patches needed since M2.|| 1|| May be done by Jan 21, pending RPM stuff || Mark|| Mark|| <br />
|-<br />
|| Distribution / components|| mklibs|| mklibs is a tool to optimize size of [e]glibc for a perticular root file system image. It is useful to save disk space on small devices. || 2|| Push to Sprint E || Saul|| Nitin Kamble|| enhancement<br />
|-<br />
|| Poky Features || Performance Enhancement || reduce disk space (hardlink) || 1 || On track for Jan 21, pending RP review || Saul / Qing, Dongxiao || rpurdie || Enhancement<br />
|-<br />
|| BSP || 2.6.37 Crown Bay Support || On Track for Jan 21 || 2 || || Tom || dvhart || <br />
|-<br />
|| BSP || 2.6.37 Emenlow Support || On track for Jan 21 || 2 || || Tom || dvhart || <br />
|}<br />
<br />
=== Sprint E (closes Jan 28, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| rootless X|| rootless x server has better security than x server launched by root. MeeGo already enable this feature. it would be nice for Yocto to also enable it. || 2|| On track for Jan 28 || Saul / Ke || yuke|| enhancement<br />
|-<br />
|| Documentation Features|| Package report system|| finish major feature development and internal review [setup a package report system in an internal machine. We need push it publicly available. The basic features like search and report have been there. But there're still some enhancements in plan, to make it a fit place to feel Yocto metadata comfortably]|| 2|| Move to Sprint E || Jonathan || ktian1|| enhancement, was M2, Sprint E<br />
|-<br />
|| Distribution / components|| perl upgrade|| perl is the most cross un-friendly recipe pending upgrade. || 2|| Slipping due to Linaro layer, moves to end of Sprint E || Nitin|| Nitin Kamble|| enhancement<br />
|-<br />
|| Supported Targets|| Intel Platform Support|| Sandybridge|| 2|| Accept|| Tom|| davest|| Basic ECG support<br />
|-<br />
|| Distribution / components|| performance indicators|| define some indicators (boot time, footprint, build time, power, component benchmarks, etc.) and then collect them for tracking purpose. The result could be posted on the wiki site, and the initial indicators can be easy ones which can be easily retrieved from autobuilder or weekly qa report). This way we have a clear track about the healthy of the Yocto project, and also identify weak areas. We can include qemu targets and several representational boards as the targets. || 2|| Review|| Beth/Jiajun|| ktian1|| enhancement<br />
|-<br />
|| Tool Development and SDK Features|| SDK user workshop|| Have some developers sit down and use our tools to develop demo software for Yocto. || 2|| Review|| Jessica|| josh|| Enhancement<br />
|-<br />
|| Kernel || Final linux-yocto_git.bb || With 2.6.37 kernel || 1 || || Bruce || dvhart ||<br />
|-<br />
|| Kernel || Final meta-linaro layer || || || || Darren || dvhart ||<br />
|-<br />
|| Kernel || Final meta-rt layer || || || || Darren || dvhart ||<br />
|-<br />
|| Kernel || Sandy Bridge || || 1 || || Tom || dvhart ||<br />
|}<br />
<br />
=== Sprint F (closes Feb 03 (THURSDAY), 11:59pm PDT -- pull request sent, initially reviewed) :: NOTE: China New Year Holiday ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Documentation|| ADT Reference Guide Draft out for review || Outline complete|| High|| WIP || Scott Rifenbark|| jzhang|| Documentation<br />
|-<br />
|| || || || || || || || <br />
|}<br />
<br />
== M4 (Feb 07 to Apr 15 -- Stabilize Complete Mar 18, Release Complete Apr 01, Contingency to Apr 15) ==<br />
<br />
This sprint is the [[Yocto Project v. 1.0 Release Cycle]].<br />
<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Documentation|| Migration chapter in the Poky Reference Manual|| This chapter would cover the four identified use-cases for migrating up to the most recent version of Yocto Project. Additionally, it would cover migration scenarios from other development systems. The chapter does not yet exist. The chapter has not been scoped outside of having a meeting that identified four use-cases that did not include migration from a development system outside of Yocto Project. It will take some more scoping time to cover those areas (a day or two). Again, I have no idea of the length. See earlier entries for standard industry writing estimates for software documentation|| Medium|| Not Started|| Scott Rifenbark|| 3-4 Weeks|| Documentation<br />
|-<br />
|| Documentation|| Yocto Project Development Guide|| This manual would be an over-arching document that frames the complete development cycle within Yocto Project. The idea here is that the document would be an umbrella document that spawned and referenced subsequent documents. The organization would be the first chapter overviewing the major development pieces such as recipe creation, building, debugging, publishing, fail-safing, back-door hook creation, etc. Scoping would be about two weeks and length would probably be about 40 pages. Overall development time would likely be a month of uniterruped time.|| Medium|| Not Started|| Scott Rifenbark|| 3 Weeks|| Documentation<br />
|-<br />
|| || Multilib Support|| Consider developing post-1.0 branch || 1|| to start in M4 || Richard|| ||<br />
|-<br />
|| Validation|| Alpha testing complete|| 4-5 internal developers unfamiliar with Yocto Project try to do a build and report on the experience and issues encountered|| 1|| Done by Feb 18 || Julie|| davest|| <br />
|-<br />
|| || || || || || || || <br />
|}<br />
<br />
== Features needed and to be put into sprints by assigned owners: ==<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || package config option enhancement|| there're several enhancements we may do here: * allow users setting specific config options (local or global) from external tool, such as poky image creator, instead of changing recipes manually. Need a mechanism to convert from variable assignments into exact config options (e.g. feature_${PN} = ""1"" -> ""--enable-feature""). Consequently dependency chain needs update with option status. * host contamination check. We have swabber to check host contamination, but I'm not sure whether it covers configuration phase. If not, this is one area to improve, as not ususually we see configure script checks host bits for available features * conditional option manipulation. In many recipes we enable/disable one option based on availability of other packages. Now this is done manually and not flexible. this should be made automatically though some new annotation to indicate condition, or just base_contains (not convenient: long line, need define distro features) || 2|| Review|| Richard/MarkH|| ktian1|| Enhancement<br />
|-<br />
|| Media|| Yocto Project Awareness Video|| This 2.5 minute video would introduce and describe the benefits of Yocto Project. The video would use entertaining animations that described concepts and benefits. The result would be suitable for YouTube, conferences, and the website. The production is called an "Epipheo" and will be created by Epipheo Studios. The engagement process has begun and the kick-off meeting will be soon. The PO is in place. Time for development is 10 weeks.|| High|| Kick-off Imminent|| Scott Rifenbark|| 10 Weeks|| Media<br />
|-<br />
|| Documentation|| Yocto Project Debugging Guide|| This would be a guide for the debugging and bug tracking process in Yocto Project. Originally, the thought was that we needed a Bugzilla User's Manual. However, since we don't own Bugzilla it doesn't make sense to produce documentation for it. Rather, we should document the process as it fits into the Yocto Project environment. Ideally, the manual would be a sub-manual that would be referenced and architected into the Yocto Project Development Guide. The manual has not been scoped and would take a week to scope. Again, I have no idea of the length. See the previous item for standard industry writing estimates for software documenation.|| Medium|| Not Started|| Scott Rifenbark|| 3-4 Weeks|| Documentation<br />
|-<br />
|| Website|| Yocto Project Website|| The 0.9 website is in place but needs updates. Items for consideration are the left-panel naviagation scheme, a contributions guidance page, color-scheming and theme (possibly).|| Medium|| Not Started|| Scott Rifenbark|| 1-2 Weeks|| Website<br />
|}<br />
<br />
== Features not believed to be needed in v1.0: ==<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || OpenEmbedded/Bitbake Upstreaming|| "We firstly need to review where we are and where OE is. We then need to make a plan about what we're going to push upstream and what we're not. I'd suggest when we're in PRC, we do a crash course in ""dealing with OE"" and then many dedicate a block of time (a week) where the distro team comes up with a patch set we then propose and get merged into OE. I'd like to find a couple of interested people to monitor OE more regularly and start a workflow of things between Poky/OE where appropriate. The key thing to remember is we need to keep the architectures compatible. The team is now at the point where I'm happy for them to actually try building OpenEmbedded and not worry about it tainting them! "|| 2|| Review|| || rpurdie|| Process<br />
|-<br />
|| Poky Features || Handle old versions in WORKDIR|| an incremental build directory may finally include many old versions WORKDIRS. It'll be good to have those old versions tracked in the cache, which can then either generate a report or allow selectively cleaning up an specific version WORKDIR. Or else it's difficult to figure it out when people want to keep the whole tmp directory but like to cleanup some old bits when disk usage is under pressure. If it's not easy to do in bitbake, perhaps some separate scripts would be also helpful || 3|| Review|| || ktian1|| Enhancement<br />
|-<br />
|| Poky Features || run bitbake w/o rebuilding the cache|| "sometimes it's useful to allow run bitbake w/o re-parsing recipes, if we know nothing metadata is changed. we can just allow reusing existing persistent cache. this is useful when people is debugging WORKDIR w/o metadata change. also sometimes ""bitbake -e"" is used frequently to check poky variable information. with existing cache, several seconds can be saved which are not negligible for a developer daily working on Yocto "|| 2|| Review|| || ktian1|| Enhancement<br />
|-<br />
|| Poky Features || parallel make improvement|| parallel make experience is not good, especially when bb threads and make threads are increased larger than 8. So far we either try to fix package makefile or mark the recipe as no parallel make, when build faiures are reported. But this greatly impacts user experience for a successfully continuous build process. Could we define a safe number we do want to support for 1.0 release? and then have our autobuilder, QA test, and developers cover that number immediately and fix any issues accordingly. Then the safe number can be suggested to the Yocto user || 2|| Review|| || ktian1|| Enhancement<br />
|-<br />
|| Poky Features || Dependency packages rebuild/clean|| It is a mechanism to rebulid or clean a package and all other packages which have build/runtime dependency on it. With this change, we can find potential influences of package upgrade to its related packages, which can make the incremental build more trustable. For example, if we upgrade a package to a new vesion which changes its API, this mechanism can easily find out the incompatibility to other packages which have dependency on it. || 2|| Review|| || dongxiao.xu|| Enhancement, replaced by checksum feature<br />
|-<br />
|| Distribution / components|| FOSSology|| This may be similar to License Update above, but start to use FOSSology to track licenses. || 2|| Review|| || sgw|| Hygiene<br />
|-<br />
|| Distribution / components|| Package Developer Tools|| Create a set of Init scripts template and then review our current init scripts and modify them to confirm to the template. || 2|| Review|| || sgw|| Easy of Use<br />
|-<br />
|| Distribution / components|| Package Website|| Complete the work the intern has started on generating the distro tracking information and get it out on the external site. || 2|| Review|| || sgw|| "Hygiene, duplicate of ""Package report system"""<br />
|-<br />
|| Distribution / components|| Bluetooth UI support|| Currently we have bluez package in poky, and we need to have a workable graphic user interface to connect/configure BT devices. One choice may be gnome-bluetooth-applet. || 3|| Review|| || dongxiao.xu|| enhancement<br />
|-<br />
|| Distribution / components|| Connman-gnome enhancement features|| Enable connman-gnome to support features like, WPA Enterprise connection, hidden SSID, etc. || 3|| Review|| || dongxiao.xu|| enhancement<br />
|-<br />
|| Distribution / components|| Java Running Environment support|| Since most embedded systems support java applications running in it, maybe we'd better consider supporting some kinds of JVMs(Embeded JVM). The JVM may not run by default, but user can launch it if running java applications. Compared with GTK/QT, java user number is not small too. || 3|| Review|| || criping|| enhancement<br />
|-<br />
|| Distribution / components|| create more use cases|| UPnP demo is one really good use case showing how Yocto is utilized to make real functionality. and we could create more to show how Yocto is easily adapted to real use cases. Those use cases can be either maintained as seperate demo layers in yocto repo, or in seperate branches for reference. We can also call for community's contribution on this which would make 1.0 full-fledged. Or else the newbies to Yocto may be in puzzle how our sample profiles can satisfy their requirements. || 2|| Review|| || ktian1|| enhancement<br />
|-<br />
|| Distribution / components|| i18n support || internationalization is an important system wide feature. Many component like font, locale affect the i18n. Yocto alreay has some i18n related package like pango, but so far did not consider i18n systematically. so this is place holder to systematically add i18n support. || 2|| Review|| || yuke/qing|| enhancement<br />
|-<br />
|| Distribution / components|| more demos || demos are a good way to educate, push the envelope, and at the same time tout the strengths of the platform. This item just records a current set of ideas from various sources which could/should be implemented: * face-recognition/face-finding, * robotic control/application of face-finding to 'camera-as-sensor' (hexbug demo), * others [tbd, add here]|| 2|| Review|| || tzanussi|| enhancement <br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer support for image-creator and needed yocto-metadata design||Come up design what need to be created as packages to support using "opkg install" for image-creator and needed yocto-metadata|| 2|| WIP, pending comments from RP regarding how to packaging metadata|| Jessica|| rpurdie|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer image-creator and needed poky-metadata support|| The poky build system will build packages for image-creator and needed poky-metadata, which the Yocto Installer will be able to use "opkg install" to install them|| 2|| Review|| Jessica|| rpurdie|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Provide qemu management UI|| In current eclipse plugin, QEMU settings are put together with project configuration. So we can only have limited settings. If we can have a separate QEMU management UI, the end user could firstly create a QEMU config, such as (env file of arch, image location, unfs or not, sato or lsb, mem size, disk size). And then he can launch a QEMU with a specific config. The dependency between project configuration and QEMU config will be resolved. After all QEMU has nothing to do project configuration. Need to careful review the UI to ensure minimal impact to testing matrix. || 3|| Review|| || criping|| "Enhancement, duplicate of ""Qemu mem/disk size can be adjusted"""<br />
|-<br />
|| Tool Development and SDK Features|| QT plugin For Eclipse|| Integrate QT Ecplise plugin and extend for Yocto Project || 3|| Review|| || jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Profiling/Trace GUI's|| We have a wealth of great tracing and profiling tools but the UI's for them are all extremely minimal and usually quite ugly. Would be great if we could compete with, or even better, Apple's offerings here. We have the technology! || 2|| Review|| || josh|| "Enhancement, duplicate of ""Tracing/Profiling Planning Complete"""<br />
|-<br />
|| Tool Development and SDK Features|| Other profiling tools|| Complete Tom's review of profiling tools and architecture || 2|| Review|| || josh|| "Enhancement, duplicate of ""Tracing/Profiling Planning Complete"""<br />
|-<br />
|| Tool Development and SDK Features|| Design next-gen tracing/profiling tools|| Yocto 1.0 will include all the essential existing tracing/profiling tools expected by users, and Josh has proposed a UI integration of all those tools as far as it's possible to do so. That level of integration, basically a 'plugin-level' integration is necessary and useful, but doesn't go far enough. A next-generation tracing tool would integrate at a much more fundamental level; if done properly, it would provide unmatched levels of power and usability to users, and would allow Yocto to distinguish itself in the embedded tracing/profiling space in a way also unmatched by any other distro/build-tool. The implementation would of course not be available for Yocto 1.0, but a coherent design, including prototypes, that could be taken to the community and implemented in a V 1.5 or 2.0 should be done in that time frame. || 1|| Review|| || tzanussi|| "Enhancement, duplicate of ""Tracing/Profiling Planning Complete"""<br />
|-<br />
|| Documentation Features|| Self Documentation of image contents|| "I'd like to see the -doc packages Poky builds being combined into some kind of large documentation index representing the collective API docs of the target being built. This can then be placed on a webserver and viewed over the web. We'd have a demonstration of this for a ""bitbake world"" target. Part of the idea here is to start making good use of the docs as if developers see this they might start writing better docs too. Aim is to lead the field :). There are a number of places poky packages disable doc generation due to missing tools so we'd need to add these so we can enable the doc generation. Many packages already have many docs though too. "|| 2|| Review|| || rpurdie|| enhancement<br />
|-<br />
|| Validation|| Testing Framework|| Add a framework for doing automated testing in the project|| 1|| Review|| || davest|| project commitment<br />
|-<br />
|| Validation|| more SDK builds on autobuilder|| enable more SDK related tests on autobuilder such as meta-ide-support, etc.|| 2|| Review|| || ktian1|| project commitment, addressed by test plan (?)<br />
|-<br />
|| Validation|| more people should try using SDK|| this may not be a feature, but a requirement. SDK including meta-toolchain is one key factor impacting user experience on Yocto. It's not enough to have only SDK team play with it|| 2|| Review|| || ktian1|| project commitment, addressed by test plan (?)<br />
|-<br />
|| Validation|| Unit Testing Framework|| Add a mechanism to bitbake to parse source packages that have unit tests and then execute them on the target|| 3|| Review|| || sgw|| "project commitment, duplicate of ""Testing Framework"""<br />
|-<br />
|| Validation|| Test Case open source|| Open source Yocto test cases with xml format|| 1|| Review|| || yyou|| "project commitment, duplicate of ""Testing Framework"""<br />
|}</div>Davesthttps://wiki.yoctoproject.org/wiki/index.php?title=Yocto_1.0_Schedule&diff=585Yocto 1.0 Schedule2011-01-25T01:28:31Z<p>Davest: /* Sprint C (closes Jan 14, 11:59pm PDT -- pull request sent, initially reviewed) */</p>
<hr />
<div>= v1.0 (release date: Apr 15, 2011) =<br />
----<br />
The detailed milestone map for v1.0 is as below. During the first week of each subsequent milestone past M1 we will have a demonstration of the previous milestone capabilities as well as a planning and design session for the current milestone.<br><br><br />
<br />
== M2 (Nov 08 to Dec 24 -- Dev Complete Dec 10, Stabilize Complete Dec 17, Release Complete Dec 24) ==<br />
=== Sprint A (closes Nov 12, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links''' <br />
|-<br />
|| Poky Features || Kernel interactive targets || To support incremental kernel development having the ability to run menuconfig (or xconfig, etc) directly is a common request. We'll need to add this for commercialization anyway. i.e. bitbake -c menuconfig. This fuctionality already exists. || 1 || Done || Richard || bruceashfield || Enhancement <br />
|-<br />
|| Distribution / components || Distro Audit: Upgrades Planned (Phase 1) || Complete plan for package upgrades in M2 || 1 || Done || Saul || || Continual Maintenance<br />
|-<br />
|| Validation || Runtime testing || Runtime testing of images as part of the autobuilder || 1 || Done || Jiajun/ScottG || rpurdie || project commitment<br />
|- <br />
|| || Poky Image Creator Wireframe/Interaction Plans Complete || || 1 || Done || Josh || ||<br />
|-<br />
|| || SDK Generator Interaction: Plans Complete || || 1 || Done || Jessica || ||<br />
|-<br />
|| || Tracing/Profiling Planning Complete || This needs to cover where we're at now, what we're missing and also propose the future enhancements that may be needed. M2 targets getting existing tools integrated and documented. F2f discussion n the future enhancements || || Done || Tom || ||<br />
|-<br />
|| || Swabber. (Still needs to be integrated into weekly build by default) || || 1 || Done || Josh || ||<br />
|-<br />
|| Build/Release || Release process documentation || || || Done || Beth || ||<br />
|-<br />
|| Validation || Test plan for v1.0 (to address any deficiencies in coverage from v0.9)|| || 1 || Done || Jiajun || ||<br />
|}<br />
<br />
=== Sprint B (closes Nov 19, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| Distro Audit: World Packages|| Audit world packages making sure it all build, making sure all are packages are required || 2|| Done || Saul|| sgw|| Hygiene<br />
|-<br />
|| Tool Development and SDK Features|| SDK Generator Installer UI|| Look at different ways of Installer UI (GTK+ and ncurses) seems none of them is the right choice, decide to go with script to implement all the functionalities of installer and later add UI part on top of it || 1||Done|| Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Customize sysroot setup || Add and test out "--sysroot" config option to cross compiler within Eclipse IDE || 1|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| SDK Generator Installer design revision|| Close all open questions regarding Yocto SDK Generator Installer function design and come up HLD || 1|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Distribution / components|| kernel version|| keeping 2.6.34 as a -stable kernel is the best option. I've also got a newer -devel tree that can be made available or made the default. || 3|| Done || Bruce|| bruceashfield|| enhancement<br />
|-<br />
|| || assign Yocto Project PM|| acquire and assign a program manager for Yocto Project|| || Done || DaveST|| || <br />
|-<br />
|| || assign Yocto Project Sys Admin|| || || Done || Saul|| || <br />
|-<br />
|| Tool Development and SDK Features|| oprofileUI|| Fixing various bugs of the oprofileUI to make it workable on big endian host.(i.e. ppc, mips) || 2 || Done || Jessica || lianhao.lu || Bug #382 / Bug #493<br />
|-<br />
|| Poky Feature|| SDK Version Control|| If we can expect that yocto SDK has lots of release in the future, we might need to consider SDK version control. Currently, every thing installed under /opt/poky which leads to things be overriden, we need to be able to use a scheme like /opt/poky-1.0, /opt/poky-2.0 to distiguish things. || 2|| Done || Josh|| jzhang|| Enhancement<br />
|-<br />
|| Kernel || Kernel plan complete || Flesh our kernel deliverables and add to Yocto 1.0 schedule || || Done|| Darren || dvhart ||<br />
|}<br />
<br />
=== Sprint C (closes Nov 26, 11:59pm PDT -- pull request sent, initially reviewed) :: NOTE: this is US Thanksgiving week ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| Distro Audit: Licence Checksums|| licence checksums || 1|| Done || Saul|| rpurdie|| Hygiene<br />
|-<br />
|| Poky Features || Performance Analysis Completed|| "I'd like someone to instrument a green release build, see where it spends time (hot/cold parsing time, individual task building time) and then compare this with our 0.9 release build. I'd also like to compare the disk usage between the two. Once we have a blame list we can then set about fixing it. Some things I know will come up: a) pseudo, b) checksums/signature code, c) exec() vs fork for executing tasks, d) task based prebuilds increasing disk usage, e) rpm dependency calculations, f) using rpm vs. ipk but I may be wrong and there may be others. We need numbers. "|| 1|| Done || Saul / Qing, Dongxiao|| rpurdie|| Enhancement<br />
|-<br />
|| Poky Features || environment variables for kernel builds|| switching a branch, or adding a configuration feature (and even changing the kernel repo) is often done during development of a BSP. Having some additional variables that are pass the bitbake environment scrub would be useful. i.e. KBRANCH=foo bitbake -c configure linux-yocto. This goes along with the other BSP bootstrapping suggestions. || 2|| Done || Bruce|| bruceashfield|| Enhancement<br />
|-<br />
|| Supported Targets|| ARM Platform Support|| Replace beagleboard with Beagleboard XM - decision || 2|| Done || Bruce|| alex|| Basic Yocto hardware support <br />
|-<br />
|| Distribution / components|| Security Process|| We need a dedicated person to scan and apply critical security updates to the distro. The MeeGo team already has a similar process with some scripts which may be leveraged. To complete the task, the process should be documented and a first pass over the metadata made to establish the current position on security. Any upgrades needed should be identified and a plan to address them should be in place but doesn't have to be implemented by this point.|| 1|| Done || ScottG|| ktian1|| enhancement<br />
|-<br />
|| Tool Development and SDK Features|| SDK Generator Installer Opkg repo design|| Come up a opkg repo design that will mimic the final Yocto package repo layout to be used by SDK Generator Installer to test against|| 2 || Done || Jessica || jzhang || <br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer tar creaion|| Create a Yocto Installer tar ball which contains Installer script and supported opkg component that will be used for installing other Yocto components|| 2 || Done || Jessica || jzhang || <br />
|-<br />
|| Documentation|| Kernel Framework Paper from WR|| The paper from WR needs to be re-written and then posted somewhere on the Yocto Project site. This will involve examiniation of the text and re-writing and formatting for presentation. Currently it is simply a text document. Completion time assuming uninterrupted time is one week.|| High|| Done || Scott Rifenbark|| 1 Week|| Documentation<br />
|-<br />
|| Documentation|| Poky Reference Manual|| This guide exists in the 0.9 form. The re-write of the text needs to be completed. So far, all the chapters have been rewritten but not re-posted on the site. Only the appendices remain for a text scrub. Time to complete this would be a week of uninterrupted time. Ideally, the manual would be a sub-manual that would be referenced and architected into the Yocto Project Development Guide.|| Medium|| Done|| Scott Rifenbark|| 1 Week|| Documentation<br />
|-<br />
|| Kernel || Initial meta-linaro layer || meta-linaro layer providing a kernel, tool-chain, and uboot loader. This deliverable is primarily to get the infrastructure in place and have a buildable kernel. Toolchain on best effort basis. || || Done || Darren || dvhart || Moderate risk of slippage due to holidays.<br />
|-<br />
|| Kernel || Tracing: blktrace and sysprof recipes || || || Done || Tom || dvhart ||<br />
|}<br />
<br />
=== Sprint D (closes Dec 3, 11:59pm PDT -- pull request sent, initially reviewed) :: NOTE: week of the F2F planning meeting ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Kernel || Kernel git branching structure revamped || || 1 || Done || Bruce || dvhart ||<br />
|-<br />
|| Kernel || Tunnel Creek (Crown Bay) || || 1 || Done || Tom || dvhart ||<br />
|}<br />
<br />
=== Sprint E (closes Dec 9 (THURSDAY), 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| Distro Audit: Upgrades Completed (Phase 1)|| Update to new versions as per the agreed plan for M2 from Sprint A|| 1|| Done || Saul|| rpurdie|| Continual Maintenance<br />
|-<br />
|| Distribution / components|| Distro Audit: Src Checksums|| Make sure all SRC_URI components have checksums too || 1|| Done || Saul|| rpurdie|| Hygiene<br />
|-<br />
|| Poky Features || enable KVM with qemu|| today all new Intel processors support VT, which are enabled on most desktop machines which are most frequently used build machine. with VT support, x86/x86-64 qemu target runs faster which is a good thing for emulation environment. This may require some qemu option tweaks and also poky-qemu script enhancement. || 2|| Done || Saul / Edwin|| ktian1|| Enhancement<br />
|-<br />
|| Kernel || New kernel recipes || dev, -devel, -custom || 3 || Done || Bruce || dvhart ||<br />
|-<br />
|| Swabber || Documentation for swabber || || 1 || Done || Alex || ||<br />
|-<br />
|| CCB || Defect triage process in public documented and implemented || || 1 || Done. Triage process is documented, out for review. || Saul || ||<br />
|}<br />
<br />
== M3 (Dec 20 to Feb 08 -- Dev Complete Feb 04, Stabilize Complete Feb 11, Release Complete Feb 18) ==<br />
=== Sprint A (closes Dec 24, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Kernel || Initial meta-rt layer || PREEMPT_RT kernel and related test-cases and benchmarks || 2 || Done by Jan 21 || Darren || dvhart || slipped out from M2<br />
|-<br />
|| Poky Features || Fetcher Overhaul Phase 1 - SRC_REV enhancement||<br />
* a) Add code in FetchData::__init__() which will check if the selected fetcher supports srcrev and the automatically call a function to set the src rev value instead of each fetcher doing this.\n <br />
* e) Break SRCREVINACTION deadlock. To do this, we need to start using a keyword for automatically increasing SRCREV, e.g. SRCREV = "AUTOINC". The actual revision can be injected into PV using SRCPV. If we do this there should no longer be a need of the deadlock; <br />
* k) Ensure that we only set __BB_DONT_CACHE when SRCREV = "AUTOREV". This may need a new method call for fetchers to tell whether they're "floating" or locked down.<br />
|| 1|| Done || Saul / Ke, RP|| rpurdie|| Enhancement, slipped out from M2<br />
|-<br />
|| Distribution / components|| Distro Audit Upgrades Planned (Phase 2)|| Complete plan for package upgrades in M2|| 1|| Done || Saul|| || Continual Maintenance<br />
|-<br />
|| Poky Features || Pseudo Performance || Implement the changes to bitbake based on pseudo's enable/disable switch|| 1|| done || Saul / Qing, Dongxiao || rpurdie|| Enhancement, slipped from M2 due to risk and not having Pseudo's change yet.<br />
|-<br />
|| Tool Development and SDK Features|| Fix the issue user target sysroot is owned by root || The ADT installer will use pseudo to extract user target sysroot which ended up owned by root, this need to be fixed || 1|| done || Jessica|| jzhang|| Cleanup <br />
|-<br />
|| Tool Development and SDK Features|| Eclipse poky tree interfacing (metadata file editor)|| Provide a metadata file editor with some syntax checking and keywords highlight capabilities|| 2|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| IDE Project templates|| Templates for various project types: Clutter GUI, Gtk+ GUI, to help developers get started quickly || 2|| Done || Jessica|| josh|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| push TCF/RSE patches upstream|| work with community to finish up our TCF terminal service, TCF/RSE integration remaining patches taken by upstream. Blocking issues including Eclipse Bug #327865 || 1|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Pseudo || Pseudo enhancement to enable on/off switch || || 1 || done || Mark || ||<br />
|-<br />
|| Pseudo || Bitbake enhancement for pseudo on/off switch || || 1 || done || Richard || ||<br />
|-<br />
|| bugzilla || Complete restructure of bugzilla categories || || 1 || done || Saul || ||<br />
|-<br />
|| Poky Features || Image creator ground work || Nomenclature determined, existing gui's bug fixed and backend work implemented || 1 || Done || Joshua || ||<br />
|-<br />
|| Kernel || Tracing: Initial SystemTap recipe || Works on x86 || 3 || Done || Tom || dvhart ||<br />
|-<br />
|| Distribution / components|| Distro Audit: Package Description/Summary completed|| Ensure DESCRIPTION/SUMMARY fields are all audited|| 2|| Done || Mark|| Mark|| Hygiene, was M2, Sprint B but missed window<br />
|-<br />
|| Distribution / components|| Zypper/RPM|| Small write-up of the problems we're having w/ Zypper and what we plan to do. (i.e. create a roadmap/design) - Includes rootfs generation - Package uprev/install/removal || 1 || Done || Mark/Qing || || was M2, Sprint B<br />
|-<br />
|| Distribution / components|| Distro Audit: Licence Checksums|| Make the licence checksums fatal if not present || 1|| Done || Saul|| rpurdie|| Hygiene, was M2, Sprint C<br />
|-<br />
|| Distribution / components|| push of all relevant Wind River patchs to Yocto (patch comparison)|| Ensure patches present to packages in WRS are also in Poky|| 1|| Done || Mark|| Mark|| was M2, Sprint C<br />
|-<br />
|| Poky Features || Performance Enhancement Completed || Initial changes to reduce disk space (sstate-build-*) || 1|| Done || Saul / Qing, Dongxiao || rpurdie|| Enhancement, was M2, Sprint E<br />
|-<br />
|| Distribution / components|| User specified qemu config support|| We'll provide user an edit box which allows advanced qemu user to specify arbitrary qemu configuration to meet their needs, which the poky-qemu scrip will just append the config list towards the end of the list of parameters to bring up qemu, it also expect the poky-qemu script to do some basic sanity check on the user specifications to catch the obvious mistake || 2|| Done || Saul / criping || criping|| enhancement, was M2, Sprint E<br />
|-<br />
|| Tool Development and SDK Features|| SDK Version Control support in SDK generator installer|| If we can expect that yocto SDK has lots of release in the future, we might need to consider SDK version control. Currently, if we un-tar the sdk, it will override the older version. It's not good for app developers since they might need the old version to do something. And also, maybe a finer installer than untar is preferred. Installer will tied to certain SDK version and the installation will go under /opt/poky-versionNo.|| 1|| Done || Jessica|| criping|| Enhancement-expect planning process by Jessica to handle this task. Was M2, Sprint E.<br />
|}<br />
<br />
=== Sprint B (closes Jan 07, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || Bitbake multi-threaded parsing|| Bitbake recipe parsing is currently single threaded. I want to make this multithreaded as the speedup would be nice. If I can only take a single task for myself for 1.0, I'm nominating this one as I enjoy this kind of thing and I have ideas on how to do it. || 1|| Done || Richard|| rpurdie|| Enhancement<br />
|-<br />
|| Distribution / components|| Lock in Kernel/Toolchain version|| Locked in 2.6.37 and gcc 4.5.1. Pending decision to move to 4.5.2 and Linaro || || Done || || Richard|| || <br />
|-<br />
|| Distribution / components|| License Update|| For each of the licences we support, I'd really like to have a licences directory with a copy of that license contained within. When it comes to deciding what a given LICENSE field means, this would be the reference. It also means we can include the licences a given image includes with the image. This continues to make our license handling world class and ahead of the field. || 2|| Done || Beth|| rpurdie|| Hygiene<br />
|-<br />
|| Tool Development and SDK Features|| Qemu configuration change|| Provice edit box for advanced user to specify qemu configurations|| 2|| Done || Jessica|| criping|| <br />
|-<br />
|| Tool Development and SDK Features|| Lock down Eclipse+CDT+TCF version|| Will use Eclipse Halo 3.6 || 1|| Done || Jessica|| || <br />
|-<br />
|| Demo|| Finalize on demo plans for v1.0 launch || || 1|| Done || Dave || || <br />
|-<br />
|| Release || Release plans for v1.0 launch || Fill out the M4 plan with the necessary release activities and timings || 1|| Done || Beth || || <br />
|-<br />
|| Poky Features || Basic image creator GUI || Functional UI missing some Advanced features || 1 || In replan || Joshua || || <br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer for SDK Generator Installation functions support||Detailed feature request can be found at: http://bugzilla.pokylinux.org/show_bug.cgi?id=589|| 1|| Done || Jessica|| rpurdie|| Enhancement<br />
|-<br />
|| Kernel || Tracing: trace-cmd python binding cleanup || || 3 || Done || Darren || dvhart ||<br />
|}<br />
<br />
=== Sprint C (closes Jan 14, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || kernel development layer|| The (correct) poky behaviour of building known revisions coupled with the fetcher requiring a BSP branch to already be present means that local modifications (and kernel source tree) are required for kernel development. I already have a layer that overrides/modifies the behaviour when added to the bblayers.conf and configured into an environment. This seems useful for more people to use. || 2|| Done || Bruce|| bruceashfield|| Enhancement, was M2, Sprint C<br />
|-<br />
|| Distribution / components|| Zypper/RPM|| RPM Uprev / Zypper Uprev [lets get to the latest versions]|| 1|| pull request by Jan 19; || Mark/Qing|| || was M2, Sprint C<br />
|-<br />
|| Supported Targets|| Intel Platform Support|| JasperForest|| 2|| Basic support in place; DPDK evaluation in process, overall BSP plan still TBD || Tom|| davest|| Basic ECG support (Moved from Sprint A)<br />
|-<br />
|| Tool Development and SDK Features|| Eclipse poky tree interfacing (git support)|| Use Eclipse git capability to install poky tree from git repo and able to interact with git repo at file level within Poky tree || 2|| Done || Jessica|| jzhang|| Enhancement<br />
<br />
|-<br />
|| Poky Features || Poky Image Creator|| A standalone application you can run which asks you to select a distro and machine, then presents a list of packages you can select. Once the selection is made, it goes off and bakes you an image which is then presented to you. Implementation wise, it should use the sstate packages, be a bitbake UI and use the usual poky bbclass files to do the image construction behind the scenes. || 1|| Re-plan || Joshua|| rpurdie|| Enhancement<br />
|-<br />
|| Validation|| Boottime/Performance Analysis|| Compare Yocto Project performance to other projects such as MeeGo|| 1|| Initial report on where we are by Feb 9 || Darren|| davest|| project commitment <br />
|-<br />
|| Distribution / components|| LSB Sanity|| execute LSB Test and improve passing rate and document failures with clear understanding|| 2|| Done || MarkH/Saul|| sgw|| Hygiene<br />
|-<br />
|| Distribution / components|| Review & Fix Standards Tests|| Review the results from LTP, POSIX and asses the result, fix as appropriate and clearly document failures.|| 2|| a Plan to resolve final items to be sent to the m.l. by Jan 14 || Saul/Kevin || sgw|| Hygiene<br />
|-<br />
|| Tool Development and SDK Features|| Image creator integration with Eclipse || || 2|| replan|| Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Kernel || Tracing: perf trace marker support || This is from feedback to the new trace command. Ingo appears to have this nearly complete already. || 3 || Done || Darren || dvhart ||<br />
|-<br />
|| Kernel || Tracing: perf trace scripting support || || 3 || Move to Sprint D; on track for Jan 21 || Tom || dvhart ||<br />
|-<br />
|| Cleanup || bitbake user experience error handling validation completed || || 2 || Done || Richard || ||<br />
|-<br />
|| Cleanup || variable scrub - ensure all metadata variables are documented || Script with a histogram of variable use done, identified 50 variables to document; Add task for actual documentation update is low on the list || 2 || Done || Scott/Darren || ||<br />
|-<br />
|| Distribution / components|| Zypper/RPM|| Integration based on design from Sprint B|| 1|| On track for Jan28 || Mark/Qing|| sgw|| Functionality, was M2, Sprint E<br />
|-<br />
|| Kernel || Tracing: package kernelshark || || 3 || Done || Darren || dvhart ||<br />
|-<br />
|| Kernel || Tracing: tuna, oscillosope recipes || || 3 || Tom to discuss plan with Darren et al || Tom || dvhart ||<br />
|- <br />
|| BSP || Beagleboard XM Support || || 3 || Move to Sprint D || Darren || dvhart ||<br />
|}<br />
<br />
=== Sprint D (closes Jan 21, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Swabber || Complete review of swabber outputs || Move to M3 Sprint D || 1 || Move to M3 Sprint D || Alex || ||<br />
|-<br />
|| Poky Features || Fetcher Overhaul Phase 2 - API reorg||<br />
* f) Add a generic unpack funciton to __init__.py based on the unpack task in Poky ;<br />
* g) Split go() methods into the following steps: i) download() - do whatever transfer is necessary to get the sources locally ii) build_mirror_data() - generate any data that would be needed to construct a source mirror iii) unpack() - takes a directory as an argument of where to place extracted sources;<br />
The existing go() methods should be replaced with a set of calls to the above sections of functionality as appropriate in the individual fetchers. Some of these categories of function make no sense in certain fetchers, in which case they shouldn't need to implement them. Functions are only executed if the method is present.<br />
* h) Change Poky's unpack to call an unpack method in the fetchers.<br />
* i) Change Poky's fetch task to call a "download" method in the fetcher instead of go().<br />
|| 1|| Will land with phase 3 in Jan 21 || Saul / Ke, RP|| rpurdie|| Enhancement<br />
|-<br />
|| Poky Features || DSO linking changes|| "By the default the gcc linker will automatically link any dependant objects/libraries. ""Inherited"" linkages can cause issues, for example, where a shared object changes its dependencies but a program has come to rely on symbols from an implicitly linked library. Fedora implemented this change in F13, seems like it would be useful to have in Poky too. "|| 2|| On track for Jan 21 || Saul / Nitin || josh|| bug#516<br />
|-<br />
|| Distribution / components|| Distro Audit Documentation Output|| Audit package documentation output || 2|| Move to Sprint D due to libtool work || Saul / ScottG || rpurdie|| Hygiene<br />
|-<br />
|| Poky Features || libtool sysroot option|| libtool 2.4 has a sysroot option. We should try and use it, see how it works and whether we can ditch some of our libtool hacks. || 1|| On track for Jan 21 || Saul / ScottG || rpurdie|| Enhancement<br />
|-<br />
|| Distribution / components|| MACHINE or Recipe specific sysroots|| Each machine should have its own sysroot. We'll probably have to split do_populate_sysroot into a two step process, creation of the package and than installtion of the package, which the installation of the package being made machine specific (put ${MACHINE} into ${STAMP} and bitbake should do that). Also allowing this to work per recipe would be desireable|| 1|| On track 21 || Saul / Dongxiao || rpurdie|| Hygiene<br />
|-<br />
|| Distribution / components|| Toolchain Bootstrap Process|| The toolchain as it bootstraps overwrites files like libc.so and libgcc.so in the sysroot directory which causes issues if you just try and rebuild part of the toolchain. Each step of the bootstrap process should use a separate sysroot. Once this is once, sstate file overwriting detection can be added and enabled. || 1|| Patches submitted for comment, slip to Sprint D || Saul / Dexuan || rpurdie|| Hygiene<br />
|-<br />
|| Documentation Features|| Package report system|| move to public server [setup a package report system in an internal machine. We need push it publicly available. The basic features like search and report have been there. But there're still some enhancements in plan, to make it a fit place to feel Yocto metadata comfortably]|| 2|| Move to Sprint E|| KevinT|| ktian1|| enhancement<br />
|-<br />
|| Distribution / components||Add headers and libraries to qemu images ||Since we'll be using qemu images as target sysroot, need to create a set of qemu images for minimal, sato, LSB that contains target header and libraries.|| 2|| Pending a discussion on Jan 18 || Saul ||jzhang|| Enhancement<br />
|-<br />
|| Distribution / components|| push of all relevant Wind River patchs to Yocto (patch comparison)|| Update any additional patches needed since M2.|| 1|| May be done by Jan 21, pending RPM stuff || Mark|| Mark|| <br />
|-<br />
|| Distribution / components|| mklibs|| mklibs is a tool to optimize size of [e]glibc for a perticular root file system image. It is useful to save disk space on small devices. || 2|| Push to Sprint E || Saul|| Nitin Kamble|| enhancement<br />
|-<br />
|| Poky Features || Performance Enhancement || reduce disk space (hardlink) || 1 || On track for Jan 21, pending RP review || Saul / Qing, Dongxiao || rpurdie || Enhancement<br />
|-<br />
|| BSP || 2.6.37 Crown Bay Support || On Track for Jan 21 || 2 || || Tom || dvhart || <br />
|-<br />
|| BSP || 2.6.37 Emenlow Support || On track for Jan 21 || 2 || || Tom || dvhart || <br />
|}<br />
<br />
=== Sprint E (closes Jan 28, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| rootless X|| rootless x server has better security than x server launched by root. MeeGo already enable this feature. it would be nice for Yocto to also enable it. || 2|| On track for Jan 28 || Saul / Ke || yuke|| enhancement<br />
|-<br />
|| Documentation Features|| Package report system|| finish major feature development and internal review [setup a package report system in an internal machine. We need push it publicly available. The basic features like search and report have been there. But there're still some enhancements in plan, to make it a fit place to feel Yocto metadata comfortably]|| 2|| Move to Sprint E || Jonathan || ktian1|| enhancement, was M2, Sprint E<br />
|-<br />
|| Distribution / components|| perl upgrade|| perl is the most cross un-friendly recipe pending upgrade. || 2|| Slipping due to Linaro layer, moves to end of Sprint E || Nitin|| Nitin Kamble|| enhancement<br />
|-<br />
|| Supported Targets|| Intel Platform Support|| Sandybridge|| 2|| Accept|| Tom|| davest|| Basic ECG support<br />
|-<br />
|| Distribution / components|| performance indicators|| define some indicators (boot time, footprint, build time, power, component benchmarks, etc.) and then collect them for tracking purpose. The result could be posted on the wiki site, and the initial indicators can be easy ones which can be easily retrieved from autobuilder or weekly qa report). This way we have a clear track about the healthy of the Yocto project, and also identify weak areas. We can include qemu targets and several representational boards as the targets. || 2|| Review|| Beth/Jiajun|| ktian1|| enhancement<br />
|-<br />
|| Tool Development and SDK Features|| SDK user workshop|| Have some developers sit down and use our tools to develop demo software for Yocto. || 2|| Review|| Jessica|| josh|| Enhancement<br />
|-<br />
|| Kernel || Final linux-yocto_git.bb || With 2.6.37 kernel || 1 || || Bruce || dvhart ||<br />
|-<br />
|| Kernel || Final meta-linaro layer || || || || Darren || dvhart ||<br />
|-<br />
|| Kernel || Final meta-rt layer || || || || Darren || dvhart ||<br />
|-<br />
|| Kernel || Sandy Bridge || || 1 || || Tom || dvhart ||<br />
|}<br />
<br />
=== Sprint F (closes Feb 03 (THURSDAY), 11:59pm PDT -- pull request sent, initially reviewed) :: NOTE: China New Year Holiday ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Documentation|| ADT Reference Guide Draft out for review || Outline complete|| High|| WIP || Scott Rifenbark|| jzhang|| Documentation<br />
|-<br />
|| || || || || || || || <br />
|}<br />
<br />
== M4 (Feb 07 to Apr 15 -- Stabilize Complete Mar 18, Release Complete Apr 01, Contingency to Apr 15) ==<br />
<br />
This sprint is the [[Yocto Project v. 1.0 Release Cycle]].<br />
<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Documentation|| Migration chapter in the Poky Reference Manual|| This chapter would cover the four identified use-cases for migrating up to the most recent version of Yocto Project. Additionally, it would cover migration scenarios from other development systems. The chapter does not yet exist. The chapter has not been scoped outside of having a meeting that identified four use-cases that did not include migration from a development system outside of Yocto Project. It will take some more scoping time to cover those areas (a day or two). Again, I have no idea of the length. See earlier entries for standard industry writing estimates for software documentation|| Medium|| Not Started|| Scott Rifenbark|| 3-4 Weeks|| Documentation<br />
|-<br />
|| Documentation|| Yocto Project Development Guide|| This manual would be an over-arching document that frames the complete development cycle within Yocto Project. The idea here is that the document would be an umbrella document that spawned and referenced subsequent documents. The organization would be the first chapter overviewing the major development pieces such as recipe creation, building, debugging, publishing, fail-safing, back-door hook creation, etc. Scoping would be about two weeks and length would probably be about 40 pages. Overall development time would likely be a month of uniterruped time.|| Medium|| Not Started|| Scott Rifenbark|| 3 Weeks|| Documentation<br />
|-<br />
|| || Multilib Support|| Consider developing post-1.0 branch || 1|| to start in M4 || Richard|| ||<br />
|-<br />
|| Validation|| Alpha testing complete|| 4-5 internal developers unfamiliar with Yocto Project try to do a build and report on the experience and issues encountered|| 1|| Done by Feb 18 || Julie|| davest|| <br />
|-<br />
|| || || || || || || || <br />
|}<br />
<br />
== Features needed and to be put into sprints by assigned owners: ==<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || package config option enhancement|| there're several enhancements we may do here: * allow users setting specific config options (local or global) from external tool, such as poky image creator, instead of changing recipes manually. Need a mechanism to convert from variable assignments into exact config options (e.g. feature_${PN} = ""1"" -> ""--enable-feature""). Consequently dependency chain needs update with option status. * host contamination check. We have swabber to check host contamination, but I'm not sure whether it covers configuration phase. If not, this is one area to improve, as not ususually we see configure script checks host bits for available features * conditional option manipulation. In many recipes we enable/disable one option based on availability of other packages. Now this is done manually and not flexible. this should be made automatically though some new annotation to indicate condition, or just base_contains (not convenient: long line, need define distro features) || 2|| Review|| Richard/MarkH|| ktian1|| Enhancement<br />
|-<br />
|| Media|| Yocto Project Awareness Video|| This 2.5 minute video would introduce and describe the benefits of Yocto Project. The video would use entertaining animations that described concepts and benefits. The result would be suitable for YouTube, conferences, and the website. The production is called an "Epipheo" and will be created by Epipheo Studios. The engagement process has begun and the kick-off meeting will be soon. The PO is in place. Time for development is 10 weeks.|| High|| Kick-off Imminent|| Scott Rifenbark|| 10 Weeks|| Media<br />
|-<br />
|| Documentation|| Yocto Project Debugging Guide|| This would be a guide for the debugging and bug tracking process in Yocto Project. Originally, the thought was that we needed a Bugzilla User's Manual. However, since we don't own Bugzilla it doesn't make sense to produce documentation for it. Rather, we should document the process as it fits into the Yocto Project environment. Ideally, the manual would be a sub-manual that would be referenced and architected into the Yocto Project Development Guide. The manual has not been scoped and would take a week to scope. Again, I have no idea of the length. See the previous item for standard industry writing estimates for software documenation.|| Medium|| Not Started|| Scott Rifenbark|| 3-4 Weeks|| Documentation<br />
|-<br />
|| Website|| Yocto Project Website|| The 0.9 website is in place but needs updates. Items for consideration are the left-panel naviagation scheme, a contributions guidance page, color-scheming and theme (possibly).|| Medium|| Not Started|| Scott Rifenbark|| 1-2 Weeks|| Website<br />
|}<br />
<br />
== Features not believed to be needed in v1.0: ==<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || OpenEmbedded/Bitbake Upstreaming|| "We firstly need to review where we are and where OE is. We then need to make a plan about what we're going to push upstream and what we're not. I'd suggest when we're in PRC, we do a crash course in ""dealing with OE"" and then many dedicate a block of time (a week) where the distro team comes up with a patch set we then propose and get merged into OE. I'd like to find a couple of interested people to monitor OE more regularly and start a workflow of things between Poky/OE where appropriate. The key thing to remember is we need to keep the architectures compatible. The team is now at the point where I'm happy for them to actually try building OpenEmbedded and not worry about it tainting them! "|| 2|| Review|| || rpurdie|| Process<br />
|-<br />
|| Poky Features || Handle old versions in WORKDIR|| an incremental build directory may finally include many old versions WORKDIRS. It'll be good to have those old versions tracked in the cache, which can then either generate a report or allow selectively cleaning up an specific version WORKDIR. Or else it's difficult to figure it out when people want to keep the whole tmp directory but like to cleanup some old bits when disk usage is under pressure. If it's not easy to do in bitbake, perhaps some separate scripts would be also helpful || 3|| Review|| || ktian1|| Enhancement<br />
|-<br />
|| Poky Features || run bitbake w/o rebuilding the cache|| "sometimes it's useful to allow run bitbake w/o re-parsing recipes, if we know nothing metadata is changed. we can just allow reusing existing persistent cache. this is useful when people is debugging WORKDIR w/o metadata change. also sometimes ""bitbake -e"" is used frequently to check poky variable information. with existing cache, several seconds can be saved which are not negligible for a developer daily working on Yocto "|| 2|| Review|| || ktian1|| Enhancement<br />
|-<br />
|| Poky Features || parallel make improvement|| parallel make experience is not good, especially when bb threads and make threads are increased larger than 8. So far we either try to fix package makefile or mark the recipe as no parallel make, when build faiures are reported. But this greatly impacts user experience for a successfully continuous build process. Could we define a safe number we do want to support for 1.0 release? and then have our autobuilder, QA test, and developers cover that number immediately and fix any issues accordingly. Then the safe number can be suggested to the Yocto user || 2|| Review|| || ktian1|| Enhancement<br />
|-<br />
|| Poky Features || Dependency packages rebuild/clean|| It is a mechanism to rebulid or clean a package and all other packages which have build/runtime dependency on it. With this change, we can find potential influences of package upgrade to its related packages, which can make the incremental build more trustable. For example, if we upgrade a package to a new vesion which changes its API, this mechanism can easily find out the incompatibility to other packages which have dependency on it. || 2|| Review|| || dongxiao.xu|| Enhancement, replaced by checksum feature<br />
|-<br />
|| Distribution / components|| FOSSology|| This may be similar to License Update above, but start to use FOSSology to track licenses. || 2|| Review|| || sgw|| Hygiene<br />
|-<br />
|| Distribution / components|| Package Developer Tools|| Create a set of Init scripts template and then review our current init scripts and modify them to confirm to the template. || 2|| Review|| || sgw|| Easy of Use<br />
|-<br />
|| Distribution / components|| Package Website|| Complete the work the intern has started on generating the distro tracking information and get it out on the external site. || 2|| Review|| || sgw|| "Hygiene, duplicate of ""Package report system"""<br />
|-<br />
|| Distribution / components|| Bluetooth UI support|| Currently we have bluez package in poky, and we need to have a workable graphic user interface to connect/configure BT devices. One choice may be gnome-bluetooth-applet. || 3|| Review|| || dongxiao.xu|| enhancement<br />
|-<br />
|| Distribution / components|| Connman-gnome enhancement features|| Enable connman-gnome to support features like, WPA Enterprise connection, hidden SSID, etc. || 3|| Review|| || dongxiao.xu|| enhancement<br />
|-<br />
|| Distribution / components|| Java Running Environment support|| Since most embedded systems support java applications running in it, maybe we'd better consider supporting some kinds of JVMs(Embeded JVM). The JVM may not run by default, but user can launch it if running java applications. Compared with GTK/QT, java user number is not small too. || 3|| Review|| || criping|| enhancement<br />
|-<br />
|| Distribution / components|| create more use cases|| UPnP demo is one really good use case showing how Yocto is utilized to make real functionality. and we could create more to show how Yocto is easily adapted to real use cases. Those use cases can be either maintained as seperate demo layers in yocto repo, or in seperate branches for reference. We can also call for community's contribution on this which would make 1.0 full-fledged. Or else the newbies to Yocto may be in puzzle how our sample profiles can satisfy their requirements. || 2|| Review|| || ktian1|| enhancement<br />
|-<br />
|| Distribution / components|| i18n support || internationalization is an important system wide feature. Many component like font, locale affect the i18n. Yocto alreay has some i18n related package like pango, but so far did not consider i18n systematically. so this is place holder to systematically add i18n support. || 2|| Review|| || yuke/qing|| enhancement<br />
|-<br />
|| Distribution / components|| more demos || demos are a good way to educate, push the envelope, and at the same time tout the strengths of the platform. This item just records a current set of ideas from various sources which could/should be implemented: * face-recognition/face-finding, * robotic control/application of face-finding to 'camera-as-sensor' (hexbug demo), * others [tbd, add here]|| 2|| Review|| || tzanussi|| enhancement <br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer support for image-creator and needed yocto-metadata design||Come up design what need to be created as packages to support using "opkg install" for image-creator and needed yocto-metadata|| 2|| WIP, pending comments from RP regarding how to packaging metadata|| Jessica|| rpurdie|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer image-creator and needed poky-metadata support|| The poky build system will build packages for image-creator and needed poky-metadata, which the Yocto Installer will be able to use "opkg install" to install them|| 2|| Review|| Jessica|| rpurdie|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Provide qemu management UI|| In current eclipse plugin, QEMU settings are put together with project configuration. So we can only have limited settings. If we can have a separate QEMU management UI, the end user could firstly create a QEMU config, such as (env file of arch, image location, unfs or not, sato or lsb, mem size, disk size). And then he can launch a QEMU with a specific config. The dependency between project configuration and QEMU config will be resolved. After all QEMU has nothing to do project configuration. Need to careful review the UI to ensure minimal impact to testing matrix. || 3|| Review|| || criping|| "Enhancement, duplicate of ""Qemu mem/disk size can be adjusted"""<br />
|-<br />
|| Tool Development and SDK Features|| QT plugin For Eclipse|| Integrate QT Ecplise plugin and extend for Yocto Project || 3|| Review|| || jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Profiling/Trace GUI's|| We have a wealth of great tracing and profiling tools but the UI's for them are all extremely minimal and usually quite ugly. Would be great if we could compete with, or even better, Apple's offerings here. We have the technology! || 2|| Review|| || josh|| "Enhancement, duplicate of ""Tracing/Profiling Planning Complete"""<br />
|-<br />
|| Tool Development and SDK Features|| Other profiling tools|| Complete Tom's review of profiling tools and architecture || 2|| Review|| || josh|| "Enhancement, duplicate of ""Tracing/Profiling Planning Complete"""<br />
|-<br />
|| Tool Development and SDK Features|| Design next-gen tracing/profiling tools|| Yocto 1.0 will include all the essential existing tracing/profiling tools expected by users, and Josh has proposed a UI integration of all those tools as far as it's possible to do so. That level of integration, basically a 'plugin-level' integration is necessary and useful, but doesn't go far enough. A next-generation tracing tool would integrate at a much more fundamental level; if done properly, it would provide unmatched levels of power and usability to users, and would allow Yocto to distinguish itself in the embedded tracing/profiling space in a way also unmatched by any other distro/build-tool. The implementation would of course not be available for Yocto 1.0, but a coherent design, including prototypes, that could be taken to the community and implemented in a V 1.5 or 2.0 should be done in that time frame. || 1|| Review|| || tzanussi|| "Enhancement, duplicate of ""Tracing/Profiling Planning Complete"""<br />
|-<br />
|| Documentation Features|| Self Documentation of image contents|| "I'd like to see the -doc packages Poky builds being combined into some kind of large documentation index representing the collective API docs of the target being built. This can then be placed on a webserver and viewed over the web. We'd have a demonstration of this for a ""bitbake world"" target. Part of the idea here is to start making good use of the docs as if developers see this they might start writing better docs too. Aim is to lead the field :). There are a number of places poky packages disable doc generation due to missing tools so we'd need to add these so we can enable the doc generation. Many packages already have many docs though too. "|| 2|| Review|| || rpurdie|| enhancement<br />
|-<br />
|| Validation|| Testing Framework|| Add a framework for doing automated testing in the project|| 1|| Review|| || davest|| project commitment<br />
|-<br />
|| Validation|| more SDK builds on autobuilder|| enable more SDK related tests on autobuilder such as meta-ide-support, etc.|| 2|| Review|| || ktian1|| project commitment, addressed by test plan (?)<br />
|-<br />
|| Validation|| more people should try using SDK|| this may not be a feature, but a requirement. SDK including meta-toolchain is one key factor impacting user experience on Yocto. It's not enough to have only SDK team play with it|| 2|| Review|| || ktian1|| project commitment, addressed by test plan (?)<br />
|-<br />
|| Validation|| Unit Testing Framework|| Add a mechanism to bitbake to parse source packages that have unit tests and then execute them on the target|| 3|| Review|| || sgw|| "project commitment, duplicate of ""Testing Framework"""<br />
|-<br />
|| Validation|| Test Case open source|| Open source Yocto test cases with xml format|| 1|| Review|| || yyou|| "project commitment, duplicate of ""Testing Framework"""<br />
|}</div>Davesthttps://wiki.yoctoproject.org/wiki/index.php?title=Yocto_1.0_Schedule&diff=584Yocto 1.0 Schedule2011-01-25T01:27:28Z<p>Davest: /* Sprint D (closes Jan 21, 11:59pm PDT -- pull request sent, initially reviewed) */</p>
<hr />
<div>= v1.0 (release date: Apr 15, 2011) =<br />
----<br />
The detailed milestone map for v1.0 is as below. During the first week of each subsequent milestone past M1 we will have a demonstration of the previous milestone capabilities as well as a planning and design session for the current milestone.<br><br><br />
<br />
== M2 (Nov 08 to Dec 24 -- Dev Complete Dec 10, Stabilize Complete Dec 17, Release Complete Dec 24) ==<br />
=== Sprint A (closes Nov 12, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links''' <br />
|-<br />
|| Poky Features || Kernel interactive targets || To support incremental kernel development having the ability to run menuconfig (or xconfig, etc) directly is a common request. We'll need to add this for commercialization anyway. i.e. bitbake -c menuconfig. This fuctionality already exists. || 1 || Done || Richard || bruceashfield || Enhancement <br />
|-<br />
|| Distribution / components || Distro Audit: Upgrades Planned (Phase 1) || Complete plan for package upgrades in M2 || 1 || Done || Saul || || Continual Maintenance<br />
|-<br />
|| Validation || Runtime testing || Runtime testing of images as part of the autobuilder || 1 || Done || Jiajun/ScottG || rpurdie || project commitment<br />
|- <br />
|| || Poky Image Creator Wireframe/Interaction Plans Complete || || 1 || Done || Josh || ||<br />
|-<br />
|| || SDK Generator Interaction: Plans Complete || || 1 || Done || Jessica || ||<br />
|-<br />
|| || Tracing/Profiling Planning Complete || This needs to cover where we're at now, what we're missing and also propose the future enhancements that may be needed. M2 targets getting existing tools integrated and documented. F2f discussion n the future enhancements || || Done || Tom || ||<br />
|-<br />
|| || Swabber. (Still needs to be integrated into weekly build by default) || || 1 || Done || Josh || ||<br />
|-<br />
|| Build/Release || Release process documentation || || || Done || Beth || ||<br />
|-<br />
|| Validation || Test plan for v1.0 (to address any deficiencies in coverage from v0.9)|| || 1 || Done || Jiajun || ||<br />
|}<br />
<br />
=== Sprint B (closes Nov 19, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| Distro Audit: World Packages|| Audit world packages making sure it all build, making sure all are packages are required || 2|| Done || Saul|| sgw|| Hygiene<br />
|-<br />
|| Tool Development and SDK Features|| SDK Generator Installer UI|| Look at different ways of Installer UI (GTK+ and ncurses) seems none of them is the right choice, decide to go with script to implement all the functionalities of installer and later add UI part on top of it || 1||Done|| Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Customize sysroot setup || Add and test out "--sysroot" config option to cross compiler within Eclipse IDE || 1|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| SDK Generator Installer design revision|| Close all open questions regarding Yocto SDK Generator Installer function design and come up HLD || 1|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Distribution / components|| kernel version|| keeping 2.6.34 as a -stable kernel is the best option. I've also got a newer -devel tree that can be made available or made the default. || 3|| Done || Bruce|| bruceashfield|| enhancement<br />
|-<br />
|| || assign Yocto Project PM|| acquire and assign a program manager for Yocto Project|| || Done || DaveST|| || <br />
|-<br />
|| || assign Yocto Project Sys Admin|| || || Done || Saul|| || <br />
|-<br />
|| Tool Development and SDK Features|| oprofileUI|| Fixing various bugs of the oprofileUI to make it workable on big endian host.(i.e. ppc, mips) || 2 || Done || Jessica || lianhao.lu || Bug #382 / Bug #493<br />
|-<br />
|| Poky Feature|| SDK Version Control|| If we can expect that yocto SDK has lots of release in the future, we might need to consider SDK version control. Currently, every thing installed under /opt/poky which leads to things be overriden, we need to be able to use a scheme like /opt/poky-1.0, /opt/poky-2.0 to distiguish things. || 2|| Done || Josh|| jzhang|| Enhancement<br />
|-<br />
|| Kernel || Kernel plan complete || Flesh our kernel deliverables and add to Yocto 1.0 schedule || || Done|| Darren || dvhart ||<br />
|}<br />
<br />
=== Sprint C (closes Nov 26, 11:59pm PDT -- pull request sent, initially reviewed) :: NOTE: this is US Thanksgiving week ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| Distro Audit: Licence Checksums|| licence checksums || 1|| Done || Saul|| rpurdie|| Hygiene<br />
|-<br />
|| Poky Features || Performance Analysis Completed|| "I'd like someone to instrument a green release build, see where it spends time (hot/cold parsing time, individual task building time) and then compare this with our 0.9 release build. I'd also like to compare the disk usage between the two. Once we have a blame list we can then set about fixing it. Some things I know will come up: a) pseudo, b) checksums/signature code, c) exec() vs fork for executing tasks, d) task based prebuilds increasing disk usage, e) rpm dependency calculations, f) using rpm vs. ipk but I may be wrong and there may be others. We need numbers. "|| 1|| Done || Saul / Qing, Dongxiao|| rpurdie|| Enhancement<br />
|-<br />
|| Poky Features || environment variables for kernel builds|| switching a branch, or adding a configuration feature (and even changing the kernel repo) is often done during development of a BSP. Having some additional variables that are pass the bitbake environment scrub would be useful. i.e. KBRANCH=foo bitbake -c configure linux-yocto. This goes along with the other BSP bootstrapping suggestions. || 2|| Done || Bruce|| bruceashfield|| Enhancement<br />
|-<br />
|| Supported Targets|| ARM Platform Support|| Replace beagleboard with Beagleboard XM - decision || 2|| Done || Bruce|| alex|| Basic Yocto hardware support <br />
|-<br />
|| Distribution / components|| Security Process|| We need a dedicated person to scan and apply critical security updates to the distro. The MeeGo team already has a similar process with some scripts which may be leveraged. To complete the task, the process should be documented and a first pass over the metadata made to establish the current position on security. Any upgrades needed should be identified and a plan to address them should be in place but doesn't have to be implemented by this point.|| 1|| Done || ScottG|| ktian1|| enhancement<br />
|-<br />
|| Tool Development and SDK Features|| SDK Generator Installer Opkg repo design|| Come up a opkg repo design that will mimic the final Yocto package repo layout to be used by SDK Generator Installer to test against|| 2 || Done || Jessica || jzhang || <br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer tar creaion|| Create a Yocto Installer tar ball which contains Installer script and supported opkg component that will be used for installing other Yocto components|| 2 || Done || Jessica || jzhang || <br />
|-<br />
|| Documentation|| Kernel Framework Paper from WR|| The paper from WR needs to be re-written and then posted somewhere on the Yocto Project site. This will involve examiniation of the text and re-writing and formatting for presentation. Currently it is simply a text document. Completion time assuming uninterrupted time is one week.|| High|| Done || Scott Rifenbark|| 1 Week|| Documentation<br />
|-<br />
|| Documentation|| Poky Reference Manual|| This guide exists in the 0.9 form. The re-write of the text needs to be completed. So far, all the chapters have been rewritten but not re-posted on the site. Only the appendices remain for a text scrub. Time to complete this would be a week of uninterrupted time. Ideally, the manual would be a sub-manual that would be referenced and architected into the Yocto Project Development Guide.|| Medium|| Done|| Scott Rifenbark|| 1 Week|| Documentation<br />
|-<br />
|| Kernel || Initial meta-linaro layer || meta-linaro layer providing a kernel, tool-chain, and uboot loader. This deliverable is primarily to get the infrastructure in place and have a buildable kernel. Toolchain on best effort basis. || || Done || Darren || dvhart || Moderate risk of slippage due to holidays.<br />
|-<br />
|| Kernel || Tracing: blktrace and sysprof recipes || || || Done || Tom || dvhart ||<br />
|}<br />
<br />
=== Sprint D (closes Dec 3, 11:59pm PDT -- pull request sent, initially reviewed) :: NOTE: week of the F2F planning meeting ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Kernel || Kernel git branching structure revamped || || 1 || Done || Bruce || dvhart ||<br />
|-<br />
|| Kernel || Tunnel Creek (Crown Bay) || || 1 || Done || Tom || dvhart ||<br />
|}<br />
<br />
=== Sprint E (closes Dec 9 (THURSDAY), 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| Distro Audit: Upgrades Completed (Phase 1)|| Update to new versions as per the agreed plan for M2 from Sprint A|| 1|| Done || Saul|| rpurdie|| Continual Maintenance<br />
|-<br />
|| Distribution / components|| Distro Audit: Src Checksums|| Make sure all SRC_URI components have checksums too || 1|| Done || Saul|| rpurdie|| Hygiene<br />
|-<br />
|| Poky Features || enable KVM with qemu|| today all new Intel processors support VT, which are enabled on most desktop machines which are most frequently used build machine. with VT support, x86/x86-64 qemu target runs faster which is a good thing for emulation environment. This may require some qemu option tweaks and also poky-qemu script enhancement. || 2|| Done || Saul / Edwin|| ktian1|| Enhancement<br />
|-<br />
|| Kernel || New kernel recipes || dev, -devel, -custom || 3 || Done || Bruce || dvhart ||<br />
|-<br />
|| Swabber || Documentation for swabber || || 1 || Done || Alex || ||<br />
|-<br />
|| CCB || Defect triage process in public documented and implemented || || 1 || Done. Triage process is documented, out for review. || Saul || ||<br />
|}<br />
<br />
== M3 (Dec 20 to Feb 08 -- Dev Complete Feb 04, Stabilize Complete Feb 11, Release Complete Feb 18) ==<br />
=== Sprint A (closes Dec 24, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Kernel || Initial meta-rt layer || PREEMPT_RT kernel and related test-cases and benchmarks || 2 || Done by Jan 21 || Darren || dvhart || slipped out from M2<br />
|-<br />
|| Poky Features || Fetcher Overhaul Phase 1 - SRC_REV enhancement||<br />
* a) Add code in FetchData::__init__() which will check if the selected fetcher supports srcrev and the automatically call a function to set the src rev value instead of each fetcher doing this.\n <br />
* e) Break SRCREVINACTION deadlock. To do this, we need to start using a keyword for automatically increasing SRCREV, e.g. SRCREV = "AUTOINC". The actual revision can be injected into PV using SRCPV. If we do this there should no longer be a need of the deadlock; <br />
* k) Ensure that we only set __BB_DONT_CACHE when SRCREV = "AUTOREV". This may need a new method call for fetchers to tell whether they're "floating" or locked down.<br />
|| 1|| Done || Saul / Ke, RP|| rpurdie|| Enhancement, slipped out from M2<br />
|-<br />
|| Distribution / components|| Distro Audit Upgrades Planned (Phase 2)|| Complete plan for package upgrades in M2|| 1|| Done || Saul|| || Continual Maintenance<br />
|-<br />
|| Poky Features || Pseudo Performance || Implement the changes to bitbake based on pseudo's enable/disable switch|| 1|| done || Saul / Qing, Dongxiao || rpurdie|| Enhancement, slipped from M2 due to risk and not having Pseudo's change yet.<br />
|-<br />
|| Tool Development and SDK Features|| Fix the issue user target sysroot is owned by root || The ADT installer will use pseudo to extract user target sysroot which ended up owned by root, this need to be fixed || 1|| done || Jessica|| jzhang|| Cleanup <br />
|-<br />
|| Tool Development and SDK Features|| Eclipse poky tree interfacing (metadata file editor)|| Provide a metadata file editor with some syntax checking and keywords highlight capabilities|| 2|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| IDE Project templates|| Templates for various project types: Clutter GUI, Gtk+ GUI, to help developers get started quickly || 2|| Done || Jessica|| josh|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| push TCF/RSE patches upstream|| work with community to finish up our TCF terminal service, TCF/RSE integration remaining patches taken by upstream. Blocking issues including Eclipse Bug #327865 || 1|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Pseudo || Pseudo enhancement to enable on/off switch || || 1 || done || Mark || ||<br />
|-<br />
|| Pseudo || Bitbake enhancement for pseudo on/off switch || || 1 || done || Richard || ||<br />
|-<br />
|| bugzilla || Complete restructure of bugzilla categories || || 1 || done || Saul || ||<br />
|-<br />
|| Poky Features || Image creator ground work || Nomenclature determined, existing gui's bug fixed and backend work implemented || 1 || Done || Joshua || ||<br />
|-<br />
|| Kernel || Tracing: Initial SystemTap recipe || Works on x86 || 3 || Done || Tom || dvhart ||<br />
|-<br />
|| Distribution / components|| Distro Audit: Package Description/Summary completed|| Ensure DESCRIPTION/SUMMARY fields are all audited|| 2|| Done || Mark|| Mark|| Hygiene, was M2, Sprint B but missed window<br />
|-<br />
|| Distribution / components|| Zypper/RPM|| Small write-up of the problems we're having w/ Zypper and what we plan to do. (i.e. create a roadmap/design) - Includes rootfs generation - Package uprev/install/removal || 1 || Done || Mark/Qing || || was M2, Sprint B<br />
|-<br />
|| Distribution / components|| Distro Audit: Licence Checksums|| Make the licence checksums fatal if not present || 1|| Done || Saul|| rpurdie|| Hygiene, was M2, Sprint C<br />
|-<br />
|| Distribution / components|| push of all relevant Wind River patchs to Yocto (patch comparison)|| Ensure patches present to packages in WRS are also in Poky|| 1|| Done || Mark|| Mark|| was M2, Sprint C<br />
|-<br />
|| Poky Features || Performance Enhancement Completed || Initial changes to reduce disk space (sstate-build-*) || 1|| Done || Saul / Qing, Dongxiao || rpurdie|| Enhancement, was M2, Sprint E<br />
|-<br />
|| Distribution / components|| User specified qemu config support|| We'll provide user an edit box which allows advanced qemu user to specify arbitrary qemu configuration to meet their needs, which the poky-qemu scrip will just append the config list towards the end of the list of parameters to bring up qemu, it also expect the poky-qemu script to do some basic sanity check on the user specifications to catch the obvious mistake || 2|| Done || Saul / criping || criping|| enhancement, was M2, Sprint E<br />
|-<br />
|| Tool Development and SDK Features|| SDK Version Control support in SDK generator installer|| If we can expect that yocto SDK has lots of release in the future, we might need to consider SDK version control. Currently, if we un-tar the sdk, it will override the older version. It's not good for app developers since they might need the old version to do something. And also, maybe a finer installer than untar is preferred. Installer will tied to certain SDK version and the installation will go under /opt/poky-versionNo.|| 1|| Done || Jessica|| criping|| Enhancement-expect planning process by Jessica to handle this task. Was M2, Sprint E.<br />
|}<br />
<br />
=== Sprint B (closes Jan 07, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || Bitbake multi-threaded parsing|| Bitbake recipe parsing is currently single threaded. I want to make this multithreaded as the speedup would be nice. If I can only take a single task for myself for 1.0, I'm nominating this one as I enjoy this kind of thing and I have ideas on how to do it. || 1|| Done || Richard|| rpurdie|| Enhancement<br />
|-<br />
|| Distribution / components|| Lock in Kernel/Toolchain version|| Locked in 2.6.37 and gcc 4.5.1. Pending decision to move to 4.5.2 and Linaro || || Done || || Richard|| || <br />
|-<br />
|| Distribution / components|| License Update|| For each of the licences we support, I'd really like to have a licences directory with a copy of that license contained within. When it comes to deciding what a given LICENSE field means, this would be the reference. It also means we can include the licences a given image includes with the image. This continues to make our license handling world class and ahead of the field. || 2|| Done || Beth|| rpurdie|| Hygiene<br />
|-<br />
|| Tool Development and SDK Features|| Qemu configuration change|| Provice edit box for advanced user to specify qemu configurations|| 2|| Done || Jessica|| criping|| <br />
|-<br />
|| Tool Development and SDK Features|| Lock down Eclipse+CDT+TCF version|| Will use Eclipse Halo 3.6 || 1|| Done || Jessica|| || <br />
|-<br />
|| Demo|| Finalize on demo plans for v1.0 launch || || 1|| Done || Dave || || <br />
|-<br />
|| Release || Release plans for v1.0 launch || Fill out the M4 plan with the necessary release activities and timings || 1|| Done || Beth || || <br />
|-<br />
|| Poky Features || Basic image creator GUI || Functional UI missing some Advanced features || 1 || In replan || Joshua || || <br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer for SDK Generator Installation functions support||Detailed feature request can be found at: http://bugzilla.pokylinux.org/show_bug.cgi?id=589|| 1|| Done || Jessica|| rpurdie|| Enhancement<br />
|-<br />
|| Kernel || Tracing: trace-cmd python binding cleanup || || 3 || Done || Darren || dvhart ||<br />
|}<br />
<br />
=== Sprint C (closes Jan 14, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || kernel development layer|| The (correct) poky behaviour of building known revisions coupled with the fetcher requiring a BSP branch to already be present means that local modifications (and kernel source tree) are required for kernel development. I already have a layer that overrides/modifies the behaviour when added to the bblayers.conf and configured into an environment. This seems useful for more people to use. || 2|| Done || Bruce|| bruceashfield|| Enhancement, was M2, Sprint C<br />
|-<br />
|| Distribution / components|| Zypper/RPM|| RPM Uprev / Zypper Uprev [lets get to the latest versions]|| 1|| pull request by Jan 19; || Mark/Qing|| || was M2, Sprint C<br />
|-<br />
|| Supported Targets|| Intel Platform Support|| JasperForest|| 2|| Basic support in place; DPDK evaluation in process, overall BSP plan still TBD || Tom|| davest|| Basic ECG support (Moved from Sprint A)<br />
|-<br />
|| Tool Development and SDK Features|| Eclipse poky tree interfacing (git support)|| Use Eclipse git capability to install poky tree from git repo and able to interact with git repo at file level within Poky tree || 2|| Done || Jessica|| jzhang|| Enhancement<br />
<br />
|-<br />
|| Poky Features || Poky Image Creator|| A standalone application you can run which asks you to select a distro and machine, then presents a list of packages you can select. Once the selection is made, it goes off and bakes you an image which is then presented to you. Implementation wise, it should use the sstate packages, be a bitbake UI and use the usual poky bbclass files to do the image construction behind the scenes. || 1|| Re-plan || Joshua|| rpurdie|| Enhancement<br />
|-<br />
|| Poky Features || Fetcher Overhaul Phase 3 - git enhancement||<br />
* j) Optimize git fetcher for the new layout so for a git checkout, we clone the repository in download(), then unpack just does a clone with references to the original repo. <br />
* k) Ensure that we only set __BB_DONT_CACHE when SRCREV = "AUTOREV". This may need a new method call for fetchers to tell whether they're "floating" or locked down. <br />
* l) Add a new "BB_NO_NETWORK" variable which the fetchers check before peforming an operation which hits anything remote. This means adding in error messages about why network access is needed at various points (e.g. SRCREV = "AUTOREV" for a given recipe) <br />
* m) Add multiple branch/srcrev support for git fetcher. These would be of the form: git://somelocation/somerepo.git;name=ref1;branch=foo;name=ref2;branch=bar SRCREV_ref1 = "hash1" SRCREV_ref2 = "hash2" which would ensure both hash1 and hash2 were in the final repo. <br />
* n) Change git fetcher to default to git protocol instead of rsync<br />
|| 1|| Slipped to Sprint D || Saul / Ke, RP|| rpurdie|| Enhancement<br />
|-<br />
|| Validation|| Boottime/Performance Analysis|| Compare Yocto Project performance to other projects such as MeeGo|| 1|| Initial report on where we are by Feb 9 || Darren|| davest|| project commitment <br />
|-<br />
|| Distribution / components|| LSB Sanity|| execute LSB Test and improve passing rate and document failures with clear understanding|| 2|| Done || MarkH/Saul|| sgw|| Hygiene<br />
|-<br />
|| Distribution / components|| Review & Fix Standards Tests|| Review the results from LTP, POSIX and asses the result, fix as appropriate and clearly document failures.|| 2|| a Plan to resolve final items to be sent to the m.l. by Jan 14 || Saul/Kevin || sgw|| Hygiene<br />
|-<br />
|| Tool Development and SDK Features|| Image creator integration with Eclipse || || 2|| replan|| Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Kernel || Tracing: perf trace marker support || This is from feedback to the new trace command. Ingo appears to have this nearly complete already. || 3 || Done || Darren || dvhart ||<br />
|-<br />
|| Kernel || Tracing: perf trace scripting support || || 3 || Move to Sprint D; on track for Jan 21 || Tom || dvhart ||<br />
|-<br />
|| Cleanup || bitbake user experience error handling validation completed || || 2 || Done || Richard || ||<br />
|-<br />
|| Cleanup || variable scrub - ensure all metadata variables are documented || Script with a histogram of variable use done, identified 50 variables to document; Add task for actual documentation update is low on the list || 2 || Done || Scott/Darren || ||<br />
|-<br />
|| Distribution / components|| Zypper/RPM|| Integration based on design from Sprint B|| 1|| On track for Jan28 || Mark/Qing|| sgw|| Functionality, was M2, Sprint E<br />
|-<br />
|| Kernel || Tracing: package kernelshark || || 3 || Done || Darren || dvhart ||<br />
|-<br />
|| Kernel || Tracing: tuna, oscillosope recipes || || 3 || Tom to discuss plan with Darren et al || Tom || dvhart ||<br />
|- <br />
|| BSP || Beagleboard XM Support || || 3 || Move to Sprint D || Darren || dvhart ||<br />
|}<br />
<br />
=== Sprint D (closes Jan 21, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Swabber || Complete review of swabber outputs || Move to M3 Sprint D || 1 || Move to M3 Sprint D || Alex || ||<br />
|-<br />
|| Poky Features || Fetcher Overhaul Phase 2 - API reorg||<br />
* f) Add a generic unpack funciton to __init__.py based on the unpack task in Poky ;<br />
* g) Split go() methods into the following steps: i) download() - do whatever transfer is necessary to get the sources locally ii) build_mirror_data() - generate any data that would be needed to construct a source mirror iii) unpack() - takes a directory as an argument of where to place extracted sources;<br />
The existing go() methods should be replaced with a set of calls to the above sections of functionality as appropriate in the individual fetchers. Some of these categories of function make no sense in certain fetchers, in which case they shouldn't need to implement them. Functions are only executed if the method is present.<br />
* h) Change Poky's unpack to call an unpack method in the fetchers.<br />
* i) Change Poky's fetch task to call a "download" method in the fetcher instead of go().<br />
|| 1|| Will land with phase 3 in Jan 21 || Saul / Ke, RP|| rpurdie|| Enhancement<br />
|-<br />
|| Poky Features || DSO linking changes|| "By the default the gcc linker will automatically link any dependant objects/libraries. ""Inherited"" linkages can cause issues, for example, where a shared object changes its dependencies but a program has come to rely on symbols from an implicitly linked library. Fedora implemented this change in F13, seems like it would be useful to have in Poky too. "|| 2|| On track for Jan 21 || Saul / Nitin || josh|| bug#516<br />
|-<br />
|| Distribution / components|| Distro Audit Documentation Output|| Audit package documentation output || 2|| Move to Sprint D due to libtool work || Saul / ScottG || rpurdie|| Hygiene<br />
|-<br />
|| Poky Features || libtool sysroot option|| libtool 2.4 has a sysroot option. We should try and use it, see how it works and whether we can ditch some of our libtool hacks. || 1|| On track for Jan 21 || Saul / ScottG || rpurdie|| Enhancement<br />
|-<br />
|| Distribution / components|| MACHINE or Recipe specific sysroots|| Each machine should have its own sysroot. We'll probably have to split do_populate_sysroot into a two step process, creation of the package and than installtion of the package, which the installation of the package being made machine specific (put ${MACHINE} into ${STAMP} and bitbake should do that). Also allowing this to work per recipe would be desireable|| 1|| On track 21 || Saul / Dongxiao || rpurdie|| Hygiene<br />
|-<br />
|| Distribution / components|| Toolchain Bootstrap Process|| The toolchain as it bootstraps overwrites files like libc.so and libgcc.so in the sysroot directory which causes issues if you just try and rebuild part of the toolchain. Each step of the bootstrap process should use a separate sysroot. Once this is once, sstate file overwriting detection can be added and enabled. || 1|| Patches submitted for comment, slip to Sprint D || Saul / Dexuan || rpurdie|| Hygiene<br />
|-<br />
|| Documentation Features|| Package report system|| move to public server [setup a package report system in an internal machine. We need push it publicly available. The basic features like search and report have been there. But there're still some enhancements in plan, to make it a fit place to feel Yocto metadata comfortably]|| 2|| Move to Sprint E|| KevinT|| ktian1|| enhancement<br />
|-<br />
|| Distribution / components||Add headers and libraries to qemu images ||Since we'll be using qemu images as target sysroot, need to create a set of qemu images for minimal, sato, LSB that contains target header and libraries.|| 2|| Pending a discussion on Jan 18 || Saul ||jzhang|| Enhancement<br />
|-<br />
|| Distribution / components|| push of all relevant Wind River patchs to Yocto (patch comparison)|| Update any additional patches needed since M2.|| 1|| May be done by Jan 21, pending RPM stuff || Mark|| Mark|| <br />
|-<br />
|| Distribution / components|| mklibs|| mklibs is a tool to optimize size of [e]glibc for a perticular root file system image. It is useful to save disk space on small devices. || 2|| Push to Sprint E || Saul|| Nitin Kamble|| enhancement<br />
|-<br />
|| Poky Features || Performance Enhancement || reduce disk space (hardlink) || 1 || On track for Jan 21, pending RP review || Saul / Qing, Dongxiao || rpurdie || Enhancement<br />
|-<br />
|| BSP || 2.6.37 Crown Bay Support || On Track for Jan 21 || 2 || || Tom || dvhart || <br />
|-<br />
|| BSP || 2.6.37 Emenlow Support || On track for Jan 21 || 2 || || Tom || dvhart || <br />
|}<br />
<br />
=== Sprint E (closes Jan 28, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| rootless X|| rootless x server has better security than x server launched by root. MeeGo already enable this feature. it would be nice for Yocto to also enable it. || 2|| On track for Jan 28 || Saul / Ke || yuke|| enhancement<br />
|-<br />
|| Documentation Features|| Package report system|| finish major feature development and internal review [setup a package report system in an internal machine. We need push it publicly available. The basic features like search and report have been there. But there're still some enhancements in plan, to make it a fit place to feel Yocto metadata comfortably]|| 2|| Move to Sprint E || Jonathan || ktian1|| enhancement, was M2, Sprint E<br />
|-<br />
|| Distribution / components|| perl upgrade|| perl is the most cross un-friendly recipe pending upgrade. || 2|| Slipping due to Linaro layer, moves to end of Sprint E || Nitin|| Nitin Kamble|| enhancement<br />
|-<br />
|| Supported Targets|| Intel Platform Support|| Sandybridge|| 2|| Accept|| Tom|| davest|| Basic ECG support<br />
|-<br />
|| Distribution / components|| performance indicators|| define some indicators (boot time, footprint, build time, power, component benchmarks, etc.) and then collect them for tracking purpose. The result could be posted on the wiki site, and the initial indicators can be easy ones which can be easily retrieved from autobuilder or weekly qa report). This way we have a clear track about the healthy of the Yocto project, and also identify weak areas. We can include qemu targets and several representational boards as the targets. || 2|| Review|| Beth/Jiajun|| ktian1|| enhancement<br />
|-<br />
|| Tool Development and SDK Features|| SDK user workshop|| Have some developers sit down and use our tools to develop demo software for Yocto. || 2|| Review|| Jessica|| josh|| Enhancement<br />
|-<br />
|| Kernel || Final linux-yocto_git.bb || With 2.6.37 kernel || 1 || || Bruce || dvhart ||<br />
|-<br />
|| Kernel || Final meta-linaro layer || || || || Darren || dvhart ||<br />
|-<br />
|| Kernel || Final meta-rt layer || || || || Darren || dvhart ||<br />
|-<br />
|| Kernel || Sandy Bridge || || 1 || || Tom || dvhart ||<br />
|}<br />
<br />
=== Sprint F (closes Feb 03 (THURSDAY), 11:59pm PDT -- pull request sent, initially reviewed) :: NOTE: China New Year Holiday ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Documentation|| ADT Reference Guide Draft out for review || Outline complete|| High|| WIP || Scott Rifenbark|| jzhang|| Documentation<br />
|-<br />
|| || || || || || || || <br />
|}<br />
<br />
== M4 (Feb 07 to Apr 15 -- Stabilize Complete Mar 18, Release Complete Apr 01, Contingency to Apr 15) ==<br />
<br />
This sprint is the [[Yocto Project v. 1.0 Release Cycle]].<br />
<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Documentation|| Migration chapter in the Poky Reference Manual|| This chapter would cover the four identified use-cases for migrating up to the most recent version of Yocto Project. Additionally, it would cover migration scenarios from other development systems. The chapter does not yet exist. The chapter has not been scoped outside of having a meeting that identified four use-cases that did not include migration from a development system outside of Yocto Project. It will take some more scoping time to cover those areas (a day or two). Again, I have no idea of the length. See earlier entries for standard industry writing estimates for software documentation|| Medium|| Not Started|| Scott Rifenbark|| 3-4 Weeks|| Documentation<br />
|-<br />
|| Documentation|| Yocto Project Development Guide|| This manual would be an over-arching document that frames the complete development cycle within Yocto Project. The idea here is that the document would be an umbrella document that spawned and referenced subsequent documents. The organization would be the first chapter overviewing the major development pieces such as recipe creation, building, debugging, publishing, fail-safing, back-door hook creation, etc. Scoping would be about two weeks and length would probably be about 40 pages. Overall development time would likely be a month of uniterruped time.|| Medium|| Not Started|| Scott Rifenbark|| 3 Weeks|| Documentation<br />
|-<br />
|| || Multilib Support|| Consider developing post-1.0 branch || 1|| to start in M4 || Richard|| ||<br />
|-<br />
|| Validation|| Alpha testing complete|| 4-5 internal developers unfamiliar with Yocto Project try to do a build and report on the experience and issues encountered|| 1|| Done by Feb 18 || Julie|| davest|| <br />
|-<br />
|| || || || || || || || <br />
|}<br />
<br />
== Features needed and to be put into sprints by assigned owners: ==<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || package config option enhancement|| there're several enhancements we may do here: * allow users setting specific config options (local or global) from external tool, such as poky image creator, instead of changing recipes manually. Need a mechanism to convert from variable assignments into exact config options (e.g. feature_${PN} = ""1"" -> ""--enable-feature""). Consequently dependency chain needs update with option status. * host contamination check. We have swabber to check host contamination, but I'm not sure whether it covers configuration phase. If not, this is one area to improve, as not ususually we see configure script checks host bits for available features * conditional option manipulation. In many recipes we enable/disable one option based on availability of other packages. Now this is done manually and not flexible. this should be made automatically though some new annotation to indicate condition, or just base_contains (not convenient: long line, need define distro features) || 2|| Review|| Richard/MarkH|| ktian1|| Enhancement<br />
|-<br />
|| Media|| Yocto Project Awareness Video|| This 2.5 minute video would introduce and describe the benefits of Yocto Project. The video would use entertaining animations that described concepts and benefits. The result would be suitable for YouTube, conferences, and the website. The production is called an "Epipheo" and will be created by Epipheo Studios. The engagement process has begun and the kick-off meeting will be soon. The PO is in place. Time for development is 10 weeks.|| High|| Kick-off Imminent|| Scott Rifenbark|| 10 Weeks|| Media<br />
|-<br />
|| Documentation|| Yocto Project Debugging Guide|| This would be a guide for the debugging and bug tracking process in Yocto Project. Originally, the thought was that we needed a Bugzilla User's Manual. However, since we don't own Bugzilla it doesn't make sense to produce documentation for it. Rather, we should document the process as it fits into the Yocto Project environment. Ideally, the manual would be a sub-manual that would be referenced and architected into the Yocto Project Development Guide. The manual has not been scoped and would take a week to scope. Again, I have no idea of the length. See the previous item for standard industry writing estimates for software documenation.|| Medium|| Not Started|| Scott Rifenbark|| 3-4 Weeks|| Documentation<br />
|-<br />
|| Website|| Yocto Project Website|| The 0.9 website is in place but needs updates. Items for consideration are the left-panel naviagation scheme, a contributions guidance page, color-scheming and theme (possibly).|| Medium|| Not Started|| Scott Rifenbark|| 1-2 Weeks|| Website<br />
|}<br />
<br />
== Features not believed to be needed in v1.0: ==<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || OpenEmbedded/Bitbake Upstreaming|| "We firstly need to review where we are and where OE is. We then need to make a plan about what we're going to push upstream and what we're not. I'd suggest when we're in PRC, we do a crash course in ""dealing with OE"" and then many dedicate a block of time (a week) where the distro team comes up with a patch set we then propose and get merged into OE. I'd like to find a couple of interested people to monitor OE more regularly and start a workflow of things between Poky/OE where appropriate. The key thing to remember is we need to keep the architectures compatible. The team is now at the point where I'm happy for them to actually try building OpenEmbedded and not worry about it tainting them! "|| 2|| Review|| || rpurdie|| Process<br />
|-<br />
|| Poky Features || Handle old versions in WORKDIR|| an incremental build directory may finally include many old versions WORKDIRS. It'll be good to have those old versions tracked in the cache, which can then either generate a report or allow selectively cleaning up an specific version WORKDIR. Or else it's difficult to figure it out when people want to keep the whole tmp directory but like to cleanup some old bits when disk usage is under pressure. If it's not easy to do in bitbake, perhaps some separate scripts would be also helpful || 3|| Review|| || ktian1|| Enhancement<br />
|-<br />
|| Poky Features || run bitbake w/o rebuilding the cache|| "sometimes it's useful to allow run bitbake w/o re-parsing recipes, if we know nothing metadata is changed. we can just allow reusing existing persistent cache. this is useful when people is debugging WORKDIR w/o metadata change. also sometimes ""bitbake -e"" is used frequently to check poky variable information. with existing cache, several seconds can be saved which are not negligible for a developer daily working on Yocto "|| 2|| Review|| || ktian1|| Enhancement<br />
|-<br />
|| Poky Features || parallel make improvement|| parallel make experience is not good, especially when bb threads and make threads are increased larger than 8. So far we either try to fix package makefile or mark the recipe as no parallel make, when build faiures are reported. But this greatly impacts user experience for a successfully continuous build process. Could we define a safe number we do want to support for 1.0 release? and then have our autobuilder, QA test, and developers cover that number immediately and fix any issues accordingly. Then the safe number can be suggested to the Yocto user || 2|| Review|| || ktian1|| Enhancement<br />
|-<br />
|| Poky Features || Dependency packages rebuild/clean|| It is a mechanism to rebulid or clean a package and all other packages which have build/runtime dependency on it. With this change, we can find potential influences of package upgrade to its related packages, which can make the incremental build more trustable. For example, if we upgrade a package to a new vesion which changes its API, this mechanism can easily find out the incompatibility to other packages which have dependency on it. || 2|| Review|| || dongxiao.xu|| Enhancement, replaced by checksum feature<br />
|-<br />
|| Distribution / components|| FOSSology|| This may be similar to License Update above, but start to use FOSSology to track licenses. || 2|| Review|| || sgw|| Hygiene<br />
|-<br />
|| Distribution / components|| Package Developer Tools|| Create a set of Init scripts template and then review our current init scripts and modify them to confirm to the template. || 2|| Review|| || sgw|| Easy of Use<br />
|-<br />
|| Distribution / components|| Package Website|| Complete the work the intern has started on generating the distro tracking information and get it out on the external site. || 2|| Review|| || sgw|| "Hygiene, duplicate of ""Package report system"""<br />
|-<br />
|| Distribution / components|| Bluetooth UI support|| Currently we have bluez package in poky, and we need to have a workable graphic user interface to connect/configure BT devices. One choice may be gnome-bluetooth-applet. || 3|| Review|| || dongxiao.xu|| enhancement<br />
|-<br />
|| Distribution / components|| Connman-gnome enhancement features|| Enable connman-gnome to support features like, WPA Enterprise connection, hidden SSID, etc. || 3|| Review|| || dongxiao.xu|| enhancement<br />
|-<br />
|| Distribution / components|| Java Running Environment support|| Since most embedded systems support java applications running in it, maybe we'd better consider supporting some kinds of JVMs(Embeded JVM). The JVM may not run by default, but user can launch it if running java applications. Compared with GTK/QT, java user number is not small too. || 3|| Review|| || criping|| enhancement<br />
|-<br />
|| Distribution / components|| create more use cases|| UPnP demo is one really good use case showing how Yocto is utilized to make real functionality. and we could create more to show how Yocto is easily adapted to real use cases. Those use cases can be either maintained as seperate demo layers in yocto repo, or in seperate branches for reference. We can also call for community's contribution on this which would make 1.0 full-fledged. Or else the newbies to Yocto may be in puzzle how our sample profiles can satisfy their requirements. || 2|| Review|| || ktian1|| enhancement<br />
|-<br />
|| Distribution / components|| i18n support || internationalization is an important system wide feature. Many component like font, locale affect the i18n. Yocto alreay has some i18n related package like pango, but so far did not consider i18n systematically. so this is place holder to systematically add i18n support. || 2|| Review|| || yuke/qing|| enhancement<br />
|-<br />
|| Distribution / components|| more demos || demos are a good way to educate, push the envelope, and at the same time tout the strengths of the platform. This item just records a current set of ideas from various sources which could/should be implemented: * face-recognition/face-finding, * robotic control/application of face-finding to 'camera-as-sensor' (hexbug demo), * others [tbd, add here]|| 2|| Review|| || tzanussi|| enhancement <br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer support for image-creator and needed yocto-metadata design||Come up design what need to be created as packages to support using "opkg install" for image-creator and needed yocto-metadata|| 2|| WIP, pending comments from RP regarding how to packaging metadata|| Jessica|| rpurdie|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer image-creator and needed poky-metadata support|| The poky build system will build packages for image-creator and needed poky-metadata, which the Yocto Installer will be able to use "opkg install" to install them|| 2|| Review|| Jessica|| rpurdie|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Provide qemu management UI|| In current eclipse plugin, QEMU settings are put together with project configuration. So we can only have limited settings. If we can have a separate QEMU management UI, the end user could firstly create a QEMU config, such as (env file of arch, image location, unfs or not, sato or lsb, mem size, disk size). And then he can launch a QEMU with a specific config. The dependency between project configuration and QEMU config will be resolved. After all QEMU has nothing to do project configuration. Need to careful review the UI to ensure minimal impact to testing matrix. || 3|| Review|| || criping|| "Enhancement, duplicate of ""Qemu mem/disk size can be adjusted"""<br />
|-<br />
|| Tool Development and SDK Features|| QT plugin For Eclipse|| Integrate QT Ecplise plugin and extend for Yocto Project || 3|| Review|| || jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Profiling/Trace GUI's|| We have a wealth of great tracing and profiling tools but the UI's for them are all extremely minimal and usually quite ugly. Would be great if we could compete with, or even better, Apple's offerings here. We have the technology! || 2|| Review|| || josh|| "Enhancement, duplicate of ""Tracing/Profiling Planning Complete"""<br />
|-<br />
|| Tool Development and SDK Features|| Other profiling tools|| Complete Tom's review of profiling tools and architecture || 2|| Review|| || josh|| "Enhancement, duplicate of ""Tracing/Profiling Planning Complete"""<br />
|-<br />
|| Tool Development and SDK Features|| Design next-gen tracing/profiling tools|| Yocto 1.0 will include all the essential existing tracing/profiling tools expected by users, and Josh has proposed a UI integration of all those tools as far as it's possible to do so. That level of integration, basically a 'plugin-level' integration is necessary and useful, but doesn't go far enough. A next-generation tracing tool would integrate at a much more fundamental level; if done properly, it would provide unmatched levels of power and usability to users, and would allow Yocto to distinguish itself in the embedded tracing/profiling space in a way also unmatched by any other distro/build-tool. The implementation would of course not be available for Yocto 1.0, but a coherent design, including prototypes, that could be taken to the community and implemented in a V 1.5 or 2.0 should be done in that time frame. || 1|| Review|| || tzanussi|| "Enhancement, duplicate of ""Tracing/Profiling Planning Complete"""<br />
|-<br />
|| Documentation Features|| Self Documentation of image contents|| "I'd like to see the -doc packages Poky builds being combined into some kind of large documentation index representing the collective API docs of the target being built. This can then be placed on a webserver and viewed over the web. We'd have a demonstration of this for a ""bitbake world"" target. Part of the idea here is to start making good use of the docs as if developers see this they might start writing better docs too. Aim is to lead the field :). There are a number of places poky packages disable doc generation due to missing tools so we'd need to add these so we can enable the doc generation. Many packages already have many docs though too. "|| 2|| Review|| || rpurdie|| enhancement<br />
|-<br />
|| Validation|| Testing Framework|| Add a framework for doing automated testing in the project|| 1|| Review|| || davest|| project commitment<br />
|-<br />
|| Validation|| more SDK builds on autobuilder|| enable more SDK related tests on autobuilder such as meta-ide-support, etc.|| 2|| Review|| || ktian1|| project commitment, addressed by test plan (?)<br />
|-<br />
|| Validation|| more people should try using SDK|| this may not be a feature, but a requirement. SDK including meta-toolchain is one key factor impacting user experience on Yocto. It's not enough to have only SDK team play with it|| 2|| Review|| || ktian1|| project commitment, addressed by test plan (?)<br />
|-<br />
|| Validation|| Unit Testing Framework|| Add a mechanism to bitbake to parse source packages that have unit tests and then execute them on the target|| 3|| Review|| || sgw|| "project commitment, duplicate of ""Testing Framework"""<br />
|-<br />
|| Validation|| Test Case open source|| Open source Yocto test cases with xml format|| 1|| Review|| || yyou|| "project commitment, duplicate of ""Testing Framework"""<br />
|}</div>Davesthttps://wiki.yoctoproject.org/wiki/index.php?title=Yocto_1.0_Schedule&diff=583Yocto 1.0 Schedule2011-01-25T01:27:03Z<p>Davest: /* Sprint C (closes Jan 14, 11:59pm PDT -- pull request sent, initially reviewed) */</p>
<hr />
<div>= v1.0 (release date: Apr 15, 2011) =<br />
----<br />
The detailed milestone map for v1.0 is as below. During the first week of each subsequent milestone past M1 we will have a demonstration of the previous milestone capabilities as well as a planning and design session for the current milestone.<br><br><br />
<br />
== M2 (Nov 08 to Dec 24 -- Dev Complete Dec 10, Stabilize Complete Dec 17, Release Complete Dec 24) ==<br />
=== Sprint A (closes Nov 12, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links''' <br />
|-<br />
|| Poky Features || Kernel interactive targets || To support incremental kernel development having the ability to run menuconfig (or xconfig, etc) directly is a common request. We'll need to add this for commercialization anyway. i.e. bitbake -c menuconfig. This fuctionality already exists. || 1 || Done || Richard || bruceashfield || Enhancement <br />
|-<br />
|| Distribution / components || Distro Audit: Upgrades Planned (Phase 1) || Complete plan for package upgrades in M2 || 1 || Done || Saul || || Continual Maintenance<br />
|-<br />
|| Validation || Runtime testing || Runtime testing of images as part of the autobuilder || 1 || Done || Jiajun/ScottG || rpurdie || project commitment<br />
|- <br />
|| || Poky Image Creator Wireframe/Interaction Plans Complete || || 1 || Done || Josh || ||<br />
|-<br />
|| || SDK Generator Interaction: Plans Complete || || 1 || Done || Jessica || ||<br />
|-<br />
|| || Tracing/Profiling Planning Complete || This needs to cover where we're at now, what we're missing and also propose the future enhancements that may be needed. M2 targets getting existing tools integrated and documented. F2f discussion n the future enhancements || || Done || Tom || ||<br />
|-<br />
|| || Swabber. (Still needs to be integrated into weekly build by default) || || 1 || Done || Josh || ||<br />
|-<br />
|| Build/Release || Release process documentation || || || Done || Beth || ||<br />
|-<br />
|| Validation || Test plan for v1.0 (to address any deficiencies in coverage from v0.9)|| || 1 || Done || Jiajun || ||<br />
|}<br />
<br />
=== Sprint B (closes Nov 19, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| Distro Audit: World Packages|| Audit world packages making sure it all build, making sure all are packages are required || 2|| Done || Saul|| sgw|| Hygiene<br />
|-<br />
|| Tool Development and SDK Features|| SDK Generator Installer UI|| Look at different ways of Installer UI (GTK+ and ncurses) seems none of them is the right choice, decide to go with script to implement all the functionalities of installer and later add UI part on top of it || 1||Done|| Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Customize sysroot setup || Add and test out "--sysroot" config option to cross compiler within Eclipse IDE || 1|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| SDK Generator Installer design revision|| Close all open questions regarding Yocto SDK Generator Installer function design and come up HLD || 1|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Distribution / components|| kernel version|| keeping 2.6.34 as a -stable kernel is the best option. I've also got a newer -devel tree that can be made available or made the default. || 3|| Done || Bruce|| bruceashfield|| enhancement<br />
|-<br />
|| || assign Yocto Project PM|| acquire and assign a program manager for Yocto Project|| || Done || DaveST|| || <br />
|-<br />
|| || assign Yocto Project Sys Admin|| || || Done || Saul|| || <br />
|-<br />
|| Tool Development and SDK Features|| oprofileUI|| Fixing various bugs of the oprofileUI to make it workable on big endian host.(i.e. ppc, mips) || 2 || Done || Jessica || lianhao.lu || Bug #382 / Bug #493<br />
|-<br />
|| Poky Feature|| SDK Version Control|| If we can expect that yocto SDK has lots of release in the future, we might need to consider SDK version control. Currently, every thing installed under /opt/poky which leads to things be overriden, we need to be able to use a scheme like /opt/poky-1.0, /opt/poky-2.0 to distiguish things. || 2|| Done || Josh|| jzhang|| Enhancement<br />
|-<br />
|| Kernel || Kernel plan complete || Flesh our kernel deliverables and add to Yocto 1.0 schedule || || Done|| Darren || dvhart ||<br />
|}<br />
<br />
=== Sprint C (closes Nov 26, 11:59pm PDT -- pull request sent, initially reviewed) :: NOTE: this is US Thanksgiving week ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| Distro Audit: Licence Checksums|| licence checksums || 1|| Done || Saul|| rpurdie|| Hygiene<br />
|-<br />
|| Poky Features || Performance Analysis Completed|| "I'd like someone to instrument a green release build, see where it spends time (hot/cold parsing time, individual task building time) and then compare this with our 0.9 release build. I'd also like to compare the disk usage between the two. Once we have a blame list we can then set about fixing it. Some things I know will come up: a) pseudo, b) checksums/signature code, c) exec() vs fork for executing tasks, d) task based prebuilds increasing disk usage, e) rpm dependency calculations, f) using rpm vs. ipk but I may be wrong and there may be others. We need numbers. "|| 1|| Done || Saul / Qing, Dongxiao|| rpurdie|| Enhancement<br />
|-<br />
|| Poky Features || environment variables for kernel builds|| switching a branch, or adding a configuration feature (and even changing the kernel repo) is often done during development of a BSP. Having some additional variables that are pass the bitbake environment scrub would be useful. i.e. KBRANCH=foo bitbake -c configure linux-yocto. This goes along with the other BSP bootstrapping suggestions. || 2|| Done || Bruce|| bruceashfield|| Enhancement<br />
|-<br />
|| Supported Targets|| ARM Platform Support|| Replace beagleboard with Beagleboard XM - decision || 2|| Done || Bruce|| alex|| Basic Yocto hardware support <br />
|-<br />
|| Distribution / components|| Security Process|| We need a dedicated person to scan and apply critical security updates to the distro. The MeeGo team already has a similar process with some scripts which may be leveraged. To complete the task, the process should be documented and a first pass over the metadata made to establish the current position on security. Any upgrades needed should be identified and a plan to address them should be in place but doesn't have to be implemented by this point.|| 1|| Done || ScottG|| ktian1|| enhancement<br />
|-<br />
|| Tool Development and SDK Features|| SDK Generator Installer Opkg repo design|| Come up a opkg repo design that will mimic the final Yocto package repo layout to be used by SDK Generator Installer to test against|| 2 || Done || Jessica || jzhang || <br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer tar creaion|| Create a Yocto Installer tar ball which contains Installer script and supported opkg component that will be used for installing other Yocto components|| 2 || Done || Jessica || jzhang || <br />
|-<br />
|| Documentation|| Kernel Framework Paper from WR|| The paper from WR needs to be re-written and then posted somewhere on the Yocto Project site. This will involve examiniation of the text and re-writing and formatting for presentation. Currently it is simply a text document. Completion time assuming uninterrupted time is one week.|| High|| Done || Scott Rifenbark|| 1 Week|| Documentation<br />
|-<br />
|| Documentation|| Poky Reference Manual|| This guide exists in the 0.9 form. The re-write of the text needs to be completed. So far, all the chapters have been rewritten but not re-posted on the site. Only the appendices remain for a text scrub. Time to complete this would be a week of uninterrupted time. Ideally, the manual would be a sub-manual that would be referenced and architected into the Yocto Project Development Guide.|| Medium|| Done|| Scott Rifenbark|| 1 Week|| Documentation<br />
|-<br />
|| Kernel || Initial meta-linaro layer || meta-linaro layer providing a kernel, tool-chain, and uboot loader. This deliverable is primarily to get the infrastructure in place and have a buildable kernel. Toolchain on best effort basis. || || Done || Darren || dvhart || Moderate risk of slippage due to holidays.<br />
|-<br />
|| Kernel || Tracing: blktrace and sysprof recipes || || || Done || Tom || dvhart ||<br />
|}<br />
<br />
=== Sprint D (closes Dec 3, 11:59pm PDT -- pull request sent, initially reviewed) :: NOTE: week of the F2F planning meeting ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Kernel || Kernel git branching structure revamped || || 1 || Done || Bruce || dvhart ||<br />
|-<br />
|| Kernel || Tunnel Creek (Crown Bay) || || 1 || Done || Tom || dvhart ||<br />
|}<br />
<br />
=== Sprint E (closes Dec 9 (THURSDAY), 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| Distro Audit: Upgrades Completed (Phase 1)|| Update to new versions as per the agreed plan for M2 from Sprint A|| 1|| Done || Saul|| rpurdie|| Continual Maintenance<br />
|-<br />
|| Distribution / components|| Distro Audit: Src Checksums|| Make sure all SRC_URI components have checksums too || 1|| Done || Saul|| rpurdie|| Hygiene<br />
|-<br />
|| Poky Features || enable KVM with qemu|| today all new Intel processors support VT, which are enabled on most desktop machines which are most frequently used build machine. with VT support, x86/x86-64 qemu target runs faster which is a good thing for emulation environment. This may require some qemu option tweaks and also poky-qemu script enhancement. || 2|| Done || Saul / Edwin|| ktian1|| Enhancement<br />
|-<br />
|| Kernel || New kernel recipes || dev, -devel, -custom || 3 || Done || Bruce || dvhart ||<br />
|-<br />
|| Swabber || Documentation for swabber || || 1 || Done || Alex || ||<br />
|-<br />
|| CCB || Defect triage process in public documented and implemented || || 1 || Done. Triage process is documented, out for review. || Saul || ||<br />
|}<br />
<br />
== M3 (Dec 20 to Feb 08 -- Dev Complete Feb 04, Stabilize Complete Feb 11, Release Complete Feb 18) ==<br />
=== Sprint A (closes Dec 24, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Kernel || Initial meta-rt layer || PREEMPT_RT kernel and related test-cases and benchmarks || 2 || Done by Jan 21 || Darren || dvhart || slipped out from M2<br />
|-<br />
|| Poky Features || Fetcher Overhaul Phase 1 - SRC_REV enhancement||<br />
* a) Add code in FetchData::__init__() which will check if the selected fetcher supports srcrev and the automatically call a function to set the src rev value instead of each fetcher doing this.\n <br />
* e) Break SRCREVINACTION deadlock. To do this, we need to start using a keyword for automatically increasing SRCREV, e.g. SRCREV = "AUTOINC". The actual revision can be injected into PV using SRCPV. If we do this there should no longer be a need of the deadlock; <br />
* k) Ensure that we only set __BB_DONT_CACHE when SRCREV = "AUTOREV". This may need a new method call for fetchers to tell whether they're "floating" or locked down.<br />
|| 1|| Done || Saul / Ke, RP|| rpurdie|| Enhancement, slipped out from M2<br />
|-<br />
|| Distribution / components|| Distro Audit Upgrades Planned (Phase 2)|| Complete plan for package upgrades in M2|| 1|| Done || Saul|| || Continual Maintenance<br />
|-<br />
|| Poky Features || Pseudo Performance || Implement the changes to bitbake based on pseudo's enable/disable switch|| 1|| done || Saul / Qing, Dongxiao || rpurdie|| Enhancement, slipped from M2 due to risk and not having Pseudo's change yet.<br />
|-<br />
|| Tool Development and SDK Features|| Fix the issue user target sysroot is owned by root || The ADT installer will use pseudo to extract user target sysroot which ended up owned by root, this need to be fixed || 1|| done || Jessica|| jzhang|| Cleanup <br />
|-<br />
|| Tool Development and SDK Features|| Eclipse poky tree interfacing (metadata file editor)|| Provide a metadata file editor with some syntax checking and keywords highlight capabilities|| 2|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| IDE Project templates|| Templates for various project types: Clutter GUI, Gtk+ GUI, to help developers get started quickly || 2|| Done || Jessica|| josh|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| push TCF/RSE patches upstream|| work with community to finish up our TCF terminal service, TCF/RSE integration remaining patches taken by upstream. Blocking issues including Eclipse Bug #327865 || 1|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Pseudo || Pseudo enhancement to enable on/off switch || || 1 || done || Mark || ||<br />
|-<br />
|| Pseudo || Bitbake enhancement for pseudo on/off switch || || 1 || done || Richard || ||<br />
|-<br />
|| bugzilla || Complete restructure of bugzilla categories || || 1 || done || Saul || ||<br />
|-<br />
|| Poky Features || Image creator ground work || Nomenclature determined, existing gui's bug fixed and backend work implemented || 1 || Done || Joshua || ||<br />
|-<br />
|| Kernel || Tracing: Initial SystemTap recipe || Works on x86 || 3 || Done || Tom || dvhart ||<br />
|-<br />
|| Distribution / components|| Distro Audit: Package Description/Summary completed|| Ensure DESCRIPTION/SUMMARY fields are all audited|| 2|| Done || Mark|| Mark|| Hygiene, was M2, Sprint B but missed window<br />
|-<br />
|| Distribution / components|| Zypper/RPM|| Small write-up of the problems we're having w/ Zypper and what we plan to do. (i.e. create a roadmap/design) - Includes rootfs generation - Package uprev/install/removal || 1 || Done || Mark/Qing || || was M2, Sprint B<br />
|-<br />
|| Distribution / components|| Distro Audit: Licence Checksums|| Make the licence checksums fatal if not present || 1|| Done || Saul|| rpurdie|| Hygiene, was M2, Sprint C<br />
|-<br />
|| Distribution / components|| push of all relevant Wind River patchs to Yocto (patch comparison)|| Ensure patches present to packages in WRS are also in Poky|| 1|| Done || Mark|| Mark|| was M2, Sprint C<br />
|-<br />
|| Poky Features || Performance Enhancement Completed || Initial changes to reduce disk space (sstate-build-*) || 1|| Done || Saul / Qing, Dongxiao || rpurdie|| Enhancement, was M2, Sprint E<br />
|-<br />
|| Distribution / components|| User specified qemu config support|| We'll provide user an edit box which allows advanced qemu user to specify arbitrary qemu configuration to meet their needs, which the poky-qemu scrip will just append the config list towards the end of the list of parameters to bring up qemu, it also expect the poky-qemu script to do some basic sanity check on the user specifications to catch the obvious mistake || 2|| Done || Saul / criping || criping|| enhancement, was M2, Sprint E<br />
|-<br />
|| Tool Development and SDK Features|| SDK Version Control support in SDK generator installer|| If we can expect that yocto SDK has lots of release in the future, we might need to consider SDK version control. Currently, if we un-tar the sdk, it will override the older version. It's not good for app developers since they might need the old version to do something. And also, maybe a finer installer than untar is preferred. Installer will tied to certain SDK version and the installation will go under /opt/poky-versionNo.|| 1|| Done || Jessica|| criping|| Enhancement-expect planning process by Jessica to handle this task. Was M2, Sprint E.<br />
|}<br />
<br />
=== Sprint B (closes Jan 07, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || Bitbake multi-threaded parsing|| Bitbake recipe parsing is currently single threaded. I want to make this multithreaded as the speedup would be nice. If I can only take a single task for myself for 1.0, I'm nominating this one as I enjoy this kind of thing and I have ideas on how to do it. || 1|| Done || Richard|| rpurdie|| Enhancement<br />
|-<br />
|| Distribution / components|| Lock in Kernel/Toolchain version|| Locked in 2.6.37 and gcc 4.5.1. Pending decision to move to 4.5.2 and Linaro || || Done || || Richard|| || <br />
|-<br />
|| Distribution / components|| License Update|| For each of the licences we support, I'd really like to have a licences directory with a copy of that license contained within. When it comes to deciding what a given LICENSE field means, this would be the reference. It also means we can include the licences a given image includes with the image. This continues to make our license handling world class and ahead of the field. || 2|| Done || Beth|| rpurdie|| Hygiene<br />
|-<br />
|| Tool Development and SDK Features|| Qemu configuration change|| Provice edit box for advanced user to specify qemu configurations|| 2|| Done || Jessica|| criping|| <br />
|-<br />
|| Tool Development and SDK Features|| Lock down Eclipse+CDT+TCF version|| Will use Eclipse Halo 3.6 || 1|| Done || Jessica|| || <br />
|-<br />
|| Demo|| Finalize on demo plans for v1.0 launch || || 1|| Done || Dave || || <br />
|-<br />
|| Release || Release plans for v1.0 launch || Fill out the M4 plan with the necessary release activities and timings || 1|| Done || Beth || || <br />
|-<br />
|| Poky Features || Basic image creator GUI || Functional UI missing some Advanced features || 1 || In replan || Joshua || || <br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer for SDK Generator Installation functions support||Detailed feature request can be found at: http://bugzilla.pokylinux.org/show_bug.cgi?id=589|| 1|| Done || Jessica|| rpurdie|| Enhancement<br />
|-<br />
|| Kernel || Tracing: trace-cmd python binding cleanup || || 3 || Done || Darren || dvhart ||<br />
|}<br />
<br />
=== Sprint C (closes Jan 14, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || kernel development layer|| The (correct) poky behaviour of building known revisions coupled with the fetcher requiring a BSP branch to already be present means that local modifications (and kernel source tree) are required for kernel development. I already have a layer that overrides/modifies the behaviour when added to the bblayers.conf and configured into an environment. This seems useful for more people to use. || 2|| Done || Bruce|| bruceashfield|| Enhancement, was M2, Sprint C<br />
|-<br />
|| Distribution / components|| Zypper/RPM|| RPM Uprev / Zypper Uprev [lets get to the latest versions]|| 1|| pull request by Jan 19; || Mark/Qing|| || was M2, Sprint C<br />
|-<br />
|| Supported Targets|| Intel Platform Support|| JasperForest|| 2|| Basic support in place; DPDK evaluation in process, overall BSP plan still TBD || Tom|| davest|| Basic ECG support (Moved from Sprint A)<br />
|-<br />
|| Tool Development and SDK Features|| Eclipse poky tree interfacing (git support)|| Use Eclipse git capability to install poky tree from git repo and able to interact with git repo at file level within Poky tree || 2|| Done || Jessica|| jzhang|| Enhancement<br />
<br />
|-<br />
|| Poky Features || Poky Image Creator|| A standalone application you can run which asks you to select a distro and machine, then presents a list of packages you can select. Once the selection is made, it goes off and bakes you an image which is then presented to you. Implementation wise, it should use the sstate packages, be a bitbake UI and use the usual poky bbclass files to do the image construction behind the scenes. || 1|| Re-plan || Joshua|| rpurdie|| Enhancement<br />
|-<br />
|| Poky Features || Fetcher Overhaul Phase 3 - git enhancement||<br />
* j) Optimize git fetcher for the new layout so for a git checkout, we clone the repository in download(), then unpack just does a clone with references to the original repo. <br />
* k) Ensure that we only set __BB_DONT_CACHE when SRCREV = "AUTOREV". This may need a new method call for fetchers to tell whether they're "floating" or locked down. <br />
* l) Add a new "BB_NO_NETWORK" variable which the fetchers check before peforming an operation which hits anything remote. This means adding in error messages about why network access is needed at various points (e.g. SRCREV = "AUTOREV" for a given recipe) <br />
* m) Add multiple branch/srcrev support for git fetcher. These would be of the form: git://somelocation/somerepo.git;name=ref1;branch=foo;name=ref2;branch=bar SRCREV_ref1 = "hash1" SRCREV_ref2 = "hash2" which would ensure both hash1 and hash2 were in the final repo. <br />
* n) Change git fetcher to default to git protocol instead of rsync<br />
|| 1|| Slipped to Sprint D || Saul / Ke, RP|| rpurdie|| Enhancement<br />
|-<br />
|| Validation|| Boottime/Performance Analysis|| Compare Yocto Project performance to other projects such as MeeGo|| 1|| Initial report on where we are by Feb 9 || Darren|| davest|| project commitment <br />
|-<br />
|| Distribution / components|| LSB Sanity|| execute LSB Test and improve passing rate and document failures with clear understanding|| 2|| Done || MarkH/Saul|| sgw|| Hygiene<br />
|-<br />
|| Distribution / components|| Review & Fix Standards Tests|| Review the results from LTP, POSIX and asses the result, fix as appropriate and clearly document failures.|| 2|| a Plan to resolve final items to be sent to the m.l. by Jan 14 || Saul/Kevin || sgw|| Hygiene<br />
|-<br />
|| Tool Development and SDK Features|| Image creator integration with Eclipse || || 2|| replan|| Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Kernel || Tracing: perf trace marker support || This is from feedback to the new trace command. Ingo appears to have this nearly complete already. || 3 || Done || Darren || dvhart ||<br />
|-<br />
|| Kernel || Tracing: perf trace scripting support || || 3 || Move to Sprint D; on track for Jan 21 || Tom || dvhart ||<br />
|-<br />
|| Cleanup || bitbake user experience error handling validation completed || || 2 || Done || Richard || ||<br />
|-<br />
|| Cleanup || variable scrub - ensure all metadata variables are documented || Script with a histogram of variable use done, identified 50 variables to document; Add task for actual documentation update is low on the list || 2 || Done || Scott/Darren || ||<br />
|-<br />
|| Distribution / components|| Zypper/RPM|| Integration based on design from Sprint B|| 1|| On track for Jan28 || Mark/Qing|| sgw|| Functionality, was M2, Sprint E<br />
|-<br />
|| Kernel || Tracing: package kernelshark || || 3 || Done || Darren || dvhart ||<br />
|-<br />
|| Kernel || Tracing: tuna, oscillosope recipes || || 3 || Tom to discuss plan with Darren et al || Tom || dvhart ||<br />
|- <br />
|| BSP || Beagleboard XM Support || || 3 || Move to Sprint D || Darren || dvhart ||<br />
|}<br />
<br />
=== Sprint D (closes Jan 21, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Swabber || Complete review of swabber outputs || Move to M3 Sprint D || 1 || Move to M3 Sprint D || Alex || ||<br />
|-<br />
|| Poky Features || Fetcher Overhaul Phase 2 - API reorg||<br />
* f) Add a generic unpack funciton to __init__.py based on the unpack task in Poky ;<br />
* g) Split go() methods into the following steps: i) download() - do whatever transfer is necessary to get the sources locally ii) build_mirror_data() - generate any data that would be needed to construct a source mirror iii) unpack() - takes a directory as an argument of where to place extracted sources;<br />
The existing go() methods should be replaced with a set of calls to the above sections of functionality as appropriate in the individual fetchers. Some of these categories of function make no sense in certain fetchers, in which case they shouldn't need to implement them. Functions are only executed if the method is present.<br />
* h) Change Poky's unpack to call an unpack method in the fetchers.<br />
* i) Change Poky's fetch task to call a "download" method in the fetcher instead of go().<br />
|| 1|| Will land with phase 3 in Jan 21 || Saul / Ke, RP|| rpurdie|| Enhancement<br />
|-<br />
|| Documentation Features|| Package report system|| move to public server [setup a package report system in an internal machine. We need push it publicly available. The basic features like search and report have been there. But there're still some enhancements in plan, to make it a fit place to feel Yocto metadata comfortably]|| 2|| Move to Sprint E|| KevinT|| ktian1|| enhancement<br />
|-<br />
|| Distribution / components||Add headers and libraries to qemu images ||Since we'll be using qemu images as target sysroot, need to create a set of qemu images for minimal, sato, LSB that contains target header and libraries.|| 2|| Pending a discussion on Jan 18 || Saul ||jzhang|| Enhancement<br />
|-<br />
|| Distribution / components|| push of all relevant Wind River patchs to Yocto (patch comparison)|| Update any additional patches needed since M2.|| 1|| May be done by Jan 21, pending RPM stuff || Mark|| Mark|| <br />
|-<br />
|| Distribution / components|| mklibs|| mklibs is a tool to optimize size of [e]glibc for a perticular root file system image. It is useful to save disk space on small devices. || 2|| Push to Sprint E || Saul|| Nitin Kamble|| enhancement<br />
|-<br />
|| Poky Features || Performance Enhancement || reduce disk space (hardlink) || 1 || On track for Jan 21, pending RP review || Saul / Qing, Dongxiao || rpurdie || Enhancement<br />
|-<br />
|| BSP || 2.6.37 Crown Bay Support || On Track for Jan 21 || 2 || || Tom || dvhart || <br />
|-<br />
|| BSP || 2.6.37 Emenlow Support || On track for Jan 21 || 2 || || Tom || dvhart || <br />
|}<br />
<br />
=== Sprint E (closes Jan 28, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| rootless X|| rootless x server has better security than x server launched by root. MeeGo already enable this feature. it would be nice for Yocto to also enable it. || 2|| On track for Jan 28 || Saul / Ke || yuke|| enhancement<br />
|-<br />
|| Documentation Features|| Package report system|| finish major feature development and internal review [setup a package report system in an internal machine. We need push it publicly available. The basic features like search and report have been there. But there're still some enhancements in plan, to make it a fit place to feel Yocto metadata comfortably]|| 2|| Move to Sprint E || Jonathan || ktian1|| enhancement, was M2, Sprint E<br />
|-<br />
|| Distribution / components|| perl upgrade|| perl is the most cross un-friendly recipe pending upgrade. || 2|| Slipping due to Linaro layer, moves to end of Sprint E || Nitin|| Nitin Kamble|| enhancement<br />
|-<br />
|| Supported Targets|| Intel Platform Support|| Sandybridge|| 2|| Accept|| Tom|| davest|| Basic ECG support<br />
|-<br />
|| Distribution / components|| performance indicators|| define some indicators (boot time, footprint, build time, power, component benchmarks, etc.) and then collect them for tracking purpose. The result could be posted on the wiki site, and the initial indicators can be easy ones which can be easily retrieved from autobuilder or weekly qa report). This way we have a clear track about the healthy of the Yocto project, and also identify weak areas. We can include qemu targets and several representational boards as the targets. || 2|| Review|| Beth/Jiajun|| ktian1|| enhancement<br />
|-<br />
|| Tool Development and SDK Features|| SDK user workshop|| Have some developers sit down and use our tools to develop demo software for Yocto. || 2|| Review|| Jessica|| josh|| Enhancement<br />
|-<br />
|| Kernel || Final linux-yocto_git.bb || With 2.6.37 kernel || 1 || || Bruce || dvhart ||<br />
|-<br />
|| Kernel || Final meta-linaro layer || || || || Darren || dvhart ||<br />
|-<br />
|| Kernel || Final meta-rt layer || || || || Darren || dvhart ||<br />
|-<br />
|| Kernel || Sandy Bridge || || 1 || || Tom || dvhart ||<br />
|}<br />
<br />
=== Sprint F (closes Feb 03 (THURSDAY), 11:59pm PDT -- pull request sent, initially reviewed) :: NOTE: China New Year Holiday ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Documentation|| ADT Reference Guide Draft out for review || Outline complete|| High|| WIP || Scott Rifenbark|| jzhang|| Documentation<br />
|-<br />
|| || || || || || || || <br />
|}<br />
<br />
== M4 (Feb 07 to Apr 15 -- Stabilize Complete Mar 18, Release Complete Apr 01, Contingency to Apr 15) ==<br />
<br />
This sprint is the [[Yocto Project v. 1.0 Release Cycle]].<br />
<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Documentation|| Migration chapter in the Poky Reference Manual|| This chapter would cover the four identified use-cases for migrating up to the most recent version of Yocto Project. Additionally, it would cover migration scenarios from other development systems. The chapter does not yet exist. The chapter has not been scoped outside of having a meeting that identified four use-cases that did not include migration from a development system outside of Yocto Project. It will take some more scoping time to cover those areas (a day or two). Again, I have no idea of the length. See earlier entries for standard industry writing estimates for software documentation|| Medium|| Not Started|| Scott Rifenbark|| 3-4 Weeks|| Documentation<br />
|-<br />
|| Documentation|| Yocto Project Development Guide|| This manual would be an over-arching document that frames the complete development cycle within Yocto Project. The idea here is that the document would be an umbrella document that spawned and referenced subsequent documents. The organization would be the first chapter overviewing the major development pieces such as recipe creation, building, debugging, publishing, fail-safing, back-door hook creation, etc. Scoping would be about two weeks and length would probably be about 40 pages. Overall development time would likely be a month of uniterruped time.|| Medium|| Not Started|| Scott Rifenbark|| 3 Weeks|| Documentation<br />
|-<br />
|| || Multilib Support|| Consider developing post-1.0 branch || 1|| to start in M4 || Richard|| ||<br />
|-<br />
|| Validation|| Alpha testing complete|| 4-5 internal developers unfamiliar with Yocto Project try to do a build and report on the experience and issues encountered|| 1|| Done by Feb 18 || Julie|| davest|| <br />
|-<br />
|| || || || || || || || <br />
|}<br />
<br />
== Features needed and to be put into sprints by assigned owners: ==<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || package config option enhancement|| there're several enhancements we may do here: * allow users setting specific config options (local or global) from external tool, such as poky image creator, instead of changing recipes manually. Need a mechanism to convert from variable assignments into exact config options (e.g. feature_${PN} = ""1"" -> ""--enable-feature""). Consequently dependency chain needs update with option status. * host contamination check. We have swabber to check host contamination, but I'm not sure whether it covers configuration phase. If not, this is one area to improve, as not ususually we see configure script checks host bits for available features * conditional option manipulation. In many recipes we enable/disable one option based on availability of other packages. Now this is done manually and not flexible. this should be made automatically though some new annotation to indicate condition, or just base_contains (not convenient: long line, need define distro features) || 2|| Review|| Richard/MarkH|| ktian1|| Enhancement<br />
|-<br />
|| Media|| Yocto Project Awareness Video|| This 2.5 minute video would introduce and describe the benefits of Yocto Project. The video would use entertaining animations that described concepts and benefits. The result would be suitable for YouTube, conferences, and the website. The production is called an "Epipheo" and will be created by Epipheo Studios. The engagement process has begun and the kick-off meeting will be soon. The PO is in place. Time for development is 10 weeks.|| High|| Kick-off Imminent|| Scott Rifenbark|| 10 Weeks|| Media<br />
|-<br />
|| Documentation|| Yocto Project Debugging Guide|| This would be a guide for the debugging and bug tracking process in Yocto Project. Originally, the thought was that we needed a Bugzilla User's Manual. However, since we don't own Bugzilla it doesn't make sense to produce documentation for it. Rather, we should document the process as it fits into the Yocto Project environment. Ideally, the manual would be a sub-manual that would be referenced and architected into the Yocto Project Development Guide. The manual has not been scoped and would take a week to scope. Again, I have no idea of the length. See the previous item for standard industry writing estimates for software documenation.|| Medium|| Not Started|| Scott Rifenbark|| 3-4 Weeks|| Documentation<br />
|-<br />
|| Website|| Yocto Project Website|| The 0.9 website is in place but needs updates. Items for consideration are the left-panel naviagation scheme, a contributions guidance page, color-scheming and theme (possibly).|| Medium|| Not Started|| Scott Rifenbark|| 1-2 Weeks|| Website<br />
|}<br />
<br />
== Features not believed to be needed in v1.0: ==<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || OpenEmbedded/Bitbake Upstreaming|| "We firstly need to review where we are and where OE is. We then need to make a plan about what we're going to push upstream and what we're not. I'd suggest when we're in PRC, we do a crash course in ""dealing with OE"" and then many dedicate a block of time (a week) where the distro team comes up with a patch set we then propose and get merged into OE. I'd like to find a couple of interested people to monitor OE more regularly and start a workflow of things between Poky/OE where appropriate. The key thing to remember is we need to keep the architectures compatible. The team is now at the point where I'm happy for them to actually try building OpenEmbedded and not worry about it tainting them! "|| 2|| Review|| || rpurdie|| Process<br />
|-<br />
|| Poky Features || Handle old versions in WORKDIR|| an incremental build directory may finally include many old versions WORKDIRS. It'll be good to have those old versions tracked in the cache, which can then either generate a report or allow selectively cleaning up an specific version WORKDIR. Or else it's difficult to figure it out when people want to keep the whole tmp directory but like to cleanup some old bits when disk usage is under pressure. If it's not easy to do in bitbake, perhaps some separate scripts would be also helpful || 3|| Review|| || ktian1|| Enhancement<br />
|-<br />
|| Poky Features || run bitbake w/o rebuilding the cache|| "sometimes it's useful to allow run bitbake w/o re-parsing recipes, if we know nothing metadata is changed. we can just allow reusing existing persistent cache. this is useful when people is debugging WORKDIR w/o metadata change. also sometimes ""bitbake -e"" is used frequently to check poky variable information. with existing cache, several seconds can be saved which are not negligible for a developer daily working on Yocto "|| 2|| Review|| || ktian1|| Enhancement<br />
|-<br />
|| Poky Features || parallel make improvement|| parallel make experience is not good, especially when bb threads and make threads are increased larger than 8. So far we either try to fix package makefile or mark the recipe as no parallel make, when build faiures are reported. But this greatly impacts user experience for a successfully continuous build process. Could we define a safe number we do want to support for 1.0 release? and then have our autobuilder, QA test, and developers cover that number immediately and fix any issues accordingly. Then the safe number can be suggested to the Yocto user || 2|| Review|| || ktian1|| Enhancement<br />
|-<br />
|| Poky Features || Dependency packages rebuild/clean|| It is a mechanism to rebulid or clean a package and all other packages which have build/runtime dependency on it. With this change, we can find potential influences of package upgrade to its related packages, which can make the incremental build more trustable. For example, if we upgrade a package to a new vesion which changes its API, this mechanism can easily find out the incompatibility to other packages which have dependency on it. || 2|| Review|| || dongxiao.xu|| Enhancement, replaced by checksum feature<br />
|-<br />
|| Distribution / components|| FOSSology|| This may be similar to License Update above, but start to use FOSSology to track licenses. || 2|| Review|| || sgw|| Hygiene<br />
|-<br />
|| Distribution / components|| Package Developer Tools|| Create a set of Init scripts template and then review our current init scripts and modify them to confirm to the template. || 2|| Review|| || sgw|| Easy of Use<br />
|-<br />
|| Distribution / components|| Package Website|| Complete the work the intern has started on generating the distro tracking information and get it out on the external site. || 2|| Review|| || sgw|| "Hygiene, duplicate of ""Package report system"""<br />
|-<br />
|| Distribution / components|| Bluetooth UI support|| Currently we have bluez package in poky, and we need to have a workable graphic user interface to connect/configure BT devices. One choice may be gnome-bluetooth-applet. || 3|| Review|| || dongxiao.xu|| enhancement<br />
|-<br />
|| Distribution / components|| Connman-gnome enhancement features|| Enable connman-gnome to support features like, WPA Enterprise connection, hidden SSID, etc. || 3|| Review|| || dongxiao.xu|| enhancement<br />
|-<br />
|| Distribution / components|| Java Running Environment support|| Since most embedded systems support java applications running in it, maybe we'd better consider supporting some kinds of JVMs(Embeded JVM). The JVM may not run by default, but user can launch it if running java applications. Compared with GTK/QT, java user number is not small too. || 3|| Review|| || criping|| enhancement<br />
|-<br />
|| Distribution / components|| create more use cases|| UPnP demo is one really good use case showing how Yocto is utilized to make real functionality. and we could create more to show how Yocto is easily adapted to real use cases. Those use cases can be either maintained as seperate demo layers in yocto repo, or in seperate branches for reference. We can also call for community's contribution on this which would make 1.0 full-fledged. Or else the newbies to Yocto may be in puzzle how our sample profiles can satisfy their requirements. || 2|| Review|| || ktian1|| enhancement<br />
|-<br />
|| Distribution / components|| i18n support || internationalization is an important system wide feature. Many component like font, locale affect the i18n. Yocto alreay has some i18n related package like pango, but so far did not consider i18n systematically. so this is place holder to systematically add i18n support. || 2|| Review|| || yuke/qing|| enhancement<br />
|-<br />
|| Distribution / components|| more demos || demos are a good way to educate, push the envelope, and at the same time tout the strengths of the platform. This item just records a current set of ideas from various sources which could/should be implemented: * face-recognition/face-finding, * robotic control/application of face-finding to 'camera-as-sensor' (hexbug demo), * others [tbd, add here]|| 2|| Review|| || tzanussi|| enhancement <br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer support for image-creator and needed yocto-metadata design||Come up design what need to be created as packages to support using "opkg install" for image-creator and needed yocto-metadata|| 2|| WIP, pending comments from RP regarding how to packaging metadata|| Jessica|| rpurdie|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer image-creator and needed poky-metadata support|| The poky build system will build packages for image-creator and needed poky-metadata, which the Yocto Installer will be able to use "opkg install" to install them|| 2|| Review|| Jessica|| rpurdie|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Provide qemu management UI|| In current eclipse plugin, QEMU settings are put together with project configuration. So we can only have limited settings. If we can have a separate QEMU management UI, the end user could firstly create a QEMU config, such as (env file of arch, image location, unfs or not, sato or lsb, mem size, disk size). And then he can launch a QEMU with a specific config. The dependency between project configuration and QEMU config will be resolved. After all QEMU has nothing to do project configuration. Need to careful review the UI to ensure minimal impact to testing matrix. || 3|| Review|| || criping|| "Enhancement, duplicate of ""Qemu mem/disk size can be adjusted"""<br />
|-<br />
|| Tool Development and SDK Features|| QT plugin For Eclipse|| Integrate QT Ecplise plugin and extend for Yocto Project || 3|| Review|| || jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Profiling/Trace GUI's|| We have a wealth of great tracing and profiling tools but the UI's for them are all extremely minimal and usually quite ugly. Would be great if we could compete with, or even better, Apple's offerings here. We have the technology! || 2|| Review|| || josh|| "Enhancement, duplicate of ""Tracing/Profiling Planning Complete"""<br />
|-<br />
|| Tool Development and SDK Features|| Other profiling tools|| Complete Tom's review of profiling tools and architecture || 2|| Review|| || josh|| "Enhancement, duplicate of ""Tracing/Profiling Planning Complete"""<br />
|-<br />
|| Tool Development and SDK Features|| Design next-gen tracing/profiling tools|| Yocto 1.0 will include all the essential existing tracing/profiling tools expected by users, and Josh has proposed a UI integration of all those tools as far as it's possible to do so. That level of integration, basically a 'plugin-level' integration is necessary and useful, but doesn't go far enough. A next-generation tracing tool would integrate at a much more fundamental level; if done properly, it would provide unmatched levels of power and usability to users, and would allow Yocto to distinguish itself in the embedded tracing/profiling space in a way also unmatched by any other distro/build-tool. The implementation would of course not be available for Yocto 1.0, but a coherent design, including prototypes, that could be taken to the community and implemented in a V 1.5 or 2.0 should be done in that time frame. || 1|| Review|| || tzanussi|| "Enhancement, duplicate of ""Tracing/Profiling Planning Complete"""<br />
|-<br />
|| Documentation Features|| Self Documentation of image contents|| "I'd like to see the -doc packages Poky builds being combined into some kind of large documentation index representing the collective API docs of the target being built. This can then be placed on a webserver and viewed over the web. We'd have a demonstration of this for a ""bitbake world"" target. Part of the idea here is to start making good use of the docs as if developers see this they might start writing better docs too. Aim is to lead the field :). There are a number of places poky packages disable doc generation due to missing tools so we'd need to add these so we can enable the doc generation. Many packages already have many docs though too. "|| 2|| Review|| || rpurdie|| enhancement<br />
|-<br />
|| Validation|| Testing Framework|| Add a framework for doing automated testing in the project|| 1|| Review|| || davest|| project commitment<br />
|-<br />
|| Validation|| more SDK builds on autobuilder|| enable more SDK related tests on autobuilder such as meta-ide-support, etc.|| 2|| Review|| || ktian1|| project commitment, addressed by test plan (?)<br />
|-<br />
|| Validation|| more people should try using SDK|| this may not be a feature, but a requirement. SDK including meta-toolchain is one key factor impacting user experience on Yocto. It's not enough to have only SDK team play with it|| 2|| Review|| || ktian1|| project commitment, addressed by test plan (?)<br />
|-<br />
|| Validation|| Unit Testing Framework|| Add a mechanism to bitbake to parse source packages that have unit tests and then execute them on the target|| 3|| Review|| || sgw|| "project commitment, duplicate of ""Testing Framework"""<br />
|-<br />
|| Validation|| Test Case open source|| Open source Yocto test cases with xml format|| 1|| Review|| || yyou|| "project commitment, duplicate of ""Testing Framework"""<br />
|}</div>Davesthttps://wiki.yoctoproject.org/wiki/index.php?title=Yocto_1.0_Schedule&diff=582Yocto 1.0 Schedule2011-01-25T01:25:35Z<p>Davest: /* Sprint D (closes Jan 21, 11:59pm PDT -- pull request sent, initially reviewed) */</p>
<hr />
<div>= v1.0 (release date: Apr 15, 2011) =<br />
----<br />
The detailed milestone map for v1.0 is as below. During the first week of each subsequent milestone past M1 we will have a demonstration of the previous milestone capabilities as well as a planning and design session for the current milestone.<br><br><br />
<br />
== M2 (Nov 08 to Dec 24 -- Dev Complete Dec 10, Stabilize Complete Dec 17, Release Complete Dec 24) ==<br />
=== Sprint A (closes Nov 12, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links''' <br />
|-<br />
|| Poky Features || Kernel interactive targets || To support incremental kernel development having the ability to run menuconfig (or xconfig, etc) directly is a common request. We'll need to add this for commercialization anyway. i.e. bitbake -c menuconfig. This fuctionality already exists. || 1 || Done || Richard || bruceashfield || Enhancement <br />
|-<br />
|| Distribution / components || Distro Audit: Upgrades Planned (Phase 1) || Complete plan for package upgrades in M2 || 1 || Done || Saul || || Continual Maintenance<br />
|-<br />
|| Validation || Runtime testing || Runtime testing of images as part of the autobuilder || 1 || Done || Jiajun/ScottG || rpurdie || project commitment<br />
|- <br />
|| || Poky Image Creator Wireframe/Interaction Plans Complete || || 1 || Done || Josh || ||<br />
|-<br />
|| || SDK Generator Interaction: Plans Complete || || 1 || Done || Jessica || ||<br />
|-<br />
|| || Tracing/Profiling Planning Complete || This needs to cover where we're at now, what we're missing and also propose the future enhancements that may be needed. M2 targets getting existing tools integrated and documented. F2f discussion n the future enhancements || || Done || Tom || ||<br />
|-<br />
|| || Swabber. (Still needs to be integrated into weekly build by default) || || 1 || Done || Josh || ||<br />
|-<br />
|| Build/Release || Release process documentation || || || Done || Beth || ||<br />
|-<br />
|| Validation || Test plan for v1.0 (to address any deficiencies in coverage from v0.9)|| || 1 || Done || Jiajun || ||<br />
|}<br />
<br />
=== Sprint B (closes Nov 19, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| Distro Audit: World Packages|| Audit world packages making sure it all build, making sure all are packages are required || 2|| Done || Saul|| sgw|| Hygiene<br />
|-<br />
|| Tool Development and SDK Features|| SDK Generator Installer UI|| Look at different ways of Installer UI (GTK+ and ncurses) seems none of them is the right choice, decide to go with script to implement all the functionalities of installer and later add UI part on top of it || 1||Done|| Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Customize sysroot setup || Add and test out "--sysroot" config option to cross compiler within Eclipse IDE || 1|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| SDK Generator Installer design revision|| Close all open questions regarding Yocto SDK Generator Installer function design and come up HLD || 1|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Distribution / components|| kernel version|| keeping 2.6.34 as a -stable kernel is the best option. I've also got a newer -devel tree that can be made available or made the default. || 3|| Done || Bruce|| bruceashfield|| enhancement<br />
|-<br />
|| || assign Yocto Project PM|| acquire and assign a program manager for Yocto Project|| || Done || DaveST|| || <br />
|-<br />
|| || assign Yocto Project Sys Admin|| || || Done || Saul|| || <br />
|-<br />
|| Tool Development and SDK Features|| oprofileUI|| Fixing various bugs of the oprofileUI to make it workable on big endian host.(i.e. ppc, mips) || 2 || Done || Jessica || lianhao.lu || Bug #382 / Bug #493<br />
|-<br />
|| Poky Feature|| SDK Version Control|| If we can expect that yocto SDK has lots of release in the future, we might need to consider SDK version control. Currently, every thing installed under /opt/poky which leads to things be overriden, we need to be able to use a scheme like /opt/poky-1.0, /opt/poky-2.0 to distiguish things. || 2|| Done || Josh|| jzhang|| Enhancement<br />
|-<br />
|| Kernel || Kernel plan complete || Flesh our kernel deliverables and add to Yocto 1.0 schedule || || Done|| Darren || dvhart ||<br />
|}<br />
<br />
=== Sprint C (closes Nov 26, 11:59pm PDT -- pull request sent, initially reviewed) :: NOTE: this is US Thanksgiving week ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| Distro Audit: Licence Checksums|| licence checksums || 1|| Done || Saul|| rpurdie|| Hygiene<br />
|-<br />
|| Poky Features || Performance Analysis Completed|| "I'd like someone to instrument a green release build, see where it spends time (hot/cold parsing time, individual task building time) and then compare this with our 0.9 release build. I'd also like to compare the disk usage between the two. Once we have a blame list we can then set about fixing it. Some things I know will come up: a) pseudo, b) checksums/signature code, c) exec() vs fork for executing tasks, d) task based prebuilds increasing disk usage, e) rpm dependency calculations, f) using rpm vs. ipk but I may be wrong and there may be others. We need numbers. "|| 1|| Done || Saul / Qing, Dongxiao|| rpurdie|| Enhancement<br />
|-<br />
|| Poky Features || environment variables for kernel builds|| switching a branch, or adding a configuration feature (and even changing the kernel repo) is often done during development of a BSP. Having some additional variables that are pass the bitbake environment scrub would be useful. i.e. KBRANCH=foo bitbake -c configure linux-yocto. This goes along with the other BSP bootstrapping suggestions. || 2|| Done || Bruce|| bruceashfield|| Enhancement<br />
|-<br />
|| Supported Targets|| ARM Platform Support|| Replace beagleboard with Beagleboard XM - decision || 2|| Done || Bruce|| alex|| Basic Yocto hardware support <br />
|-<br />
|| Distribution / components|| Security Process|| We need a dedicated person to scan and apply critical security updates to the distro. The MeeGo team already has a similar process with some scripts which may be leveraged. To complete the task, the process should be documented and a first pass over the metadata made to establish the current position on security. Any upgrades needed should be identified and a plan to address them should be in place but doesn't have to be implemented by this point.|| 1|| Done || ScottG|| ktian1|| enhancement<br />
|-<br />
|| Tool Development and SDK Features|| SDK Generator Installer Opkg repo design|| Come up a opkg repo design that will mimic the final Yocto package repo layout to be used by SDK Generator Installer to test against|| 2 || Done || Jessica || jzhang || <br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer tar creaion|| Create a Yocto Installer tar ball which contains Installer script and supported opkg component that will be used for installing other Yocto components|| 2 || Done || Jessica || jzhang || <br />
|-<br />
|| Documentation|| Kernel Framework Paper from WR|| The paper from WR needs to be re-written and then posted somewhere on the Yocto Project site. This will involve examiniation of the text and re-writing and formatting for presentation. Currently it is simply a text document. Completion time assuming uninterrupted time is one week.|| High|| Done || Scott Rifenbark|| 1 Week|| Documentation<br />
|-<br />
|| Documentation|| Poky Reference Manual|| This guide exists in the 0.9 form. The re-write of the text needs to be completed. So far, all the chapters have been rewritten but not re-posted on the site. Only the appendices remain for a text scrub. Time to complete this would be a week of uninterrupted time. Ideally, the manual would be a sub-manual that would be referenced and architected into the Yocto Project Development Guide.|| Medium|| Done|| Scott Rifenbark|| 1 Week|| Documentation<br />
|-<br />
|| Kernel || Initial meta-linaro layer || meta-linaro layer providing a kernel, tool-chain, and uboot loader. This deliverable is primarily to get the infrastructure in place and have a buildable kernel. Toolchain on best effort basis. || || Done || Darren || dvhart || Moderate risk of slippage due to holidays.<br />
|-<br />
|| Kernel || Tracing: blktrace and sysprof recipes || || || Done || Tom || dvhart ||<br />
|}<br />
<br />
=== Sprint D (closes Dec 3, 11:59pm PDT -- pull request sent, initially reviewed) :: NOTE: week of the F2F planning meeting ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Kernel || Kernel git branching structure revamped || || 1 || Done || Bruce || dvhart ||<br />
|-<br />
|| Kernel || Tunnel Creek (Crown Bay) || || 1 || Done || Tom || dvhart ||<br />
|}<br />
<br />
=== Sprint E (closes Dec 9 (THURSDAY), 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| Distro Audit: Upgrades Completed (Phase 1)|| Update to new versions as per the agreed plan for M2 from Sprint A|| 1|| Done || Saul|| rpurdie|| Continual Maintenance<br />
|-<br />
|| Distribution / components|| Distro Audit: Src Checksums|| Make sure all SRC_URI components have checksums too || 1|| Done || Saul|| rpurdie|| Hygiene<br />
|-<br />
|| Poky Features || enable KVM with qemu|| today all new Intel processors support VT, which are enabled on most desktop machines which are most frequently used build machine. with VT support, x86/x86-64 qemu target runs faster which is a good thing for emulation environment. This may require some qemu option tweaks and also poky-qemu script enhancement. || 2|| Done || Saul / Edwin|| ktian1|| Enhancement<br />
|-<br />
|| Kernel || New kernel recipes || dev, -devel, -custom || 3 || Done || Bruce || dvhart ||<br />
|-<br />
|| Swabber || Documentation for swabber || || 1 || Done || Alex || ||<br />
|-<br />
|| CCB || Defect triage process in public documented and implemented || || 1 || Done. Triage process is documented, out for review. || Saul || ||<br />
|}<br />
<br />
== M3 (Dec 20 to Feb 08 -- Dev Complete Feb 04, Stabilize Complete Feb 11, Release Complete Feb 18) ==<br />
=== Sprint A (closes Dec 24, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Kernel || Initial meta-rt layer || PREEMPT_RT kernel and related test-cases and benchmarks || 2 || Done by Jan 21 || Darren || dvhart || slipped out from M2<br />
|-<br />
|| Poky Features || Fetcher Overhaul Phase 1 - SRC_REV enhancement||<br />
* a) Add code in FetchData::__init__() which will check if the selected fetcher supports srcrev and the automatically call a function to set the src rev value instead of each fetcher doing this.\n <br />
* e) Break SRCREVINACTION deadlock. To do this, we need to start using a keyword for automatically increasing SRCREV, e.g. SRCREV = "AUTOINC". The actual revision can be injected into PV using SRCPV. If we do this there should no longer be a need of the deadlock; <br />
* k) Ensure that we only set __BB_DONT_CACHE when SRCREV = "AUTOREV". This may need a new method call for fetchers to tell whether they're "floating" or locked down.<br />
|| 1|| Done || Saul / Ke, RP|| rpurdie|| Enhancement, slipped out from M2<br />
|-<br />
|| Distribution / components|| Distro Audit Upgrades Planned (Phase 2)|| Complete plan for package upgrades in M2|| 1|| Done || Saul|| || Continual Maintenance<br />
|-<br />
|| Poky Features || Pseudo Performance || Implement the changes to bitbake based on pseudo's enable/disable switch|| 1|| done || Saul / Qing, Dongxiao || rpurdie|| Enhancement, slipped from M2 due to risk and not having Pseudo's change yet.<br />
|-<br />
|| Tool Development and SDK Features|| Fix the issue user target sysroot is owned by root || The ADT installer will use pseudo to extract user target sysroot which ended up owned by root, this need to be fixed || 1|| done || Jessica|| jzhang|| Cleanup <br />
|-<br />
|| Tool Development and SDK Features|| Eclipse poky tree interfacing (metadata file editor)|| Provide a metadata file editor with some syntax checking and keywords highlight capabilities|| 2|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| IDE Project templates|| Templates for various project types: Clutter GUI, Gtk+ GUI, to help developers get started quickly || 2|| Done || Jessica|| josh|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| push TCF/RSE patches upstream|| work with community to finish up our TCF terminal service, TCF/RSE integration remaining patches taken by upstream. Blocking issues including Eclipse Bug #327865 || 1|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Pseudo || Pseudo enhancement to enable on/off switch || || 1 || done || Mark || ||<br />
|-<br />
|| Pseudo || Bitbake enhancement for pseudo on/off switch || || 1 || done || Richard || ||<br />
|-<br />
|| bugzilla || Complete restructure of bugzilla categories || || 1 || done || Saul || ||<br />
|-<br />
|| Poky Features || Image creator ground work || Nomenclature determined, existing gui's bug fixed and backend work implemented || 1 || Done || Joshua || ||<br />
|-<br />
|| Kernel || Tracing: Initial SystemTap recipe || Works on x86 || 3 || Done || Tom || dvhart ||<br />
|-<br />
|| Distribution / components|| Distro Audit: Package Description/Summary completed|| Ensure DESCRIPTION/SUMMARY fields are all audited|| 2|| Done || Mark|| Mark|| Hygiene, was M2, Sprint B but missed window<br />
|-<br />
|| Distribution / components|| Zypper/RPM|| Small write-up of the problems we're having w/ Zypper and what we plan to do. (i.e. create a roadmap/design) - Includes rootfs generation - Package uprev/install/removal || 1 || Done || Mark/Qing || || was M2, Sprint B<br />
|-<br />
|| Distribution / components|| Distro Audit: Licence Checksums|| Make the licence checksums fatal if not present || 1|| Done || Saul|| rpurdie|| Hygiene, was M2, Sprint C<br />
|-<br />
|| Distribution / components|| push of all relevant Wind River patchs to Yocto (patch comparison)|| Ensure patches present to packages in WRS are also in Poky|| 1|| Done || Mark|| Mark|| was M2, Sprint C<br />
|-<br />
|| Poky Features || Performance Enhancement Completed || Initial changes to reduce disk space (sstate-build-*) || 1|| Done || Saul / Qing, Dongxiao || rpurdie|| Enhancement, was M2, Sprint E<br />
|-<br />
|| Distribution / components|| User specified qemu config support|| We'll provide user an edit box which allows advanced qemu user to specify arbitrary qemu configuration to meet their needs, which the poky-qemu scrip will just append the config list towards the end of the list of parameters to bring up qemu, it also expect the poky-qemu script to do some basic sanity check on the user specifications to catch the obvious mistake || 2|| Done || Saul / criping || criping|| enhancement, was M2, Sprint E<br />
|-<br />
|| Tool Development and SDK Features|| SDK Version Control support in SDK generator installer|| If we can expect that yocto SDK has lots of release in the future, we might need to consider SDK version control. Currently, if we un-tar the sdk, it will override the older version. It's not good for app developers since they might need the old version to do something. And also, maybe a finer installer than untar is preferred. Installer will tied to certain SDK version and the installation will go under /opt/poky-versionNo.|| 1|| Done || Jessica|| criping|| Enhancement-expect planning process by Jessica to handle this task. Was M2, Sprint E.<br />
|}<br />
<br />
=== Sprint B (closes Jan 07, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || Bitbake multi-threaded parsing|| Bitbake recipe parsing is currently single threaded. I want to make this multithreaded as the speedup would be nice. If I can only take a single task for myself for 1.0, I'm nominating this one as I enjoy this kind of thing and I have ideas on how to do it. || 1|| Done || Richard|| rpurdie|| Enhancement<br />
|-<br />
|| Distribution / components|| Lock in Kernel/Toolchain version|| Locked in 2.6.37 and gcc 4.5.1. Pending decision to move to 4.5.2 and Linaro || || Done || || Richard|| || <br />
|-<br />
|| Distribution / components|| License Update|| For each of the licences we support, I'd really like to have a licences directory with a copy of that license contained within. When it comes to deciding what a given LICENSE field means, this would be the reference. It also means we can include the licences a given image includes with the image. This continues to make our license handling world class and ahead of the field. || 2|| Done || Beth|| rpurdie|| Hygiene<br />
|-<br />
|| Tool Development and SDK Features|| Qemu configuration change|| Provice edit box for advanced user to specify qemu configurations|| 2|| Done || Jessica|| criping|| <br />
|-<br />
|| Tool Development and SDK Features|| Lock down Eclipse+CDT+TCF version|| Will use Eclipse Halo 3.6 || 1|| Done || Jessica|| || <br />
|-<br />
|| Demo|| Finalize on demo plans for v1.0 launch || || 1|| Done || Dave || || <br />
|-<br />
|| Release || Release plans for v1.0 launch || Fill out the M4 plan with the necessary release activities and timings || 1|| Done || Beth || || <br />
|-<br />
|| Poky Features || Basic image creator GUI || Functional UI missing some Advanced features || 1 || In replan || Joshua || || <br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer for SDK Generator Installation functions support||Detailed feature request can be found at: http://bugzilla.pokylinux.org/show_bug.cgi?id=589|| 1|| Done || Jessica|| rpurdie|| Enhancement<br />
|-<br />
|| Kernel || Tracing: trace-cmd python binding cleanup || || 3 || Done || Darren || dvhart ||<br />
|}<br />
<br />
=== Sprint C (closes Jan 14, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || kernel development layer|| The (correct) poky behaviour of building known revisions coupled with the fetcher requiring a BSP branch to already be present means that local modifications (and kernel source tree) are required for kernel development. I already have a layer that overrides/modifies the behaviour when added to the bblayers.conf and configured into an environment. This seems useful for more people to use. || 2|| Done || Bruce|| bruceashfield|| Enhancement, was M2, Sprint C<br />
|-<br />
|| Distribution / components|| Zypper/RPM|| RPM Uprev / Zypper Uprev [lets get to the latest versions]|| 1|| pull request by Jan 19; || Mark/Qing|| || was M2, Sprint C<br />
|-<br />
|| Supported Targets|| Intel Platform Support|| JasperForest|| 2|| Basic support in place; DPDK evaluation in process, overall BSP plan still TBD || Tom|| davest|| Basic ECG support (Moved from Sprint A)<br />
|-<br />
|| Tool Development and SDK Features|| Eclipse poky tree interfacing (git support)|| Use Eclipse git capability to install poky tree from git repo and able to interact with git repo at file level within Poky tree || 2|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Poky Features || DSO linking changes|| "By the default the gcc linker will automatically link any dependant objects/libraries. ""Inherited"" linkages can cause issues, for example, where a shared object changes its dependencies but a program has come to rely on symbols from an implicitly linked library. Fedora implemented this change in F13, seems like it would be useful to have in Poky too. "|| 2|| On track for Jan 21 || Saul / Nitin || josh|| bug#516<br />
|-<br />
|| Distribution / components|| Distro Audit Documentation Output|| Audit package documentation output || 2|| Move to Sprint D due to libtool work || Saul / ScottG || rpurdie|| Hygiene<br />
|-<br />
|| Poky Features || libtool sysroot option|| libtool 2.4 has a sysroot option. We should try and use it, see how it works and whether we can ditch some of our libtool hacks. || 1|| On track for Jan 21 || Saul / ScottG || rpurdie|| Enhancement<br />
|-<br />
|| Distribution / components|| MACHINE or Recipe specific sysroots|| Each machine should have its own sysroot. We'll probably have to split do_populate_sysroot into a two step process, creation of the package and than installtion of the package, which the installation of the package being made machine specific (put ${MACHINE} into ${STAMP} and bitbake should do that). Also allowing this to work per recipe would be desireable|| 1|| On track 21 || Saul / Dongxiao || rpurdie|| Hygiene<br />
|-<br />
|| Distribution / components|| Toolchain Bootstrap Process|| The toolchain as it bootstraps overwrites files like libc.so and libgcc.so in the sysroot directory which causes issues if you just try and rebuild part of the toolchain. Each step of the bootstrap process should use a separate sysroot. Once this is once, sstate file overwriting detection can be added and enabled. || 1|| Patches submitted for comment, slip to Sprint D || Saul / Dexuan || rpurdie|| Hygiene<br />
|-<br />
|| Poky Features || Poky Image Creator|| A standalone application you can run which asks you to select a distro and machine, then presents a list of packages you can select. Once the selection is made, it goes off and bakes you an image which is then presented to you. Implementation wise, it should use the sstate packages, be a bitbake UI and use the usual poky bbclass files to do the image construction behind the scenes. || 1|| Re-plan || Joshua|| rpurdie|| Enhancement<br />
|-<br />
|| Poky Features || Fetcher Overhaul Phase 3 - git enhancement||<br />
* j) Optimize git fetcher for the new layout so for a git checkout, we clone the repository in download(), then unpack just does a clone with references to the original repo. <br />
* k) Ensure that we only set __BB_DONT_CACHE when SRCREV = "AUTOREV". This may need a new method call for fetchers to tell whether they're "floating" or locked down. <br />
* l) Add a new "BB_NO_NETWORK" variable which the fetchers check before peforming an operation which hits anything remote. This means adding in error messages about why network access is needed at various points (e.g. SRCREV = "AUTOREV" for a given recipe) <br />
* m) Add multiple branch/srcrev support for git fetcher. These would be of the form: git://somelocation/somerepo.git;name=ref1;branch=foo;name=ref2;branch=bar SRCREV_ref1 = "hash1" SRCREV_ref2 = "hash2" which would ensure both hash1 and hash2 were in the final repo. <br />
* n) Change git fetcher to default to git protocol instead of rsync<br />
|| 1|| Slipped to Sprint D || Saul / Ke, RP|| rpurdie|| Enhancement<br />
<br />
|-<br />
|| Validation|| Boottime/Performance Analysis|| Compare Yocto Project performance to other projects such as MeeGo|| 1|| Initial report on where we are by Feb 9 || Darren|| davest|| project commitment <br />
|-<br />
|| Distribution / components|| LSB Sanity|| execute LSB Test and improve passing rate and document failures with clear understanding|| 2|| Done || MarkH/Saul|| sgw|| Hygiene<br />
|-<br />
|| Distribution / components|| Review & Fix Standards Tests|| Review the results from LTP, POSIX and asses the result, fix as appropriate and clearly document failures.|| 2|| a Plan to resolve final items to be sent to the m.l. by Jan 14 || Saul/Kevin || sgw|| Hygiene<br />
|-<br />
|| Tool Development and SDK Features|| Image creator integration with Eclipse || || 2|| replan|| Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Kernel || Tracing: perf trace marker support || This is from feedback to the new trace command. Ingo appears to have this nearly complete already. || 3 || Done || Darren || dvhart ||<br />
|-<br />
|| Kernel || Tracing: perf trace scripting support || || 3 || Move to Sprint D; on track for Jan 21 || Tom || dvhart ||<br />
|-<br />
|| Cleanup || bitbake user experience error handling validation completed || || 2 || Done || Richard || ||<br />
|-<br />
|| Cleanup || variable scrub - ensure all metadata variables are documented || Script with a histogram of variable use done, identified 50 variables to document; Add task for actual documentation update is low on the list || 2 || Done || Scott/Darren || ||<br />
|-<br />
|| Distribution / components|| Zypper/RPM|| Integration based on design from Sprint B|| 1|| On track for Jan28 || Mark/Qing|| sgw|| Functionality, was M2, Sprint E<br />
|-<br />
|| Kernel || Tracing: package kernelshark || || 3 || Done || Darren || dvhart ||<br />
|-<br />
|| Kernel || Tracing: tuna, oscillosope recipes || || 3 || Tom to discuss plan with Darren et al || Tom || dvhart ||<br />
|- <br />
|| BSP || Beagleboard XM Support || || 3 || Move to Sprint D || Darren || dvhart ||<br />
|}<br />
<br />
=== Sprint D (closes Jan 21, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Swabber || Complete review of swabber outputs || Move to M3 Sprint D || 1 || Move to M3 Sprint D || Alex || ||<br />
|-<br />
|| Poky Features || Fetcher Overhaul Phase 2 - API reorg||<br />
* f) Add a generic unpack funciton to __init__.py based on the unpack task in Poky ;<br />
* g) Split go() methods into the following steps: i) download() - do whatever transfer is necessary to get the sources locally ii) build_mirror_data() - generate any data that would be needed to construct a source mirror iii) unpack() - takes a directory as an argument of where to place extracted sources;<br />
The existing go() methods should be replaced with a set of calls to the above sections of functionality as appropriate in the individual fetchers. Some of these categories of function make no sense in certain fetchers, in which case they shouldn't need to implement them. Functions are only executed if the method is present.<br />
* h) Change Poky's unpack to call an unpack method in the fetchers.<br />
* i) Change Poky's fetch task to call a "download" method in the fetcher instead of go().<br />
|| 1|| Will land with phase 3 in Jan 21 || Saul / Ke, RP|| rpurdie|| Enhancement<br />
|-<br />
|| Documentation Features|| Package report system|| move to public server [setup a package report system in an internal machine. We need push it publicly available. The basic features like search and report have been there. But there're still some enhancements in plan, to make it a fit place to feel Yocto metadata comfortably]|| 2|| Move to Sprint E|| KevinT|| ktian1|| enhancement<br />
|-<br />
|| Distribution / components||Add headers and libraries to qemu images ||Since we'll be using qemu images as target sysroot, need to create a set of qemu images for minimal, sato, LSB that contains target header and libraries.|| 2|| Pending a discussion on Jan 18 || Saul ||jzhang|| Enhancement<br />
|-<br />
|| Distribution / components|| push of all relevant Wind River patchs to Yocto (patch comparison)|| Update any additional patches needed since M2.|| 1|| May be done by Jan 21, pending RPM stuff || Mark|| Mark|| <br />
|-<br />
|| Distribution / components|| mklibs|| mklibs is a tool to optimize size of [e]glibc for a perticular root file system image. It is useful to save disk space on small devices. || 2|| Push to Sprint E || Saul|| Nitin Kamble|| enhancement<br />
|-<br />
|| Poky Features || Performance Enhancement || reduce disk space (hardlink) || 1 || On track for Jan 21, pending RP review || Saul / Qing, Dongxiao || rpurdie || Enhancement<br />
|-<br />
|| BSP || 2.6.37 Crown Bay Support || On Track for Jan 21 || 2 || || Tom || dvhart || <br />
|-<br />
|| BSP || 2.6.37 Emenlow Support || On track for Jan 21 || 2 || || Tom || dvhart || <br />
|}<br />
<br />
=== Sprint E (closes Jan 28, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| rootless X|| rootless x server has better security than x server launched by root. MeeGo already enable this feature. it would be nice for Yocto to also enable it. || 2|| On track for Jan 28 || Saul / Ke || yuke|| enhancement<br />
|-<br />
|| Documentation Features|| Package report system|| finish major feature development and internal review [setup a package report system in an internal machine. We need push it publicly available. The basic features like search and report have been there. But there're still some enhancements in plan, to make it a fit place to feel Yocto metadata comfortably]|| 2|| Move to Sprint E || Jonathan || ktian1|| enhancement, was M2, Sprint E<br />
|-<br />
|| Distribution / components|| perl upgrade|| perl is the most cross un-friendly recipe pending upgrade. || 2|| Slipping due to Linaro layer, moves to end of Sprint E || Nitin|| Nitin Kamble|| enhancement<br />
|-<br />
|| Supported Targets|| Intel Platform Support|| Sandybridge|| 2|| Accept|| Tom|| davest|| Basic ECG support<br />
|-<br />
|| Distribution / components|| performance indicators|| define some indicators (boot time, footprint, build time, power, component benchmarks, etc.) and then collect them for tracking purpose. The result could be posted on the wiki site, and the initial indicators can be easy ones which can be easily retrieved from autobuilder or weekly qa report). This way we have a clear track about the healthy of the Yocto project, and also identify weak areas. We can include qemu targets and several representational boards as the targets. || 2|| Review|| Beth/Jiajun|| ktian1|| enhancement<br />
|-<br />
|| Tool Development and SDK Features|| SDK user workshop|| Have some developers sit down and use our tools to develop demo software for Yocto. || 2|| Review|| Jessica|| josh|| Enhancement<br />
|-<br />
|| Kernel || Final linux-yocto_git.bb || With 2.6.37 kernel || 1 || || Bruce || dvhart ||<br />
|-<br />
|| Kernel || Final meta-linaro layer || || || || Darren || dvhart ||<br />
|-<br />
|| Kernel || Final meta-rt layer || || || || Darren || dvhart ||<br />
|-<br />
|| Kernel || Sandy Bridge || || 1 || || Tom || dvhart ||<br />
|}<br />
<br />
=== Sprint F (closes Feb 03 (THURSDAY), 11:59pm PDT -- pull request sent, initially reviewed) :: NOTE: China New Year Holiday ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Documentation|| ADT Reference Guide Draft out for review || Outline complete|| High|| WIP || Scott Rifenbark|| jzhang|| Documentation<br />
|-<br />
|| || || || || || || || <br />
|}<br />
<br />
== M4 (Feb 07 to Apr 15 -- Stabilize Complete Mar 18, Release Complete Apr 01, Contingency to Apr 15) ==<br />
<br />
This sprint is the [[Yocto Project v. 1.0 Release Cycle]].<br />
<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Documentation|| Migration chapter in the Poky Reference Manual|| This chapter would cover the four identified use-cases for migrating up to the most recent version of Yocto Project. Additionally, it would cover migration scenarios from other development systems. The chapter does not yet exist. The chapter has not been scoped outside of having a meeting that identified four use-cases that did not include migration from a development system outside of Yocto Project. It will take some more scoping time to cover those areas (a day or two). Again, I have no idea of the length. See earlier entries for standard industry writing estimates for software documentation|| Medium|| Not Started|| Scott Rifenbark|| 3-4 Weeks|| Documentation<br />
|-<br />
|| Documentation|| Yocto Project Development Guide|| This manual would be an over-arching document that frames the complete development cycle within Yocto Project. The idea here is that the document would be an umbrella document that spawned and referenced subsequent documents. The organization would be the first chapter overviewing the major development pieces such as recipe creation, building, debugging, publishing, fail-safing, back-door hook creation, etc. Scoping would be about two weeks and length would probably be about 40 pages. Overall development time would likely be a month of uniterruped time.|| Medium|| Not Started|| Scott Rifenbark|| 3 Weeks|| Documentation<br />
|-<br />
|| || Multilib Support|| Consider developing post-1.0 branch || 1|| to start in M4 || Richard|| ||<br />
|-<br />
|| Validation|| Alpha testing complete|| 4-5 internal developers unfamiliar with Yocto Project try to do a build and report on the experience and issues encountered|| 1|| Done by Feb 18 || Julie|| davest|| <br />
|-<br />
|| || || || || || || || <br />
|}<br />
<br />
== Features needed and to be put into sprints by assigned owners: ==<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || package config option enhancement|| there're several enhancements we may do here: * allow users setting specific config options (local or global) from external tool, such as poky image creator, instead of changing recipes manually. Need a mechanism to convert from variable assignments into exact config options (e.g. feature_${PN} = ""1"" -> ""--enable-feature""). Consequently dependency chain needs update with option status. * host contamination check. We have swabber to check host contamination, but I'm not sure whether it covers configuration phase. If not, this is one area to improve, as not ususually we see configure script checks host bits for available features * conditional option manipulation. In many recipes we enable/disable one option based on availability of other packages. Now this is done manually and not flexible. this should be made automatically though some new annotation to indicate condition, or just base_contains (not convenient: long line, need define distro features) || 2|| Review|| Richard/MarkH|| ktian1|| Enhancement<br />
|-<br />
|| Media|| Yocto Project Awareness Video|| This 2.5 minute video would introduce and describe the benefits of Yocto Project. The video would use entertaining animations that described concepts and benefits. The result would be suitable for YouTube, conferences, and the website. The production is called an "Epipheo" and will be created by Epipheo Studios. The engagement process has begun and the kick-off meeting will be soon. The PO is in place. Time for development is 10 weeks.|| High|| Kick-off Imminent|| Scott Rifenbark|| 10 Weeks|| Media<br />
|-<br />
|| Documentation|| Yocto Project Debugging Guide|| This would be a guide for the debugging and bug tracking process in Yocto Project. Originally, the thought was that we needed a Bugzilla User's Manual. However, since we don't own Bugzilla it doesn't make sense to produce documentation for it. Rather, we should document the process as it fits into the Yocto Project environment. Ideally, the manual would be a sub-manual that would be referenced and architected into the Yocto Project Development Guide. The manual has not been scoped and would take a week to scope. Again, I have no idea of the length. See the previous item for standard industry writing estimates for software documenation.|| Medium|| Not Started|| Scott Rifenbark|| 3-4 Weeks|| Documentation<br />
|-<br />
|| Website|| Yocto Project Website|| The 0.9 website is in place but needs updates. Items for consideration are the left-panel naviagation scheme, a contributions guidance page, color-scheming and theme (possibly).|| Medium|| Not Started|| Scott Rifenbark|| 1-2 Weeks|| Website<br />
|}<br />
<br />
== Features not believed to be needed in v1.0: ==<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || OpenEmbedded/Bitbake Upstreaming|| "We firstly need to review where we are and where OE is. We then need to make a plan about what we're going to push upstream and what we're not. I'd suggest when we're in PRC, we do a crash course in ""dealing with OE"" and then many dedicate a block of time (a week) where the distro team comes up with a patch set we then propose and get merged into OE. I'd like to find a couple of interested people to monitor OE more regularly and start a workflow of things between Poky/OE where appropriate. The key thing to remember is we need to keep the architectures compatible. The team is now at the point where I'm happy for them to actually try building OpenEmbedded and not worry about it tainting them! "|| 2|| Review|| || rpurdie|| Process<br />
|-<br />
|| Poky Features || Handle old versions in WORKDIR|| an incremental build directory may finally include many old versions WORKDIRS. It'll be good to have those old versions tracked in the cache, which can then either generate a report or allow selectively cleaning up an specific version WORKDIR. Or else it's difficult to figure it out when people want to keep the whole tmp directory but like to cleanup some old bits when disk usage is under pressure. If it's not easy to do in bitbake, perhaps some separate scripts would be also helpful || 3|| Review|| || ktian1|| Enhancement<br />
|-<br />
|| Poky Features || run bitbake w/o rebuilding the cache|| "sometimes it's useful to allow run bitbake w/o re-parsing recipes, if we know nothing metadata is changed. we can just allow reusing existing persistent cache. this is useful when people is debugging WORKDIR w/o metadata change. also sometimes ""bitbake -e"" is used frequently to check poky variable information. with existing cache, several seconds can be saved which are not negligible for a developer daily working on Yocto "|| 2|| Review|| || ktian1|| Enhancement<br />
|-<br />
|| Poky Features || parallel make improvement|| parallel make experience is not good, especially when bb threads and make threads are increased larger than 8. So far we either try to fix package makefile or mark the recipe as no parallel make, when build faiures are reported. But this greatly impacts user experience for a successfully continuous build process. Could we define a safe number we do want to support for 1.0 release? and then have our autobuilder, QA test, and developers cover that number immediately and fix any issues accordingly. Then the safe number can be suggested to the Yocto user || 2|| Review|| || ktian1|| Enhancement<br />
|-<br />
|| Poky Features || Dependency packages rebuild/clean|| It is a mechanism to rebulid or clean a package and all other packages which have build/runtime dependency on it. With this change, we can find potential influences of package upgrade to its related packages, which can make the incremental build more trustable. For example, if we upgrade a package to a new vesion which changes its API, this mechanism can easily find out the incompatibility to other packages which have dependency on it. || 2|| Review|| || dongxiao.xu|| Enhancement, replaced by checksum feature<br />
|-<br />
|| Distribution / components|| FOSSology|| This may be similar to License Update above, but start to use FOSSology to track licenses. || 2|| Review|| || sgw|| Hygiene<br />
|-<br />
|| Distribution / components|| Package Developer Tools|| Create a set of Init scripts template and then review our current init scripts and modify them to confirm to the template. || 2|| Review|| || sgw|| Easy of Use<br />
|-<br />
|| Distribution / components|| Package Website|| Complete the work the intern has started on generating the distro tracking information and get it out on the external site. || 2|| Review|| || sgw|| "Hygiene, duplicate of ""Package report system"""<br />
|-<br />
|| Distribution / components|| Bluetooth UI support|| Currently we have bluez package in poky, and we need to have a workable graphic user interface to connect/configure BT devices. One choice may be gnome-bluetooth-applet. || 3|| Review|| || dongxiao.xu|| enhancement<br />
|-<br />
|| Distribution / components|| Connman-gnome enhancement features|| Enable connman-gnome to support features like, WPA Enterprise connection, hidden SSID, etc. || 3|| Review|| || dongxiao.xu|| enhancement<br />
|-<br />
|| Distribution / components|| Java Running Environment support|| Since most embedded systems support java applications running in it, maybe we'd better consider supporting some kinds of JVMs(Embeded JVM). The JVM may not run by default, but user can launch it if running java applications. Compared with GTK/QT, java user number is not small too. || 3|| Review|| || criping|| enhancement<br />
|-<br />
|| Distribution / components|| create more use cases|| UPnP demo is one really good use case showing how Yocto is utilized to make real functionality. and we could create more to show how Yocto is easily adapted to real use cases. Those use cases can be either maintained as seperate demo layers in yocto repo, or in seperate branches for reference. We can also call for community's contribution on this which would make 1.0 full-fledged. Or else the newbies to Yocto may be in puzzle how our sample profiles can satisfy their requirements. || 2|| Review|| || ktian1|| enhancement<br />
|-<br />
|| Distribution / components|| i18n support || internationalization is an important system wide feature. Many component like font, locale affect the i18n. Yocto alreay has some i18n related package like pango, but so far did not consider i18n systematically. so this is place holder to systematically add i18n support. || 2|| Review|| || yuke/qing|| enhancement<br />
|-<br />
|| Distribution / components|| more demos || demos are a good way to educate, push the envelope, and at the same time tout the strengths of the platform. This item just records a current set of ideas from various sources which could/should be implemented: * face-recognition/face-finding, * robotic control/application of face-finding to 'camera-as-sensor' (hexbug demo), * others [tbd, add here]|| 2|| Review|| || tzanussi|| enhancement <br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer support for image-creator and needed yocto-metadata design||Come up design what need to be created as packages to support using "opkg install" for image-creator and needed yocto-metadata|| 2|| WIP, pending comments from RP regarding how to packaging metadata|| Jessica|| rpurdie|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer image-creator and needed poky-metadata support|| The poky build system will build packages for image-creator and needed poky-metadata, which the Yocto Installer will be able to use "opkg install" to install them|| 2|| Review|| Jessica|| rpurdie|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Provide qemu management UI|| In current eclipse plugin, QEMU settings are put together with project configuration. So we can only have limited settings. If we can have a separate QEMU management UI, the end user could firstly create a QEMU config, such as (env file of arch, image location, unfs or not, sato or lsb, mem size, disk size). And then he can launch a QEMU with a specific config. The dependency between project configuration and QEMU config will be resolved. After all QEMU has nothing to do project configuration. Need to careful review the UI to ensure minimal impact to testing matrix. || 3|| Review|| || criping|| "Enhancement, duplicate of ""Qemu mem/disk size can be adjusted"""<br />
|-<br />
|| Tool Development and SDK Features|| QT plugin For Eclipse|| Integrate QT Ecplise plugin and extend for Yocto Project || 3|| Review|| || jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Profiling/Trace GUI's|| We have a wealth of great tracing and profiling tools but the UI's for them are all extremely minimal and usually quite ugly. Would be great if we could compete with, or even better, Apple's offerings here. We have the technology! || 2|| Review|| || josh|| "Enhancement, duplicate of ""Tracing/Profiling Planning Complete"""<br />
|-<br />
|| Tool Development and SDK Features|| Other profiling tools|| Complete Tom's review of profiling tools and architecture || 2|| Review|| || josh|| "Enhancement, duplicate of ""Tracing/Profiling Planning Complete"""<br />
|-<br />
|| Tool Development and SDK Features|| Design next-gen tracing/profiling tools|| Yocto 1.0 will include all the essential existing tracing/profiling tools expected by users, and Josh has proposed a UI integration of all those tools as far as it's possible to do so. That level of integration, basically a 'plugin-level' integration is necessary and useful, but doesn't go far enough. A next-generation tracing tool would integrate at a much more fundamental level; if done properly, it would provide unmatched levels of power and usability to users, and would allow Yocto to distinguish itself in the embedded tracing/profiling space in a way also unmatched by any other distro/build-tool. The implementation would of course not be available for Yocto 1.0, but a coherent design, including prototypes, that could be taken to the community and implemented in a V 1.5 or 2.0 should be done in that time frame. || 1|| Review|| || tzanussi|| "Enhancement, duplicate of ""Tracing/Profiling Planning Complete"""<br />
|-<br />
|| Documentation Features|| Self Documentation of image contents|| "I'd like to see the -doc packages Poky builds being combined into some kind of large documentation index representing the collective API docs of the target being built. This can then be placed on a webserver and viewed over the web. We'd have a demonstration of this for a ""bitbake world"" target. Part of the idea here is to start making good use of the docs as if developers see this they might start writing better docs too. Aim is to lead the field :). There are a number of places poky packages disable doc generation due to missing tools so we'd need to add these so we can enable the doc generation. Many packages already have many docs though too. "|| 2|| Review|| || rpurdie|| enhancement<br />
|-<br />
|| Validation|| Testing Framework|| Add a framework for doing automated testing in the project|| 1|| Review|| || davest|| project commitment<br />
|-<br />
|| Validation|| more SDK builds on autobuilder|| enable more SDK related tests on autobuilder such as meta-ide-support, etc.|| 2|| Review|| || ktian1|| project commitment, addressed by test plan (?)<br />
|-<br />
|| Validation|| more people should try using SDK|| this may not be a feature, but a requirement. SDK including meta-toolchain is one key factor impacting user experience on Yocto. It's not enough to have only SDK team play with it|| 2|| Review|| || ktian1|| project commitment, addressed by test plan (?)<br />
|-<br />
|| Validation|| Unit Testing Framework|| Add a mechanism to bitbake to parse source packages that have unit tests and then execute them on the target|| 3|| Review|| || sgw|| "project commitment, duplicate of ""Testing Framework"""<br />
|-<br />
|| Validation|| Test Case open source|| Open source Yocto test cases with xml format|| 1|| Review|| || yyou|| "project commitment, duplicate of ""Testing Framework"""<br />
|}</div>Davesthttps://wiki.yoctoproject.org/wiki/index.php?title=Yocto_1.0_Schedule&diff=581Yocto 1.0 Schedule2011-01-25T01:25:14Z<p>Davest: /* Sprint C (closes Jan 14, 11:59pm PDT -- pull request sent, initially reviewed) */</p>
<hr />
<div>= v1.0 (release date: Apr 15, 2011) =<br />
----<br />
The detailed milestone map for v1.0 is as below. During the first week of each subsequent milestone past M1 we will have a demonstration of the previous milestone capabilities as well as a planning and design session for the current milestone.<br><br><br />
<br />
== M2 (Nov 08 to Dec 24 -- Dev Complete Dec 10, Stabilize Complete Dec 17, Release Complete Dec 24) ==<br />
=== Sprint A (closes Nov 12, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links''' <br />
|-<br />
|| Poky Features || Kernel interactive targets || To support incremental kernel development having the ability to run menuconfig (or xconfig, etc) directly is a common request. We'll need to add this for commercialization anyway. i.e. bitbake -c menuconfig. This fuctionality already exists. || 1 || Done || Richard || bruceashfield || Enhancement <br />
|-<br />
|| Distribution / components || Distro Audit: Upgrades Planned (Phase 1) || Complete plan for package upgrades in M2 || 1 || Done || Saul || || Continual Maintenance<br />
|-<br />
|| Validation || Runtime testing || Runtime testing of images as part of the autobuilder || 1 || Done || Jiajun/ScottG || rpurdie || project commitment<br />
|- <br />
|| || Poky Image Creator Wireframe/Interaction Plans Complete || || 1 || Done || Josh || ||<br />
|-<br />
|| || SDK Generator Interaction: Plans Complete || || 1 || Done || Jessica || ||<br />
|-<br />
|| || Tracing/Profiling Planning Complete || This needs to cover where we're at now, what we're missing and also propose the future enhancements that may be needed. M2 targets getting existing tools integrated and documented. F2f discussion n the future enhancements || || Done || Tom || ||<br />
|-<br />
|| || Swabber. (Still needs to be integrated into weekly build by default) || || 1 || Done || Josh || ||<br />
|-<br />
|| Build/Release || Release process documentation || || || Done || Beth || ||<br />
|-<br />
|| Validation || Test plan for v1.0 (to address any deficiencies in coverage from v0.9)|| || 1 || Done || Jiajun || ||<br />
|}<br />
<br />
=== Sprint B (closes Nov 19, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| Distro Audit: World Packages|| Audit world packages making sure it all build, making sure all are packages are required || 2|| Done || Saul|| sgw|| Hygiene<br />
|-<br />
|| Tool Development and SDK Features|| SDK Generator Installer UI|| Look at different ways of Installer UI (GTK+ and ncurses) seems none of them is the right choice, decide to go with script to implement all the functionalities of installer and later add UI part on top of it || 1||Done|| Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Customize sysroot setup || Add and test out "--sysroot" config option to cross compiler within Eclipse IDE || 1|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| SDK Generator Installer design revision|| Close all open questions regarding Yocto SDK Generator Installer function design and come up HLD || 1|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Distribution / components|| kernel version|| keeping 2.6.34 as a -stable kernel is the best option. I've also got a newer -devel tree that can be made available or made the default. || 3|| Done || Bruce|| bruceashfield|| enhancement<br />
|-<br />
|| || assign Yocto Project PM|| acquire and assign a program manager for Yocto Project|| || Done || DaveST|| || <br />
|-<br />
|| || assign Yocto Project Sys Admin|| || || Done || Saul|| || <br />
|-<br />
|| Tool Development and SDK Features|| oprofileUI|| Fixing various bugs of the oprofileUI to make it workable on big endian host.(i.e. ppc, mips) || 2 || Done || Jessica || lianhao.lu || Bug #382 / Bug #493<br />
|-<br />
|| Poky Feature|| SDK Version Control|| If we can expect that yocto SDK has lots of release in the future, we might need to consider SDK version control. Currently, every thing installed under /opt/poky which leads to things be overriden, we need to be able to use a scheme like /opt/poky-1.0, /opt/poky-2.0 to distiguish things. || 2|| Done || Josh|| jzhang|| Enhancement<br />
|-<br />
|| Kernel || Kernel plan complete || Flesh our kernel deliverables and add to Yocto 1.0 schedule || || Done|| Darren || dvhart ||<br />
|}<br />
<br />
=== Sprint C (closes Nov 26, 11:59pm PDT -- pull request sent, initially reviewed) :: NOTE: this is US Thanksgiving week ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| Distro Audit: Licence Checksums|| licence checksums || 1|| Done || Saul|| rpurdie|| Hygiene<br />
|-<br />
|| Poky Features || Performance Analysis Completed|| "I'd like someone to instrument a green release build, see where it spends time (hot/cold parsing time, individual task building time) and then compare this with our 0.9 release build. I'd also like to compare the disk usage between the two. Once we have a blame list we can then set about fixing it. Some things I know will come up: a) pseudo, b) checksums/signature code, c) exec() vs fork for executing tasks, d) task based prebuilds increasing disk usage, e) rpm dependency calculations, f) using rpm vs. ipk but I may be wrong and there may be others. We need numbers. "|| 1|| Done || Saul / Qing, Dongxiao|| rpurdie|| Enhancement<br />
|-<br />
|| Poky Features || environment variables for kernel builds|| switching a branch, or adding a configuration feature (and even changing the kernel repo) is often done during development of a BSP. Having some additional variables that are pass the bitbake environment scrub would be useful. i.e. KBRANCH=foo bitbake -c configure linux-yocto. This goes along with the other BSP bootstrapping suggestions. || 2|| Done || Bruce|| bruceashfield|| Enhancement<br />
|-<br />
|| Supported Targets|| ARM Platform Support|| Replace beagleboard with Beagleboard XM - decision || 2|| Done || Bruce|| alex|| Basic Yocto hardware support <br />
|-<br />
|| Distribution / components|| Security Process|| We need a dedicated person to scan and apply critical security updates to the distro. The MeeGo team already has a similar process with some scripts which may be leveraged. To complete the task, the process should be documented and a first pass over the metadata made to establish the current position on security. Any upgrades needed should be identified and a plan to address them should be in place but doesn't have to be implemented by this point.|| 1|| Done || ScottG|| ktian1|| enhancement<br />
|-<br />
|| Tool Development and SDK Features|| SDK Generator Installer Opkg repo design|| Come up a opkg repo design that will mimic the final Yocto package repo layout to be used by SDK Generator Installer to test against|| 2 || Done || Jessica || jzhang || <br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer tar creaion|| Create a Yocto Installer tar ball which contains Installer script and supported opkg component that will be used for installing other Yocto components|| 2 || Done || Jessica || jzhang || <br />
|-<br />
|| Documentation|| Kernel Framework Paper from WR|| The paper from WR needs to be re-written and then posted somewhere on the Yocto Project site. This will involve examiniation of the text and re-writing and formatting for presentation. Currently it is simply a text document. Completion time assuming uninterrupted time is one week.|| High|| Done || Scott Rifenbark|| 1 Week|| Documentation<br />
|-<br />
|| Documentation|| Poky Reference Manual|| This guide exists in the 0.9 form. The re-write of the text needs to be completed. So far, all the chapters have been rewritten but not re-posted on the site. Only the appendices remain for a text scrub. Time to complete this would be a week of uninterrupted time. Ideally, the manual would be a sub-manual that would be referenced and architected into the Yocto Project Development Guide.|| Medium|| Done|| Scott Rifenbark|| 1 Week|| Documentation<br />
|-<br />
|| Kernel || Initial meta-linaro layer || meta-linaro layer providing a kernel, tool-chain, and uboot loader. This deliverable is primarily to get the infrastructure in place and have a buildable kernel. Toolchain on best effort basis. || || Done || Darren || dvhart || Moderate risk of slippage due to holidays.<br />
|-<br />
|| Kernel || Tracing: blktrace and sysprof recipes || || || Done || Tom || dvhart ||<br />
|}<br />
<br />
=== Sprint D (closes Dec 3, 11:59pm PDT -- pull request sent, initially reviewed) :: NOTE: week of the F2F planning meeting ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Kernel || Kernel git branching structure revamped || || 1 || Done || Bruce || dvhart ||<br />
|-<br />
|| Kernel || Tunnel Creek (Crown Bay) || || 1 || Done || Tom || dvhart ||<br />
|}<br />
<br />
=== Sprint E (closes Dec 9 (THURSDAY), 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| Distro Audit: Upgrades Completed (Phase 1)|| Update to new versions as per the agreed plan for M2 from Sprint A|| 1|| Done || Saul|| rpurdie|| Continual Maintenance<br />
|-<br />
|| Distribution / components|| Distro Audit: Src Checksums|| Make sure all SRC_URI components have checksums too || 1|| Done || Saul|| rpurdie|| Hygiene<br />
|-<br />
|| Poky Features || enable KVM with qemu|| today all new Intel processors support VT, which are enabled on most desktop machines which are most frequently used build machine. with VT support, x86/x86-64 qemu target runs faster which is a good thing for emulation environment. This may require some qemu option tweaks and also poky-qemu script enhancement. || 2|| Done || Saul / Edwin|| ktian1|| Enhancement<br />
|-<br />
|| Kernel || New kernel recipes || dev, -devel, -custom || 3 || Done || Bruce || dvhart ||<br />
|-<br />
|| Swabber || Documentation for swabber || || 1 || Done || Alex || ||<br />
|-<br />
|| CCB || Defect triage process in public documented and implemented || || 1 || Done. Triage process is documented, out for review. || Saul || ||<br />
|}<br />
<br />
== M3 (Dec 20 to Feb 08 -- Dev Complete Feb 04, Stabilize Complete Feb 11, Release Complete Feb 18) ==<br />
=== Sprint A (closes Dec 24, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Kernel || Initial meta-rt layer || PREEMPT_RT kernel and related test-cases and benchmarks || 2 || Done by Jan 21 || Darren || dvhart || slipped out from M2<br />
|-<br />
|| Poky Features || Fetcher Overhaul Phase 1 - SRC_REV enhancement||<br />
* a) Add code in FetchData::__init__() which will check if the selected fetcher supports srcrev and the automatically call a function to set the src rev value instead of each fetcher doing this.\n <br />
* e) Break SRCREVINACTION deadlock. To do this, we need to start using a keyword for automatically increasing SRCREV, e.g. SRCREV = "AUTOINC". The actual revision can be injected into PV using SRCPV. If we do this there should no longer be a need of the deadlock; <br />
* k) Ensure that we only set __BB_DONT_CACHE when SRCREV = "AUTOREV". This may need a new method call for fetchers to tell whether they're "floating" or locked down.<br />
|| 1|| Done || Saul / Ke, RP|| rpurdie|| Enhancement, slipped out from M2<br />
|-<br />
|| Distribution / components|| Distro Audit Upgrades Planned (Phase 2)|| Complete plan for package upgrades in M2|| 1|| Done || Saul|| || Continual Maintenance<br />
|-<br />
|| Poky Features || Pseudo Performance || Implement the changes to bitbake based on pseudo's enable/disable switch|| 1|| done || Saul / Qing, Dongxiao || rpurdie|| Enhancement, slipped from M2 due to risk and not having Pseudo's change yet.<br />
|-<br />
|| Tool Development and SDK Features|| Fix the issue user target sysroot is owned by root || The ADT installer will use pseudo to extract user target sysroot which ended up owned by root, this need to be fixed || 1|| done || Jessica|| jzhang|| Cleanup <br />
|-<br />
|| Tool Development and SDK Features|| Eclipse poky tree interfacing (metadata file editor)|| Provide a metadata file editor with some syntax checking and keywords highlight capabilities|| 2|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| IDE Project templates|| Templates for various project types: Clutter GUI, Gtk+ GUI, to help developers get started quickly || 2|| Done || Jessica|| josh|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| push TCF/RSE patches upstream|| work with community to finish up our TCF terminal service, TCF/RSE integration remaining patches taken by upstream. Blocking issues including Eclipse Bug #327865 || 1|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Pseudo || Pseudo enhancement to enable on/off switch || || 1 || done || Mark || ||<br />
|-<br />
|| Pseudo || Bitbake enhancement for pseudo on/off switch || || 1 || done || Richard || ||<br />
|-<br />
|| bugzilla || Complete restructure of bugzilla categories || || 1 || done || Saul || ||<br />
|-<br />
|| Poky Features || Image creator ground work || Nomenclature determined, existing gui's bug fixed and backend work implemented || 1 || Done || Joshua || ||<br />
|-<br />
|| Kernel || Tracing: Initial SystemTap recipe || Works on x86 || 3 || Done || Tom || dvhart ||<br />
|-<br />
|| Distribution / components|| Distro Audit: Package Description/Summary completed|| Ensure DESCRIPTION/SUMMARY fields are all audited|| 2|| Done || Mark|| Mark|| Hygiene, was M2, Sprint B but missed window<br />
|-<br />
|| Distribution / components|| Zypper/RPM|| Small write-up of the problems we're having w/ Zypper and what we plan to do. (i.e. create a roadmap/design) - Includes rootfs generation - Package uprev/install/removal || 1 || Done || Mark/Qing || || was M2, Sprint B<br />
|-<br />
|| Distribution / components|| Distro Audit: Licence Checksums|| Make the licence checksums fatal if not present || 1|| Done || Saul|| rpurdie|| Hygiene, was M2, Sprint C<br />
|-<br />
|| Distribution / components|| push of all relevant Wind River patchs to Yocto (patch comparison)|| Ensure patches present to packages in WRS are also in Poky|| 1|| Done || Mark|| Mark|| was M2, Sprint C<br />
|-<br />
|| Poky Features || Performance Enhancement Completed || Initial changes to reduce disk space (sstate-build-*) || 1|| Done || Saul / Qing, Dongxiao || rpurdie|| Enhancement, was M2, Sprint E<br />
|-<br />
|| Distribution / components|| User specified qemu config support|| We'll provide user an edit box which allows advanced qemu user to specify arbitrary qemu configuration to meet their needs, which the poky-qemu scrip will just append the config list towards the end of the list of parameters to bring up qemu, it also expect the poky-qemu script to do some basic sanity check on the user specifications to catch the obvious mistake || 2|| Done || Saul / criping || criping|| enhancement, was M2, Sprint E<br />
|-<br />
|| Tool Development and SDK Features|| SDK Version Control support in SDK generator installer|| If we can expect that yocto SDK has lots of release in the future, we might need to consider SDK version control. Currently, if we un-tar the sdk, it will override the older version. It's not good for app developers since they might need the old version to do something. And also, maybe a finer installer than untar is preferred. Installer will tied to certain SDK version and the installation will go under /opt/poky-versionNo.|| 1|| Done || Jessica|| criping|| Enhancement-expect planning process by Jessica to handle this task. Was M2, Sprint E.<br />
|}<br />
<br />
=== Sprint B (closes Jan 07, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || Bitbake multi-threaded parsing|| Bitbake recipe parsing is currently single threaded. I want to make this multithreaded as the speedup would be nice. If I can only take a single task for myself for 1.0, I'm nominating this one as I enjoy this kind of thing and I have ideas on how to do it. || 1|| Done || Richard|| rpurdie|| Enhancement<br />
|-<br />
|| Distribution / components|| Lock in Kernel/Toolchain version|| Locked in 2.6.37 and gcc 4.5.1. Pending decision to move to 4.5.2 and Linaro || || Done || || Richard|| || <br />
|-<br />
|| Distribution / components|| License Update|| For each of the licences we support, I'd really like to have a licences directory with a copy of that license contained within. When it comes to deciding what a given LICENSE field means, this would be the reference. It also means we can include the licences a given image includes with the image. This continues to make our license handling world class and ahead of the field. || 2|| Done || Beth|| rpurdie|| Hygiene<br />
|-<br />
|| Tool Development and SDK Features|| Qemu configuration change|| Provice edit box for advanced user to specify qemu configurations|| 2|| Done || Jessica|| criping|| <br />
|-<br />
|| Tool Development and SDK Features|| Lock down Eclipse+CDT+TCF version|| Will use Eclipse Halo 3.6 || 1|| Done || Jessica|| || <br />
|-<br />
|| Demo|| Finalize on demo plans for v1.0 launch || || 1|| Done || Dave || || <br />
|-<br />
|| Release || Release plans for v1.0 launch || Fill out the M4 plan with the necessary release activities and timings || 1|| Done || Beth || || <br />
|-<br />
|| Poky Features || Basic image creator GUI || Functional UI missing some Advanced features || 1 || In replan || Joshua || || <br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer for SDK Generator Installation functions support||Detailed feature request can be found at: http://bugzilla.pokylinux.org/show_bug.cgi?id=589|| 1|| Done || Jessica|| rpurdie|| Enhancement<br />
|-<br />
|| Kernel || Tracing: trace-cmd python binding cleanup || || 3 || Done || Darren || dvhart ||<br />
|}<br />
<br />
=== Sprint C (closes Jan 14, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || kernel development layer|| The (correct) poky behaviour of building known revisions coupled with the fetcher requiring a BSP branch to already be present means that local modifications (and kernel source tree) are required for kernel development. I already have a layer that overrides/modifies the behaviour when added to the bblayers.conf and configured into an environment. This seems useful for more people to use. || 2|| Done || Bruce|| bruceashfield|| Enhancement, was M2, Sprint C<br />
|-<br />
|| Distribution / components|| Zypper/RPM|| RPM Uprev / Zypper Uprev [lets get to the latest versions]|| 1|| pull request by Jan 19; || Mark/Qing|| || was M2, Sprint C<br />
|-<br />
|| Supported Targets|| Intel Platform Support|| JasperForest|| 2|| Basic support in place; DPDK evaluation in process, overall BSP plan still TBD || Tom|| davest|| Basic ECG support (Moved from Sprint A)<br />
|-<br />
|| Tool Development and SDK Features|| Eclipse poky tree interfacing (git support)|| Use Eclipse git capability to install poky tree from git repo and able to interact with git repo at file level within Poky tree || 2|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Poky Features || DSO linking changes|| "By the default the gcc linker will automatically link any dependant objects/libraries. ""Inherited"" linkages can cause issues, for example, where a shared object changes its dependencies but a program has come to rely on symbols from an implicitly linked library. Fedora implemented this change in F13, seems like it would be useful to have in Poky too. "|| 2|| On track for Jan 21 || Saul / Nitin || josh|| bug#516<br />
|-<br />
|| Distribution / components|| Distro Audit Documentation Output|| Audit package documentation output || 2|| Move to Sprint D due to libtool work || Saul / ScottG || rpurdie|| Hygiene<br />
|-<br />
|| Poky Features || libtool sysroot option|| libtool 2.4 has a sysroot option. We should try and use it, see how it works and whether we can ditch some of our libtool hacks. || 1|| On track for Jan 21 || Saul / ScottG || rpurdie|| Enhancement<br />
|-<br />
|| Distribution / components|| MACHINE or Recipe specific sysroots|| Each machine should have its own sysroot. We'll probably have to split do_populate_sysroot into a two step process, creation of the package and than installtion of the package, which the installation of the package being made machine specific (put ${MACHINE} into ${STAMP} and bitbake should do that). Also allowing this to work per recipe would be desireable|| 1|| On track 21 || Saul / Dongxiao || rpurdie|| Hygiene<br />
|-<br />
|| Distribution / components|| Toolchain Bootstrap Process|| The toolchain as it bootstraps overwrites files like libc.so and libgcc.so in the sysroot directory which causes issues if you just try and rebuild part of the toolchain. Each step of the bootstrap process should use a separate sysroot. Once this is once, sstate file overwriting detection can be added and enabled. || 1|| Patches submitted for comment, slip to Sprint D || Saul / Dexuan || rpurdie|| Hygiene<br />
|-<br />
|| Poky Features || Poky Image Creator|| A standalone application you can run which asks you to select a distro and machine, then presents a list of packages you can select. Once the selection is made, it goes off and bakes you an image which is then presented to you. Implementation wise, it should use the sstate packages, be a bitbake UI and use the usual poky bbclass files to do the image construction behind the scenes. || 1|| Re-plan || Joshua|| rpurdie|| Enhancement<br />
|-<br />
|| Poky Features || Fetcher Overhaul Phase 3 - git enhancement||<br />
* j) Optimize git fetcher for the new layout so for a git checkout, we clone the repository in download(), then unpack just does a clone with references to the original repo. <br />
* k) Ensure that we only set __BB_DONT_CACHE when SRCREV = "AUTOREV". This may need a new method call for fetchers to tell whether they're "floating" or locked down. <br />
* l) Add a new "BB_NO_NETWORK" variable which the fetchers check before peforming an operation which hits anything remote. This means adding in error messages about why network access is needed at various points (e.g. SRCREV = "AUTOREV" for a given recipe) <br />
* m) Add multiple branch/srcrev support for git fetcher. These would be of the form: git://somelocation/somerepo.git;name=ref1;branch=foo;name=ref2;branch=bar SRCREV_ref1 = "hash1" SRCREV_ref2 = "hash2" which would ensure both hash1 and hash2 were in the final repo. <br />
* n) Change git fetcher to default to git protocol instead of rsync<br />
|| 1|| Slipped to Sprint D || Saul / Ke, RP|| rpurdie|| Enhancement<br />
<br />
|-<br />
|| Validation|| Boottime/Performance Analysis|| Compare Yocto Project performance to other projects such as MeeGo|| 1|| Initial report on where we are by Feb 9 || Darren|| davest|| project commitment <br />
|-<br />
|| Distribution / components|| LSB Sanity|| execute LSB Test and improve passing rate and document failures with clear understanding|| 2|| Done || MarkH/Saul|| sgw|| Hygiene<br />
|-<br />
|| Distribution / components|| Review & Fix Standards Tests|| Review the results from LTP, POSIX and asses the result, fix as appropriate and clearly document failures.|| 2|| a Plan to resolve final items to be sent to the m.l. by Jan 14 || Saul/Kevin || sgw|| Hygiene<br />
|-<br />
|| Tool Development and SDK Features|| Image creator integration with Eclipse || || 2|| replan|| Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Kernel || Tracing: perf trace marker support || This is from feedback to the new trace command. Ingo appears to have this nearly complete already. || 3 || Done || Darren || dvhart ||<br />
|-<br />
|| Kernel || Tracing: perf trace scripting support || || 3 || Move to Sprint D; on track for Jan 21 || Tom || dvhart ||<br />
|-<br />
|| Cleanup || bitbake user experience error handling validation completed || || 2 || Done || Richard || ||<br />
|-<br />
|| Cleanup || variable scrub - ensure all metadata variables are documented || Script with a histogram of variable use done, identified 50 variables to document; Add task for actual documentation update is low on the list || 2 || Done || Scott/Darren || ||<br />
|-<br />
|| Distribution / components|| Zypper/RPM|| Integration based on design from Sprint B|| 1|| On track for Jan28 || Mark/Qing|| sgw|| Functionality, was M2, Sprint E<br />
|-<br />
|| Kernel || Tracing: package kernelshark || || 3 || Done || Darren || dvhart ||<br />
|-<br />
|| Kernel || Tracing: tuna, oscillosope recipes || || 3 || Tom to discuss plan with Darren et al || Tom || dvhart ||<br />
|- <br />
|| BSP || Beagleboard XM Support || || 3 || Move to Sprint D || Darren || dvhart ||<br />
|}<br />
<br />
=== Sprint D (closes Jan 21, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Swabber || Complete review of swabber outputs || Move to M3 Sprint D || 1 || Move to M3 Sprint D || Alex || ||<br />
|-<br />
|| Documentation Features|| Package report system|| move to public server [setup a package report system in an internal machine. We need push it publicly available. The basic features like search and report have been there. But there're still some enhancements in plan, to make it a fit place to feel Yocto metadata comfortably]|| 2|| Move to Sprint E|| KevinT|| ktian1|| enhancement<br />
|-<br />
|| Distribution / components||Add headers and libraries to qemu images ||Since we'll be using qemu images as target sysroot, need to create a set of qemu images for minimal, sato, LSB that contains target header and libraries.|| 2|| Pending a discussion on Jan 18 || Saul ||jzhang|| Enhancement<br />
|-<br />
|| Distribution / components|| push of all relevant Wind River patchs to Yocto (patch comparison)|| Update any additional patches needed since M2.|| 1|| May be done by Jan 21, pending RPM stuff || Mark|| Mark|| <br />
|-<br />
|| Distribution / components|| mklibs|| mklibs is a tool to optimize size of [e]glibc for a perticular root file system image. It is useful to save disk space on small devices. || 2|| Push to Sprint E || Saul|| Nitin Kamble|| enhancement<br />
|-<br />
|| Poky Features || Performance Enhancement || reduce disk space (hardlink) || 1 || On track for Jan 21, pending RP review || Saul / Qing, Dongxiao || rpurdie || Enhancement<br />
|-<br />
|| BSP || 2.6.37 Crown Bay Support || On Track for Jan 21 || 2 || || Tom || dvhart || <br />
|-<br />
|| BSP || 2.6.37 Emenlow Support || On track for Jan 21 || 2 || || Tom || dvhart || <br />
|}<br />
<br />
=== Sprint E (closes Jan 28, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| rootless X|| rootless x server has better security than x server launched by root. MeeGo already enable this feature. it would be nice for Yocto to also enable it. || 2|| On track for Jan 28 || Saul / Ke || yuke|| enhancement<br />
|-<br />
|| Documentation Features|| Package report system|| finish major feature development and internal review [setup a package report system in an internal machine. We need push it publicly available. The basic features like search and report have been there. But there're still some enhancements in plan, to make it a fit place to feel Yocto metadata comfortably]|| 2|| Move to Sprint E || Jonathan || ktian1|| enhancement, was M2, Sprint E<br />
|-<br />
|| Distribution / components|| perl upgrade|| perl is the most cross un-friendly recipe pending upgrade. || 2|| Slipping due to Linaro layer, moves to end of Sprint E || Nitin|| Nitin Kamble|| enhancement<br />
|-<br />
|| Supported Targets|| Intel Platform Support|| Sandybridge|| 2|| Accept|| Tom|| davest|| Basic ECG support<br />
|-<br />
|| Distribution / components|| performance indicators|| define some indicators (boot time, footprint, build time, power, component benchmarks, etc.) and then collect them for tracking purpose. The result could be posted on the wiki site, and the initial indicators can be easy ones which can be easily retrieved from autobuilder or weekly qa report). This way we have a clear track about the healthy of the Yocto project, and also identify weak areas. We can include qemu targets and several representational boards as the targets. || 2|| Review|| Beth/Jiajun|| ktian1|| enhancement<br />
|-<br />
|| Tool Development and SDK Features|| SDK user workshop|| Have some developers sit down and use our tools to develop demo software for Yocto. || 2|| Review|| Jessica|| josh|| Enhancement<br />
|-<br />
|| Kernel || Final linux-yocto_git.bb || With 2.6.37 kernel || 1 || || Bruce || dvhart ||<br />
|-<br />
|| Kernel || Final meta-linaro layer || || || || Darren || dvhart ||<br />
|-<br />
|| Kernel || Final meta-rt layer || || || || Darren || dvhart ||<br />
|-<br />
|| Kernel || Sandy Bridge || || 1 || || Tom || dvhart ||<br />
|}<br />
<br />
=== Sprint F (closes Feb 03 (THURSDAY), 11:59pm PDT -- pull request sent, initially reviewed) :: NOTE: China New Year Holiday ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Documentation|| ADT Reference Guide Draft out for review || Outline complete|| High|| WIP || Scott Rifenbark|| jzhang|| Documentation<br />
|-<br />
|| || || || || || || || <br />
|}<br />
<br />
== M4 (Feb 07 to Apr 15 -- Stabilize Complete Mar 18, Release Complete Apr 01, Contingency to Apr 15) ==<br />
<br />
This sprint is the [[Yocto Project v. 1.0 Release Cycle]].<br />
<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Documentation|| Migration chapter in the Poky Reference Manual|| This chapter would cover the four identified use-cases for migrating up to the most recent version of Yocto Project. Additionally, it would cover migration scenarios from other development systems. The chapter does not yet exist. The chapter has not been scoped outside of having a meeting that identified four use-cases that did not include migration from a development system outside of Yocto Project. It will take some more scoping time to cover those areas (a day or two). Again, I have no idea of the length. See earlier entries for standard industry writing estimates for software documentation|| Medium|| Not Started|| Scott Rifenbark|| 3-4 Weeks|| Documentation<br />
|-<br />
|| Documentation|| Yocto Project Development Guide|| This manual would be an over-arching document that frames the complete development cycle within Yocto Project. The idea here is that the document would be an umbrella document that spawned and referenced subsequent documents. The organization would be the first chapter overviewing the major development pieces such as recipe creation, building, debugging, publishing, fail-safing, back-door hook creation, etc. Scoping would be about two weeks and length would probably be about 40 pages. Overall development time would likely be a month of uniterruped time.|| Medium|| Not Started|| Scott Rifenbark|| 3 Weeks|| Documentation<br />
|-<br />
|| || Multilib Support|| Consider developing post-1.0 branch || 1|| to start in M4 || Richard|| ||<br />
|-<br />
|| Validation|| Alpha testing complete|| 4-5 internal developers unfamiliar with Yocto Project try to do a build and report on the experience and issues encountered|| 1|| Done by Feb 18 || Julie|| davest|| <br />
|-<br />
|| || || || || || || || <br />
|}<br />
<br />
== Features needed and to be put into sprints by assigned owners: ==<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || package config option enhancement|| there're several enhancements we may do here: * allow users setting specific config options (local or global) from external tool, such as poky image creator, instead of changing recipes manually. Need a mechanism to convert from variable assignments into exact config options (e.g. feature_${PN} = ""1"" -> ""--enable-feature""). Consequently dependency chain needs update with option status. * host contamination check. We have swabber to check host contamination, but I'm not sure whether it covers configuration phase. If not, this is one area to improve, as not ususually we see configure script checks host bits for available features * conditional option manipulation. In many recipes we enable/disable one option based on availability of other packages. Now this is done manually and not flexible. this should be made automatically though some new annotation to indicate condition, or just base_contains (not convenient: long line, need define distro features) || 2|| Review|| Richard/MarkH|| ktian1|| Enhancement<br />
|-<br />
|| Media|| Yocto Project Awareness Video|| This 2.5 minute video would introduce and describe the benefits of Yocto Project. The video would use entertaining animations that described concepts and benefits. The result would be suitable for YouTube, conferences, and the website. The production is called an "Epipheo" and will be created by Epipheo Studios. The engagement process has begun and the kick-off meeting will be soon. The PO is in place. Time for development is 10 weeks.|| High|| Kick-off Imminent|| Scott Rifenbark|| 10 Weeks|| Media<br />
|-<br />
|| Documentation|| Yocto Project Debugging Guide|| This would be a guide for the debugging and bug tracking process in Yocto Project. Originally, the thought was that we needed a Bugzilla User's Manual. However, since we don't own Bugzilla it doesn't make sense to produce documentation for it. Rather, we should document the process as it fits into the Yocto Project environment. Ideally, the manual would be a sub-manual that would be referenced and architected into the Yocto Project Development Guide. The manual has not been scoped and would take a week to scope. Again, I have no idea of the length. See the previous item for standard industry writing estimates for software documenation.|| Medium|| Not Started|| Scott Rifenbark|| 3-4 Weeks|| Documentation<br />
|-<br />
|| Website|| Yocto Project Website|| The 0.9 website is in place but needs updates. Items for consideration are the left-panel naviagation scheme, a contributions guidance page, color-scheming and theme (possibly).|| Medium|| Not Started|| Scott Rifenbark|| 1-2 Weeks|| Website<br />
|}<br />
<br />
== Features not believed to be needed in v1.0: ==<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || OpenEmbedded/Bitbake Upstreaming|| "We firstly need to review where we are and where OE is. We then need to make a plan about what we're going to push upstream and what we're not. I'd suggest when we're in PRC, we do a crash course in ""dealing with OE"" and then many dedicate a block of time (a week) where the distro team comes up with a patch set we then propose and get merged into OE. I'd like to find a couple of interested people to monitor OE more regularly and start a workflow of things between Poky/OE where appropriate. The key thing to remember is we need to keep the architectures compatible. The team is now at the point where I'm happy for them to actually try building OpenEmbedded and not worry about it tainting them! "|| 2|| Review|| || rpurdie|| Process<br />
|-<br />
|| Poky Features || Handle old versions in WORKDIR|| an incremental build directory may finally include many old versions WORKDIRS. It'll be good to have those old versions tracked in the cache, which can then either generate a report or allow selectively cleaning up an specific version WORKDIR. Or else it's difficult to figure it out when people want to keep the whole tmp directory but like to cleanup some old bits when disk usage is under pressure. If it's not easy to do in bitbake, perhaps some separate scripts would be also helpful || 3|| Review|| || ktian1|| Enhancement<br />
|-<br />
|| Poky Features || run bitbake w/o rebuilding the cache|| "sometimes it's useful to allow run bitbake w/o re-parsing recipes, if we know nothing metadata is changed. we can just allow reusing existing persistent cache. this is useful when people is debugging WORKDIR w/o metadata change. also sometimes ""bitbake -e"" is used frequently to check poky variable information. with existing cache, several seconds can be saved which are not negligible for a developer daily working on Yocto "|| 2|| Review|| || ktian1|| Enhancement<br />
|-<br />
|| Poky Features || parallel make improvement|| parallel make experience is not good, especially when bb threads and make threads are increased larger than 8. So far we either try to fix package makefile or mark the recipe as no parallel make, when build faiures are reported. But this greatly impacts user experience for a successfully continuous build process. Could we define a safe number we do want to support for 1.0 release? and then have our autobuilder, QA test, and developers cover that number immediately and fix any issues accordingly. Then the safe number can be suggested to the Yocto user || 2|| Review|| || ktian1|| Enhancement<br />
|-<br />
|| Poky Features || Dependency packages rebuild/clean|| It is a mechanism to rebulid or clean a package and all other packages which have build/runtime dependency on it. With this change, we can find potential influences of package upgrade to its related packages, which can make the incremental build more trustable. For example, if we upgrade a package to a new vesion which changes its API, this mechanism can easily find out the incompatibility to other packages which have dependency on it. || 2|| Review|| || dongxiao.xu|| Enhancement, replaced by checksum feature<br />
|-<br />
|| Distribution / components|| FOSSology|| This may be similar to License Update above, but start to use FOSSology to track licenses. || 2|| Review|| || sgw|| Hygiene<br />
|-<br />
|| Distribution / components|| Package Developer Tools|| Create a set of Init scripts template and then review our current init scripts and modify them to confirm to the template. || 2|| Review|| || sgw|| Easy of Use<br />
|-<br />
|| Distribution / components|| Package Website|| Complete the work the intern has started on generating the distro tracking information and get it out on the external site. || 2|| Review|| || sgw|| "Hygiene, duplicate of ""Package report system"""<br />
|-<br />
|| Distribution / components|| Bluetooth UI support|| Currently we have bluez package in poky, and we need to have a workable graphic user interface to connect/configure BT devices. One choice may be gnome-bluetooth-applet. || 3|| Review|| || dongxiao.xu|| enhancement<br />
|-<br />
|| Distribution / components|| Connman-gnome enhancement features|| Enable connman-gnome to support features like, WPA Enterprise connection, hidden SSID, etc. || 3|| Review|| || dongxiao.xu|| enhancement<br />
|-<br />
|| Distribution / components|| Java Running Environment support|| Since most embedded systems support java applications running in it, maybe we'd better consider supporting some kinds of JVMs(Embeded JVM). The JVM may not run by default, but user can launch it if running java applications. Compared with GTK/QT, java user number is not small too. || 3|| Review|| || criping|| enhancement<br />
|-<br />
|| Distribution / components|| create more use cases|| UPnP demo is one really good use case showing how Yocto is utilized to make real functionality. and we could create more to show how Yocto is easily adapted to real use cases. Those use cases can be either maintained as seperate demo layers in yocto repo, or in seperate branches for reference. We can also call for community's contribution on this which would make 1.0 full-fledged. Or else the newbies to Yocto may be in puzzle how our sample profiles can satisfy their requirements. || 2|| Review|| || ktian1|| enhancement<br />
|-<br />
|| Distribution / components|| i18n support || internationalization is an important system wide feature. Many component like font, locale affect the i18n. Yocto alreay has some i18n related package like pango, but so far did not consider i18n systematically. so this is place holder to systematically add i18n support. || 2|| Review|| || yuke/qing|| enhancement<br />
|-<br />
|| Distribution / components|| more demos || demos are a good way to educate, push the envelope, and at the same time tout the strengths of the platform. This item just records a current set of ideas from various sources which could/should be implemented: * face-recognition/face-finding, * robotic control/application of face-finding to 'camera-as-sensor' (hexbug demo), * others [tbd, add here]|| 2|| Review|| || tzanussi|| enhancement <br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer support for image-creator and needed yocto-metadata design||Come up design what need to be created as packages to support using "opkg install" for image-creator and needed yocto-metadata|| 2|| WIP, pending comments from RP regarding how to packaging metadata|| Jessica|| rpurdie|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer image-creator and needed poky-metadata support|| The poky build system will build packages for image-creator and needed poky-metadata, which the Yocto Installer will be able to use "opkg install" to install them|| 2|| Review|| Jessica|| rpurdie|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Provide qemu management UI|| In current eclipse plugin, QEMU settings are put together with project configuration. So we can only have limited settings. If we can have a separate QEMU management UI, the end user could firstly create a QEMU config, such as (env file of arch, image location, unfs or not, sato or lsb, mem size, disk size). And then he can launch a QEMU with a specific config. The dependency between project configuration and QEMU config will be resolved. After all QEMU has nothing to do project configuration. Need to careful review the UI to ensure minimal impact to testing matrix. || 3|| Review|| || criping|| "Enhancement, duplicate of ""Qemu mem/disk size can be adjusted"""<br />
|-<br />
|| Tool Development and SDK Features|| QT plugin For Eclipse|| Integrate QT Ecplise plugin and extend for Yocto Project || 3|| Review|| || jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Profiling/Trace GUI's|| We have a wealth of great tracing and profiling tools but the UI's for them are all extremely minimal and usually quite ugly. Would be great if we could compete with, or even better, Apple's offerings here. We have the technology! || 2|| Review|| || josh|| "Enhancement, duplicate of ""Tracing/Profiling Planning Complete"""<br />
|-<br />
|| Tool Development and SDK Features|| Other profiling tools|| Complete Tom's review of profiling tools and architecture || 2|| Review|| || josh|| "Enhancement, duplicate of ""Tracing/Profiling Planning Complete"""<br />
|-<br />
|| Tool Development and SDK Features|| Design next-gen tracing/profiling tools|| Yocto 1.0 will include all the essential existing tracing/profiling tools expected by users, and Josh has proposed a UI integration of all those tools as far as it's possible to do so. That level of integration, basically a 'plugin-level' integration is necessary and useful, but doesn't go far enough. A next-generation tracing tool would integrate at a much more fundamental level; if done properly, it would provide unmatched levels of power and usability to users, and would allow Yocto to distinguish itself in the embedded tracing/profiling space in a way also unmatched by any other distro/build-tool. The implementation would of course not be available for Yocto 1.0, but a coherent design, including prototypes, that could be taken to the community and implemented in a V 1.5 or 2.0 should be done in that time frame. || 1|| Review|| || tzanussi|| "Enhancement, duplicate of ""Tracing/Profiling Planning Complete"""<br />
|-<br />
|| Documentation Features|| Self Documentation of image contents|| "I'd like to see the -doc packages Poky builds being combined into some kind of large documentation index representing the collective API docs of the target being built. This can then be placed on a webserver and viewed over the web. We'd have a demonstration of this for a ""bitbake world"" target. Part of the idea here is to start making good use of the docs as if developers see this they might start writing better docs too. Aim is to lead the field :). There are a number of places poky packages disable doc generation due to missing tools so we'd need to add these so we can enable the doc generation. Many packages already have many docs though too. "|| 2|| Review|| || rpurdie|| enhancement<br />
|-<br />
|| Validation|| Testing Framework|| Add a framework for doing automated testing in the project|| 1|| Review|| || davest|| project commitment<br />
|-<br />
|| Validation|| more SDK builds on autobuilder|| enable more SDK related tests on autobuilder such as meta-ide-support, etc.|| 2|| Review|| || ktian1|| project commitment, addressed by test plan (?)<br />
|-<br />
|| Validation|| more people should try using SDK|| this may not be a feature, but a requirement. SDK including meta-toolchain is one key factor impacting user experience on Yocto. It's not enough to have only SDK team play with it|| 2|| Review|| || ktian1|| project commitment, addressed by test plan (?)<br />
|-<br />
|| Validation|| Unit Testing Framework|| Add a mechanism to bitbake to parse source packages that have unit tests and then execute them on the target|| 3|| Review|| || sgw|| "project commitment, duplicate of ""Testing Framework"""<br />
|-<br />
|| Validation|| Test Case open source|| Open source Yocto test cases with xml format|| 1|| Review|| || yyou|| "project commitment, duplicate of ""Testing Framework"""<br />
|}</div>Davesthttps://wiki.yoctoproject.org/wiki/index.php?title=Yocto_1.0_Schedule&diff=580Yocto 1.0 Schedule2011-01-25T01:20:55Z<p>Davest: /* Sprint B (closes Jan 07, 11:59pm PDT -- pull request sent, initially reviewed) */</p>
<hr />
<div>= v1.0 (release date: Apr 15, 2011) =<br />
----<br />
The detailed milestone map for v1.0 is as below. During the first week of each subsequent milestone past M1 we will have a demonstration of the previous milestone capabilities as well as a planning and design session for the current milestone.<br><br><br />
<br />
== M2 (Nov 08 to Dec 24 -- Dev Complete Dec 10, Stabilize Complete Dec 17, Release Complete Dec 24) ==<br />
=== Sprint A (closes Nov 12, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links''' <br />
|-<br />
|| Poky Features || Kernel interactive targets || To support incremental kernel development having the ability to run menuconfig (or xconfig, etc) directly is a common request. We'll need to add this for commercialization anyway. i.e. bitbake -c menuconfig. This fuctionality already exists. || 1 || Done || Richard || bruceashfield || Enhancement <br />
|-<br />
|| Distribution / components || Distro Audit: Upgrades Planned (Phase 1) || Complete plan for package upgrades in M2 || 1 || Done || Saul || || Continual Maintenance<br />
|-<br />
|| Validation || Runtime testing || Runtime testing of images as part of the autobuilder || 1 || Done || Jiajun/ScottG || rpurdie || project commitment<br />
|- <br />
|| || Poky Image Creator Wireframe/Interaction Plans Complete || || 1 || Done || Josh || ||<br />
|-<br />
|| || SDK Generator Interaction: Plans Complete || || 1 || Done || Jessica || ||<br />
|-<br />
|| || Tracing/Profiling Planning Complete || This needs to cover where we're at now, what we're missing and also propose the future enhancements that may be needed. M2 targets getting existing tools integrated and documented. F2f discussion n the future enhancements || || Done || Tom || ||<br />
|-<br />
|| || Swabber. (Still needs to be integrated into weekly build by default) || || 1 || Done || Josh || ||<br />
|-<br />
|| Build/Release || Release process documentation || || || Done || Beth || ||<br />
|-<br />
|| Validation || Test plan for v1.0 (to address any deficiencies in coverage from v0.9)|| || 1 || Done || Jiajun || ||<br />
|}<br />
<br />
=== Sprint B (closes Nov 19, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| Distro Audit: World Packages|| Audit world packages making sure it all build, making sure all are packages are required || 2|| Done || Saul|| sgw|| Hygiene<br />
|-<br />
|| Tool Development and SDK Features|| SDK Generator Installer UI|| Look at different ways of Installer UI (GTK+ and ncurses) seems none of them is the right choice, decide to go with script to implement all the functionalities of installer and later add UI part on top of it || 1||Done|| Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Customize sysroot setup || Add and test out "--sysroot" config option to cross compiler within Eclipse IDE || 1|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| SDK Generator Installer design revision|| Close all open questions regarding Yocto SDK Generator Installer function design and come up HLD || 1|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Distribution / components|| kernel version|| keeping 2.6.34 as a -stable kernel is the best option. I've also got a newer -devel tree that can be made available or made the default. || 3|| Done || Bruce|| bruceashfield|| enhancement<br />
|-<br />
|| || assign Yocto Project PM|| acquire and assign a program manager for Yocto Project|| || Done || DaveST|| || <br />
|-<br />
|| || assign Yocto Project Sys Admin|| || || Done || Saul|| || <br />
|-<br />
|| Tool Development and SDK Features|| oprofileUI|| Fixing various bugs of the oprofileUI to make it workable on big endian host.(i.e. ppc, mips) || 2 || Done || Jessica || lianhao.lu || Bug #382 / Bug #493<br />
|-<br />
|| Poky Feature|| SDK Version Control|| If we can expect that yocto SDK has lots of release in the future, we might need to consider SDK version control. Currently, every thing installed under /opt/poky which leads to things be overriden, we need to be able to use a scheme like /opt/poky-1.0, /opt/poky-2.0 to distiguish things. || 2|| Done || Josh|| jzhang|| Enhancement<br />
|-<br />
|| Kernel || Kernel plan complete || Flesh our kernel deliverables and add to Yocto 1.0 schedule || || Done|| Darren || dvhart ||<br />
|}<br />
<br />
=== Sprint C (closes Nov 26, 11:59pm PDT -- pull request sent, initially reviewed) :: NOTE: this is US Thanksgiving week ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| Distro Audit: Licence Checksums|| licence checksums || 1|| Done || Saul|| rpurdie|| Hygiene<br />
|-<br />
|| Poky Features || Performance Analysis Completed|| "I'd like someone to instrument a green release build, see where it spends time (hot/cold parsing time, individual task building time) and then compare this with our 0.9 release build. I'd also like to compare the disk usage between the two. Once we have a blame list we can then set about fixing it. Some things I know will come up: a) pseudo, b) checksums/signature code, c) exec() vs fork for executing tasks, d) task based prebuilds increasing disk usage, e) rpm dependency calculations, f) using rpm vs. ipk but I may be wrong and there may be others. We need numbers. "|| 1|| Done || Saul / Qing, Dongxiao|| rpurdie|| Enhancement<br />
|-<br />
|| Poky Features || environment variables for kernel builds|| switching a branch, or adding a configuration feature (and even changing the kernel repo) is often done during development of a BSP. Having some additional variables that are pass the bitbake environment scrub would be useful. i.e. KBRANCH=foo bitbake -c configure linux-yocto. This goes along with the other BSP bootstrapping suggestions. || 2|| Done || Bruce|| bruceashfield|| Enhancement<br />
|-<br />
|| Supported Targets|| ARM Platform Support|| Replace beagleboard with Beagleboard XM - decision || 2|| Done || Bruce|| alex|| Basic Yocto hardware support <br />
|-<br />
|| Distribution / components|| Security Process|| We need a dedicated person to scan and apply critical security updates to the distro. The MeeGo team already has a similar process with some scripts which may be leveraged. To complete the task, the process should be documented and a first pass over the metadata made to establish the current position on security. Any upgrades needed should be identified and a plan to address them should be in place but doesn't have to be implemented by this point.|| 1|| Done || ScottG|| ktian1|| enhancement<br />
|-<br />
|| Tool Development and SDK Features|| SDK Generator Installer Opkg repo design|| Come up a opkg repo design that will mimic the final Yocto package repo layout to be used by SDK Generator Installer to test against|| 2 || Done || Jessica || jzhang || <br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer tar creaion|| Create a Yocto Installer tar ball which contains Installer script and supported opkg component that will be used for installing other Yocto components|| 2 || Done || Jessica || jzhang || <br />
|-<br />
|| Documentation|| Kernel Framework Paper from WR|| The paper from WR needs to be re-written and then posted somewhere on the Yocto Project site. This will involve examiniation of the text and re-writing and formatting for presentation. Currently it is simply a text document. Completion time assuming uninterrupted time is one week.|| High|| Done || Scott Rifenbark|| 1 Week|| Documentation<br />
|-<br />
|| Documentation|| Poky Reference Manual|| This guide exists in the 0.9 form. The re-write of the text needs to be completed. So far, all the chapters have been rewritten but not re-posted on the site. Only the appendices remain for a text scrub. Time to complete this would be a week of uninterrupted time. Ideally, the manual would be a sub-manual that would be referenced and architected into the Yocto Project Development Guide.|| Medium|| Done|| Scott Rifenbark|| 1 Week|| Documentation<br />
|-<br />
|| Kernel || Initial meta-linaro layer || meta-linaro layer providing a kernel, tool-chain, and uboot loader. This deliverable is primarily to get the infrastructure in place and have a buildable kernel. Toolchain on best effort basis. || || Done || Darren || dvhart || Moderate risk of slippage due to holidays.<br />
|-<br />
|| Kernel || Tracing: blktrace and sysprof recipes || || || Done || Tom || dvhart ||<br />
|}<br />
<br />
=== Sprint D (closes Dec 3, 11:59pm PDT -- pull request sent, initially reviewed) :: NOTE: week of the F2F planning meeting ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Kernel || Kernel git branching structure revamped || || 1 || Done || Bruce || dvhart ||<br />
|-<br />
|| Kernel || Tunnel Creek (Crown Bay) || || 1 || Done || Tom || dvhart ||<br />
|}<br />
<br />
=== Sprint E (closes Dec 9 (THURSDAY), 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| Distro Audit: Upgrades Completed (Phase 1)|| Update to new versions as per the agreed plan for M2 from Sprint A|| 1|| Done || Saul|| rpurdie|| Continual Maintenance<br />
|-<br />
|| Distribution / components|| Distro Audit: Src Checksums|| Make sure all SRC_URI components have checksums too || 1|| Done || Saul|| rpurdie|| Hygiene<br />
|-<br />
|| Poky Features || enable KVM with qemu|| today all new Intel processors support VT, which are enabled on most desktop machines which are most frequently used build machine. with VT support, x86/x86-64 qemu target runs faster which is a good thing for emulation environment. This may require some qemu option tweaks and also poky-qemu script enhancement. || 2|| Done || Saul / Edwin|| ktian1|| Enhancement<br />
|-<br />
|| Kernel || New kernel recipes || dev, -devel, -custom || 3 || Done || Bruce || dvhart ||<br />
|-<br />
|| Swabber || Documentation for swabber || || 1 || Done || Alex || ||<br />
|-<br />
|| CCB || Defect triage process in public documented and implemented || || 1 || Done. Triage process is documented, out for review. || Saul || ||<br />
|}<br />
<br />
== M3 (Dec 20 to Feb 08 -- Dev Complete Feb 04, Stabilize Complete Feb 11, Release Complete Feb 18) ==<br />
=== Sprint A (closes Dec 24, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Kernel || Initial meta-rt layer || PREEMPT_RT kernel and related test-cases and benchmarks || 2 || Done by Jan 21 || Darren || dvhart || slipped out from M2<br />
|-<br />
|| Poky Features || Fetcher Overhaul Phase 1 - SRC_REV enhancement||<br />
* a) Add code in FetchData::__init__() which will check if the selected fetcher supports srcrev and the automatically call a function to set the src rev value instead of each fetcher doing this.\n <br />
* e) Break SRCREVINACTION deadlock. To do this, we need to start using a keyword for automatically increasing SRCREV, e.g. SRCREV = "AUTOINC". The actual revision can be injected into PV using SRCPV. If we do this there should no longer be a need of the deadlock; <br />
* k) Ensure that we only set __BB_DONT_CACHE when SRCREV = "AUTOREV". This may need a new method call for fetchers to tell whether they're "floating" or locked down.<br />
|| 1|| Done || Saul / Ke, RP|| rpurdie|| Enhancement, slipped out from M2<br />
|-<br />
|| Distribution / components|| Distro Audit Upgrades Planned (Phase 2)|| Complete plan for package upgrades in M2|| 1|| Done || Saul|| || Continual Maintenance<br />
|-<br />
|| Poky Features || Pseudo Performance || Implement the changes to bitbake based on pseudo's enable/disable switch|| 1|| done || Saul / Qing, Dongxiao || rpurdie|| Enhancement, slipped from M2 due to risk and not having Pseudo's change yet.<br />
|-<br />
|| Tool Development and SDK Features|| Fix the issue user target sysroot is owned by root || The ADT installer will use pseudo to extract user target sysroot which ended up owned by root, this need to be fixed || 1|| done || Jessica|| jzhang|| Cleanup <br />
|-<br />
|| Tool Development and SDK Features|| Eclipse poky tree interfacing (metadata file editor)|| Provide a metadata file editor with some syntax checking and keywords highlight capabilities|| 2|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| IDE Project templates|| Templates for various project types: Clutter GUI, Gtk+ GUI, to help developers get started quickly || 2|| Done || Jessica|| josh|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| push TCF/RSE patches upstream|| work with community to finish up our TCF terminal service, TCF/RSE integration remaining patches taken by upstream. Blocking issues including Eclipse Bug #327865 || 1|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Pseudo || Pseudo enhancement to enable on/off switch || || 1 || done || Mark || ||<br />
|-<br />
|| Pseudo || Bitbake enhancement for pseudo on/off switch || || 1 || done || Richard || ||<br />
|-<br />
|| bugzilla || Complete restructure of bugzilla categories || || 1 || done || Saul || ||<br />
|-<br />
|| Poky Features || Image creator ground work || Nomenclature determined, existing gui's bug fixed and backend work implemented || 1 || Done || Joshua || ||<br />
|-<br />
|| Kernel || Tracing: Initial SystemTap recipe || Works on x86 || 3 || Done || Tom || dvhart ||<br />
|-<br />
|| Distribution / components|| Distro Audit: Package Description/Summary completed|| Ensure DESCRIPTION/SUMMARY fields are all audited|| 2|| Done || Mark|| Mark|| Hygiene, was M2, Sprint B but missed window<br />
|-<br />
|| Distribution / components|| Zypper/RPM|| Small write-up of the problems we're having w/ Zypper and what we plan to do. (i.e. create a roadmap/design) - Includes rootfs generation - Package uprev/install/removal || 1 || Done || Mark/Qing || || was M2, Sprint B<br />
|-<br />
|| Distribution / components|| Distro Audit: Licence Checksums|| Make the licence checksums fatal if not present || 1|| Done || Saul|| rpurdie|| Hygiene, was M2, Sprint C<br />
|-<br />
|| Distribution / components|| push of all relevant Wind River patchs to Yocto (patch comparison)|| Ensure patches present to packages in WRS are also in Poky|| 1|| Done || Mark|| Mark|| was M2, Sprint C<br />
|-<br />
|| Poky Features || Performance Enhancement Completed || Initial changes to reduce disk space (sstate-build-*) || 1|| Done || Saul / Qing, Dongxiao || rpurdie|| Enhancement, was M2, Sprint E<br />
|-<br />
|| Distribution / components|| User specified qemu config support|| We'll provide user an edit box which allows advanced qemu user to specify arbitrary qemu configuration to meet their needs, which the poky-qemu scrip will just append the config list towards the end of the list of parameters to bring up qemu, it also expect the poky-qemu script to do some basic sanity check on the user specifications to catch the obvious mistake || 2|| Done || Saul / criping || criping|| enhancement, was M2, Sprint E<br />
|-<br />
|| Tool Development and SDK Features|| SDK Version Control support in SDK generator installer|| If we can expect that yocto SDK has lots of release in the future, we might need to consider SDK version control. Currently, if we un-tar the sdk, it will override the older version. It's not good for app developers since they might need the old version to do something. And also, maybe a finer installer than untar is preferred. Installer will tied to certain SDK version and the installation will go under /opt/poky-versionNo.|| 1|| Done || Jessica|| criping|| Enhancement-expect planning process by Jessica to handle this task. Was M2, Sprint E.<br />
|}<br />
<br />
=== Sprint B (closes Jan 07, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || Bitbake multi-threaded parsing|| Bitbake recipe parsing is currently single threaded. I want to make this multithreaded as the speedup would be nice. If I can only take a single task for myself for 1.0, I'm nominating this one as I enjoy this kind of thing and I have ideas on how to do it. || 1|| Done || Richard|| rpurdie|| Enhancement<br />
|-<br />
|| Distribution / components|| Lock in Kernel/Toolchain version|| Locked in 2.6.37 and gcc 4.5.1. Pending decision to move to 4.5.2 and Linaro || || Done || || Richard|| || <br />
|-<br />
|| Distribution / components|| License Update|| For each of the licences we support, I'd really like to have a licences directory with a copy of that license contained within. When it comes to deciding what a given LICENSE field means, this would be the reference. It also means we can include the licences a given image includes with the image. This continues to make our license handling world class and ahead of the field. || 2|| Done || Beth|| rpurdie|| Hygiene<br />
|-<br />
|| Tool Development and SDK Features|| Qemu configuration change|| Provice edit box for advanced user to specify qemu configurations|| 2|| Done || Jessica|| criping|| <br />
|-<br />
|| Tool Development and SDK Features|| Lock down Eclipse+CDT+TCF version|| Will use Eclipse Halo 3.6 || 1|| Done || Jessica|| || <br />
|-<br />
|| Demo|| Finalize on demo plans for v1.0 launch || || 1|| Done || Dave || || <br />
|-<br />
|| Release || Release plans for v1.0 launch || Fill out the M4 plan with the necessary release activities and timings || 1|| Done || Beth || || <br />
|-<br />
|| Poky Features || Basic image creator GUI || Functional UI missing some Advanced features || 1 || In replan || Joshua || || <br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer for SDK Generator Installation functions support||Detailed feature request can be found at: http://bugzilla.pokylinux.org/show_bug.cgi?id=589|| 1|| Done || Jessica|| rpurdie|| Enhancement<br />
|-<br />
|| Kernel || Tracing: trace-cmd python binding cleanup || || 3 || Done || Darren || dvhart ||<br />
|}<br />
<br />
=== Sprint C (closes Jan 14, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || kernel development layer|| The (correct) poky behaviour of building known revisions coupled with the fetcher requiring a BSP branch to already be present means that local modifications (and kernel source tree) are required for kernel development. I already have a layer that overrides/modifies the behaviour when added to the bblayers.conf and configured into an environment. This seems useful for more people to use. || 2|| Done || Bruce|| bruceashfield|| Enhancement, was M2, Sprint C<br />
|-<br />
|| Distribution / components|| Zypper/RPM|| RPM Uprev / Zypper Uprev [lets get to the latest versions]|| 1|| pull request by Jan 19; || Mark/Qing|| || was M2, Sprint C<br />
|-<br />
|| Supported Targets|| Intel Platform Support|| JasperForest|| 2|| Basic support in place; DPDK evaluation in process, overall BSP plan still TBD || Tom|| davest|| Basic ECG support (Moved from Sprint A)<br />
|-<br />
|| Tool Development and SDK Features|| Eclipse poky tree interfacing (git support)|| Use Eclipse git capability to install poky tree from git repo and able to interact with git repo at file level within Poky tree || 2|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Poky Features || Fetcher Overhaul Phase 2 - API reorg||<br />
* f) Add a generic unpack funciton to __init__.py based on the unpack task in Poky ;<br />
* g) Split go() methods into the following steps: i) download() - do whatever transfer is necessary to get the sources locally ii) build_mirror_data() - generate any data that would be needed to construct a source mirror iii) unpack() - takes a directory as an argument of where to place extracted sources;<br />
The existing go() methods should be replaced with a set of calls to the above sections of functionality as appropriate in the individual fetchers. Some of these categories of function make no sense in certain fetchers, in which case they shouldn't need to implement them. Functions are only executed if the method is present.<br />
* h) Change Poky's unpack to call an unpack method in the fetchers.<br />
* i) Change Poky's fetch task to call a "download" method in the fetcher instead of go().<br />
|| 1|| Will land with phase 3 in Jan 21 || Saul / Ke, RP|| rpurdie|| Enhancement<br />
|-<br />
|| Poky Features || DSO linking changes|| "By the default the gcc linker will automatically link any dependant objects/libraries. ""Inherited"" linkages can cause issues, for example, where a shared object changes its dependencies but a program has come to rely on symbols from an implicitly linked library. Fedora implemented this change in F13, seems like it would be useful to have in Poky too. "|| 2|| On track for Jan 21 || Saul / Nitin || josh|| bug#516<br />
|-<br />
|| Distribution / components|| Distro Audit Documentation Output|| Audit package documentation output || 2|| Move to Sprint D due to libtool work || Saul / ScottG || rpurdie|| Hygiene<br />
|-<br />
|| Poky Features || libtool sysroot option|| libtool 2.4 has a sysroot option. We should try and use it, see how it works and whether we can ditch some of our libtool hacks. || 1|| On track for Jan 21 || Saul / ScottG || rpurdie|| Enhancement<br />
|-<br />
|| Distribution / components|| MACHINE or Recipe specific sysroots|| Each machine should have its own sysroot. We'll probably have to split do_populate_sysroot into a two step process, creation of the package and than installtion of the package, which the installation of the package being made machine specific (put ${MACHINE} into ${STAMP} and bitbake should do that). Also allowing this to work per recipe would be desireable|| 1|| On track 21 || Saul / Dongxiao || rpurdie|| Hygiene<br />
|-<br />
|| Distribution / components|| Toolchain Bootstrap Process|| The toolchain as it bootstraps overwrites files like libc.so and libgcc.so in the sysroot directory which causes issues if you just try and rebuild part of the toolchain. Each step of the bootstrap process should use a separate sysroot. Once this is once, sstate file overwriting detection can be added and enabled. || 1|| Patches submitted for comment, slip to Sprint D || Saul / Dexuan || rpurdie|| Hygiene<br />
|-<br />
|| Poky Features || Poky Image Creator|| A standalone application you can run which asks you to select a distro and machine, then presents a list of packages you can select. Once the selection is made, it goes off and bakes you an image which is then presented to you. Implementation wise, it should use the sstate packages, be a bitbake UI and use the usual poky bbclass files to do the image construction behind the scenes. || 1|| Re-plan || Joshua|| rpurdie|| Enhancement<br />
|-<br />
|| Poky Features || Fetcher Overhaul Phase 3 - git enhancement||<br />
* j) Optimize git fetcher for the new layout so for a git checkout, we clone the repository in download(), then unpack just does a clone with references to the original repo. <br />
* k) Ensure that we only set __BB_DONT_CACHE when SRCREV = "AUTOREV". This may need a new method call for fetchers to tell whether they're "floating" or locked down. <br />
* l) Add a new "BB_NO_NETWORK" variable which the fetchers check before peforming an operation which hits anything remote. This means adding in error messages about why network access is needed at various points (e.g. SRCREV = "AUTOREV" for a given recipe) <br />
* m) Add multiple branch/srcrev support for git fetcher. These would be of the form: git://somelocation/somerepo.git;name=ref1;branch=foo;name=ref2;branch=bar SRCREV_ref1 = "hash1" SRCREV_ref2 = "hash2" which would ensure both hash1 and hash2 were in the final repo. <br />
* n) Change git fetcher to default to git protocol instead of rsync<br />
|| 1|| Slipped to Sprint D || Saul / Ke, RP|| rpurdie|| Enhancement<br />
<br />
|-<br />
|| Validation|| Boottime/Performance Analysis|| Compare Yocto Project performance to other projects such as MeeGo|| 1|| Initial report on where we are by Feb 9 || Darren|| davest|| project commitment <br />
|-<br />
|| Distribution / components|| LSB Sanity|| execute LSB Test and improve passing rate and document failures with clear understanding|| 2|| Done || MarkH/Saul|| sgw|| Hygiene<br />
|-<br />
|| Distribution / components|| Review & Fix Standards Tests|| Review the results from LTP, POSIX and asses the result, fix as appropriate and clearly document failures.|| 2|| a Plan to resolve final items to be sent to the m.l. by Jan 14 || Saul/Kevin || sgw|| Hygiene<br />
|-<br />
|| Tool Development and SDK Features|| Image creator integration with Eclipse || || 2|| replan|| Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Kernel || Tracing: perf trace marker support || This is from feedback to the new trace command. Ingo appears to have this nearly complete already. || 3 || Done || Darren || dvhart ||<br />
|-<br />
|| Kernel || Tracing: perf trace scripting support || || 3 || Move to Sprint D; on track for Jan 21 || Tom || dvhart ||<br />
|-<br />
|| Cleanup || bitbake user experience error handling validation completed || || 2 || Done || Richard || ||<br />
|-<br />
|| Cleanup || variable scrub - ensure all metadata variables are documented || Script with a histogram of variable use done, identified 50 variables to document; Add task for actual documentation update is low on the list || 2 || Done || Scott/Darren || ||<br />
|-<br />
|| Distribution / components|| Zypper/RPM|| Integration based on design from Sprint B|| 1|| On track for Jan28 || Mark/Qing|| sgw|| Functionality, was M2, Sprint E<br />
|-<br />
|| Kernel || Tracing: package kernelshark || || 3 || Done || Darren || dvhart ||<br />
|-<br />
|| Kernel || Tracing: tuna, oscillosope recipes || || 3 || Tom to discuss plan with Darren et al || Tom || dvhart ||<br />
|- <br />
|| BSP || Beagleboard XM Support || || 3 || Move to Sprint D || Darren || dvhart ||<br />
|}<br />
<br />
=== Sprint D (closes Jan 21, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Swabber || Complete review of swabber outputs || Move to M3 Sprint D || 1 || Move to M3 Sprint D || Alex || ||<br />
|-<br />
|| Documentation Features|| Package report system|| move to public server [setup a package report system in an internal machine. We need push it publicly available. The basic features like search and report have been there. But there're still some enhancements in plan, to make it a fit place to feel Yocto metadata comfortably]|| 2|| Move to Sprint E|| KevinT|| ktian1|| enhancement<br />
|-<br />
|| Distribution / components||Add headers and libraries to qemu images ||Since we'll be using qemu images as target sysroot, need to create a set of qemu images for minimal, sato, LSB that contains target header and libraries.|| 2|| Pending a discussion on Jan 18 || Saul ||jzhang|| Enhancement<br />
|-<br />
|| Distribution / components|| push of all relevant Wind River patchs to Yocto (patch comparison)|| Update any additional patches needed since M2.|| 1|| May be done by Jan 21, pending RPM stuff || Mark|| Mark|| <br />
|-<br />
|| Distribution / components|| mklibs|| mklibs is a tool to optimize size of [e]glibc for a perticular root file system image. It is useful to save disk space on small devices. || 2|| Push to Sprint E || Saul|| Nitin Kamble|| enhancement<br />
|-<br />
|| Poky Features || Performance Enhancement || reduce disk space (hardlink) || 1 || On track for Jan 21, pending RP review || Saul / Qing, Dongxiao || rpurdie || Enhancement<br />
|-<br />
|| BSP || 2.6.37 Crown Bay Support || On Track for Jan 21 || 2 || || Tom || dvhart || <br />
|-<br />
|| BSP || 2.6.37 Emenlow Support || On track for Jan 21 || 2 || || Tom || dvhart || <br />
|}<br />
<br />
=== Sprint E (closes Jan 28, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| rootless X|| rootless x server has better security than x server launched by root. MeeGo already enable this feature. it would be nice for Yocto to also enable it. || 2|| On track for Jan 28 || Saul / Ke || yuke|| enhancement<br />
|-<br />
|| Documentation Features|| Package report system|| finish major feature development and internal review [setup a package report system in an internal machine. We need push it publicly available. The basic features like search and report have been there. But there're still some enhancements in plan, to make it a fit place to feel Yocto metadata comfortably]|| 2|| Move to Sprint E || Jonathan || ktian1|| enhancement, was M2, Sprint E<br />
|-<br />
|| Distribution / components|| perl upgrade|| perl is the most cross un-friendly recipe pending upgrade. || 2|| Slipping due to Linaro layer, moves to end of Sprint E || Nitin|| Nitin Kamble|| enhancement<br />
|-<br />
|| Supported Targets|| Intel Platform Support|| Sandybridge|| 2|| Accept|| Tom|| davest|| Basic ECG support<br />
|-<br />
|| Distribution / components|| performance indicators|| define some indicators (boot time, footprint, build time, power, component benchmarks, etc.) and then collect them for tracking purpose. The result could be posted on the wiki site, and the initial indicators can be easy ones which can be easily retrieved from autobuilder or weekly qa report). This way we have a clear track about the healthy of the Yocto project, and also identify weak areas. We can include qemu targets and several representational boards as the targets. || 2|| Review|| Beth/Jiajun|| ktian1|| enhancement<br />
|-<br />
|| Tool Development and SDK Features|| SDK user workshop|| Have some developers sit down and use our tools to develop demo software for Yocto. || 2|| Review|| Jessica|| josh|| Enhancement<br />
|-<br />
|| Kernel || Final linux-yocto_git.bb || With 2.6.37 kernel || 1 || || Bruce || dvhart ||<br />
|-<br />
|| Kernel || Final meta-linaro layer || || || || Darren || dvhart ||<br />
|-<br />
|| Kernel || Final meta-rt layer || || || || Darren || dvhart ||<br />
|-<br />
|| Kernel || Sandy Bridge || || 1 || || Tom || dvhart ||<br />
|}<br />
<br />
=== Sprint F (closes Feb 03 (THURSDAY), 11:59pm PDT -- pull request sent, initially reviewed) :: NOTE: China New Year Holiday ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Documentation|| ADT Reference Guide Draft out for review || Outline complete|| High|| WIP || Scott Rifenbark|| jzhang|| Documentation<br />
|-<br />
|| || || || || || || || <br />
|}<br />
<br />
== M4 (Feb 07 to Apr 15 -- Stabilize Complete Mar 18, Release Complete Apr 01, Contingency to Apr 15) ==<br />
<br />
This sprint is the [[Yocto Project v. 1.0 Release Cycle]].<br />
<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Documentation|| Migration chapter in the Poky Reference Manual|| This chapter would cover the four identified use-cases for migrating up to the most recent version of Yocto Project. Additionally, it would cover migration scenarios from other development systems. The chapter does not yet exist. The chapter has not been scoped outside of having a meeting that identified four use-cases that did not include migration from a development system outside of Yocto Project. It will take some more scoping time to cover those areas (a day or two). Again, I have no idea of the length. See earlier entries for standard industry writing estimates for software documentation|| Medium|| Not Started|| Scott Rifenbark|| 3-4 Weeks|| Documentation<br />
|-<br />
|| Documentation|| Yocto Project Development Guide|| This manual would be an over-arching document that frames the complete development cycle within Yocto Project. The idea here is that the document would be an umbrella document that spawned and referenced subsequent documents. The organization would be the first chapter overviewing the major development pieces such as recipe creation, building, debugging, publishing, fail-safing, back-door hook creation, etc. Scoping would be about two weeks and length would probably be about 40 pages. Overall development time would likely be a month of uniterruped time.|| Medium|| Not Started|| Scott Rifenbark|| 3 Weeks|| Documentation<br />
|-<br />
|| || Multilib Support|| Consider developing post-1.0 branch || 1|| to start in M4 || Richard|| ||<br />
|-<br />
|| Validation|| Alpha testing complete|| 4-5 internal developers unfamiliar with Yocto Project try to do a build and report on the experience and issues encountered|| 1|| Done by Feb 18 || Julie|| davest|| <br />
|-<br />
|| || || || || || || || <br />
|}<br />
<br />
== Features needed and to be put into sprints by assigned owners: ==<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || package config option enhancement|| there're several enhancements we may do here: * allow users setting specific config options (local or global) from external tool, such as poky image creator, instead of changing recipes manually. Need a mechanism to convert from variable assignments into exact config options (e.g. feature_${PN} = ""1"" -> ""--enable-feature""). Consequently dependency chain needs update with option status. * host contamination check. We have swabber to check host contamination, but I'm not sure whether it covers configuration phase. If not, this is one area to improve, as not ususually we see configure script checks host bits for available features * conditional option manipulation. In many recipes we enable/disable one option based on availability of other packages. Now this is done manually and not flexible. this should be made automatically though some new annotation to indicate condition, or just base_contains (not convenient: long line, need define distro features) || 2|| Review|| Richard/MarkH|| ktian1|| Enhancement<br />
|-<br />
|| Media|| Yocto Project Awareness Video|| This 2.5 minute video would introduce and describe the benefits of Yocto Project. The video would use entertaining animations that described concepts and benefits. The result would be suitable for YouTube, conferences, and the website. The production is called an "Epipheo" and will be created by Epipheo Studios. The engagement process has begun and the kick-off meeting will be soon. The PO is in place. Time for development is 10 weeks.|| High|| Kick-off Imminent|| Scott Rifenbark|| 10 Weeks|| Media<br />
|-<br />
|| Documentation|| Yocto Project Debugging Guide|| This would be a guide for the debugging and bug tracking process in Yocto Project. Originally, the thought was that we needed a Bugzilla User's Manual. However, since we don't own Bugzilla it doesn't make sense to produce documentation for it. Rather, we should document the process as it fits into the Yocto Project environment. Ideally, the manual would be a sub-manual that would be referenced and architected into the Yocto Project Development Guide. The manual has not been scoped and would take a week to scope. Again, I have no idea of the length. See the previous item for standard industry writing estimates for software documenation.|| Medium|| Not Started|| Scott Rifenbark|| 3-4 Weeks|| Documentation<br />
|-<br />
|| Website|| Yocto Project Website|| The 0.9 website is in place but needs updates. Items for consideration are the left-panel naviagation scheme, a contributions guidance page, color-scheming and theme (possibly).|| Medium|| Not Started|| Scott Rifenbark|| 1-2 Weeks|| Website<br />
|}<br />
<br />
== Features not believed to be needed in v1.0: ==<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || OpenEmbedded/Bitbake Upstreaming|| "We firstly need to review where we are and where OE is. We then need to make a plan about what we're going to push upstream and what we're not. I'd suggest when we're in PRC, we do a crash course in ""dealing with OE"" and then many dedicate a block of time (a week) where the distro team comes up with a patch set we then propose and get merged into OE. I'd like to find a couple of interested people to monitor OE more regularly and start a workflow of things between Poky/OE where appropriate. The key thing to remember is we need to keep the architectures compatible. The team is now at the point where I'm happy for them to actually try building OpenEmbedded and not worry about it tainting them! "|| 2|| Review|| || rpurdie|| Process<br />
|-<br />
|| Poky Features || Handle old versions in WORKDIR|| an incremental build directory may finally include many old versions WORKDIRS. It'll be good to have those old versions tracked in the cache, which can then either generate a report or allow selectively cleaning up an specific version WORKDIR. Or else it's difficult to figure it out when people want to keep the whole tmp directory but like to cleanup some old bits when disk usage is under pressure. If it's not easy to do in bitbake, perhaps some separate scripts would be also helpful || 3|| Review|| || ktian1|| Enhancement<br />
|-<br />
|| Poky Features || run bitbake w/o rebuilding the cache|| "sometimes it's useful to allow run bitbake w/o re-parsing recipes, if we know nothing metadata is changed. we can just allow reusing existing persistent cache. this is useful when people is debugging WORKDIR w/o metadata change. also sometimes ""bitbake -e"" is used frequently to check poky variable information. with existing cache, several seconds can be saved which are not negligible for a developer daily working on Yocto "|| 2|| Review|| || ktian1|| Enhancement<br />
|-<br />
|| Poky Features || parallel make improvement|| parallel make experience is not good, especially when bb threads and make threads are increased larger than 8. So far we either try to fix package makefile or mark the recipe as no parallel make, when build faiures are reported. But this greatly impacts user experience for a successfully continuous build process. Could we define a safe number we do want to support for 1.0 release? and then have our autobuilder, QA test, and developers cover that number immediately and fix any issues accordingly. Then the safe number can be suggested to the Yocto user || 2|| Review|| || ktian1|| Enhancement<br />
|-<br />
|| Poky Features || Dependency packages rebuild/clean|| It is a mechanism to rebulid or clean a package and all other packages which have build/runtime dependency on it. With this change, we can find potential influences of package upgrade to its related packages, which can make the incremental build more trustable. For example, if we upgrade a package to a new vesion which changes its API, this mechanism can easily find out the incompatibility to other packages which have dependency on it. || 2|| Review|| || dongxiao.xu|| Enhancement, replaced by checksum feature<br />
|-<br />
|| Distribution / components|| FOSSology|| This may be similar to License Update above, but start to use FOSSology to track licenses. || 2|| Review|| || sgw|| Hygiene<br />
|-<br />
|| Distribution / components|| Package Developer Tools|| Create a set of Init scripts template and then review our current init scripts and modify them to confirm to the template. || 2|| Review|| || sgw|| Easy of Use<br />
|-<br />
|| Distribution / components|| Package Website|| Complete the work the intern has started on generating the distro tracking information and get it out on the external site. || 2|| Review|| || sgw|| "Hygiene, duplicate of ""Package report system"""<br />
|-<br />
|| Distribution / components|| Bluetooth UI support|| Currently we have bluez package in poky, and we need to have a workable graphic user interface to connect/configure BT devices. One choice may be gnome-bluetooth-applet. || 3|| Review|| || dongxiao.xu|| enhancement<br />
|-<br />
|| Distribution / components|| Connman-gnome enhancement features|| Enable connman-gnome to support features like, WPA Enterprise connection, hidden SSID, etc. || 3|| Review|| || dongxiao.xu|| enhancement<br />
|-<br />
|| Distribution / components|| Java Running Environment support|| Since most embedded systems support java applications running in it, maybe we'd better consider supporting some kinds of JVMs(Embeded JVM). The JVM may not run by default, but user can launch it if running java applications. Compared with GTK/QT, java user number is not small too. || 3|| Review|| || criping|| enhancement<br />
|-<br />
|| Distribution / components|| create more use cases|| UPnP demo is one really good use case showing how Yocto is utilized to make real functionality. and we could create more to show how Yocto is easily adapted to real use cases. Those use cases can be either maintained as seperate demo layers in yocto repo, or in seperate branches for reference. We can also call for community's contribution on this which would make 1.0 full-fledged. Or else the newbies to Yocto may be in puzzle how our sample profiles can satisfy their requirements. || 2|| Review|| || ktian1|| enhancement<br />
|-<br />
|| Distribution / components|| i18n support || internationalization is an important system wide feature. Many component like font, locale affect the i18n. Yocto alreay has some i18n related package like pango, but so far did not consider i18n systematically. so this is place holder to systematically add i18n support. || 2|| Review|| || yuke/qing|| enhancement<br />
|-<br />
|| Distribution / components|| more demos || demos are a good way to educate, push the envelope, and at the same time tout the strengths of the platform. This item just records a current set of ideas from various sources which could/should be implemented: * face-recognition/face-finding, * robotic control/application of face-finding to 'camera-as-sensor' (hexbug demo), * others [tbd, add here]|| 2|| Review|| || tzanussi|| enhancement <br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer support for image-creator and needed yocto-metadata design||Come up design what need to be created as packages to support using "opkg install" for image-creator and needed yocto-metadata|| 2|| WIP, pending comments from RP regarding how to packaging metadata|| Jessica|| rpurdie|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer image-creator and needed poky-metadata support|| The poky build system will build packages for image-creator and needed poky-metadata, which the Yocto Installer will be able to use "opkg install" to install them|| 2|| Review|| Jessica|| rpurdie|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Provide qemu management UI|| In current eclipse plugin, QEMU settings are put together with project configuration. So we can only have limited settings. If we can have a separate QEMU management UI, the end user could firstly create a QEMU config, such as (env file of arch, image location, unfs or not, sato or lsb, mem size, disk size). And then he can launch a QEMU with a specific config. The dependency between project configuration and QEMU config will be resolved. After all QEMU has nothing to do project configuration. Need to careful review the UI to ensure minimal impact to testing matrix. || 3|| Review|| || criping|| "Enhancement, duplicate of ""Qemu mem/disk size can be adjusted"""<br />
|-<br />
|| Tool Development and SDK Features|| QT plugin For Eclipse|| Integrate QT Ecplise plugin and extend for Yocto Project || 3|| Review|| || jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Profiling/Trace GUI's|| We have a wealth of great tracing and profiling tools but the UI's for them are all extremely minimal and usually quite ugly. Would be great if we could compete with, or even better, Apple's offerings here. We have the technology! || 2|| Review|| || josh|| "Enhancement, duplicate of ""Tracing/Profiling Planning Complete"""<br />
|-<br />
|| Tool Development and SDK Features|| Other profiling tools|| Complete Tom's review of profiling tools and architecture || 2|| Review|| || josh|| "Enhancement, duplicate of ""Tracing/Profiling Planning Complete"""<br />
|-<br />
|| Tool Development and SDK Features|| Design next-gen tracing/profiling tools|| Yocto 1.0 will include all the essential existing tracing/profiling tools expected by users, and Josh has proposed a UI integration of all those tools as far as it's possible to do so. That level of integration, basically a 'plugin-level' integration is necessary and useful, but doesn't go far enough. A next-generation tracing tool would integrate at a much more fundamental level; if done properly, it would provide unmatched levels of power and usability to users, and would allow Yocto to distinguish itself in the embedded tracing/profiling space in a way also unmatched by any other distro/build-tool. The implementation would of course not be available for Yocto 1.0, but a coherent design, including prototypes, that could be taken to the community and implemented in a V 1.5 or 2.0 should be done in that time frame. || 1|| Review|| || tzanussi|| "Enhancement, duplicate of ""Tracing/Profiling Planning Complete"""<br />
|-<br />
|| Documentation Features|| Self Documentation of image contents|| "I'd like to see the -doc packages Poky builds being combined into some kind of large documentation index representing the collective API docs of the target being built. This can then be placed on a webserver and viewed over the web. We'd have a demonstration of this for a ""bitbake world"" target. Part of the idea here is to start making good use of the docs as if developers see this they might start writing better docs too. Aim is to lead the field :). There are a number of places poky packages disable doc generation due to missing tools so we'd need to add these so we can enable the doc generation. Many packages already have many docs though too. "|| 2|| Review|| || rpurdie|| enhancement<br />
|-<br />
|| Validation|| Testing Framework|| Add a framework for doing automated testing in the project|| 1|| Review|| || davest|| project commitment<br />
|-<br />
|| Validation|| more SDK builds on autobuilder|| enable more SDK related tests on autobuilder such as meta-ide-support, etc.|| 2|| Review|| || ktian1|| project commitment, addressed by test plan (?)<br />
|-<br />
|| Validation|| more people should try using SDK|| this may not be a feature, but a requirement. SDK including meta-toolchain is one key factor impacting user experience on Yocto. It's not enough to have only SDK team play with it|| 2|| Review|| || ktian1|| project commitment, addressed by test plan (?)<br />
|-<br />
|| Validation|| Unit Testing Framework|| Add a mechanism to bitbake to parse source packages that have unit tests and then execute them on the target|| 3|| Review|| || sgw|| "project commitment, duplicate of ""Testing Framework"""<br />
|-<br />
|| Validation|| Test Case open source|| Open source Yocto test cases with xml format|| 1|| Review|| || yyou|| "project commitment, duplicate of ""Testing Framework"""<br />
|}</div>Davesthttps://wiki.yoctoproject.org/wiki/index.php?title=Yocto_1.0_Schedule&diff=579Yocto 1.0 Schedule2011-01-25T01:19:30Z<p>Davest: /* Sprint E (closes Jan 28, 11:59pm PDT -- pull request sent, initially reviewed) */</p>
<hr />
<div>= v1.0 (release date: Apr 15, 2011) =<br />
----<br />
The detailed milestone map for v1.0 is as below. During the first week of each subsequent milestone past M1 we will have a demonstration of the previous milestone capabilities as well as a planning and design session for the current milestone.<br><br><br />
<br />
== M2 (Nov 08 to Dec 24 -- Dev Complete Dec 10, Stabilize Complete Dec 17, Release Complete Dec 24) ==<br />
=== Sprint A (closes Nov 12, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links''' <br />
|-<br />
|| Poky Features || Kernel interactive targets || To support incremental kernel development having the ability to run menuconfig (or xconfig, etc) directly is a common request. We'll need to add this for commercialization anyway. i.e. bitbake -c menuconfig. This fuctionality already exists. || 1 || Done || Richard || bruceashfield || Enhancement <br />
|-<br />
|| Distribution / components || Distro Audit: Upgrades Planned (Phase 1) || Complete plan for package upgrades in M2 || 1 || Done || Saul || || Continual Maintenance<br />
|-<br />
|| Validation || Runtime testing || Runtime testing of images as part of the autobuilder || 1 || Done || Jiajun/ScottG || rpurdie || project commitment<br />
|- <br />
|| || Poky Image Creator Wireframe/Interaction Plans Complete || || 1 || Done || Josh || ||<br />
|-<br />
|| || SDK Generator Interaction: Plans Complete || || 1 || Done || Jessica || ||<br />
|-<br />
|| || Tracing/Profiling Planning Complete || This needs to cover where we're at now, what we're missing and also propose the future enhancements that may be needed. M2 targets getting existing tools integrated and documented. F2f discussion n the future enhancements || || Done || Tom || ||<br />
|-<br />
|| || Swabber. (Still needs to be integrated into weekly build by default) || || 1 || Done || Josh || ||<br />
|-<br />
|| Build/Release || Release process documentation || || || Done || Beth || ||<br />
|-<br />
|| Validation || Test plan for v1.0 (to address any deficiencies in coverage from v0.9)|| || 1 || Done || Jiajun || ||<br />
|}<br />
<br />
=== Sprint B (closes Nov 19, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| Distro Audit: World Packages|| Audit world packages making sure it all build, making sure all are packages are required || 2|| Done || Saul|| sgw|| Hygiene<br />
|-<br />
|| Tool Development and SDK Features|| SDK Generator Installer UI|| Look at different ways of Installer UI (GTK+ and ncurses) seems none of them is the right choice, decide to go with script to implement all the functionalities of installer and later add UI part on top of it || 1||Done|| Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Customize sysroot setup || Add and test out "--sysroot" config option to cross compiler within Eclipse IDE || 1|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| SDK Generator Installer design revision|| Close all open questions regarding Yocto SDK Generator Installer function design and come up HLD || 1|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Distribution / components|| kernel version|| keeping 2.6.34 as a -stable kernel is the best option. I've also got a newer -devel tree that can be made available or made the default. || 3|| Done || Bruce|| bruceashfield|| enhancement<br />
|-<br />
|| || assign Yocto Project PM|| acquire and assign a program manager for Yocto Project|| || Done || DaveST|| || <br />
|-<br />
|| || assign Yocto Project Sys Admin|| || || Done || Saul|| || <br />
|-<br />
|| Tool Development and SDK Features|| oprofileUI|| Fixing various bugs of the oprofileUI to make it workable on big endian host.(i.e. ppc, mips) || 2 || Done || Jessica || lianhao.lu || Bug #382 / Bug #493<br />
|-<br />
|| Poky Feature|| SDK Version Control|| If we can expect that yocto SDK has lots of release in the future, we might need to consider SDK version control. Currently, every thing installed under /opt/poky which leads to things be overriden, we need to be able to use a scheme like /opt/poky-1.0, /opt/poky-2.0 to distiguish things. || 2|| Done || Josh|| jzhang|| Enhancement<br />
|-<br />
|| Kernel || Kernel plan complete || Flesh our kernel deliverables and add to Yocto 1.0 schedule || || Done|| Darren || dvhart ||<br />
|}<br />
<br />
=== Sprint C (closes Nov 26, 11:59pm PDT -- pull request sent, initially reviewed) :: NOTE: this is US Thanksgiving week ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| Distro Audit: Licence Checksums|| licence checksums || 1|| Done || Saul|| rpurdie|| Hygiene<br />
|-<br />
|| Poky Features || Performance Analysis Completed|| "I'd like someone to instrument a green release build, see where it spends time (hot/cold parsing time, individual task building time) and then compare this with our 0.9 release build. I'd also like to compare the disk usage between the two. Once we have a blame list we can then set about fixing it. Some things I know will come up: a) pseudo, b) checksums/signature code, c) exec() vs fork for executing tasks, d) task based prebuilds increasing disk usage, e) rpm dependency calculations, f) using rpm vs. ipk but I may be wrong and there may be others. We need numbers. "|| 1|| Done || Saul / Qing, Dongxiao|| rpurdie|| Enhancement<br />
|-<br />
|| Poky Features || environment variables for kernel builds|| switching a branch, or adding a configuration feature (and even changing the kernel repo) is often done during development of a BSP. Having some additional variables that are pass the bitbake environment scrub would be useful. i.e. KBRANCH=foo bitbake -c configure linux-yocto. This goes along with the other BSP bootstrapping suggestions. || 2|| Done || Bruce|| bruceashfield|| Enhancement<br />
|-<br />
|| Supported Targets|| ARM Platform Support|| Replace beagleboard with Beagleboard XM - decision || 2|| Done || Bruce|| alex|| Basic Yocto hardware support <br />
|-<br />
|| Distribution / components|| Security Process|| We need a dedicated person to scan and apply critical security updates to the distro. The MeeGo team already has a similar process with some scripts which may be leveraged. To complete the task, the process should be documented and a first pass over the metadata made to establish the current position on security. Any upgrades needed should be identified and a plan to address them should be in place but doesn't have to be implemented by this point.|| 1|| Done || ScottG|| ktian1|| enhancement<br />
|-<br />
|| Tool Development and SDK Features|| SDK Generator Installer Opkg repo design|| Come up a opkg repo design that will mimic the final Yocto package repo layout to be used by SDK Generator Installer to test against|| 2 || Done || Jessica || jzhang || <br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer tar creaion|| Create a Yocto Installer tar ball which contains Installer script and supported opkg component that will be used for installing other Yocto components|| 2 || Done || Jessica || jzhang || <br />
|-<br />
|| Documentation|| Kernel Framework Paper from WR|| The paper from WR needs to be re-written and then posted somewhere on the Yocto Project site. This will involve examiniation of the text and re-writing and formatting for presentation. Currently it is simply a text document. Completion time assuming uninterrupted time is one week.|| High|| Done || Scott Rifenbark|| 1 Week|| Documentation<br />
|-<br />
|| Documentation|| Poky Reference Manual|| This guide exists in the 0.9 form. The re-write of the text needs to be completed. So far, all the chapters have been rewritten but not re-posted on the site. Only the appendices remain for a text scrub. Time to complete this would be a week of uninterrupted time. Ideally, the manual would be a sub-manual that would be referenced and architected into the Yocto Project Development Guide.|| Medium|| Done|| Scott Rifenbark|| 1 Week|| Documentation<br />
|-<br />
|| Kernel || Initial meta-linaro layer || meta-linaro layer providing a kernel, tool-chain, and uboot loader. This deliverable is primarily to get the infrastructure in place and have a buildable kernel. Toolchain on best effort basis. || || Done || Darren || dvhart || Moderate risk of slippage due to holidays.<br />
|-<br />
|| Kernel || Tracing: blktrace and sysprof recipes || || || Done || Tom || dvhart ||<br />
|}<br />
<br />
=== Sprint D (closes Dec 3, 11:59pm PDT -- pull request sent, initially reviewed) :: NOTE: week of the F2F planning meeting ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Kernel || Kernel git branching structure revamped || || 1 || Done || Bruce || dvhart ||<br />
|-<br />
|| Kernel || Tunnel Creek (Crown Bay) || || 1 || Done || Tom || dvhart ||<br />
|}<br />
<br />
=== Sprint E (closes Dec 9 (THURSDAY), 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| Distro Audit: Upgrades Completed (Phase 1)|| Update to new versions as per the agreed plan for M2 from Sprint A|| 1|| Done || Saul|| rpurdie|| Continual Maintenance<br />
|-<br />
|| Distribution / components|| Distro Audit: Src Checksums|| Make sure all SRC_URI components have checksums too || 1|| Done || Saul|| rpurdie|| Hygiene<br />
|-<br />
|| Poky Features || enable KVM with qemu|| today all new Intel processors support VT, which are enabled on most desktop machines which are most frequently used build machine. with VT support, x86/x86-64 qemu target runs faster which is a good thing for emulation environment. This may require some qemu option tweaks and also poky-qemu script enhancement. || 2|| Done || Saul / Edwin|| ktian1|| Enhancement<br />
|-<br />
|| Kernel || New kernel recipes || dev, -devel, -custom || 3 || Done || Bruce || dvhart ||<br />
|-<br />
|| Swabber || Documentation for swabber || || 1 || Done || Alex || ||<br />
|-<br />
|| CCB || Defect triage process in public documented and implemented || || 1 || Done. Triage process is documented, out for review. || Saul || ||<br />
|}<br />
<br />
== M3 (Dec 20 to Feb 08 -- Dev Complete Feb 04, Stabilize Complete Feb 11, Release Complete Feb 18) ==<br />
=== Sprint A (closes Dec 24, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Kernel || Initial meta-rt layer || PREEMPT_RT kernel and related test-cases and benchmarks || 2 || Done by Jan 21 || Darren || dvhart || slipped out from M2<br />
|-<br />
|| Poky Features || Fetcher Overhaul Phase 1 - SRC_REV enhancement||<br />
* a) Add code in FetchData::__init__() which will check if the selected fetcher supports srcrev and the automatically call a function to set the src rev value instead of each fetcher doing this.\n <br />
* e) Break SRCREVINACTION deadlock. To do this, we need to start using a keyword for automatically increasing SRCREV, e.g. SRCREV = "AUTOINC". The actual revision can be injected into PV using SRCPV. If we do this there should no longer be a need of the deadlock; <br />
* k) Ensure that we only set __BB_DONT_CACHE when SRCREV = "AUTOREV". This may need a new method call for fetchers to tell whether they're "floating" or locked down.<br />
|| 1|| Done || Saul / Ke, RP|| rpurdie|| Enhancement, slipped out from M2<br />
|-<br />
|| Distribution / components|| Distro Audit Upgrades Planned (Phase 2)|| Complete plan for package upgrades in M2|| 1|| Done || Saul|| || Continual Maintenance<br />
|-<br />
|| Poky Features || Pseudo Performance || Implement the changes to bitbake based on pseudo's enable/disable switch|| 1|| done || Saul / Qing, Dongxiao || rpurdie|| Enhancement, slipped from M2 due to risk and not having Pseudo's change yet.<br />
|-<br />
|| Tool Development and SDK Features|| Fix the issue user target sysroot is owned by root || The ADT installer will use pseudo to extract user target sysroot which ended up owned by root, this need to be fixed || 1|| done || Jessica|| jzhang|| Cleanup <br />
|-<br />
|| Tool Development and SDK Features|| Eclipse poky tree interfacing (metadata file editor)|| Provide a metadata file editor with some syntax checking and keywords highlight capabilities|| 2|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| IDE Project templates|| Templates for various project types: Clutter GUI, Gtk+ GUI, to help developers get started quickly || 2|| Done || Jessica|| josh|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| push TCF/RSE patches upstream|| work with community to finish up our TCF terminal service, TCF/RSE integration remaining patches taken by upstream. Blocking issues including Eclipse Bug #327865 || 1|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Pseudo || Pseudo enhancement to enable on/off switch || || 1 || done || Mark || ||<br />
|-<br />
|| Pseudo || Bitbake enhancement for pseudo on/off switch || || 1 || done || Richard || ||<br />
|-<br />
|| bugzilla || Complete restructure of bugzilla categories || || 1 || done || Saul || ||<br />
|-<br />
|| Poky Features || Image creator ground work || Nomenclature determined, existing gui's bug fixed and backend work implemented || 1 || Done || Joshua || ||<br />
|-<br />
|| Kernel || Tracing: Initial SystemTap recipe || Works on x86 || 3 || Done || Tom || dvhart ||<br />
|-<br />
|| Distribution / components|| Distro Audit: Package Description/Summary completed|| Ensure DESCRIPTION/SUMMARY fields are all audited|| 2|| Done || Mark|| Mark|| Hygiene, was M2, Sprint B but missed window<br />
|-<br />
|| Distribution / components|| Zypper/RPM|| Small write-up of the problems we're having w/ Zypper and what we plan to do. (i.e. create a roadmap/design) - Includes rootfs generation - Package uprev/install/removal || 1 || Done || Mark/Qing || || was M2, Sprint B<br />
|-<br />
|| Distribution / components|| Distro Audit: Licence Checksums|| Make the licence checksums fatal if not present || 1|| Done || Saul|| rpurdie|| Hygiene, was M2, Sprint C<br />
|-<br />
|| Distribution / components|| push of all relevant Wind River patchs to Yocto (patch comparison)|| Ensure patches present to packages in WRS are also in Poky|| 1|| Done || Mark|| Mark|| was M2, Sprint C<br />
|-<br />
|| Poky Features || Performance Enhancement Completed || Initial changes to reduce disk space (sstate-build-*) || 1|| Done || Saul / Qing, Dongxiao || rpurdie|| Enhancement, was M2, Sprint E<br />
|-<br />
|| Distribution / components|| User specified qemu config support|| We'll provide user an edit box which allows advanced qemu user to specify arbitrary qemu configuration to meet their needs, which the poky-qemu scrip will just append the config list towards the end of the list of parameters to bring up qemu, it also expect the poky-qemu script to do some basic sanity check on the user specifications to catch the obvious mistake || 2|| Done || Saul / criping || criping|| enhancement, was M2, Sprint E<br />
|-<br />
|| Tool Development and SDK Features|| SDK Version Control support in SDK generator installer|| If we can expect that yocto SDK has lots of release in the future, we might need to consider SDK version control. Currently, if we un-tar the sdk, it will override the older version. It's not good for app developers since they might need the old version to do something. And also, maybe a finer installer than untar is preferred. Installer will tied to certain SDK version and the installation will go under /opt/poky-versionNo.|| 1|| Done || Jessica|| criping|| Enhancement-expect planning process by Jessica to handle this task. Was M2, Sprint E.<br />
|}<br />
<br />
=== Sprint B (closes Jan 07, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || Bitbake multi-threaded parsing|| Bitbake recipe parsing is currently single threaded. I want to make this multithreaded as the speedup would be nice. If I can only take a single task for myself for 1.0, I'm nominating this one as I enjoy this kind of thing and I have ideas on how to do it. || 1|| Done || Richard|| rpurdie|| Enhancement<br />
|-<br />
|| Distribution / components|| Lock in Kernel/Toolchain version|| Locked in 2.6.37 and gcc 4.5.1. Pending decision to move to 4.5.2 and Linaro || || Done || || Richard|| || <br />
|-<br />
|| Distribution / components|| License Update|| For each of the licences we support, I'd really like to have a licences directory with a copy of that license contained within. When it comes to deciding what a given LICENSE field means, this would be the reference. It also means we can include the licences a given image includes with the image. This continues to make our license handling world class and ahead of the field. || 2|| Done || Beth|| rpurdie|| Hygiene<br />
|-<br />
|| Tool Development and SDK Features|| Qemu configuration change|| Provice edit box for advanced user to specify qemu configurations|| 2|| Done || Jessica|| criping|| <br />
|-<br />
|| Tool Development and SDK Features|| Lock down Eclipse+CDT+TCF version|| Will use Eclipse Halo 3.6 || 1|| Done || Jessica|| || <br />
|-<br />
|| Demo|| Finalize on demo plans for v1.0 launch || || 1|| Slip to Sprint C || Dave || || <br />
|-<br />
|| Release || Release plans for v1.0 launch || Fill out the M4 plan with the necessary release activities and timings || 1|| Done || Beth || || <br />
|-<br />
|| Poky Features || Basic image creator GUI || Functional UI missing some Advanced features || 1 || In replan || Joshua || || <br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer for SDK Generator Installation functions support||Detailed feature request can be found at: http://bugzilla.pokylinux.org/show_bug.cgi?id=589|| 1|| Done || Jessica|| rpurdie|| Enhancement<br />
|-<br />
|| Kernel || Tracing: trace-cmd python binding cleanup || || 3 || Done || Darren || dvhart ||<br />
|}<br />
<br />
=== Sprint C (closes Jan 14, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || kernel development layer|| The (correct) poky behaviour of building known revisions coupled with the fetcher requiring a BSP branch to already be present means that local modifications (and kernel source tree) are required for kernel development. I already have a layer that overrides/modifies the behaviour when added to the bblayers.conf and configured into an environment. This seems useful for more people to use. || 2|| Done || Bruce|| bruceashfield|| Enhancement, was M2, Sprint C<br />
|-<br />
|| Distribution / components|| Zypper/RPM|| RPM Uprev / Zypper Uprev [lets get to the latest versions]|| 1|| pull request by Jan 19; || Mark/Qing|| || was M2, Sprint C<br />
|-<br />
|| Supported Targets|| Intel Platform Support|| JasperForest|| 2|| Basic support in place; DPDK evaluation in process, overall BSP plan still TBD || Tom|| davest|| Basic ECG support (Moved from Sprint A)<br />
|-<br />
|| Tool Development and SDK Features|| Eclipse poky tree interfacing (git support)|| Use Eclipse git capability to install poky tree from git repo and able to interact with git repo at file level within Poky tree || 2|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Poky Features || Fetcher Overhaul Phase 2 - API reorg||<br />
* f) Add a generic unpack funciton to __init__.py based on the unpack task in Poky ;<br />
* g) Split go() methods into the following steps: i) download() - do whatever transfer is necessary to get the sources locally ii) build_mirror_data() - generate any data that would be needed to construct a source mirror iii) unpack() - takes a directory as an argument of where to place extracted sources;<br />
The existing go() methods should be replaced with a set of calls to the above sections of functionality as appropriate in the individual fetchers. Some of these categories of function make no sense in certain fetchers, in which case they shouldn't need to implement them. Functions are only executed if the method is present.<br />
* h) Change Poky's unpack to call an unpack method in the fetchers.<br />
* i) Change Poky's fetch task to call a "download" method in the fetcher instead of go().<br />
|| 1|| Will land with phase 3 in Jan 21 || Saul / Ke, RP|| rpurdie|| Enhancement<br />
|-<br />
|| Poky Features || DSO linking changes|| "By the default the gcc linker will automatically link any dependant objects/libraries. ""Inherited"" linkages can cause issues, for example, where a shared object changes its dependencies but a program has come to rely on symbols from an implicitly linked library. Fedora implemented this change in F13, seems like it would be useful to have in Poky too. "|| 2|| On track for Jan 21 || Saul / Nitin || josh|| bug#516<br />
|-<br />
|| Distribution / components|| Distro Audit Documentation Output|| Audit package documentation output || 2|| Move to Sprint D due to libtool work || Saul / ScottG || rpurdie|| Hygiene<br />
|-<br />
|| Poky Features || libtool sysroot option|| libtool 2.4 has a sysroot option. We should try and use it, see how it works and whether we can ditch some of our libtool hacks. || 1|| On track for Jan 21 || Saul / ScottG || rpurdie|| Enhancement<br />
|-<br />
|| Distribution / components|| MACHINE or Recipe specific sysroots|| Each machine should have its own sysroot. We'll probably have to split do_populate_sysroot into a two step process, creation of the package and than installtion of the package, which the installation of the package being made machine specific (put ${MACHINE} into ${STAMP} and bitbake should do that). Also allowing this to work per recipe would be desireable|| 1|| On track 21 || Saul / Dongxiao || rpurdie|| Hygiene<br />
|-<br />
|| Distribution / components|| Toolchain Bootstrap Process|| The toolchain as it bootstraps overwrites files like libc.so and libgcc.so in the sysroot directory which causes issues if you just try and rebuild part of the toolchain. Each step of the bootstrap process should use a separate sysroot. Once this is once, sstate file overwriting detection can be added and enabled. || 1|| Patches submitted for comment, slip to Sprint D || Saul / Dexuan || rpurdie|| Hygiene<br />
|-<br />
|| Poky Features || Poky Image Creator|| A standalone application you can run which asks you to select a distro and machine, then presents a list of packages you can select. Once the selection is made, it goes off and bakes you an image which is then presented to you. Implementation wise, it should use the sstate packages, be a bitbake UI and use the usual poky bbclass files to do the image construction behind the scenes. || 1|| Re-plan || Joshua|| rpurdie|| Enhancement<br />
|-<br />
|| Poky Features || Fetcher Overhaul Phase 3 - git enhancement||<br />
* j) Optimize git fetcher for the new layout so for a git checkout, we clone the repository in download(), then unpack just does a clone with references to the original repo. <br />
* k) Ensure that we only set __BB_DONT_CACHE when SRCREV = "AUTOREV". This may need a new method call for fetchers to tell whether they're "floating" or locked down. <br />
* l) Add a new "BB_NO_NETWORK" variable which the fetchers check before peforming an operation which hits anything remote. This means adding in error messages about why network access is needed at various points (e.g. SRCREV = "AUTOREV" for a given recipe) <br />
* m) Add multiple branch/srcrev support for git fetcher. These would be of the form: git://somelocation/somerepo.git;name=ref1;branch=foo;name=ref2;branch=bar SRCREV_ref1 = "hash1" SRCREV_ref2 = "hash2" which would ensure both hash1 and hash2 were in the final repo. <br />
* n) Change git fetcher to default to git protocol instead of rsync<br />
|| 1|| Slipped to Sprint D || Saul / Ke, RP|| rpurdie|| Enhancement<br />
<br />
|-<br />
|| Validation|| Boottime/Performance Analysis|| Compare Yocto Project performance to other projects such as MeeGo|| 1|| Initial report on where we are by Feb 9 || Darren|| davest|| project commitment <br />
|-<br />
|| Distribution / components|| LSB Sanity|| execute LSB Test and improve passing rate and document failures with clear understanding|| 2|| Done || MarkH/Saul|| sgw|| Hygiene<br />
|-<br />
|| Distribution / components|| Review & Fix Standards Tests|| Review the results from LTP, POSIX and asses the result, fix as appropriate and clearly document failures.|| 2|| a Plan to resolve final items to be sent to the m.l. by Jan 14 || Saul/Kevin || sgw|| Hygiene<br />
|-<br />
|| Tool Development and SDK Features|| Image creator integration with Eclipse || || 2|| replan|| Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Kernel || Tracing: perf trace marker support || This is from feedback to the new trace command. Ingo appears to have this nearly complete already. || 3 || Done || Darren || dvhart ||<br />
|-<br />
|| Kernel || Tracing: perf trace scripting support || || 3 || Move to Sprint D; on track for Jan 21 || Tom || dvhart ||<br />
|-<br />
|| Cleanup || bitbake user experience error handling validation completed || || 2 || Done || Richard || ||<br />
|-<br />
|| Cleanup || variable scrub - ensure all metadata variables are documented || Script with a histogram of variable use done, identified 50 variables to document; Add task for actual documentation update is low on the list || 2 || Done || Scott/Darren || ||<br />
|-<br />
|| Distribution / components|| Zypper/RPM|| Integration based on design from Sprint B|| 1|| On track for Jan28 || Mark/Qing|| sgw|| Functionality, was M2, Sprint E<br />
|-<br />
|| Kernel || Tracing: package kernelshark || || 3 || Done || Darren || dvhart ||<br />
|-<br />
|| Kernel || Tracing: tuna, oscillosope recipes || || 3 || Tom to discuss plan with Darren et al || Tom || dvhart ||<br />
|- <br />
|| BSP || Beagleboard XM Support || || 3 || Move to Sprint D || Darren || dvhart ||<br />
|}<br />
<br />
=== Sprint D (closes Jan 21, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Swabber || Complete review of swabber outputs || Move to M3 Sprint D || 1 || Move to M3 Sprint D || Alex || ||<br />
|-<br />
|| Documentation Features|| Package report system|| move to public server [setup a package report system in an internal machine. We need push it publicly available. The basic features like search and report have been there. But there're still some enhancements in plan, to make it a fit place to feel Yocto metadata comfortably]|| 2|| Move to Sprint E|| KevinT|| ktian1|| enhancement<br />
|-<br />
|| Distribution / components||Add headers and libraries to qemu images ||Since we'll be using qemu images as target sysroot, need to create a set of qemu images for minimal, sato, LSB that contains target header and libraries.|| 2|| Pending a discussion on Jan 18 || Saul ||jzhang|| Enhancement<br />
|-<br />
|| Distribution / components|| push of all relevant Wind River patchs to Yocto (patch comparison)|| Update any additional patches needed since M2.|| 1|| May be done by Jan 21, pending RPM stuff || Mark|| Mark|| <br />
|-<br />
|| Distribution / components|| mklibs|| mklibs is a tool to optimize size of [e]glibc for a perticular root file system image. It is useful to save disk space on small devices. || 2|| Push to Sprint E || Saul|| Nitin Kamble|| enhancement<br />
|-<br />
|| Poky Features || Performance Enhancement || reduce disk space (hardlink) || 1 || On track for Jan 21, pending RP review || Saul / Qing, Dongxiao || rpurdie || Enhancement<br />
|-<br />
|| BSP || 2.6.37 Crown Bay Support || On Track for Jan 21 || 2 || || Tom || dvhart || <br />
|-<br />
|| BSP || 2.6.37 Emenlow Support || On track for Jan 21 || 2 || || Tom || dvhart || <br />
|}<br />
<br />
=== Sprint E (closes Jan 28, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| rootless X|| rootless x server has better security than x server launched by root. MeeGo already enable this feature. it would be nice for Yocto to also enable it. || 2|| On track for Jan 28 || Saul / Ke || yuke|| enhancement<br />
|-<br />
|| Documentation Features|| Package report system|| finish major feature development and internal review [setup a package report system in an internal machine. We need push it publicly available. The basic features like search and report have been there. But there're still some enhancements in plan, to make it a fit place to feel Yocto metadata comfortably]|| 2|| Move to Sprint E || Jonathan || ktian1|| enhancement, was M2, Sprint E<br />
|-<br />
|| Distribution / components|| perl upgrade|| perl is the most cross un-friendly recipe pending upgrade. || 2|| Slipping due to Linaro layer, moves to end of Sprint E || Nitin|| Nitin Kamble|| enhancement<br />
|-<br />
|| Supported Targets|| Intel Platform Support|| Sandybridge|| 2|| Accept|| Tom|| davest|| Basic ECG support<br />
|-<br />
|| Distribution / components|| performance indicators|| define some indicators (boot time, footprint, build time, power, component benchmarks, etc.) and then collect them for tracking purpose. The result could be posted on the wiki site, and the initial indicators can be easy ones which can be easily retrieved from autobuilder or weekly qa report). This way we have a clear track about the healthy of the Yocto project, and also identify weak areas. We can include qemu targets and several representational boards as the targets. || 2|| Review|| Beth/Jiajun|| ktian1|| enhancement<br />
|-<br />
|| Tool Development and SDK Features|| SDK user workshop|| Have some developers sit down and use our tools to develop demo software for Yocto. || 2|| Review|| Jessica|| josh|| Enhancement<br />
|-<br />
|| Kernel || Final linux-yocto_git.bb || With 2.6.37 kernel || 1 || || Bruce || dvhart ||<br />
|-<br />
|| Kernel || Final meta-linaro layer || || || || Darren || dvhart ||<br />
|-<br />
|| Kernel || Final meta-rt layer || || || || Darren || dvhart ||<br />
|-<br />
|| Kernel || Sandy Bridge || || 1 || || Tom || dvhart ||<br />
|}<br />
<br />
=== Sprint F (closes Feb 03 (THURSDAY), 11:59pm PDT -- pull request sent, initially reviewed) :: NOTE: China New Year Holiday ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Documentation|| ADT Reference Guide Draft out for review || Outline complete|| High|| WIP || Scott Rifenbark|| jzhang|| Documentation<br />
|-<br />
|| || || || || || || || <br />
|}<br />
<br />
== M4 (Feb 07 to Apr 15 -- Stabilize Complete Mar 18, Release Complete Apr 01, Contingency to Apr 15) ==<br />
<br />
This sprint is the [[Yocto Project v. 1.0 Release Cycle]].<br />
<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Documentation|| Migration chapter in the Poky Reference Manual|| This chapter would cover the four identified use-cases for migrating up to the most recent version of Yocto Project. Additionally, it would cover migration scenarios from other development systems. The chapter does not yet exist. The chapter has not been scoped outside of having a meeting that identified four use-cases that did not include migration from a development system outside of Yocto Project. It will take some more scoping time to cover those areas (a day or two). Again, I have no idea of the length. See earlier entries for standard industry writing estimates for software documentation|| Medium|| Not Started|| Scott Rifenbark|| 3-4 Weeks|| Documentation<br />
|-<br />
|| Documentation|| Yocto Project Development Guide|| This manual would be an over-arching document that frames the complete development cycle within Yocto Project. The idea here is that the document would be an umbrella document that spawned and referenced subsequent documents. The organization would be the first chapter overviewing the major development pieces such as recipe creation, building, debugging, publishing, fail-safing, back-door hook creation, etc. Scoping would be about two weeks and length would probably be about 40 pages. Overall development time would likely be a month of uniterruped time.|| Medium|| Not Started|| Scott Rifenbark|| 3 Weeks|| Documentation<br />
|-<br />
|| || Multilib Support|| Consider developing post-1.0 branch || 1|| to start in M4 || Richard|| ||<br />
|-<br />
|| Validation|| Alpha testing complete|| 4-5 internal developers unfamiliar with Yocto Project try to do a build and report on the experience and issues encountered|| 1|| Done by Feb 18 || Julie|| davest|| <br />
|-<br />
|| || || || || || || || <br />
|}<br />
<br />
== Features needed and to be put into sprints by assigned owners: ==<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || package config option enhancement|| there're several enhancements we may do here: * allow users setting specific config options (local or global) from external tool, such as poky image creator, instead of changing recipes manually. Need a mechanism to convert from variable assignments into exact config options (e.g. feature_${PN} = ""1"" -> ""--enable-feature""). Consequently dependency chain needs update with option status. * host contamination check. We have swabber to check host contamination, but I'm not sure whether it covers configuration phase. If not, this is one area to improve, as not ususually we see configure script checks host bits for available features * conditional option manipulation. In many recipes we enable/disable one option based on availability of other packages. Now this is done manually and not flexible. this should be made automatically though some new annotation to indicate condition, or just base_contains (not convenient: long line, need define distro features) || 2|| Review|| Richard/MarkH|| ktian1|| Enhancement<br />
|-<br />
|| Media|| Yocto Project Awareness Video|| This 2.5 minute video would introduce and describe the benefits of Yocto Project. The video would use entertaining animations that described concepts and benefits. The result would be suitable for YouTube, conferences, and the website. The production is called an "Epipheo" and will be created by Epipheo Studios. The engagement process has begun and the kick-off meeting will be soon. The PO is in place. Time for development is 10 weeks.|| High|| Kick-off Imminent|| Scott Rifenbark|| 10 Weeks|| Media<br />
|-<br />
|| Documentation|| Yocto Project Debugging Guide|| This would be a guide for the debugging and bug tracking process in Yocto Project. Originally, the thought was that we needed a Bugzilla User's Manual. However, since we don't own Bugzilla it doesn't make sense to produce documentation for it. Rather, we should document the process as it fits into the Yocto Project environment. Ideally, the manual would be a sub-manual that would be referenced and architected into the Yocto Project Development Guide. The manual has not been scoped and would take a week to scope. Again, I have no idea of the length. See the previous item for standard industry writing estimates for software documenation.|| Medium|| Not Started|| Scott Rifenbark|| 3-4 Weeks|| Documentation<br />
|-<br />
|| Website|| Yocto Project Website|| The 0.9 website is in place but needs updates. Items for consideration are the left-panel naviagation scheme, a contributions guidance page, color-scheming and theme (possibly).|| Medium|| Not Started|| Scott Rifenbark|| 1-2 Weeks|| Website<br />
|}<br />
<br />
== Features not believed to be needed in v1.0: ==<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || OpenEmbedded/Bitbake Upstreaming|| "We firstly need to review where we are and where OE is. We then need to make a plan about what we're going to push upstream and what we're not. I'd suggest when we're in PRC, we do a crash course in ""dealing with OE"" and then many dedicate a block of time (a week) where the distro team comes up with a patch set we then propose and get merged into OE. I'd like to find a couple of interested people to monitor OE more regularly and start a workflow of things between Poky/OE where appropriate. The key thing to remember is we need to keep the architectures compatible. The team is now at the point where I'm happy for them to actually try building OpenEmbedded and not worry about it tainting them! "|| 2|| Review|| || rpurdie|| Process<br />
|-<br />
|| Poky Features || Handle old versions in WORKDIR|| an incremental build directory may finally include many old versions WORKDIRS. It'll be good to have those old versions tracked in the cache, which can then either generate a report or allow selectively cleaning up an specific version WORKDIR. Or else it's difficult to figure it out when people want to keep the whole tmp directory but like to cleanup some old bits when disk usage is under pressure. If it's not easy to do in bitbake, perhaps some separate scripts would be also helpful || 3|| Review|| || ktian1|| Enhancement<br />
|-<br />
|| Poky Features || run bitbake w/o rebuilding the cache|| "sometimes it's useful to allow run bitbake w/o re-parsing recipes, if we know nothing metadata is changed. we can just allow reusing existing persistent cache. this is useful when people is debugging WORKDIR w/o metadata change. also sometimes ""bitbake -e"" is used frequently to check poky variable information. with existing cache, several seconds can be saved which are not negligible for a developer daily working on Yocto "|| 2|| Review|| || ktian1|| Enhancement<br />
|-<br />
|| Poky Features || parallel make improvement|| parallel make experience is not good, especially when bb threads and make threads are increased larger than 8. So far we either try to fix package makefile or mark the recipe as no parallel make, when build faiures are reported. But this greatly impacts user experience for a successfully continuous build process. Could we define a safe number we do want to support for 1.0 release? and then have our autobuilder, QA test, and developers cover that number immediately and fix any issues accordingly. Then the safe number can be suggested to the Yocto user || 2|| Review|| || ktian1|| Enhancement<br />
|-<br />
|| Poky Features || Dependency packages rebuild/clean|| It is a mechanism to rebulid or clean a package and all other packages which have build/runtime dependency on it. With this change, we can find potential influences of package upgrade to its related packages, which can make the incremental build more trustable. For example, if we upgrade a package to a new vesion which changes its API, this mechanism can easily find out the incompatibility to other packages which have dependency on it. || 2|| Review|| || dongxiao.xu|| Enhancement, replaced by checksum feature<br />
|-<br />
|| Distribution / components|| FOSSology|| This may be similar to License Update above, but start to use FOSSology to track licenses. || 2|| Review|| || sgw|| Hygiene<br />
|-<br />
|| Distribution / components|| Package Developer Tools|| Create a set of Init scripts template and then review our current init scripts and modify them to confirm to the template. || 2|| Review|| || sgw|| Easy of Use<br />
|-<br />
|| Distribution / components|| Package Website|| Complete the work the intern has started on generating the distro tracking information and get it out on the external site. || 2|| Review|| || sgw|| "Hygiene, duplicate of ""Package report system"""<br />
|-<br />
|| Distribution / components|| Bluetooth UI support|| Currently we have bluez package in poky, and we need to have a workable graphic user interface to connect/configure BT devices. One choice may be gnome-bluetooth-applet. || 3|| Review|| || dongxiao.xu|| enhancement<br />
|-<br />
|| Distribution / components|| Connman-gnome enhancement features|| Enable connman-gnome to support features like, WPA Enterprise connection, hidden SSID, etc. || 3|| Review|| || dongxiao.xu|| enhancement<br />
|-<br />
|| Distribution / components|| Java Running Environment support|| Since most embedded systems support java applications running in it, maybe we'd better consider supporting some kinds of JVMs(Embeded JVM). The JVM may not run by default, but user can launch it if running java applications. Compared with GTK/QT, java user number is not small too. || 3|| Review|| || criping|| enhancement<br />
|-<br />
|| Distribution / components|| create more use cases|| UPnP demo is one really good use case showing how Yocto is utilized to make real functionality. and we could create more to show how Yocto is easily adapted to real use cases. Those use cases can be either maintained as seperate demo layers in yocto repo, or in seperate branches for reference. We can also call for community's contribution on this which would make 1.0 full-fledged. Or else the newbies to Yocto may be in puzzle how our sample profiles can satisfy their requirements. || 2|| Review|| || ktian1|| enhancement<br />
|-<br />
|| Distribution / components|| i18n support || internationalization is an important system wide feature. Many component like font, locale affect the i18n. Yocto alreay has some i18n related package like pango, but so far did not consider i18n systematically. so this is place holder to systematically add i18n support. || 2|| Review|| || yuke/qing|| enhancement<br />
|-<br />
|| Distribution / components|| more demos || demos are a good way to educate, push the envelope, and at the same time tout the strengths of the platform. This item just records a current set of ideas from various sources which could/should be implemented: * face-recognition/face-finding, * robotic control/application of face-finding to 'camera-as-sensor' (hexbug demo), * others [tbd, add here]|| 2|| Review|| || tzanussi|| enhancement <br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer support for image-creator and needed yocto-metadata design||Come up design what need to be created as packages to support using "opkg install" for image-creator and needed yocto-metadata|| 2|| WIP, pending comments from RP regarding how to packaging metadata|| Jessica|| rpurdie|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer image-creator and needed poky-metadata support|| The poky build system will build packages for image-creator and needed poky-metadata, which the Yocto Installer will be able to use "opkg install" to install them|| 2|| Review|| Jessica|| rpurdie|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Provide qemu management UI|| In current eclipse plugin, QEMU settings are put together with project configuration. So we can only have limited settings. If we can have a separate QEMU management UI, the end user could firstly create a QEMU config, such as (env file of arch, image location, unfs or not, sato or lsb, mem size, disk size). And then he can launch a QEMU with a specific config. The dependency between project configuration and QEMU config will be resolved. After all QEMU has nothing to do project configuration. Need to careful review the UI to ensure minimal impact to testing matrix. || 3|| Review|| || criping|| "Enhancement, duplicate of ""Qemu mem/disk size can be adjusted"""<br />
|-<br />
|| Tool Development and SDK Features|| QT plugin For Eclipse|| Integrate QT Ecplise plugin and extend for Yocto Project || 3|| Review|| || jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Profiling/Trace GUI's|| We have a wealth of great tracing and profiling tools but the UI's for them are all extremely minimal and usually quite ugly. Would be great if we could compete with, or even better, Apple's offerings here. We have the technology! || 2|| Review|| || josh|| "Enhancement, duplicate of ""Tracing/Profiling Planning Complete"""<br />
|-<br />
|| Tool Development and SDK Features|| Other profiling tools|| Complete Tom's review of profiling tools and architecture || 2|| Review|| || josh|| "Enhancement, duplicate of ""Tracing/Profiling Planning Complete"""<br />
|-<br />
|| Tool Development and SDK Features|| Design next-gen tracing/profiling tools|| Yocto 1.0 will include all the essential existing tracing/profiling tools expected by users, and Josh has proposed a UI integration of all those tools as far as it's possible to do so. That level of integration, basically a 'plugin-level' integration is necessary and useful, but doesn't go far enough. A next-generation tracing tool would integrate at a much more fundamental level; if done properly, it would provide unmatched levels of power and usability to users, and would allow Yocto to distinguish itself in the embedded tracing/profiling space in a way also unmatched by any other distro/build-tool. The implementation would of course not be available for Yocto 1.0, but a coherent design, including prototypes, that could be taken to the community and implemented in a V 1.5 or 2.0 should be done in that time frame. || 1|| Review|| || tzanussi|| "Enhancement, duplicate of ""Tracing/Profiling Planning Complete"""<br />
|-<br />
|| Documentation Features|| Self Documentation of image contents|| "I'd like to see the -doc packages Poky builds being combined into some kind of large documentation index representing the collective API docs of the target being built. This can then be placed on a webserver and viewed over the web. We'd have a demonstration of this for a ""bitbake world"" target. Part of the idea here is to start making good use of the docs as if developers see this they might start writing better docs too. Aim is to lead the field :). There are a number of places poky packages disable doc generation due to missing tools so we'd need to add these so we can enable the doc generation. Many packages already have many docs though too. "|| 2|| Review|| || rpurdie|| enhancement<br />
|-<br />
|| Validation|| Testing Framework|| Add a framework for doing automated testing in the project|| 1|| Review|| || davest|| project commitment<br />
|-<br />
|| Validation|| more SDK builds on autobuilder|| enable more SDK related tests on autobuilder such as meta-ide-support, etc.|| 2|| Review|| || ktian1|| project commitment, addressed by test plan (?)<br />
|-<br />
|| Validation|| more people should try using SDK|| this may not be a feature, but a requirement. SDK including meta-toolchain is one key factor impacting user experience on Yocto. It's not enough to have only SDK team play with it|| 2|| Review|| || ktian1|| project commitment, addressed by test plan (?)<br />
|-<br />
|| Validation|| Unit Testing Framework|| Add a mechanism to bitbake to parse source packages that have unit tests and then execute them on the target|| 3|| Review|| || sgw|| "project commitment, duplicate of ""Testing Framework"""<br />
|-<br />
|| Validation|| Test Case open source|| Open source Yocto test cases with xml format|| 1|| Review|| || yyou|| "project commitment, duplicate of ""Testing Framework"""<br />
|}</div>Davesthttps://wiki.yoctoproject.org/wiki/index.php?title=Yocto_1.0_Schedule&diff=578Yocto 1.0 Schedule2011-01-25T01:19:02Z<p>Davest: /* Sprint B (closes Jan 07, 11:59pm PDT -- pull request sent, initially reviewed) */</p>
<hr />
<div>= v1.0 (release date: Apr 15, 2011) =<br />
----<br />
The detailed milestone map for v1.0 is as below. During the first week of each subsequent milestone past M1 we will have a demonstration of the previous milestone capabilities as well as a planning and design session for the current milestone.<br><br><br />
<br />
== M2 (Nov 08 to Dec 24 -- Dev Complete Dec 10, Stabilize Complete Dec 17, Release Complete Dec 24) ==<br />
=== Sprint A (closes Nov 12, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links''' <br />
|-<br />
|| Poky Features || Kernel interactive targets || To support incremental kernel development having the ability to run menuconfig (or xconfig, etc) directly is a common request. We'll need to add this for commercialization anyway. i.e. bitbake -c menuconfig. This fuctionality already exists. || 1 || Done || Richard || bruceashfield || Enhancement <br />
|-<br />
|| Distribution / components || Distro Audit: Upgrades Planned (Phase 1) || Complete plan for package upgrades in M2 || 1 || Done || Saul || || Continual Maintenance<br />
|-<br />
|| Validation || Runtime testing || Runtime testing of images as part of the autobuilder || 1 || Done || Jiajun/ScottG || rpurdie || project commitment<br />
|- <br />
|| || Poky Image Creator Wireframe/Interaction Plans Complete || || 1 || Done || Josh || ||<br />
|-<br />
|| || SDK Generator Interaction: Plans Complete || || 1 || Done || Jessica || ||<br />
|-<br />
|| || Tracing/Profiling Planning Complete || This needs to cover where we're at now, what we're missing and also propose the future enhancements that may be needed. M2 targets getting existing tools integrated and documented. F2f discussion n the future enhancements || || Done || Tom || ||<br />
|-<br />
|| || Swabber. (Still needs to be integrated into weekly build by default) || || 1 || Done || Josh || ||<br />
|-<br />
|| Build/Release || Release process documentation || || || Done || Beth || ||<br />
|-<br />
|| Validation || Test plan for v1.0 (to address any deficiencies in coverage from v0.9)|| || 1 || Done || Jiajun || ||<br />
|}<br />
<br />
=== Sprint B (closes Nov 19, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| Distro Audit: World Packages|| Audit world packages making sure it all build, making sure all are packages are required || 2|| Done || Saul|| sgw|| Hygiene<br />
|-<br />
|| Tool Development and SDK Features|| SDK Generator Installer UI|| Look at different ways of Installer UI (GTK+ and ncurses) seems none of them is the right choice, decide to go with script to implement all the functionalities of installer and later add UI part on top of it || 1||Done|| Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Customize sysroot setup || Add and test out "--sysroot" config option to cross compiler within Eclipse IDE || 1|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| SDK Generator Installer design revision|| Close all open questions regarding Yocto SDK Generator Installer function design and come up HLD || 1|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Distribution / components|| kernel version|| keeping 2.6.34 as a -stable kernel is the best option. I've also got a newer -devel tree that can be made available or made the default. || 3|| Done || Bruce|| bruceashfield|| enhancement<br />
|-<br />
|| || assign Yocto Project PM|| acquire and assign a program manager for Yocto Project|| || Done || DaveST|| || <br />
|-<br />
|| || assign Yocto Project Sys Admin|| || || Done || Saul|| || <br />
|-<br />
|| Tool Development and SDK Features|| oprofileUI|| Fixing various bugs of the oprofileUI to make it workable on big endian host.(i.e. ppc, mips) || 2 || Done || Jessica || lianhao.lu || Bug #382 / Bug #493<br />
|-<br />
|| Poky Feature|| SDK Version Control|| If we can expect that yocto SDK has lots of release in the future, we might need to consider SDK version control. Currently, every thing installed under /opt/poky which leads to things be overriden, we need to be able to use a scheme like /opt/poky-1.0, /opt/poky-2.0 to distiguish things. || 2|| Done || Josh|| jzhang|| Enhancement<br />
|-<br />
|| Kernel || Kernel plan complete || Flesh our kernel deliverables and add to Yocto 1.0 schedule || || Done|| Darren || dvhart ||<br />
|}<br />
<br />
=== Sprint C (closes Nov 26, 11:59pm PDT -- pull request sent, initially reviewed) :: NOTE: this is US Thanksgiving week ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| Distro Audit: Licence Checksums|| licence checksums || 1|| Done || Saul|| rpurdie|| Hygiene<br />
|-<br />
|| Poky Features || Performance Analysis Completed|| "I'd like someone to instrument a green release build, see where it spends time (hot/cold parsing time, individual task building time) and then compare this with our 0.9 release build. I'd also like to compare the disk usage between the two. Once we have a blame list we can then set about fixing it. Some things I know will come up: a) pseudo, b) checksums/signature code, c) exec() vs fork for executing tasks, d) task based prebuilds increasing disk usage, e) rpm dependency calculations, f) using rpm vs. ipk but I may be wrong and there may be others. We need numbers. "|| 1|| Done || Saul / Qing, Dongxiao|| rpurdie|| Enhancement<br />
|-<br />
|| Poky Features || environment variables for kernel builds|| switching a branch, or adding a configuration feature (and even changing the kernel repo) is often done during development of a BSP. Having some additional variables that are pass the bitbake environment scrub would be useful. i.e. KBRANCH=foo bitbake -c configure linux-yocto. This goes along with the other BSP bootstrapping suggestions. || 2|| Done || Bruce|| bruceashfield|| Enhancement<br />
|-<br />
|| Supported Targets|| ARM Platform Support|| Replace beagleboard with Beagleboard XM - decision || 2|| Done || Bruce|| alex|| Basic Yocto hardware support <br />
|-<br />
|| Distribution / components|| Security Process|| We need a dedicated person to scan and apply critical security updates to the distro. The MeeGo team already has a similar process with some scripts which may be leveraged. To complete the task, the process should be documented and a first pass over the metadata made to establish the current position on security. Any upgrades needed should be identified and a plan to address them should be in place but doesn't have to be implemented by this point.|| 1|| Done || ScottG|| ktian1|| enhancement<br />
|-<br />
|| Tool Development and SDK Features|| SDK Generator Installer Opkg repo design|| Come up a opkg repo design that will mimic the final Yocto package repo layout to be used by SDK Generator Installer to test against|| 2 || Done || Jessica || jzhang || <br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer tar creaion|| Create a Yocto Installer tar ball which contains Installer script and supported opkg component that will be used for installing other Yocto components|| 2 || Done || Jessica || jzhang || <br />
|-<br />
|| Documentation|| Kernel Framework Paper from WR|| The paper from WR needs to be re-written and then posted somewhere on the Yocto Project site. This will involve examiniation of the text and re-writing and formatting for presentation. Currently it is simply a text document. Completion time assuming uninterrupted time is one week.|| High|| Done || Scott Rifenbark|| 1 Week|| Documentation<br />
|-<br />
|| Documentation|| Poky Reference Manual|| This guide exists in the 0.9 form. The re-write of the text needs to be completed. So far, all the chapters have been rewritten but not re-posted on the site. Only the appendices remain for a text scrub. Time to complete this would be a week of uninterrupted time. Ideally, the manual would be a sub-manual that would be referenced and architected into the Yocto Project Development Guide.|| Medium|| Done|| Scott Rifenbark|| 1 Week|| Documentation<br />
|-<br />
|| Kernel || Initial meta-linaro layer || meta-linaro layer providing a kernel, tool-chain, and uboot loader. This deliverable is primarily to get the infrastructure in place and have a buildable kernel. Toolchain on best effort basis. || || Done || Darren || dvhart || Moderate risk of slippage due to holidays.<br />
|-<br />
|| Kernel || Tracing: blktrace and sysprof recipes || || || Done || Tom || dvhart ||<br />
|}<br />
<br />
=== Sprint D (closes Dec 3, 11:59pm PDT -- pull request sent, initially reviewed) :: NOTE: week of the F2F planning meeting ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Kernel || Kernel git branching structure revamped || || 1 || Done || Bruce || dvhart ||<br />
|-<br />
|| Kernel || Tunnel Creek (Crown Bay) || || 1 || Done || Tom || dvhart ||<br />
|}<br />
<br />
=== Sprint E (closes Dec 9 (THURSDAY), 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| Distro Audit: Upgrades Completed (Phase 1)|| Update to new versions as per the agreed plan for M2 from Sprint A|| 1|| Done || Saul|| rpurdie|| Continual Maintenance<br />
|-<br />
|| Distribution / components|| Distro Audit: Src Checksums|| Make sure all SRC_URI components have checksums too || 1|| Done || Saul|| rpurdie|| Hygiene<br />
|-<br />
|| Poky Features || enable KVM with qemu|| today all new Intel processors support VT, which are enabled on most desktop machines which are most frequently used build machine. with VT support, x86/x86-64 qemu target runs faster which is a good thing for emulation environment. This may require some qemu option tweaks and also poky-qemu script enhancement. || 2|| Done || Saul / Edwin|| ktian1|| Enhancement<br />
|-<br />
|| Kernel || New kernel recipes || dev, -devel, -custom || 3 || Done || Bruce || dvhart ||<br />
|-<br />
|| Swabber || Documentation for swabber || || 1 || Done || Alex || ||<br />
|-<br />
|| CCB || Defect triage process in public documented and implemented || || 1 || Done. Triage process is documented, out for review. || Saul || ||<br />
|}<br />
<br />
== M3 (Dec 20 to Feb 08 -- Dev Complete Feb 04, Stabilize Complete Feb 11, Release Complete Feb 18) ==<br />
=== Sprint A (closes Dec 24, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Kernel || Initial meta-rt layer || PREEMPT_RT kernel and related test-cases and benchmarks || 2 || Done by Jan 21 || Darren || dvhart || slipped out from M2<br />
|-<br />
|| Poky Features || Fetcher Overhaul Phase 1 - SRC_REV enhancement||<br />
* a) Add code in FetchData::__init__() which will check if the selected fetcher supports srcrev and the automatically call a function to set the src rev value instead of each fetcher doing this.\n <br />
* e) Break SRCREVINACTION deadlock. To do this, we need to start using a keyword for automatically increasing SRCREV, e.g. SRCREV = "AUTOINC". The actual revision can be injected into PV using SRCPV. If we do this there should no longer be a need of the deadlock; <br />
* k) Ensure that we only set __BB_DONT_CACHE when SRCREV = "AUTOREV". This may need a new method call for fetchers to tell whether they're "floating" or locked down.<br />
|| 1|| Done || Saul / Ke, RP|| rpurdie|| Enhancement, slipped out from M2<br />
|-<br />
|| Distribution / components|| Distro Audit Upgrades Planned (Phase 2)|| Complete plan for package upgrades in M2|| 1|| Done || Saul|| || Continual Maintenance<br />
|-<br />
|| Poky Features || Pseudo Performance || Implement the changes to bitbake based on pseudo's enable/disable switch|| 1|| done || Saul / Qing, Dongxiao || rpurdie|| Enhancement, slipped from M2 due to risk and not having Pseudo's change yet.<br />
|-<br />
|| Tool Development and SDK Features|| Fix the issue user target sysroot is owned by root || The ADT installer will use pseudo to extract user target sysroot which ended up owned by root, this need to be fixed || 1|| done || Jessica|| jzhang|| Cleanup <br />
|-<br />
|| Tool Development and SDK Features|| Eclipse poky tree interfacing (metadata file editor)|| Provide a metadata file editor with some syntax checking and keywords highlight capabilities|| 2|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| IDE Project templates|| Templates for various project types: Clutter GUI, Gtk+ GUI, to help developers get started quickly || 2|| Done || Jessica|| josh|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| push TCF/RSE patches upstream|| work with community to finish up our TCF terminal service, TCF/RSE integration remaining patches taken by upstream. Blocking issues including Eclipse Bug #327865 || 1|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Pseudo || Pseudo enhancement to enable on/off switch || || 1 || done || Mark || ||<br />
|-<br />
|| Pseudo || Bitbake enhancement for pseudo on/off switch || || 1 || done || Richard || ||<br />
|-<br />
|| bugzilla || Complete restructure of bugzilla categories || || 1 || done || Saul || ||<br />
|-<br />
|| Poky Features || Image creator ground work || Nomenclature determined, existing gui's bug fixed and backend work implemented || 1 || Done || Joshua || ||<br />
|-<br />
|| Kernel || Tracing: Initial SystemTap recipe || Works on x86 || 3 || Done || Tom || dvhart ||<br />
|-<br />
|| Distribution / components|| Distro Audit: Package Description/Summary completed|| Ensure DESCRIPTION/SUMMARY fields are all audited|| 2|| Done || Mark|| Mark|| Hygiene, was M2, Sprint B but missed window<br />
|-<br />
|| Distribution / components|| Zypper/RPM|| Small write-up of the problems we're having w/ Zypper and what we plan to do. (i.e. create a roadmap/design) - Includes rootfs generation - Package uprev/install/removal || 1 || Done || Mark/Qing || || was M2, Sprint B<br />
|-<br />
|| Distribution / components|| Distro Audit: Licence Checksums|| Make the licence checksums fatal if not present || 1|| Done || Saul|| rpurdie|| Hygiene, was M2, Sprint C<br />
|-<br />
|| Distribution / components|| push of all relevant Wind River patchs to Yocto (patch comparison)|| Ensure patches present to packages in WRS are also in Poky|| 1|| Done || Mark|| Mark|| was M2, Sprint C<br />
|-<br />
|| Poky Features || Performance Enhancement Completed || Initial changes to reduce disk space (sstate-build-*) || 1|| Done || Saul / Qing, Dongxiao || rpurdie|| Enhancement, was M2, Sprint E<br />
|-<br />
|| Distribution / components|| User specified qemu config support|| We'll provide user an edit box which allows advanced qemu user to specify arbitrary qemu configuration to meet their needs, which the poky-qemu scrip will just append the config list towards the end of the list of parameters to bring up qemu, it also expect the poky-qemu script to do some basic sanity check on the user specifications to catch the obvious mistake || 2|| Done || Saul / criping || criping|| enhancement, was M2, Sprint E<br />
|-<br />
|| Tool Development and SDK Features|| SDK Version Control support in SDK generator installer|| If we can expect that yocto SDK has lots of release in the future, we might need to consider SDK version control. Currently, if we un-tar the sdk, it will override the older version. It's not good for app developers since they might need the old version to do something. And also, maybe a finer installer than untar is preferred. Installer will tied to certain SDK version and the installation will go under /opt/poky-versionNo.|| 1|| Done || Jessica|| criping|| Enhancement-expect planning process by Jessica to handle this task. Was M2, Sprint E.<br />
|}<br />
<br />
=== Sprint B (closes Jan 07, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || Bitbake multi-threaded parsing|| Bitbake recipe parsing is currently single threaded. I want to make this multithreaded as the speedup would be nice. If I can only take a single task for myself for 1.0, I'm nominating this one as I enjoy this kind of thing and I have ideas on how to do it. || 1|| Done || Richard|| rpurdie|| Enhancement<br />
|-<br />
|| Distribution / components|| Lock in Kernel/Toolchain version|| Locked in 2.6.37 and gcc 4.5.1. Pending decision to move to 4.5.2 and Linaro || || Done || || Richard|| || <br />
|-<br />
|| Distribution / components|| License Update|| For each of the licences we support, I'd really like to have a licences directory with a copy of that license contained within. When it comes to deciding what a given LICENSE field means, this would be the reference. It also means we can include the licences a given image includes with the image. This continues to make our license handling world class and ahead of the field. || 2|| Done || Beth|| rpurdie|| Hygiene<br />
|-<br />
|| Tool Development and SDK Features|| Qemu configuration change|| Provice edit box for advanced user to specify qemu configurations|| 2|| Done || Jessica|| criping|| <br />
|-<br />
|| Tool Development and SDK Features|| Lock down Eclipse+CDT+TCF version|| Will use Eclipse Halo 3.6 || 1|| Done || Jessica|| || <br />
|-<br />
|| Demo|| Finalize on demo plans for v1.0 launch || || 1|| Slip to Sprint C || Dave || || <br />
|-<br />
|| Release || Release plans for v1.0 launch || Fill out the M4 plan with the necessary release activities and timings || 1|| Done || Beth || || <br />
|-<br />
|| Poky Features || Basic image creator GUI || Functional UI missing some Advanced features || 1 || In replan || Joshua || || <br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer for SDK Generator Installation functions support||Detailed feature request can be found at: http://bugzilla.pokylinux.org/show_bug.cgi?id=589|| 1|| Done || Jessica|| rpurdie|| Enhancement<br />
|-<br />
|| Kernel || Tracing: trace-cmd python binding cleanup || || 3 || Done || Darren || dvhart ||<br />
|}<br />
<br />
=== Sprint C (closes Jan 14, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || kernel development layer|| The (correct) poky behaviour of building known revisions coupled with the fetcher requiring a BSP branch to already be present means that local modifications (and kernel source tree) are required for kernel development. I already have a layer that overrides/modifies the behaviour when added to the bblayers.conf and configured into an environment. This seems useful for more people to use. || 2|| Done || Bruce|| bruceashfield|| Enhancement, was M2, Sprint C<br />
|-<br />
|| Distribution / components|| Zypper/RPM|| RPM Uprev / Zypper Uprev [lets get to the latest versions]|| 1|| pull request by Jan 19; || Mark/Qing|| || was M2, Sprint C<br />
|-<br />
|| Supported Targets|| Intel Platform Support|| JasperForest|| 2|| Basic support in place; DPDK evaluation in process, overall BSP plan still TBD || Tom|| davest|| Basic ECG support (Moved from Sprint A)<br />
|-<br />
|| Tool Development and SDK Features|| Eclipse poky tree interfacing (git support)|| Use Eclipse git capability to install poky tree from git repo and able to interact with git repo at file level within Poky tree || 2|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Poky Features || Fetcher Overhaul Phase 2 - API reorg||<br />
* f) Add a generic unpack funciton to __init__.py based on the unpack task in Poky ;<br />
* g) Split go() methods into the following steps: i) download() - do whatever transfer is necessary to get the sources locally ii) build_mirror_data() - generate any data that would be needed to construct a source mirror iii) unpack() - takes a directory as an argument of where to place extracted sources;<br />
The existing go() methods should be replaced with a set of calls to the above sections of functionality as appropriate in the individual fetchers. Some of these categories of function make no sense in certain fetchers, in which case they shouldn't need to implement them. Functions are only executed if the method is present.<br />
* h) Change Poky's unpack to call an unpack method in the fetchers.<br />
* i) Change Poky's fetch task to call a "download" method in the fetcher instead of go().<br />
|| 1|| Will land with phase 3 in Jan 21 || Saul / Ke, RP|| rpurdie|| Enhancement<br />
|-<br />
|| Poky Features || DSO linking changes|| "By the default the gcc linker will automatically link any dependant objects/libraries. ""Inherited"" linkages can cause issues, for example, where a shared object changes its dependencies but a program has come to rely on symbols from an implicitly linked library. Fedora implemented this change in F13, seems like it would be useful to have in Poky too. "|| 2|| On track for Jan 21 || Saul / Nitin || josh|| bug#516<br />
|-<br />
|| Distribution / components|| Distro Audit Documentation Output|| Audit package documentation output || 2|| Move to Sprint D due to libtool work || Saul / ScottG || rpurdie|| Hygiene<br />
|-<br />
|| Poky Features || libtool sysroot option|| libtool 2.4 has a sysroot option. We should try and use it, see how it works and whether we can ditch some of our libtool hacks. || 1|| On track for Jan 21 || Saul / ScottG || rpurdie|| Enhancement<br />
|-<br />
|| Distribution / components|| MACHINE or Recipe specific sysroots|| Each machine should have its own sysroot. We'll probably have to split do_populate_sysroot into a two step process, creation of the package and than installtion of the package, which the installation of the package being made machine specific (put ${MACHINE} into ${STAMP} and bitbake should do that). Also allowing this to work per recipe would be desireable|| 1|| On track 21 || Saul / Dongxiao || rpurdie|| Hygiene<br />
|-<br />
|| Distribution / components|| Toolchain Bootstrap Process|| The toolchain as it bootstraps overwrites files like libc.so and libgcc.so in the sysroot directory which causes issues if you just try and rebuild part of the toolchain. Each step of the bootstrap process should use a separate sysroot. Once this is once, sstate file overwriting detection can be added and enabled. || 1|| Patches submitted for comment, slip to Sprint D || Saul / Dexuan || rpurdie|| Hygiene<br />
|-<br />
|| Poky Features || Poky Image Creator|| A standalone application you can run which asks you to select a distro and machine, then presents a list of packages you can select. Once the selection is made, it goes off and bakes you an image which is then presented to you. Implementation wise, it should use the sstate packages, be a bitbake UI and use the usual poky bbclass files to do the image construction behind the scenes. || 1|| Re-plan || Joshua|| rpurdie|| Enhancement<br />
|-<br />
|| Poky Features || Fetcher Overhaul Phase 3 - git enhancement||<br />
* j) Optimize git fetcher for the new layout so for a git checkout, we clone the repository in download(), then unpack just does a clone with references to the original repo. <br />
* k) Ensure that we only set __BB_DONT_CACHE when SRCREV = "AUTOREV". This may need a new method call for fetchers to tell whether they're "floating" or locked down. <br />
* l) Add a new "BB_NO_NETWORK" variable which the fetchers check before peforming an operation which hits anything remote. This means adding in error messages about why network access is needed at various points (e.g. SRCREV = "AUTOREV" for a given recipe) <br />
* m) Add multiple branch/srcrev support for git fetcher. These would be of the form: git://somelocation/somerepo.git;name=ref1;branch=foo;name=ref2;branch=bar SRCREV_ref1 = "hash1" SRCREV_ref2 = "hash2" which would ensure both hash1 and hash2 were in the final repo. <br />
* n) Change git fetcher to default to git protocol instead of rsync<br />
|| 1|| Slipped to Sprint D || Saul / Ke, RP|| rpurdie|| Enhancement<br />
<br />
|-<br />
|| Validation|| Boottime/Performance Analysis|| Compare Yocto Project performance to other projects such as MeeGo|| 1|| Initial report on where we are by Feb 9 || Darren|| davest|| project commitment <br />
|-<br />
|| Distribution / components|| LSB Sanity|| execute LSB Test and improve passing rate and document failures with clear understanding|| 2|| Done || MarkH/Saul|| sgw|| Hygiene<br />
|-<br />
|| Distribution / components|| Review & Fix Standards Tests|| Review the results from LTP, POSIX and asses the result, fix as appropriate and clearly document failures.|| 2|| a Plan to resolve final items to be sent to the m.l. by Jan 14 || Saul/Kevin || sgw|| Hygiene<br />
|-<br />
|| Tool Development and SDK Features|| Image creator integration with Eclipse || || 2|| replan|| Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Kernel || Tracing: perf trace marker support || This is from feedback to the new trace command. Ingo appears to have this nearly complete already. || 3 || Done || Darren || dvhart ||<br />
|-<br />
|| Kernel || Tracing: perf trace scripting support || || 3 || Move to Sprint D; on track for Jan 21 || Tom || dvhart ||<br />
|-<br />
|| Cleanup || bitbake user experience error handling validation completed || || 2 || Done || Richard || ||<br />
|-<br />
|| Cleanup || variable scrub - ensure all metadata variables are documented || Script with a histogram of variable use done, identified 50 variables to document; Add task for actual documentation update is low on the list || 2 || Done || Scott/Darren || ||<br />
|-<br />
|| Distribution / components|| Zypper/RPM|| Integration based on design from Sprint B|| 1|| On track for Jan28 || Mark/Qing|| sgw|| Functionality, was M2, Sprint E<br />
|-<br />
|| Kernel || Tracing: package kernelshark || || 3 || Done || Darren || dvhart ||<br />
|-<br />
|| Kernel || Tracing: tuna, oscillosope recipes || || 3 || Tom to discuss plan with Darren et al || Tom || dvhart ||<br />
|- <br />
|| BSP || Beagleboard XM Support || || 3 || Move to Sprint D || Darren || dvhart ||<br />
|}<br />
<br />
=== Sprint D (closes Jan 21, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Swabber || Complete review of swabber outputs || Move to M3 Sprint D || 1 || Move to M3 Sprint D || Alex || ||<br />
|-<br />
|| Documentation Features|| Package report system|| move to public server [setup a package report system in an internal machine. We need push it publicly available. The basic features like search and report have been there. But there're still some enhancements in plan, to make it a fit place to feel Yocto metadata comfortably]|| 2|| Move to Sprint E|| KevinT|| ktian1|| enhancement<br />
|-<br />
|| Distribution / components||Add headers and libraries to qemu images ||Since we'll be using qemu images as target sysroot, need to create a set of qemu images for minimal, sato, LSB that contains target header and libraries.|| 2|| Pending a discussion on Jan 18 || Saul ||jzhang|| Enhancement<br />
|-<br />
|| Distribution / components|| push of all relevant Wind River patchs to Yocto (patch comparison)|| Update any additional patches needed since M2.|| 1|| May be done by Jan 21, pending RPM stuff || Mark|| Mark|| <br />
|-<br />
|| Distribution / components|| mklibs|| mklibs is a tool to optimize size of [e]glibc for a perticular root file system image. It is useful to save disk space on small devices. || 2|| Push to Sprint E || Saul|| Nitin Kamble|| enhancement<br />
|-<br />
|| Poky Features || Performance Enhancement || reduce disk space (hardlink) || 1 || On track for Jan 21, pending RP review || Saul / Qing, Dongxiao || rpurdie || Enhancement<br />
|-<br />
|| BSP || 2.6.37 Crown Bay Support || On Track for Jan 21 || 2 || || Tom || dvhart || <br />
|-<br />
|| BSP || 2.6.37 Emenlow Support || On track for Jan 21 || 2 || || Tom || dvhart || <br />
|}<br />
<br />
=== Sprint E (closes Jan 28, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Documentation Features|| Package report system|| finish major feature development and internal review [setup a package report system in an internal machine. We need push it publicly available. The basic features like search and report have been there. But there're still some enhancements in plan, to make it a fit place to feel Yocto metadata comfortably]|| 2|| Move to Sprint E || Jonathan || ktian1|| enhancement, was M2, Sprint E<br />
|-<br />
|| Distribution / components|| perl upgrade|| perl is the most cross un-friendly recipe pending upgrade. || 2|| Slipping due to Linaro layer, moves to end of Sprint E || Nitin|| Nitin Kamble|| enhancement<br />
|-<br />
|| Supported Targets|| Intel Platform Support|| Sandybridge|| 2|| Accept|| Tom|| davest|| Basic ECG support<br />
|-<br />
|| Distribution / components|| performance indicators|| define some indicators (boot time, footprint, build time, power, component benchmarks, etc.) and then collect them for tracking purpose. The result could be posted on the wiki site, and the initial indicators can be easy ones which can be easily retrieved from autobuilder or weekly qa report). This way we have a clear track about the healthy of the Yocto project, and also identify weak areas. We can include qemu targets and several representational boards as the targets. || 2|| Review|| Beth/Jiajun|| ktian1|| enhancement<br />
|-<br />
|| Tool Development and SDK Features|| SDK user workshop|| Have some developers sit down and use our tools to develop demo software for Yocto. || 2|| Review|| Jessica|| josh|| Enhancement<br />
|-<br />
|| Kernel || Final linux-yocto_git.bb || With 2.6.37 kernel || 1 || || Bruce || dvhart ||<br />
|-<br />
|| Kernel || Final meta-linaro layer || || || || Darren || dvhart ||<br />
|-<br />
|| Kernel || Final meta-rt layer || || || || Darren || dvhart ||<br />
|-<br />
|| Kernel || Sandy Bridge || || 1 || || Tom || dvhart ||<br />
|}<br />
<br />
=== Sprint F (closes Feb 03 (THURSDAY), 11:59pm PDT -- pull request sent, initially reviewed) :: NOTE: China New Year Holiday ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Documentation|| ADT Reference Guide Draft out for review || Outline complete|| High|| WIP || Scott Rifenbark|| jzhang|| Documentation<br />
|-<br />
|| || || || || || || || <br />
|}<br />
<br />
== M4 (Feb 07 to Apr 15 -- Stabilize Complete Mar 18, Release Complete Apr 01, Contingency to Apr 15) ==<br />
<br />
This sprint is the [[Yocto Project v. 1.0 Release Cycle]].<br />
<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Documentation|| Migration chapter in the Poky Reference Manual|| This chapter would cover the four identified use-cases for migrating up to the most recent version of Yocto Project. Additionally, it would cover migration scenarios from other development systems. The chapter does not yet exist. The chapter has not been scoped outside of having a meeting that identified four use-cases that did not include migration from a development system outside of Yocto Project. It will take some more scoping time to cover those areas (a day or two). Again, I have no idea of the length. See earlier entries for standard industry writing estimates for software documentation|| Medium|| Not Started|| Scott Rifenbark|| 3-4 Weeks|| Documentation<br />
|-<br />
|| Documentation|| Yocto Project Development Guide|| This manual would be an over-arching document that frames the complete development cycle within Yocto Project. The idea here is that the document would be an umbrella document that spawned and referenced subsequent documents. The organization would be the first chapter overviewing the major development pieces such as recipe creation, building, debugging, publishing, fail-safing, back-door hook creation, etc. Scoping would be about two weeks and length would probably be about 40 pages. Overall development time would likely be a month of uniterruped time.|| Medium|| Not Started|| Scott Rifenbark|| 3 Weeks|| Documentation<br />
|-<br />
|| || Multilib Support|| Consider developing post-1.0 branch || 1|| to start in M4 || Richard|| ||<br />
|-<br />
|| Validation|| Alpha testing complete|| 4-5 internal developers unfamiliar with Yocto Project try to do a build and report on the experience and issues encountered|| 1|| Done by Feb 18 || Julie|| davest|| <br />
|-<br />
|| || || || || || || || <br />
|}<br />
<br />
== Features needed and to be put into sprints by assigned owners: ==<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || package config option enhancement|| there're several enhancements we may do here: * allow users setting specific config options (local or global) from external tool, such as poky image creator, instead of changing recipes manually. Need a mechanism to convert from variable assignments into exact config options (e.g. feature_${PN} = ""1"" -> ""--enable-feature""). Consequently dependency chain needs update with option status. * host contamination check. We have swabber to check host contamination, but I'm not sure whether it covers configuration phase. If not, this is one area to improve, as not ususually we see configure script checks host bits for available features * conditional option manipulation. In many recipes we enable/disable one option based on availability of other packages. Now this is done manually and not flexible. this should be made automatically though some new annotation to indicate condition, or just base_contains (not convenient: long line, need define distro features) || 2|| Review|| Richard/MarkH|| ktian1|| Enhancement<br />
|-<br />
|| Media|| Yocto Project Awareness Video|| This 2.5 minute video would introduce and describe the benefits of Yocto Project. The video would use entertaining animations that described concepts and benefits. The result would be suitable for YouTube, conferences, and the website. The production is called an "Epipheo" and will be created by Epipheo Studios. The engagement process has begun and the kick-off meeting will be soon. The PO is in place. Time for development is 10 weeks.|| High|| Kick-off Imminent|| Scott Rifenbark|| 10 Weeks|| Media<br />
|-<br />
|| Documentation|| Yocto Project Debugging Guide|| This would be a guide for the debugging and bug tracking process in Yocto Project. Originally, the thought was that we needed a Bugzilla User's Manual. However, since we don't own Bugzilla it doesn't make sense to produce documentation for it. Rather, we should document the process as it fits into the Yocto Project environment. Ideally, the manual would be a sub-manual that would be referenced and architected into the Yocto Project Development Guide. The manual has not been scoped and would take a week to scope. Again, I have no idea of the length. See the previous item for standard industry writing estimates for software documenation.|| Medium|| Not Started|| Scott Rifenbark|| 3-4 Weeks|| Documentation<br />
|-<br />
|| Website|| Yocto Project Website|| The 0.9 website is in place but needs updates. Items for consideration are the left-panel naviagation scheme, a contributions guidance page, color-scheming and theme (possibly).|| Medium|| Not Started|| Scott Rifenbark|| 1-2 Weeks|| Website<br />
|}<br />
<br />
== Features not believed to be needed in v1.0: ==<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || OpenEmbedded/Bitbake Upstreaming|| "We firstly need to review where we are and where OE is. We then need to make a plan about what we're going to push upstream and what we're not. I'd suggest when we're in PRC, we do a crash course in ""dealing with OE"" and then many dedicate a block of time (a week) where the distro team comes up with a patch set we then propose and get merged into OE. I'd like to find a couple of interested people to monitor OE more regularly and start a workflow of things between Poky/OE where appropriate. The key thing to remember is we need to keep the architectures compatible. The team is now at the point where I'm happy for them to actually try building OpenEmbedded and not worry about it tainting them! "|| 2|| Review|| || rpurdie|| Process<br />
|-<br />
|| Poky Features || Handle old versions in WORKDIR|| an incremental build directory may finally include many old versions WORKDIRS. It'll be good to have those old versions tracked in the cache, which can then either generate a report or allow selectively cleaning up an specific version WORKDIR. Or else it's difficult to figure it out when people want to keep the whole tmp directory but like to cleanup some old bits when disk usage is under pressure. If it's not easy to do in bitbake, perhaps some separate scripts would be also helpful || 3|| Review|| || ktian1|| Enhancement<br />
|-<br />
|| Poky Features || run bitbake w/o rebuilding the cache|| "sometimes it's useful to allow run bitbake w/o re-parsing recipes, if we know nothing metadata is changed. we can just allow reusing existing persistent cache. this is useful when people is debugging WORKDIR w/o metadata change. also sometimes ""bitbake -e"" is used frequently to check poky variable information. with existing cache, several seconds can be saved which are not negligible for a developer daily working on Yocto "|| 2|| Review|| || ktian1|| Enhancement<br />
|-<br />
|| Poky Features || parallel make improvement|| parallel make experience is not good, especially when bb threads and make threads are increased larger than 8. So far we either try to fix package makefile or mark the recipe as no parallel make, when build faiures are reported. But this greatly impacts user experience for a successfully continuous build process. Could we define a safe number we do want to support for 1.0 release? and then have our autobuilder, QA test, and developers cover that number immediately and fix any issues accordingly. Then the safe number can be suggested to the Yocto user || 2|| Review|| || ktian1|| Enhancement<br />
|-<br />
|| Poky Features || Dependency packages rebuild/clean|| It is a mechanism to rebulid or clean a package and all other packages which have build/runtime dependency on it. With this change, we can find potential influences of package upgrade to its related packages, which can make the incremental build more trustable. For example, if we upgrade a package to a new vesion which changes its API, this mechanism can easily find out the incompatibility to other packages which have dependency on it. || 2|| Review|| || dongxiao.xu|| Enhancement, replaced by checksum feature<br />
|-<br />
|| Distribution / components|| FOSSology|| This may be similar to License Update above, but start to use FOSSology to track licenses. || 2|| Review|| || sgw|| Hygiene<br />
|-<br />
|| Distribution / components|| Package Developer Tools|| Create a set of Init scripts template and then review our current init scripts and modify them to confirm to the template. || 2|| Review|| || sgw|| Easy of Use<br />
|-<br />
|| Distribution / components|| Package Website|| Complete the work the intern has started on generating the distro tracking information and get it out on the external site. || 2|| Review|| || sgw|| "Hygiene, duplicate of ""Package report system"""<br />
|-<br />
|| Distribution / components|| Bluetooth UI support|| Currently we have bluez package in poky, and we need to have a workable graphic user interface to connect/configure BT devices. One choice may be gnome-bluetooth-applet. || 3|| Review|| || dongxiao.xu|| enhancement<br />
|-<br />
|| Distribution / components|| Connman-gnome enhancement features|| Enable connman-gnome to support features like, WPA Enterprise connection, hidden SSID, etc. || 3|| Review|| || dongxiao.xu|| enhancement<br />
|-<br />
|| Distribution / components|| Java Running Environment support|| Since most embedded systems support java applications running in it, maybe we'd better consider supporting some kinds of JVMs(Embeded JVM). The JVM may not run by default, but user can launch it if running java applications. Compared with GTK/QT, java user number is not small too. || 3|| Review|| || criping|| enhancement<br />
|-<br />
|| Distribution / components|| create more use cases|| UPnP demo is one really good use case showing how Yocto is utilized to make real functionality. and we could create more to show how Yocto is easily adapted to real use cases. Those use cases can be either maintained as seperate demo layers in yocto repo, or in seperate branches for reference. We can also call for community's contribution on this which would make 1.0 full-fledged. Or else the newbies to Yocto may be in puzzle how our sample profiles can satisfy their requirements. || 2|| Review|| || ktian1|| enhancement<br />
|-<br />
|| Distribution / components|| i18n support || internationalization is an important system wide feature. Many component like font, locale affect the i18n. Yocto alreay has some i18n related package like pango, but so far did not consider i18n systematically. so this is place holder to systematically add i18n support. || 2|| Review|| || yuke/qing|| enhancement<br />
|-<br />
|| Distribution / components|| more demos || demos are a good way to educate, push the envelope, and at the same time tout the strengths of the platform. This item just records a current set of ideas from various sources which could/should be implemented: * face-recognition/face-finding, * robotic control/application of face-finding to 'camera-as-sensor' (hexbug demo), * others [tbd, add here]|| 2|| Review|| || tzanussi|| enhancement <br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer support for image-creator and needed yocto-metadata design||Come up design what need to be created as packages to support using "opkg install" for image-creator and needed yocto-metadata|| 2|| WIP, pending comments from RP regarding how to packaging metadata|| Jessica|| rpurdie|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer image-creator and needed poky-metadata support|| The poky build system will build packages for image-creator and needed poky-metadata, which the Yocto Installer will be able to use "opkg install" to install them|| 2|| Review|| Jessica|| rpurdie|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Provide qemu management UI|| In current eclipse plugin, QEMU settings are put together with project configuration. So we can only have limited settings. If we can have a separate QEMU management UI, the end user could firstly create a QEMU config, such as (env file of arch, image location, unfs or not, sato or lsb, mem size, disk size). And then he can launch a QEMU with a specific config. The dependency between project configuration and QEMU config will be resolved. After all QEMU has nothing to do project configuration. Need to careful review the UI to ensure minimal impact to testing matrix. || 3|| Review|| || criping|| "Enhancement, duplicate of ""Qemu mem/disk size can be adjusted"""<br />
|-<br />
|| Tool Development and SDK Features|| QT plugin For Eclipse|| Integrate QT Ecplise plugin and extend for Yocto Project || 3|| Review|| || jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Profiling/Trace GUI's|| We have a wealth of great tracing and profiling tools but the UI's for them are all extremely minimal and usually quite ugly. Would be great if we could compete with, or even better, Apple's offerings here. We have the technology! || 2|| Review|| || josh|| "Enhancement, duplicate of ""Tracing/Profiling Planning Complete"""<br />
|-<br />
|| Tool Development and SDK Features|| Other profiling tools|| Complete Tom's review of profiling tools and architecture || 2|| Review|| || josh|| "Enhancement, duplicate of ""Tracing/Profiling Planning Complete"""<br />
|-<br />
|| Tool Development and SDK Features|| Design next-gen tracing/profiling tools|| Yocto 1.0 will include all the essential existing tracing/profiling tools expected by users, and Josh has proposed a UI integration of all those tools as far as it's possible to do so. That level of integration, basically a 'plugin-level' integration is necessary and useful, but doesn't go far enough. A next-generation tracing tool would integrate at a much more fundamental level; if done properly, it would provide unmatched levels of power and usability to users, and would allow Yocto to distinguish itself in the embedded tracing/profiling space in a way also unmatched by any other distro/build-tool. The implementation would of course not be available for Yocto 1.0, but a coherent design, including prototypes, that could be taken to the community and implemented in a V 1.5 or 2.0 should be done in that time frame. || 1|| Review|| || tzanussi|| "Enhancement, duplicate of ""Tracing/Profiling Planning Complete"""<br />
|-<br />
|| Documentation Features|| Self Documentation of image contents|| "I'd like to see the -doc packages Poky builds being combined into some kind of large documentation index representing the collective API docs of the target being built. This can then be placed on a webserver and viewed over the web. We'd have a demonstration of this for a ""bitbake world"" target. Part of the idea here is to start making good use of the docs as if developers see this they might start writing better docs too. Aim is to lead the field :). There are a number of places poky packages disable doc generation due to missing tools so we'd need to add these so we can enable the doc generation. Many packages already have many docs though too. "|| 2|| Review|| || rpurdie|| enhancement<br />
|-<br />
|| Validation|| Testing Framework|| Add a framework for doing automated testing in the project|| 1|| Review|| || davest|| project commitment<br />
|-<br />
|| Validation|| more SDK builds on autobuilder|| enable more SDK related tests on autobuilder such as meta-ide-support, etc.|| 2|| Review|| || ktian1|| project commitment, addressed by test plan (?)<br />
|-<br />
|| Validation|| more people should try using SDK|| this may not be a feature, but a requirement. SDK including meta-toolchain is one key factor impacting user experience on Yocto. It's not enough to have only SDK team play with it|| 2|| Review|| || ktian1|| project commitment, addressed by test plan (?)<br />
|-<br />
|| Validation|| Unit Testing Framework|| Add a mechanism to bitbake to parse source packages that have unit tests and then execute them on the target|| 3|| Review|| || sgw|| "project commitment, duplicate of ""Testing Framework"""<br />
|-<br />
|| Validation|| Test Case open source|| Open source Yocto test cases with xml format|| 1|| Review|| || yyou|| "project commitment, duplicate of ""Testing Framework"""<br />
|}</div>Davesthttps://wiki.yoctoproject.org/wiki/index.php?title=Yocto_1.0_Schedule&diff=577Yocto 1.0 Schedule2011-01-25T01:16:40Z<p>Davest: /* Sprint D (closes Jan 21, 11:59pm PDT -- pull request sent, initially reviewed) */</p>
<hr />
<div>= v1.0 (release date: Apr 15, 2011) =<br />
----<br />
The detailed milestone map for v1.0 is as below. During the first week of each subsequent milestone past M1 we will have a demonstration of the previous milestone capabilities as well as a planning and design session for the current milestone.<br><br><br />
<br />
== M2 (Nov 08 to Dec 24 -- Dev Complete Dec 10, Stabilize Complete Dec 17, Release Complete Dec 24) ==<br />
=== Sprint A (closes Nov 12, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links''' <br />
|-<br />
|| Poky Features || Kernel interactive targets || To support incremental kernel development having the ability to run menuconfig (or xconfig, etc) directly is a common request. We'll need to add this for commercialization anyway. i.e. bitbake -c menuconfig. This fuctionality already exists. || 1 || Done || Richard || bruceashfield || Enhancement <br />
|-<br />
|| Distribution / components || Distro Audit: Upgrades Planned (Phase 1) || Complete plan for package upgrades in M2 || 1 || Done || Saul || || Continual Maintenance<br />
|-<br />
|| Validation || Runtime testing || Runtime testing of images as part of the autobuilder || 1 || Done || Jiajun/ScottG || rpurdie || project commitment<br />
|- <br />
|| || Poky Image Creator Wireframe/Interaction Plans Complete || || 1 || Done || Josh || ||<br />
|-<br />
|| || SDK Generator Interaction: Plans Complete || || 1 || Done || Jessica || ||<br />
|-<br />
|| || Tracing/Profiling Planning Complete || This needs to cover where we're at now, what we're missing and also propose the future enhancements that may be needed. M2 targets getting existing tools integrated and documented. F2f discussion n the future enhancements || || Done || Tom || ||<br />
|-<br />
|| || Swabber. (Still needs to be integrated into weekly build by default) || || 1 || Done || Josh || ||<br />
|-<br />
|| Build/Release || Release process documentation || || || Done || Beth || ||<br />
|-<br />
|| Validation || Test plan for v1.0 (to address any deficiencies in coverage from v0.9)|| || 1 || Done || Jiajun || ||<br />
|}<br />
<br />
=== Sprint B (closes Nov 19, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| Distro Audit: World Packages|| Audit world packages making sure it all build, making sure all are packages are required || 2|| Done || Saul|| sgw|| Hygiene<br />
|-<br />
|| Tool Development and SDK Features|| SDK Generator Installer UI|| Look at different ways of Installer UI (GTK+ and ncurses) seems none of them is the right choice, decide to go with script to implement all the functionalities of installer and later add UI part on top of it || 1||Done|| Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Customize sysroot setup || Add and test out "--sysroot" config option to cross compiler within Eclipse IDE || 1|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| SDK Generator Installer design revision|| Close all open questions regarding Yocto SDK Generator Installer function design and come up HLD || 1|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Distribution / components|| kernel version|| keeping 2.6.34 as a -stable kernel is the best option. I've also got a newer -devel tree that can be made available or made the default. || 3|| Done || Bruce|| bruceashfield|| enhancement<br />
|-<br />
|| || assign Yocto Project PM|| acquire and assign a program manager for Yocto Project|| || Done || DaveST|| || <br />
|-<br />
|| || assign Yocto Project Sys Admin|| || || Done || Saul|| || <br />
|-<br />
|| Tool Development and SDK Features|| oprofileUI|| Fixing various bugs of the oprofileUI to make it workable on big endian host.(i.e. ppc, mips) || 2 || Done || Jessica || lianhao.lu || Bug #382 / Bug #493<br />
|-<br />
|| Poky Feature|| SDK Version Control|| If we can expect that yocto SDK has lots of release in the future, we might need to consider SDK version control. Currently, every thing installed under /opt/poky which leads to things be overriden, we need to be able to use a scheme like /opt/poky-1.0, /opt/poky-2.0 to distiguish things. || 2|| Done || Josh|| jzhang|| Enhancement<br />
|-<br />
|| Kernel || Kernel plan complete || Flesh our kernel deliverables and add to Yocto 1.0 schedule || || Done|| Darren || dvhart ||<br />
|}<br />
<br />
=== Sprint C (closes Nov 26, 11:59pm PDT -- pull request sent, initially reviewed) :: NOTE: this is US Thanksgiving week ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| Distro Audit: Licence Checksums|| licence checksums || 1|| Done || Saul|| rpurdie|| Hygiene<br />
|-<br />
|| Poky Features || Performance Analysis Completed|| "I'd like someone to instrument a green release build, see where it spends time (hot/cold parsing time, individual task building time) and then compare this with our 0.9 release build. I'd also like to compare the disk usage between the two. Once we have a blame list we can then set about fixing it. Some things I know will come up: a) pseudo, b) checksums/signature code, c) exec() vs fork for executing tasks, d) task based prebuilds increasing disk usage, e) rpm dependency calculations, f) using rpm vs. ipk but I may be wrong and there may be others. We need numbers. "|| 1|| Done || Saul / Qing, Dongxiao|| rpurdie|| Enhancement<br />
|-<br />
|| Poky Features || environment variables for kernel builds|| switching a branch, or adding a configuration feature (and even changing the kernel repo) is often done during development of a BSP. Having some additional variables that are pass the bitbake environment scrub would be useful. i.e. KBRANCH=foo bitbake -c configure linux-yocto. This goes along with the other BSP bootstrapping suggestions. || 2|| Done || Bruce|| bruceashfield|| Enhancement<br />
|-<br />
|| Supported Targets|| ARM Platform Support|| Replace beagleboard with Beagleboard XM - decision || 2|| Done || Bruce|| alex|| Basic Yocto hardware support <br />
|-<br />
|| Distribution / components|| Security Process|| We need a dedicated person to scan and apply critical security updates to the distro. The MeeGo team already has a similar process with some scripts which may be leveraged. To complete the task, the process should be documented and a first pass over the metadata made to establish the current position on security. Any upgrades needed should be identified and a plan to address them should be in place but doesn't have to be implemented by this point.|| 1|| Done || ScottG|| ktian1|| enhancement<br />
|-<br />
|| Tool Development and SDK Features|| SDK Generator Installer Opkg repo design|| Come up a opkg repo design that will mimic the final Yocto package repo layout to be used by SDK Generator Installer to test against|| 2 || Done || Jessica || jzhang || <br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer tar creaion|| Create a Yocto Installer tar ball which contains Installer script and supported opkg component that will be used for installing other Yocto components|| 2 || Done || Jessica || jzhang || <br />
|-<br />
|| Documentation|| Kernel Framework Paper from WR|| The paper from WR needs to be re-written and then posted somewhere on the Yocto Project site. This will involve examiniation of the text and re-writing and formatting for presentation. Currently it is simply a text document. Completion time assuming uninterrupted time is one week.|| High|| Done || Scott Rifenbark|| 1 Week|| Documentation<br />
|-<br />
|| Documentation|| Poky Reference Manual|| This guide exists in the 0.9 form. The re-write of the text needs to be completed. So far, all the chapters have been rewritten but not re-posted on the site. Only the appendices remain for a text scrub. Time to complete this would be a week of uninterrupted time. Ideally, the manual would be a sub-manual that would be referenced and architected into the Yocto Project Development Guide.|| Medium|| Done|| Scott Rifenbark|| 1 Week|| Documentation<br />
|-<br />
|| Kernel || Initial meta-linaro layer || meta-linaro layer providing a kernel, tool-chain, and uboot loader. This deliverable is primarily to get the infrastructure in place and have a buildable kernel. Toolchain on best effort basis. || || Done || Darren || dvhart || Moderate risk of slippage due to holidays.<br />
|-<br />
|| Kernel || Tracing: blktrace and sysprof recipes || || || Done || Tom || dvhart ||<br />
|}<br />
<br />
=== Sprint D (closes Dec 3, 11:59pm PDT -- pull request sent, initially reviewed) :: NOTE: week of the F2F planning meeting ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Kernel || Kernel git branching structure revamped || || 1 || Done || Bruce || dvhart ||<br />
|-<br />
|| Kernel || Tunnel Creek (Crown Bay) || || 1 || Done || Tom || dvhart ||<br />
|}<br />
<br />
=== Sprint E (closes Dec 9 (THURSDAY), 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Distribution / components|| Distro Audit: Upgrades Completed (Phase 1)|| Update to new versions as per the agreed plan for M2 from Sprint A|| 1|| Done || Saul|| rpurdie|| Continual Maintenance<br />
|-<br />
|| Distribution / components|| Distro Audit: Src Checksums|| Make sure all SRC_URI components have checksums too || 1|| Done || Saul|| rpurdie|| Hygiene<br />
|-<br />
|| Poky Features || enable KVM with qemu|| today all new Intel processors support VT, which are enabled on most desktop machines which are most frequently used build machine. with VT support, x86/x86-64 qemu target runs faster which is a good thing for emulation environment. This may require some qemu option tweaks and also poky-qemu script enhancement. || 2|| Done || Saul / Edwin|| ktian1|| Enhancement<br />
|-<br />
|| Kernel || New kernel recipes || dev, -devel, -custom || 3 || Done || Bruce || dvhart ||<br />
|-<br />
|| Swabber || Documentation for swabber || || 1 || Done || Alex || ||<br />
|-<br />
|| CCB || Defect triage process in public documented and implemented || || 1 || Done. Triage process is documented, out for review. || Saul || ||<br />
|}<br />
<br />
== M3 (Dec 20 to Feb 08 -- Dev Complete Feb 04, Stabilize Complete Feb 11, Release Complete Feb 18) ==<br />
=== Sprint A (closes Dec 24, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Kernel || Initial meta-rt layer || PREEMPT_RT kernel and related test-cases and benchmarks || 2 || Done by Jan 21 || Darren || dvhart || slipped out from M2<br />
|-<br />
|| Poky Features || Fetcher Overhaul Phase 1 - SRC_REV enhancement||<br />
* a) Add code in FetchData::__init__() which will check if the selected fetcher supports srcrev and the automatically call a function to set the src rev value instead of each fetcher doing this.\n <br />
* e) Break SRCREVINACTION deadlock. To do this, we need to start using a keyword for automatically increasing SRCREV, e.g. SRCREV = "AUTOINC". The actual revision can be injected into PV using SRCPV. If we do this there should no longer be a need of the deadlock; <br />
* k) Ensure that we only set __BB_DONT_CACHE when SRCREV = "AUTOREV". This may need a new method call for fetchers to tell whether they're "floating" or locked down.<br />
|| 1|| Done || Saul / Ke, RP|| rpurdie|| Enhancement, slipped out from M2<br />
|-<br />
|| Distribution / components|| Distro Audit Upgrades Planned (Phase 2)|| Complete plan for package upgrades in M2|| 1|| Done || Saul|| || Continual Maintenance<br />
|-<br />
|| Poky Features || Pseudo Performance || Implement the changes to bitbake based on pseudo's enable/disable switch|| 1|| done || Saul / Qing, Dongxiao || rpurdie|| Enhancement, slipped from M2 due to risk and not having Pseudo's change yet.<br />
|-<br />
|| Tool Development and SDK Features|| Fix the issue user target sysroot is owned by root || The ADT installer will use pseudo to extract user target sysroot which ended up owned by root, this need to be fixed || 1|| done || Jessica|| jzhang|| Cleanup <br />
|-<br />
|| Tool Development and SDK Features|| Eclipse poky tree interfacing (metadata file editor)|| Provide a metadata file editor with some syntax checking and keywords highlight capabilities|| 2|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| IDE Project templates|| Templates for various project types: Clutter GUI, Gtk+ GUI, to help developers get started quickly || 2|| Done || Jessica|| josh|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| push TCF/RSE patches upstream|| work with community to finish up our TCF terminal service, TCF/RSE integration remaining patches taken by upstream. Blocking issues including Eclipse Bug #327865 || 1|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Pseudo || Pseudo enhancement to enable on/off switch || || 1 || done || Mark || ||<br />
|-<br />
|| Pseudo || Bitbake enhancement for pseudo on/off switch || || 1 || done || Richard || ||<br />
|-<br />
|| bugzilla || Complete restructure of bugzilla categories || || 1 || done || Saul || ||<br />
|-<br />
|| Poky Features || Image creator ground work || Nomenclature determined, existing gui's bug fixed and backend work implemented || 1 || Done || Joshua || ||<br />
|-<br />
|| Kernel || Tracing: Initial SystemTap recipe || Works on x86 || 3 || Done || Tom || dvhart ||<br />
|-<br />
|| Distribution / components|| Distro Audit: Package Description/Summary completed|| Ensure DESCRIPTION/SUMMARY fields are all audited|| 2|| Done || Mark|| Mark|| Hygiene, was M2, Sprint B but missed window<br />
|-<br />
|| Distribution / components|| Zypper/RPM|| Small write-up of the problems we're having w/ Zypper and what we plan to do. (i.e. create a roadmap/design) - Includes rootfs generation - Package uprev/install/removal || 1 || Done || Mark/Qing || || was M2, Sprint B<br />
|-<br />
|| Distribution / components|| Distro Audit: Licence Checksums|| Make the licence checksums fatal if not present || 1|| Done || Saul|| rpurdie|| Hygiene, was M2, Sprint C<br />
|-<br />
|| Distribution / components|| push of all relevant Wind River patchs to Yocto (patch comparison)|| Ensure patches present to packages in WRS are also in Poky|| 1|| Done || Mark|| Mark|| was M2, Sprint C<br />
|-<br />
|| Poky Features || Performance Enhancement Completed || Initial changes to reduce disk space (sstate-build-*) || 1|| Done || Saul / Qing, Dongxiao || rpurdie|| Enhancement, was M2, Sprint E<br />
|-<br />
|| Distribution / components|| User specified qemu config support|| We'll provide user an edit box which allows advanced qemu user to specify arbitrary qemu configuration to meet their needs, which the poky-qemu scrip will just append the config list towards the end of the list of parameters to bring up qemu, it also expect the poky-qemu script to do some basic sanity check on the user specifications to catch the obvious mistake || 2|| Done || Saul / criping || criping|| enhancement, was M2, Sprint E<br />
|-<br />
|| Tool Development and SDK Features|| SDK Version Control support in SDK generator installer|| If we can expect that yocto SDK has lots of release in the future, we might need to consider SDK version control. Currently, if we un-tar the sdk, it will override the older version. It's not good for app developers since they might need the old version to do something. And also, maybe a finer installer than untar is preferred. Installer will tied to certain SDK version and the installation will go under /opt/poky-versionNo.|| 1|| Done || Jessica|| criping|| Enhancement-expect planning process by Jessica to handle this task. Was M2, Sprint E.<br />
|}<br />
<br />
=== Sprint B (closes Jan 07, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || Bitbake multi-threaded parsing|| Bitbake recipe parsing is currently single threaded. I want to make this multithreaded as the speedup would be nice. If I can only take a single task for myself for 1.0, I'm nominating this one as I enjoy this kind of thing and I have ideas on how to do it. || 1|| Done || Richard|| rpurdie|| Enhancement<br />
|-<br />
|| Distribution / components|| Lock in Kernel/Toolchain version|| Locked in 2.6.37 and gcc 4.5.1. Pending decision to move to 4.5.2 and Linaro || || Done || || Richard|| || <br />
|-<br />
|| Distribution / components|| License Update|| For each of the licences we support, I'd really like to have a licences directory with a copy of that license contained within. When it comes to deciding what a given LICENSE field means, this would be the reference. It also means we can include the licences a given image includes with the image. This continues to make our license handling world class and ahead of the field. || 2|| Done || Beth|| rpurdie|| Hygiene<br />
|-<br />
|| Distribution / components|| rootless X|| rootless x server has better security than x server launched by root. MeeGo already enable this feature. it would be nice for Yocto to also enable it. || 2|| On track for Jan 28 || Saul / Ke || yuke|| enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Qemu configuration change|| Provice edit box for advanced user to specify qemu configurations|| 2|| Done || Jessica|| criping|| <br />
|-<br />
|| Tool Development and SDK Features|| Lock down Eclipse+CDT+TCF version|| Will use Eclipse Halo 3.6 || 1|| Done || Jessica|| || <br />
|-<br />
|| Demo|| Finalize on demo plans for v1.0 launch || || 1|| Slip to Sprint C || Dave || || <br />
|-<br />
|| Release || Release plans for v1.0 launch || Fill out the M4 plan with the necessary release activities and timings || 1|| Done || Beth || || <br />
|-<br />
|| Poky Features || Basic image creator GUI || Functional UI missing some Advanced features || 1 || In replan || Joshua || || <br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer for SDK Generator Installation functions support||Detailed feature request can be found at: http://bugzilla.pokylinux.org/show_bug.cgi?id=589|| 1|| Done || Jessica|| rpurdie|| Enhancement<br />
|-<br />
|| Kernel || Tracing: trace-cmd python binding cleanup || || 3 || Done || Darren || dvhart ||<br />
|}<br />
<br />
=== Sprint C (closes Jan 14, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || kernel development layer|| The (correct) poky behaviour of building known revisions coupled with the fetcher requiring a BSP branch to already be present means that local modifications (and kernel source tree) are required for kernel development. I already have a layer that overrides/modifies the behaviour when added to the bblayers.conf and configured into an environment. This seems useful for more people to use. || 2|| Done || Bruce|| bruceashfield|| Enhancement, was M2, Sprint C<br />
|-<br />
|| Distribution / components|| Zypper/RPM|| RPM Uprev / Zypper Uprev [lets get to the latest versions]|| 1|| pull request by Jan 19; || Mark/Qing|| || was M2, Sprint C<br />
|-<br />
|| Supported Targets|| Intel Platform Support|| JasperForest|| 2|| Basic support in place; DPDK evaluation in process, overall BSP plan still TBD || Tom|| davest|| Basic ECG support (Moved from Sprint A)<br />
|-<br />
|| Tool Development and SDK Features|| Eclipse poky tree interfacing (git support)|| Use Eclipse git capability to install poky tree from git repo and able to interact with git repo at file level within Poky tree || 2|| Done || Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Poky Features || Fetcher Overhaul Phase 2 - API reorg||<br />
* f) Add a generic unpack funciton to __init__.py based on the unpack task in Poky ;<br />
* g) Split go() methods into the following steps: i) download() - do whatever transfer is necessary to get the sources locally ii) build_mirror_data() - generate any data that would be needed to construct a source mirror iii) unpack() - takes a directory as an argument of where to place extracted sources;<br />
The existing go() methods should be replaced with a set of calls to the above sections of functionality as appropriate in the individual fetchers. Some of these categories of function make no sense in certain fetchers, in which case they shouldn't need to implement them. Functions are only executed if the method is present.<br />
* h) Change Poky's unpack to call an unpack method in the fetchers.<br />
* i) Change Poky's fetch task to call a "download" method in the fetcher instead of go().<br />
|| 1|| Will land with phase 3 in Jan 21 || Saul / Ke, RP|| rpurdie|| Enhancement<br />
|-<br />
|| Poky Features || DSO linking changes|| "By the default the gcc linker will automatically link any dependant objects/libraries. ""Inherited"" linkages can cause issues, for example, where a shared object changes its dependencies but a program has come to rely on symbols from an implicitly linked library. Fedora implemented this change in F13, seems like it would be useful to have in Poky too. "|| 2|| On track for Jan 21 || Saul / Nitin || josh|| bug#516<br />
|-<br />
|| Distribution / components|| Distro Audit Documentation Output|| Audit package documentation output || 2|| Move to Sprint D due to libtool work || Saul / ScottG || rpurdie|| Hygiene<br />
|-<br />
|| Poky Features || libtool sysroot option|| libtool 2.4 has a sysroot option. We should try and use it, see how it works and whether we can ditch some of our libtool hacks. || 1|| On track for Jan 21 || Saul / ScottG || rpurdie|| Enhancement<br />
|-<br />
|| Distribution / components|| MACHINE or Recipe specific sysroots|| Each machine should have its own sysroot. We'll probably have to split do_populate_sysroot into a two step process, creation of the package and than installtion of the package, which the installation of the package being made machine specific (put ${MACHINE} into ${STAMP} and bitbake should do that). Also allowing this to work per recipe would be desireable|| 1|| On track 21 || Saul / Dongxiao || rpurdie|| Hygiene<br />
|-<br />
|| Distribution / components|| Toolchain Bootstrap Process|| The toolchain as it bootstraps overwrites files like libc.so and libgcc.so in the sysroot directory which causes issues if you just try and rebuild part of the toolchain. Each step of the bootstrap process should use a separate sysroot. Once this is once, sstate file overwriting detection can be added and enabled. || 1|| Patches submitted for comment, slip to Sprint D || Saul / Dexuan || rpurdie|| Hygiene<br />
|-<br />
|| Poky Features || Poky Image Creator|| A standalone application you can run which asks you to select a distro and machine, then presents a list of packages you can select. Once the selection is made, it goes off and bakes you an image which is then presented to you. Implementation wise, it should use the sstate packages, be a bitbake UI and use the usual poky bbclass files to do the image construction behind the scenes. || 1|| Re-plan || Joshua|| rpurdie|| Enhancement<br />
|-<br />
|| Poky Features || Fetcher Overhaul Phase 3 - git enhancement||<br />
* j) Optimize git fetcher for the new layout so for a git checkout, we clone the repository in download(), then unpack just does a clone with references to the original repo. <br />
* k) Ensure that we only set __BB_DONT_CACHE when SRCREV = "AUTOREV". This may need a new method call for fetchers to tell whether they're "floating" or locked down. <br />
* l) Add a new "BB_NO_NETWORK" variable which the fetchers check before peforming an operation which hits anything remote. This means adding in error messages about why network access is needed at various points (e.g. SRCREV = "AUTOREV" for a given recipe) <br />
* m) Add multiple branch/srcrev support for git fetcher. These would be of the form: git://somelocation/somerepo.git;name=ref1;branch=foo;name=ref2;branch=bar SRCREV_ref1 = "hash1" SRCREV_ref2 = "hash2" which would ensure both hash1 and hash2 were in the final repo. <br />
* n) Change git fetcher to default to git protocol instead of rsync<br />
|| 1|| Slipped to Sprint D || Saul / Ke, RP|| rpurdie|| Enhancement<br />
<br />
|-<br />
|| Validation|| Boottime/Performance Analysis|| Compare Yocto Project performance to other projects such as MeeGo|| 1|| Initial report on where we are by Feb 9 || Darren|| davest|| project commitment <br />
|-<br />
|| Distribution / components|| LSB Sanity|| execute LSB Test and improve passing rate and document failures with clear understanding|| 2|| Done || MarkH/Saul|| sgw|| Hygiene<br />
|-<br />
|| Distribution / components|| Review & Fix Standards Tests|| Review the results from LTP, POSIX and asses the result, fix as appropriate and clearly document failures.|| 2|| a Plan to resolve final items to be sent to the m.l. by Jan 14 || Saul/Kevin || sgw|| Hygiene<br />
|-<br />
|| Tool Development and SDK Features|| Image creator integration with Eclipse || || 2|| replan|| Jessica|| jzhang|| Enhancement<br />
|-<br />
|| Kernel || Tracing: perf trace marker support || This is from feedback to the new trace command. Ingo appears to have this nearly complete already. || 3 || Done || Darren || dvhart ||<br />
|-<br />
|| Kernel || Tracing: perf trace scripting support || || 3 || Move to Sprint D; on track for Jan 21 || Tom || dvhart ||<br />
|-<br />
|| Cleanup || bitbake user experience error handling validation completed || || 2 || Done || Richard || ||<br />
|-<br />
|| Cleanup || variable scrub - ensure all metadata variables are documented || Script with a histogram of variable use done, identified 50 variables to document; Add task for actual documentation update is low on the list || 2 || Done || Scott/Darren || ||<br />
|-<br />
|| Distribution / components|| Zypper/RPM|| Integration based on design from Sprint B|| 1|| On track for Jan28 || Mark/Qing|| sgw|| Functionality, was M2, Sprint E<br />
|-<br />
|| Kernel || Tracing: package kernelshark || || 3 || Done || Darren || dvhart ||<br />
|-<br />
|| Kernel || Tracing: tuna, oscillosope recipes || || 3 || Tom to discuss plan with Darren et al || Tom || dvhart ||<br />
|- <br />
|| BSP || Beagleboard XM Support || || 3 || Move to Sprint D || Darren || dvhart ||<br />
|}<br />
<br />
=== Sprint D (closes Jan 21, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Swabber || Complete review of swabber outputs || Move to M3 Sprint D || 1 || Move to M3 Sprint D || Alex || ||<br />
|-<br />
|| Documentation Features|| Package report system|| move to public server [setup a package report system in an internal machine. We need push it publicly available. The basic features like search and report have been there. But there're still some enhancements in plan, to make it a fit place to feel Yocto metadata comfortably]|| 2|| Move to Sprint E|| KevinT|| ktian1|| enhancement<br />
|-<br />
|| Distribution / components||Add headers and libraries to qemu images ||Since we'll be using qemu images as target sysroot, need to create a set of qemu images for minimal, sato, LSB that contains target header and libraries.|| 2|| Pending a discussion on Jan 18 || Saul ||jzhang|| Enhancement<br />
|-<br />
|| Distribution / components|| push of all relevant Wind River patchs to Yocto (patch comparison)|| Update any additional patches needed since M2.|| 1|| May be done by Jan 21, pending RPM stuff || Mark|| Mark|| <br />
|-<br />
|| Distribution / components|| mklibs|| mklibs is a tool to optimize size of [e]glibc for a perticular root file system image. It is useful to save disk space on small devices. || 2|| Push to Sprint E || Saul|| Nitin Kamble|| enhancement<br />
|-<br />
|| Poky Features || Performance Enhancement || reduce disk space (hardlink) || 1 || On track for Jan 21, pending RP review || Saul / Qing, Dongxiao || rpurdie || Enhancement<br />
|-<br />
|| BSP || 2.6.37 Crown Bay Support || On Track for Jan 21 || 2 || || Tom || dvhart || <br />
|-<br />
|| BSP || 2.6.37 Emenlow Support || On track for Jan 21 || 2 || || Tom || dvhart || <br />
|}<br />
<br />
=== Sprint E (closes Jan 28, 11:59pm PDT -- pull request sent, initially reviewed) ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Documentation Features|| Package report system|| finish major feature development and internal review [setup a package report system in an internal machine. We need push it publicly available. The basic features like search and report have been there. But there're still some enhancements in plan, to make it a fit place to feel Yocto metadata comfortably]|| 2|| Move to Sprint E || Jonathan || ktian1|| enhancement, was M2, Sprint E<br />
|-<br />
|| Distribution / components|| perl upgrade|| perl is the most cross un-friendly recipe pending upgrade. || 2|| Slipping due to Linaro layer, moves to end of Sprint E || Nitin|| Nitin Kamble|| enhancement<br />
|-<br />
|| Supported Targets|| Intel Platform Support|| Sandybridge|| 2|| Accept|| Tom|| davest|| Basic ECG support<br />
|-<br />
|| Distribution / components|| performance indicators|| define some indicators (boot time, footprint, build time, power, component benchmarks, etc.) and then collect them for tracking purpose. The result could be posted on the wiki site, and the initial indicators can be easy ones which can be easily retrieved from autobuilder or weekly qa report). This way we have a clear track about the healthy of the Yocto project, and also identify weak areas. We can include qemu targets and several representational boards as the targets. || 2|| Review|| Beth/Jiajun|| ktian1|| enhancement<br />
|-<br />
|| Tool Development and SDK Features|| SDK user workshop|| Have some developers sit down and use our tools to develop demo software for Yocto. || 2|| Review|| Jessica|| josh|| Enhancement<br />
|-<br />
|| Kernel || Final linux-yocto_git.bb || With 2.6.37 kernel || 1 || || Bruce || dvhart ||<br />
|-<br />
|| Kernel || Final meta-linaro layer || || || || Darren || dvhart ||<br />
|-<br />
|| Kernel || Final meta-rt layer || || || || Darren || dvhart ||<br />
|-<br />
|| Kernel || Sandy Bridge || || 1 || || Tom || dvhart ||<br />
|}<br />
<br />
=== Sprint F (closes Feb 03 (THURSDAY), 11:59pm PDT -- pull request sent, initially reviewed) :: NOTE: China New Year Holiday ===<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Documentation|| ADT Reference Guide Draft out for review || Outline complete|| High|| WIP || Scott Rifenbark|| jzhang|| Documentation<br />
|-<br />
|| || || || || || || || <br />
|}<br />
<br />
== M4 (Feb 07 to Apr 15 -- Stabilize Complete Mar 18, Release Complete Apr 01, Contingency to Apr 15) ==<br />
<br />
This sprint is the [[Yocto Project v. 1.0 Release Cycle]].<br />
<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Documentation|| Migration chapter in the Poky Reference Manual|| This chapter would cover the four identified use-cases for migrating up to the most recent version of Yocto Project. Additionally, it would cover migration scenarios from other development systems. The chapter does not yet exist. The chapter has not been scoped outside of having a meeting that identified four use-cases that did not include migration from a development system outside of Yocto Project. It will take some more scoping time to cover those areas (a day or two). Again, I have no idea of the length. See earlier entries for standard industry writing estimates for software documentation|| Medium|| Not Started|| Scott Rifenbark|| 3-4 Weeks|| Documentation<br />
|-<br />
|| Documentation|| Yocto Project Development Guide|| This manual would be an over-arching document that frames the complete development cycle within Yocto Project. The idea here is that the document would be an umbrella document that spawned and referenced subsequent documents. The organization would be the first chapter overviewing the major development pieces such as recipe creation, building, debugging, publishing, fail-safing, back-door hook creation, etc. Scoping would be about two weeks and length would probably be about 40 pages. Overall development time would likely be a month of uniterruped time.|| Medium|| Not Started|| Scott Rifenbark|| 3 Weeks|| Documentation<br />
|-<br />
|| || Multilib Support|| Consider developing post-1.0 branch || 1|| to start in M4 || Richard|| ||<br />
|-<br />
|| Validation|| Alpha testing complete|| 4-5 internal developers unfamiliar with Yocto Project try to do a build and report on the experience and issues encountered|| 1|| Done by Feb 18 || Julie|| davest|| <br />
|-<br />
|| || || || || || || || <br />
|}<br />
<br />
== Features needed and to be put into sprints by assigned owners: ==<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || package config option enhancement|| there're several enhancements we may do here: * allow users setting specific config options (local or global) from external tool, such as poky image creator, instead of changing recipes manually. Need a mechanism to convert from variable assignments into exact config options (e.g. feature_${PN} = ""1"" -> ""--enable-feature""). Consequently dependency chain needs update with option status. * host contamination check. We have swabber to check host contamination, but I'm not sure whether it covers configuration phase. If not, this is one area to improve, as not ususually we see configure script checks host bits for available features * conditional option manipulation. In many recipes we enable/disable one option based on availability of other packages. Now this is done manually and not flexible. this should be made automatically though some new annotation to indicate condition, or just base_contains (not convenient: long line, need define distro features) || 2|| Review|| Richard/MarkH|| ktian1|| Enhancement<br />
|-<br />
|| Media|| Yocto Project Awareness Video|| This 2.5 minute video would introduce and describe the benefits of Yocto Project. The video would use entertaining animations that described concepts and benefits. The result would be suitable for YouTube, conferences, and the website. The production is called an "Epipheo" and will be created by Epipheo Studios. The engagement process has begun and the kick-off meeting will be soon. The PO is in place. Time for development is 10 weeks.|| High|| Kick-off Imminent|| Scott Rifenbark|| 10 Weeks|| Media<br />
|-<br />
|| Documentation|| Yocto Project Debugging Guide|| This would be a guide for the debugging and bug tracking process in Yocto Project. Originally, the thought was that we needed a Bugzilla User's Manual. However, since we don't own Bugzilla it doesn't make sense to produce documentation for it. Rather, we should document the process as it fits into the Yocto Project environment. Ideally, the manual would be a sub-manual that would be referenced and architected into the Yocto Project Development Guide. The manual has not been scoped and would take a week to scope. Again, I have no idea of the length. See the previous item for standard industry writing estimates for software documenation.|| Medium|| Not Started|| Scott Rifenbark|| 3-4 Weeks|| Documentation<br />
|-<br />
|| Website|| Yocto Project Website|| The 0.9 website is in place but needs updates. Items for consideration are the left-panel naviagation scheme, a contributions guidance page, color-scheming and theme (possibly).|| Medium|| Not Started|| Scott Rifenbark|| 1-2 Weeks|| Website<br />
|}<br />
<br />
== Features not believed to be needed in v1.0: ==<br />
<br />
{|border="1"<br />
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''<br />
|-<br />
|| Poky Features || OpenEmbedded/Bitbake Upstreaming|| "We firstly need to review where we are and where OE is. We then need to make a plan about what we're going to push upstream and what we're not. I'd suggest when we're in PRC, we do a crash course in ""dealing with OE"" and then many dedicate a block of time (a week) where the distro team comes up with a patch set we then propose and get merged into OE. I'd like to find a couple of interested people to monitor OE more regularly and start a workflow of things between Poky/OE where appropriate. The key thing to remember is we need to keep the architectures compatible. The team is now at the point where I'm happy for them to actually try building OpenEmbedded and not worry about it tainting them! "|| 2|| Review|| || rpurdie|| Process<br />
|-<br />
|| Poky Features || Handle old versions in WORKDIR|| an incremental build directory may finally include many old versions WORKDIRS. It'll be good to have those old versions tracked in the cache, which can then either generate a report or allow selectively cleaning up an specific version WORKDIR. Or else it's difficult to figure it out when people want to keep the whole tmp directory but like to cleanup some old bits when disk usage is under pressure. If it's not easy to do in bitbake, perhaps some separate scripts would be also helpful || 3|| Review|| || ktian1|| Enhancement<br />
|-<br />
|| Poky Features || run bitbake w/o rebuilding the cache|| "sometimes it's useful to allow run bitbake w/o re-parsing recipes, if we know nothing metadata is changed. we can just allow reusing existing persistent cache. this is useful when people is debugging WORKDIR w/o metadata change. also sometimes ""bitbake -e"" is used frequently to check poky variable information. with existing cache, several seconds can be saved which are not negligible for a developer daily working on Yocto "|| 2|| Review|| || ktian1|| Enhancement<br />
|-<br />
|| Poky Features || parallel make improvement|| parallel make experience is not good, especially when bb threads and make threads are increased larger than 8. So far we either try to fix package makefile or mark the recipe as no parallel make, when build faiures are reported. But this greatly impacts user experience for a successfully continuous build process. Could we define a safe number we do want to support for 1.0 release? and then have our autobuilder, QA test, and developers cover that number immediately and fix any issues accordingly. Then the safe number can be suggested to the Yocto user || 2|| Review|| || ktian1|| Enhancement<br />
|-<br />
|| Poky Features || Dependency packages rebuild/clean|| It is a mechanism to rebulid or clean a package and all other packages which have build/runtime dependency on it. With this change, we can find potential influences of package upgrade to its related packages, which can make the incremental build more trustable. For example, if we upgrade a package to a new vesion which changes its API, this mechanism can easily find out the incompatibility to other packages which have dependency on it. || 2|| Review|| || dongxiao.xu|| Enhancement, replaced by checksum feature<br />
|-<br />
|| Distribution / components|| FOSSology|| This may be similar to License Update above, but start to use FOSSology to track licenses. || 2|| Review|| || sgw|| Hygiene<br />
|-<br />
|| Distribution / components|| Package Developer Tools|| Create a set of Init scripts template and then review our current init scripts and modify them to confirm to the template. || 2|| Review|| || sgw|| Easy of Use<br />
|-<br />
|| Distribution / components|| Package Website|| Complete the work the intern has started on generating the distro tracking information and get it out on the external site. || 2|| Review|| || sgw|| "Hygiene, duplicate of ""Package report system"""<br />
|-<br />
|| Distribution / components|| Bluetooth UI support|| Currently we have bluez package in poky, and we need to have a workable graphic user interface to connect/configure BT devices. One choice may be gnome-bluetooth-applet. || 3|| Review|| || dongxiao.xu|| enhancement<br />
|-<br />
|| Distribution / components|| Connman-gnome enhancement features|| Enable connman-gnome to support features like, WPA Enterprise connection, hidden SSID, etc. || 3|| Review|| || dongxiao.xu|| enhancement<br />
|-<br />
|| Distribution / components|| Java Running Environment support|| Since most embedded systems support java applications running in it, maybe we'd better consider supporting some kinds of JVMs(Embeded JVM). The JVM may not run by default, but user can launch it if running java applications. Compared with GTK/QT, java user number is not small too. || 3|| Review|| || criping|| enhancement<br />
|-<br />
|| Distribution / components|| create more use cases|| UPnP demo is one really good use case showing how Yocto is utilized to make real functionality. and we could create more to show how Yocto is easily adapted to real use cases. Those use cases can be either maintained as seperate demo layers in yocto repo, or in seperate branches for reference. We can also call for community's contribution on this which would make 1.0 full-fledged. Or else the newbies to Yocto may be in puzzle how our sample profiles can satisfy their requirements. || 2|| Review|| || ktian1|| enhancement<br />
|-<br />
|| Distribution / components|| i18n support || internationalization is an important system wide feature. Many component like font, locale affect the i18n. Yocto alreay has some i18n related package like pango, but so far did not consider i18n systematically. so this is place holder to systematically add i18n support. || 2|| Review|| || yuke/qing|| enhancement<br />
|-<br />
|| Distribution / components|| more demos || demos are a good way to educate, push the envelope, and at the same time tout the strengths of the platform. This item just records a current set of ideas from various sources which could/should be implemented: * face-recognition/face-finding, * robotic control/application of face-finding to 'camera-as-sensor' (hexbug demo), * others [tbd, add here]|| 2|| Review|| || tzanussi|| enhancement <br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer support for image-creator and needed yocto-metadata design||Come up design what need to be created as packages to support using "opkg install" for image-creator and needed yocto-metadata|| 2|| WIP, pending comments from RP regarding how to packaging metadata|| Jessica|| rpurdie|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Yocto Installer image-creator and needed poky-metadata support|| The poky build system will build packages for image-creator and needed poky-metadata, which the Yocto Installer will be able to use "opkg install" to install them|| 2|| Review|| Jessica|| rpurdie|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Provide qemu management UI|| In current eclipse plugin, QEMU settings are put together with project configuration. So we can only have limited settings. If we can have a separate QEMU management UI, the end user could firstly create a QEMU config, such as (env file of arch, image location, unfs or not, sato or lsb, mem size, disk size). And then he can launch a QEMU with a specific config. The dependency between project configuration and QEMU config will be resolved. After all QEMU has nothing to do project configuration. Need to careful review the UI to ensure minimal impact to testing matrix. || 3|| Review|| || criping|| "Enhancement, duplicate of ""Qemu mem/disk size can be adjusted"""<br />
|-<br />
|| Tool Development and SDK Features|| QT plugin For Eclipse|| Integrate QT Ecplise plugin and extend for Yocto Project || 3|| Review|| || jzhang|| Enhancement<br />
|-<br />
|| Tool Development and SDK Features|| Profiling/Trace GUI's|| We have a wealth of great tracing and profiling tools but the UI's for them are all extremely minimal and usually quite ugly. Would be great if we could compete with, or even better, Apple's offerings here. We have the technology! || 2|| Review|| || josh|| "Enhancement, duplicate of ""Tracing/Profiling Planning Complete"""<br />
|-<br />
|| Tool Development and SDK Features|| Other profiling tools|| Complete Tom's review of profiling tools and architecture || 2|| Review|| || josh|| "Enhancement, duplicate of ""Tracing/Profiling Planning Complete"""<br />
|-<br />
|| Tool Development and SDK Features|| Design next-gen tracing/profiling tools|| Yocto 1.0 will include all the essential existing tracing/profiling tools expected by users, and Josh has proposed a UI integration of all those tools as far as it's possible to do so. That level of integration, basically a 'plugin-level' integration is necessary and useful, but doesn't go far enough. A next-generation tracing tool would integrate at a much more fundamental level; if done properly, it would provide unmatched levels of power and usability to users, and would allow Yocto to distinguish itself in the embedded tracing/profiling space in a way also unmatched by any other distro/build-tool. The implementation would of course not be available for Yocto 1.0, but a coherent design, including prototypes, that could be taken to the community and implemented in a V 1.5 or 2.0 should be done in that time frame. || 1|| Review|| || tzanussi|| "Enhancement, duplicate of ""Tracing/Profiling Planning Complete"""<br />
|-<br />
|| Documentation Features|| Self Documentation of image contents|| "I'd like to see the -doc packages Poky builds being combined into some kind of large documentation index representing the collective API docs of the target being built. This can then be placed on a webserver and viewed over the web. We'd have a demonstration of this for a ""bitbake world"" target. Part of the idea here is to start making good use of the docs as if developers see this they might start writing better docs too. Aim is to lead the field :). There are a number of places poky packages disable doc generation due to missing tools so we'd need to add these so we can enable the doc generation. Many packages already have many docs though too. "|| 2|| Review|| || rpurdie|| enhancement<br />
|-<br />
|| Validation|| Testing Framework|| Add a framework for doing automated testing in the project|| 1|| Review|| || davest|| project commitment<br />
|-<br />
|| Validation|| more SDK builds on autobuilder|| enable more SDK related tests on autobuilder such as meta-ide-support, etc.|| 2|| Review|| || ktian1|| project commitment, addressed by test plan (?)<br />
|-<br />
|| Validation|| more people should try using SDK|| this may not be a feature, but a requirement. SDK including meta-toolchain is one key factor impacting user experience on Yocto. It's not enough to have only SDK team play with it|| 2|| Review|| || ktian1|| project commitment, addressed by test plan (?)<br />
|-<br />
|| Validation|| Unit Testing Framework|| Add a mechanism to bitbake to parse source packages that have unit tests and then execute them on the target|| 3|| Review|| || sgw|| "project commitment, duplicate of ""Testing Framework"""<br />
|-<br />
|| Validation|| Test Case open source|| Open source Yocto test cases with xml format|| 1|| Review|| || yyou|| "project commitment, duplicate of ""Testing Framework"""<br />
|}</div>Davest