== Potential Yocto Project 2011.10 Features ==
Yocto Project 2011.10 (a.k.a. Yocto Project 1.1) - Target release = October 2011

== Yocto Project 2011.10 Themes ==
The topics below are the themes that some members of the team have started brainstorming for Yocto Project 2011.10. These will grow and change with community input.

=== Yocto Project 2011.10 Objectives ===
The objectives of the Yocto 2011.10 release are to grow participation in Yocto and increase the number of BSPs written for Yocto and partner products based on Yocto.

=== Yocto Project 2011.10 Theme List ===
The Yocto Project 2011.10 Themes towards the Objectives listed above are:

* Multilibs & OE-core config - This work, which began in Yocto Project 1.0, needs to be completed.
* Improve ease of BSP creation - Document the lifecycle and process. Possibly create walkthroughs or tutorials to integrate a new board into the linux-yocto kernel.
* Build performance – Get to the goal of 1 hour build time on a developer machine.
* Upstreaming – Submit patches to upstream projects in order to reduce the 2,000+ patches which are currently part of Yocto Project.

== Process for Entering New Feature Requests ==

* Create a new entry in the appropriate feature table below (Poky, SDK, Hardware)
** Suggestion: start by copying an existing request as a template
* Give the feature a short, descriptive name
* Provide a one or two sentence brief description of the feature
* Set the priority as appropriate (see the legend below)
* Set the Status to "Review"
* In the Source field, enter your name along with the origination of the request (e.g. OSV, OEM, Community) if applicable; provide as much detail here as you can
* In the Comments / Bugzilla field, provide any additional information for the request, such as a link to a bugzilla entry
* Preview your Entry to make sure it looks ok and then save it

''Legend''

'''Priority:''' 1 = Must Have, 2 = Nice to Have, 3 = Optional

'''Status:''' Accept = Engineering agreement to include in release, Review = Under Review for Inclusion in this release, Reject = Will not be included in this release
== Sample Table ==

This is a sample table to show how to submit features.

{| border="1"
||'''Feature Name''' ||'''Description''' ||'''Priority''' ||'''Status''' ||'''Source''' ||'''Comments / Bugzilla Links'''
|-
||Placeholder feature name || Placeholder description of the feature || 1, 2, or 3 || Review|| name|| Comment
|}

== Architecture ==
{| border="1"
||'''Feature Name''' ||'''Description''' ||'''Priority''' ||'''Status''' ||'''Source''' ||'''Comments / Bugzilla Links'''
|-
|| Layer Tooling || This includes the architectural work plus implementing the changes. || 1 || Review || Architect || M2; Owner = Richard
|-
|| OE-Core || Restructuring, renaming, rebranding || 1 || Review || RP Notes || M1; Owner = Richard
|}

== Poky/Bitbake ==
This section contains features for the Poky/Bitbake infastructure.
{| border="1"
||'''Feature Name''' ||'''Description''' ||'''Priority''' ||'''Status''' ||'''Source''' ||'''Comments / Bugzilla Links'''
|-
|| Error handling in bitbake || desc || 1 || Review || RP Notes || M2; Owner = Saul
|-
|| crazygit fetcher || TI issues with fetch2 || 2 || Review || RP Notes || Owner = Saul (Ke) Timescale: 2-3 days
|-
|| multi-lib || multi-lib support for 32-bit & 64-bit and capable of being installed at the same time || 1 || Review || from 1.0 || M1; Owner = Richard
|-
|| Image Creator || finish the Image Creator to add features pushed out from 1.0 || 1 || Review || from 1.0 || M2; Owner = Josh + someone else (Dave investigating someone on Jessica's team)
|-
|| Recipe-specific sysroot || || 3 || Review || from 1.0 || Not scheduled at this time
|-
|| Handle old versions in WORKDIR || || 3 || Review || from 1.0 || Not scheduled at this time
|-
|| Package config option enhancement || need to plan and then implement || 2 || Review || from 1.0 || Owner: RP for plan, Saul implementation
|-
|| Clean up warning messages || A build that runs correctly to completion still includes a ton of WARNING messages. We need a project to clean these up. || 2 || Review || davest and RP || Owner: Saul
|-
|| Monitor disk availability || Monitor disk availability and warn the user if it is running low. May only focus on a few directories, for example: poky/build and poky/build/downloads, this would solve the multiple mount point problem || 2 || Review || RP and Robert || Owner: WR Distro Team
|}

== QA Items ==
{| border="1"
||'''Feature Name''' ||'''Description''' ||'''Priority''' ||'''Status''' ||'''Source''' ||'''Comments / Bugzilla Links'''
|-
||SDK support in sanity test framework || This task includes enabling unfs and toolchain testing in sanity test framework, enabling toolchain testing on PRC autobuilder|| 1 || Accept || QA || M1; Owner = Jiajun/Meilei
|-
|| Open Source Test Cases || Perform technical, legal, and QA steps necessary to move test cases into open source. || 3 || Review|| QA || M2;Owner = Jiajun
|-
|| Test framework || this is a test framework that we can include in the distribution || 3 || Review || RP Notes || M2;Is it the TI’s test framework we discussed before? Owner = Jiajun
|-
|| Be prepared for Distro upgrades || Our release is right around the time of the 6monthly distro release dates, we should accommodate for this in our testing plan || 2 || Review || Joshua || M3;Should we include more OSDs, besides fedora, ubuntu and opensuse? Owner = Jiajun
|}

== Meta-data ==
{| border="1"
||'''Feature Name''' ||'''Description''' ||'''Priority''' ||'''Status''' ||'''Source''' ||'''Comments / Bugzilla Links'''
|-
|| Upstream our patches || We'll add this as a task in a milestone to give people time to do
|| 1 || Review|| Meta-data|| M2; Owner = Saul
|-
|| 3G || We have an ofono recipe but need some integration work doing || 2 || Review|| Meta-data|| Owner: Saul
|-
|| btrfs || || 2 || Review|| Meta-data|| Owner: Saul (Nitin)
|-
|| Other components? || Saul will investigate other components. || 2 || Review|| Meta-data|| Owner: Saul
|-
|| Replacement for video/audio players currently in Yocto || Codec…
|| 3 || Review|| Meta-data|| Not scheduled at this time
|-
|| Investigate New UI || For demos, we would like need a reference UI that is not Sato. Investigate possibilities that the Yocto team won't need to maintain. OpenBox? Gnome-desktop? GP? LXDE? KDE Mobile?
|| 3 || Review|| Meta-data|| Not scheduled at this time
|-
|| Qemugl upstreaming || Opengl ES Support || 3 || Review|| Meta-data|| Not scheduled at this time
|-
|| Sync qemugl with MeeGo ||
|| 2 || Review|| Meta-data|| Owner: Saul (Edwin)
|-
|| Package reporting system enhancement||
|| 2 || Review|| Meta-data|| Owner: Saul
|-
|| pam patch integration || add PAM patches throughout the system switchable via the PAM feature (Mark H)
|| 2 || Review|| Meta-data|| Owner: WR Distro Team?
|-
|| selinux patch integration || add SE Linux patches in a similar way to PAM
|| 3 || Review|| Meta-data|| Not scheduled at this time
|-
|| Finish LSB "distribution" work || Merge patches which are pushed during ycoto 1.0. Add packages(qt3,xdg-* ...) LSB Test Suite need. Hardware platform x86, x86-64 and ppc32(if qt4 can be supported) can be finished.
|| 2 || Review|| Meta-data|| M2; Owner = Xiaofeng Yan,Jingdong Lu,Kai kang,Xudong Hao
|-
|| OE Comparison || Compare Yocto core set against integration work in OE and other distributions looking for bug fixes, (relevant) feature enhancements, and integration/policy hints.
|| 1 || Review|| Meta-data|| M1; Owner = Mark
|-
|| Framework to support multiple library versions co-existing || similar to recipe specific sysroot; needs documentation
|| 2 || Review|| Team || Owner: Saul
|-
|| Embedded java environment or even JDK support ||
|| 3 || Review|| Team || Not scheduled at this time
|-
|| Automatically generate package repos || automatically generate package repositories (and be able to "use them" -- to be defined) for both ipk and rpm/zypper combinations; NEEDS MORE DISCUSSION
|| 2|| Review|| Team || Owner: Saul
|-
|| MeeGo GPLv2 Sync || compare with Yocto, sync any patches || 2 || Review || RP Notes || Owner: Saul
|-
|| Incompatible License || || 2 || Review || Paul || Owner: Saul
|-
|| End of package revision || replace with a network service || 2 || Review || RP Notes || Owner = Jessica
|-
|| Target module build || Allow for building kernel modules on the target device || 2 || Review || RP Notes || Owner = Darren
|-
|| Live images || make live images their own image type || 2 || Review || RP Notes || Owner = Saul
|-
|| multiple update-alternatives || fixed? || 3 || Review || RP Notes || Owner: Saul
|-
|| init scripts || provide an image/recipe skeleton as a canonical example || 3 || Review || RP Notes || M2; Owner: WR Distro Team
|-
|| running post installs at rootfs gen time || || 2 || Review || RP Notes || Owner: Saul
|-
|| remove gnome-vfs || || 3 || Review || RP Notes || Owner: Saul
|-
|| gtk+ sato filechooser patch || || 3 || Review || RP Notes || Not scheduled at this time
|-
|| sato refresh || || 3 || Review || RP Notes || Not scheduled at this time
|-
|| adding eglibc config control || this goes with the package config options || 1.5 || Review || RP Notes || M2; Owner = Mark
|-
|| Sanity checks on per recipe basis || || 2 || Review || RP Notes || Owner: Saul
|-
|| x32 || layer to support toolchain, libc, and kernel || 2 || Review || RP Notes || Owner: Saul (Nitin)
|-
|| User Creation at postinstall || || 1 || Review || RP Notes || M1; Owner = Mark
|-
|| Directory Ownership || || 1.5 || Review || RP Notes || M2; Owner = Mark
|-
|| Optimise Configure || || 2 || Review || RP Notes || Performance idea, Owner: Saul
|-
|| Ability to build SRPM || || 3 || Review || RP Notes || Owner: Jeff Polk/Mark
|-
|| Check SRCREV in recipe files || should work, may need dev || 2 || Review || RP Notes || Owner: RP/Ke
|-
|| Add Directfb（license LGPL） function || Directfb is more appropriate embedded device than other graphic software|| 3 || Review ||Meta-data || M2; Owner: WR Distro Team
|}

== BSPs ==
{| border="1"
||'''Feature Name''' ||'''Description''' ||'''Priority''' ||'''Status''' ||'''Source''' ||'''Comments / Bugzilla Links'''
|-
|| Support for AVX as in kernel 2.6.30. - Already in 1.0 || Any toolchain support needed?
|| 1|| Review|| Jay || M1; Owner = Nitin
|-
|| Optimize support for Intel hardware features || We need to understand and track each important Intel hardware feature and how it should be optimally supported in the Intel BSPS. Items that immediately come to mind are power, video, and performance counter settings, etc. || 1|| Review|| Tom || Owner: Tom/Darren
|-
|| Fish River Island/Fish River Island II BSP(s) || The base Fish River Island BSP exists already, we now need to add support for the extra devices, and add support for changes introduced by Fish River Island II || 2|| Review|| Tom || Owner: Tom
|-
|| Support ECG (ongoing) || ECG is ramping up with Yocto BSPs and likely will require significant amounts of time and help. Also, since we're trading their BSP work for our help in upstreaming patches, we're also likely to have to spend a significant amount of time with upstream-related tasks too. || 1|| Review|| Tom || Owner: Tom
|-
|| Additional config options || The following configurations need to be enabled to support DPDK.
| bgcolor="yellow"| 1|| Review|| Rahul
|bgcolor="yellow"| Owner: TBD
|}

== ADT ==
{| border="1"
||'''Feature Name''' ||'''Description''' ||'''Priority''' ||'''Status''' ||'''Source''' ||'''Comments / Bugzilla Links'''
|-
|| More test cases about toolchain in autobuilder ||
|| 2 || Review|| ADT Team || Owner = Jessica
|-
|| Eclipse-native tools interface || More integrated with upstream once there's integrated Linux tools that meets our need, e.g. lttng-remote
|| 2 || Review|| ADT Team || Owner = Jessica
|-
|| Indigo update || Update to the latest Eclipse release (Indigo) || 2 || Review|| ADT Team || M2; Owner = Jessica
|-
|| Changes for Image Creator || Eclipse changes pending Image Creator || 1 || Review|| ADT Team || M2; Owner = Jessica
|-
|| Secure login || || 2 || Review|| ADT Team || Owner = Jessica
|-
|| Prebuit SDK integration || speedup target image generation by reusing prebuilt tools from SDK native and target binaries. See: http://wiki.secretlab.ca/Yocto_prebuilt_SDK_integration|| 2 || Deline || Adrian || This functionality looks to have been provided by sstate packages? Owner = Jessica
|-
|| Systemtap integration || Make it easy and convenient for the user to write and execute Systemtap scripts from the IDE. http://www.eclipse.org/linuxtools/projectPages/systemtap/ might provide a good starting point and may be something we can contribute to. We may also need to contribute further up the chain to provide e.g. remote target capabilities. || 2 || Review || Tom || Owner = Jessica
|-
|| 'perf scripting' integration || Make it easy and convenient for the user to write and execute 'perf scripts' from the IDE. We should be able to leverage and build on the Systemtap integration for this. || 2 || Review || Tom || Owner = Jessica
|-
|| Enhance the deploy part in remote debug || ADT is currently using org.eclipse.cdt.remote.launch for remote debug. One limitation in this plug-in is that it can only deploy one single file to the target during the debug. Though it is ok for debugging static linked program, debugging dynamic linked program might require deploying multiple files(including executables and libraries) to the target. || 2 || Review || Lianhao || Owner = Jessica
|-
|}

== Documentation ==
{| border="1"
||'''Feature Name''' ||'''Description''' ||'''Priority''' ||'''Status''' ||'''Source''' ||'''Comments / Bugzilla Links'''
|-
|| Package Documentation Audit || Make changes defined in the package documentation audit from Yocto 1.0
|| 2|| Review|| from 1.0 || Owner = Saul
|-
|| Yocto Project Development Guide || This manual would be an over-arching document that frames the complete development cycle within Yocto Project. The idea here is that the document would be an umbrella document that spawned and referenced subsequent documents. The organization would be the first chapter overviews the major development pieces such as recipe creation, building, debugging, publishing, fail-safing, back-door hook creation, etc. This manual will also include migration information. Scoping would be about two weeks and length would probably be about 40 pages. Overall development time will likely take up to the release given my experience on the creation of the ADT manual (there is no uniterruped time).
|| 1|| Not Started || from scratch || Owner = ScottR
|-
|| Various Demo Videos || The idea here is to create screen-capture type tutorials similar to what exists for the ADT Eclipse Plug-in. However, we want to contract out some help for professional voice-over talent to be used with the images. These don't have to be limited to screen-capture material but could include well-done PPT decks - similar to how other business units in Intel create various training modules. For 1.1 it would be good to capture the script for the existing ADT Eclipse Plug-in module and have it voiced over. Also, for 1.1 it would be good to create a similar module for the Image Creator application.
|| 2|| Not Started || From ADT module and scratch || Owner = ScottR
|-
|| Open-source Newbie Information || This information will be for developers new to open-source. These people do not know what IRC means. Targeted for developers coming from a non-open-source environment. I think the best place for this information would be the website. I haven't looked yet but I suspect information already exists on the web. For Yocto it will be a matter of collecting the best and most useful information, orginizing it and properly referencing/leveraging it.
|| 2|| Not Started || From scratch || Owner = ScottR
|-
|| Tarball Doc process || Right now tarball docs are frozen shortly before a release. The tarball never gets updated beyond that during subsequent documentation development. However, website docs are periodically updated as changes are made during the next development cycle. We need a documentation process where the tarball docs are updated along with the website docs. Perhaps releasing and building a separate documentation tarball is an answer... This whole scheme needs thought about and something implemented.
|| 3|| Not Started || From scratch || Owner = ScottR
|-
|| OOB documentation || Create an out of box guide for giveaway systems built using Yocto. || 1|| Review || Julie || Owner = ScottR
|-
|| Tracing/profiling HOWTOs || Create a document or extend the current Yocto tracing wiki page to explain in detail how to use all the tracing tools in Yocto. It should detail not only how to use each tool individually, but also how to use them in conjunction with each other, highlighting situations in which each is most useful. There should also be some extensive worked examples of real-life use-cases and how they could be investigated using the Yocto tracing/profiling tools. || 2|| Review || Tom ||
|}

== Build ==
This section contains requirements related to the build (autobuilder activities, performance, footprint, etc.)
{| border="1"
||'''Feature Name''' ||'''Description''' ||'''Priority''' ||'''Status''' ||'''Source''' ||'''Comments / Bugzilla Links'''
|-
|| Autobuilder maintenance || Bring scripts into configuration or get git repo working for those that can't be brought in. (takes 2 days)
|bgcolor="yellow"| 1 || Review || Beth || M1; Owner = Beth
|-
|| Meta targets || Part of the challenge of autobuilder is that you have to go into autobuilder, edit script, reconfigure, to change just one build target. This is error prone. What we need is a meta-target where Beth can say she wants to build Poky-image-sato for QEMU x86 and have it just do that. Beth thinks this is done via an override to the web page. (takes ~2 weeks)
|bgcolor="yellow"| 1 || Review || Beth || M2; Owner = Beth
|-
|| License tracking || Get common licenses for all packages and consolidate base file licenses. (takes ~3 days)
|bgcolor="yellow"| 1 || Review || Beth || M1; Owner = Beth
|-
|| License tracking || Build a parser to do license tracking more gracefully and make sure all recipes are correct. (takes ~2 weeks)
|bgcolor="yellow"| 1 || Review || Beth || M2; Owner = Beth
|-
|| Audotbuilder infrastructure || Bring up additional autobuilders and work with sysadmin to configure.
|bgcolor="yellow"| 1 || Review || Beth || M2; Owner = Beth
|-
|| Overall Project || Host a retrospective to discuss what went well and what can be improved in Yocto 1.0. (questions on this?)
|bgcolor="yellow"| 1 || Review || Beth || M1; Owner = Beth
|-
|| Release Scripts || Create Release Scripts that can be used for both a weekly release and for OCT 2011 release to be run by autobuilder (a week. testing on this may take longer)
|bgcolor="yellow"| 1 || Review || Beth || M3; Owner = Beth
|-
|| Enhanced Performance || Also, environmental requirements/suggestions for expected performance; Goal is to build in under 1 hour || 2 || Review || from 1.0 ||
|-
|| Disk Space Reduction ||
|| 2 || Review || Team ||
|-
|| Share gcc work directories ||
|| 2 || Review || Team ||
|-
|| Patch Test System || Create a machine where developers can upload/test patches before submitting them to master to ensure builds won't break when patches are added. (developer autobuilders? Fuzz builds?)
|| 2 || Review || Team ||
|-
|| build statistics reporting || As someone interested in how long it takes to build different images on different hardware configurations and other assorted build metrics, I would like a web based service, that takes output generated by an extended buildstats.bbclass and stores it, to compare against different machines. The end result should be a way to visualize the collected data. See: https://wiki.yoctoproject.org/wiki/Yocto_Buildbot_Autobuilder_Discussions
|| || Review || eflanagan/Jay7/ka6sox ||
|-
|| BSP builds || Autobuilder git fetcher improvements (3 days) || 2 || Review || from 1.0 || M1; Owner = Beth
|-
|| Implement Continuous Autobuilds || Build constantly instead of daily (need fuzz builds for this. once fuzz builds are implemented, this is trivial) || 2 || Review || from 1.0 || M1; Owner = Beth
|}

== Performance and Usability ==
This section contains general Yocto performance as well as usability items.
{| border="1"
||'''Feature Name''' ||'''Description''' ||'''Priority''' ||'''Status''' ||'''Source''' ||'''Comments / Bugzilla Links'''
|-
|| Fast boot time || 2 second boot time target
|| 1|| Review|| Team || M2; Owner = Darren
|-
|| Build Yocto behind firewall || Darren will investigate site.conf and documentation
|| 2 || Review|| Dave||
|-
|| Minimal Image unique || make minimal image smaller || 3 || Review|| Team ||
|-
|| POSIX support || address POSIX failures found in 1.1
|| 2|| Review|| Team ||
|}

== Kernel ==
This section contains items specific to the Yocto kernel.
{| border="1"
||'''Feature Name''' ||'''Description''' ||'''Priority''' ||'''Status''' ||'''Source''' ||'''Comments / Bugzilla Links'''
|-
|| BSP kernel config audit || Audit kernel configs for the various BSPS. Should not be limited to just kernel config options -- it should also include discussion of overall strategies for defining and managing base branches, feature topic branches, config features, etc, and should result in not only the current kernels being changed to match, but also BKMs being published somewhere, probably in the kernel manual.
|| 1|| Review|| Team ||
|-
|| Ongoing kernel maintenance || There should be a task spread out over the whole release, say 10% of one person's time (just a guess), for monitoring LKML and Linus' master branch, and/or relevant lists for patches relevant to the BSPs we maintain. We also need to figure out if Bruce needs help with the management of the base branches e.g. re-enabling features after kernel uprevs, moving feature tags forward, etc.
|| 1|| Review|| Tom ||
|-
|| Tracing: perf trace scripting support || Basically this means allowing perf to be built with the Perl and Python bindings, which turned out to be a headache last time. || 2 || Review || from 1.0 ||
|-
|| Tracing: Add Systemtap support for userspace tracing || Add utrace, etc || 2 || Review || Tom ||
|-
|| Tracing: Systemtap usability in Yocto || Right now, there are instructions on the wiki on how to configure and use Systemtap with Yocto. While straightforward, they are tedious and unlikely to be useful to most people pressed for time. We need to make it easier to use - in addition to documentation/HOWTO tasks listed elsewhere on this page, we need to make it usable 'out of the box' (i.e. outside of ADT) e.g. all paths and configuration handled via script or something similar || 2 || Review || Tom ||
|-
|| Tracing: tuna, oscilloscope recipes || catch up with Tom, likely to remove || 3 || Review || from 1.0 ||
|}

== Project-Wide Features ==
This section contains features for the entire project or for the project website or mailing lists.
{| border="1"
||'''Feature Name''' ||'''Description''' ||'''Priority''' ||'''Status''' ||'''Source''' ||'''Comments / Bugzilla Links'''
|-
|| Patchwork || is it worth the overhead, are there alternatives || 3 || Review || RP Notes ||
|-
|| Alpha || Begin an alpha program after the stabilization period for M3. || 1 || Review || Team ||
|-
|| Bugzilla to Wiki || Create a script which automatically populates and updates the Wiki based on changes in bugzilla.
|bgcolor="yellow"| ? || Review || Darren ||
|}

Yocto 1.1 Features

2011-03-31T10:34:56Z

Robert: /* Poky/Bitbake */

== Potential Yocto Project 2011.10 Features ==
Yocto Project 2011.10 (a.k.a. Yocto Project 1.1) - Target release = October 2011

== Yocto Project 2011.10 Themes ==
The topics below are the themes that some members of the team have started brainstorming for Yocto Project 2011.10. These will grow and change with community input.

=== Yocto Project 2011.10 Objectives ===
The objectives of the Yocto 2011.10 release are to grow participation in Yocto and increase the number of BSPs written for Yocto and partner products based on Yocto.

=== Yocto Project 2011.10 Theme List ===
The Yocto Project 2011.10 Themes towards the Objectives listed above are:

* Multilibs & OE-core config - This work, which began in Yocto Project 1.0, needs to be completed.
* Improve ease of BSP creation - Document the lifecycle and process. Possibly create walkthroughs or tutorials to integrate a new board into the linux-yocto kernel.
* Build performance – Get to the goal of 1 hour build time on a developer machine.
* Upstreaming – Submit patches to upstream projects in order to reduce the 2,000+ patches which are currently part of Yocto Project.

== Process for Entering New Feature Requests ==

* Create a new entry in the appropriate feature table below (Poky, SDK, Hardware)
** Suggestion: start by copying an existing request as a template
* Give the feature a short, descriptive name
* Provide a one or two sentence brief description of the feature
* Set the priority as appropriate (see the legend below)
* Set the Status to "Review"
* In the Source field, enter your name along with the origination of the request (e.g. OSV, OEM, Community) if applicable; provide as much detail here as you can
* In the Comments / Bugzilla field, provide any additional information for the request, such as a link to a bugzilla entry
* Preview your Entry to make sure it looks ok and then save it

''Legend''

'''Priority:''' 1 = Must Have, 2 = Nice to Have, 3 = Optional

'''Status:''' Accept = Engineering agreement to include in release, Review = Under Review for Inclusion in this release, Reject = Will not be included in this release
== Sample Table ==

This is a sample table to show how to submit features.

{| border="1"
||'''Feature Name''' ||'''Description''' ||'''Priority''' ||'''Status''' ||'''Source''' ||'''Comments / Bugzilla Links'''
|-
||Placeholder feature name || Placeholder description of the feature || 1, 2, or 3 || Review|| name|| Comment
|}

== Architecture ==
{| border="1"
||'''Feature Name''' ||'''Description''' ||'''Priority''' ||'''Status''' ||'''Source''' ||'''Comments / Bugzilla Links'''
|-
|| Layer Tooling || This includes the architectural work plus implementing the changes. || 1 || Review || Architect || M2; Owner = Richard
|-
|| OE-Core || Restructuring, renaming, rebranding || 1 || Review || RP Notes || M1; Owner = Richard
|}

== Poky/Bitbake ==
This section contains features for the Poky/Bitbake infastructure.
{| border="1"
||'''Feature Name''' ||'''Description''' ||'''Priority''' ||'''Status''' ||'''Source''' ||'''Comments / Bugzilla Links'''
|-
|| Error handling in bitbake || desc || 1 || Review || RP Notes || M2; Owner = Saul
|-
|| crazygit fetcher || TI issues with fetch2 || 2 || Review || RP Notes ||
|-
|| multi-lib || multi-lib support for 32-bit & 64-bit and capable of being installed at the same time || 1 || Review || from 1.0 || M1; Owner = Richard
|-
|| Image Creator || finish the Image Creator to add features pushed out from 1.0 || 1 || Review || from 1.0 || M2; Owner = Josh + someone else (Dave investigating someone on Jessica's team)
|-
|| Recipe-specific sysroot || || 3 || Review || from 1.0 ||
|-
|| Handle old versions in WORKDIR || || 3 || Review || from 1.0 ||
|-
|| Package config option enhancement || need to plan and then implement || 2 || Review || from 1.0 ||
|-
|| 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 ||
|-
|| 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 ||
|}

== QA Items ==
{| border="1"
||'''Feature Name''' ||'''Description''' ||'''Priority''' ||'''Status''' ||'''Source''' ||'''Comments / Bugzilla Links'''
|-
||QA Framework Enhancements ||
* Add test for unfs_qemu bootup in the sanity test framework and give Liping his patch (Jiajun)
* Help to define long-term flexible framework for SDK/meta-toolchain testing.. Under the test folder, we have different groups of test, such as sanity, SDK(tools), meta-toolchain. User could freely select which test cases they want to test. (Control granularity/level group? Or even a single case has a switch) (Jiajun)
* More test-projects into existing manual test part for meta-toolchain. We should help to find the two typical projects, one c and o C++. (Jiajun)
* Transform the meta-toolchain manual testing into the unified test-framework. (Liping)
* Prepare a workable environment for testing all those newly added features. (Liping)
* After sanity test framework is in the upstream, collect data when selecting different kinds of test components. (MeiLei)
|bgcolor="yellow"| ?? || Review|| QA ||
|-
|| Open Source Test Cases || Perform technical, legal, and QA steps necessary to move test cases into open source. || 3 || Review|| QA ||
|-
|| Automated test infrastructure || Automate the test infrastructure
|| 2 || Review|| QA ||
|-
|| Test framework || this is a test framework that we can include in the distribution || 3 || Review || RP Notes ||
|-
|| 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 ||
|}

== Meta-data ==
{| border="1"
||'''Feature Name''' ||'''Description''' ||'''Priority''' ||'''Status''' ||'''Source''' ||'''Comments / Bugzilla Links'''
|-
|| Upstream our patches || We'll add this as a task in a milestone to give people time to do
|| 1 || Review|| Meta-data|| M2; Owner = Saul
|-
|| 3G || We have an ofono recipe but need some integration work doing || 2 || Review|| Meta-data||
|-
|| btrfs || || 2 || Review|| Meta-data||
|-
|| Other components? || Saul will investigate other components. || 2 || Review|| Meta-data||
|-
|| Replacement for video/audio players currently in Yocto || Codec…
|| 3 || Review|| Meta-data||
|-
|| Investigate New UI || For demos, we would like need a reference UI that is not Sato. Investigate possibilities that the Yocto team won't need to maintain. OpenBox? Gnome-desktop? GP? LXDE? KDE Mobile?
|| 3 || Review|| Meta-data||
|-
|| Qemugl upstreaming || Opengl ES Support || 3 || Review|| Meta-data||
|-
|| Sync qemugl with MeeGo ||
|| 2 || Review|| Meta-data||
|-
|| Package reporting system enhancement||
|| 2 || Review|| Meta-data||
|-
|| pam patch integration || add PAM patches throughout the system switchable via the PAM feature (Mark H)
|| 2 || Review|| Meta-data||
|-
|| selinux patch integration || add SE Linux patches in a similar way to PAM
|| 3 || Review|| Meta-data||
|-
|| Finish LSB "distribution" work || Merge patches which are pushed during ycoto 1.0. Add packages LSB Test Suite need. Hardware platform x86, x86-64 and ppc32(if qt4 can be supported) can be finished.
|| 2 || Review|| Meta-data|| M2; Owner = Xiaofeng Yan, Jingdong Lu, Kai kang,Xudong Hao
|-
|| OE Comparison || Compare Yocto core set against integration work in OE and other distributions looking for bug fixes, (relevant) feature enhancements, and integration/policy hints.
|| 1 || Review|| Meta-data|| M1; Owner = Mark
|-
|| Framework to support multiple library versions co-existing || similar to recipe specific sysroot; needs documentation
|| 2 || Review|| Team ||
|-
|| Embedded java environment or even JDK support ||
|| 3 || Review|| Team ||
|-
|| Automatically generate package repos || automatically generate package repositories (and be able to "use them" -- to be defined) for both ipk and rpm/zypper combinations; NEEDS MORE DISCUSSION
|| 2|| Review|| Team ||
|-
|| MeeGo GPLv2 Sync || compare with Yocto, sync any patches || 2 || Review || RP Notes ||
|-
|| Incompatible License || || 2 || Review || Paul ||
|-
|| End of package revision || replace with a network service || 2 || Review || RP Notes || Owner = Jessica
|-
|| Target module build || Allow for building kernel modules on the target device || 2 || Review || RP Notes || Owner = Darren
|-
|| Live images || make live images their own image type || 2 || Review || RP Notes || Owner = Saul
|-
|| multiple update-alternatives || fixed? || 3 || Review || RP Notes ||
|-
|| init scripts || provide an image/recipe skeleton as a canonical example || 3 || Review || RP Notes ||
|-
|| running post installs at rootfs gen time || || 2 || Review || RP Notes ||
|-
|| remove gnome-vfs || || 3 || Review || RP Notes ||
|-
|| gtk+ sato filechooser patch || || 3 || Review || RP Notes ||
|-
|| sato refresh || || 3 || Review || RP Notes ||
|-
|| adding eglibc config control || this goes with the package config options || 1.5 || Review || RP Notes || M2; Owner = Mark
|-
|| Sanity checks on per recipe basis || || 2 || Review || RP Notes ||
|-
|| x32 || layer to support toolchain, libc, and kernel || 2 || Review || RP Notes ||
|-
|| User Creation at postinstall || || 1 || Review || RP Notes || M1; Owner = Mark
|-
|| Directory Ownership || || 1.5 || Review || RP Notes || M2; Owner = Mark
|-
|| Optimise Configure || || 2 || Review || RP Notes || Performance idea
|-
|| Ability to build SRPM || || 3 || Review || RP Notes ||
|-
|| Check SRCREV in recipe files || should work, may need dev || 2 || Review || RP Notes ||
|-
|| Add Directfb（license LGPL） function || Directfb is more appropriate embedded device than other graphic software|| 3 || Review ||Meta-data || M3;Owner = Xiaofeng Yan if possible
|}

== BSPs ==
{| border="1"
||'''Feature Name''' ||'''Description''' ||'''Priority''' ||'''Status''' ||'''Source''' ||'''Comments / Bugzilla Links'''
|-
|| Support for AVX as in kernel 2.6.30. - Already in 1.0 || Any toolchain support needed?
|| 1|| Review|| Jay || M1; Owner = Saul

|}

== ADT ==
{| border="1"
||'''Feature Name''' ||'''Description''' ||'''Priority''' ||'''Status''' ||'''Source''' ||'''Comments / Bugzilla Links'''
|-
|| More test cases about toolchain in autobuilder ||
|| 2 || Review|| ADT Team || Owner = Jessica
|-
|| Eclipse-native tools interface || not using oprofile-UI. More integrated with upstream
|| 2 || Review|| ADT Team ||
|-
|| Indigo update || Update to the latest Eclipse release (Indigo) || 2 || Review|| ADT Team || M2; Owner = Jessica
|-
|| Changes for Image Creator || Eclipse changes pending Image Creator || 1 || Review|| ADT Team || M2; Owner = Jessica
|-
|| Secure logging || || 2 || Review|| ADT Team ||
|-
|| Prebuit SDK integration || speedup target image generation by reusing prebuilt tools from SDK native and target binaries. See: http://wiki.secretlab.ca/Yocto_prebuilt_SDK_integration|| 2 || Review || Adrian ||
|}

== Documentation ==
{| border="1"
||'''Feature Name''' ||'''Description''' ||'''Priority''' ||'''Status''' ||'''Source''' ||'''Comments / Bugzilla Links'''
|-
|| Package Documentation Audit || Make changes defined in the package documentation audit from Yocto 1.0
|| 2|| Review|| from 1.0 || Owner = Saul
|-
|| Yocto Project Development Guide || This manual would be an over-arching document that frames the complete development cycle within Yocto Project. The idea here is that the document would be an umbrella document that spawned and referenced subsequent documents. The organization would be the first chapter overviews the major development pieces such as recipe creation, building, debugging, publishing, fail-safing, back-door hook creation, etc. This manual will also include migration information. Scoping would be about two weeks and length would probably be about 40 pages. Overall development time will likely take up to the release given my experience on the creation of the ADT manual (there is no uniterruped time).
|| 1|| Not Started || from scratch || Owner = ScottR
|-
|| Various Demo Videos || The idea here is to create screen-capture type tutorials similar to what exists for the ADT Eclipse Plug-in. However, we want to contract out some help for professional voice-over talent to be used with the images. These don't have to be limited to screen-capture material but could include well-done PPT decks - similar to how other business units in Intel create various training modules. For 1.1 it would be good to capture the script for the existing ADT Eclipse Plug-in module and have it voiced over. Also, for 1.1 it would be good to create a similar module for the Image Creator application.
|| 2|| Not Started || From ADT module and scratch || Owner = ScottR
|-
|| Open-source Newbie Information || This information will be for developers new to open-source. These people do not know what IRC means. Targeted for developers coming from a non-open-source environment. I think the best place for this information would be the website. I haven't looked yet but I suspect information already exists on the web. For Yocto it will be a matter of collecting the best and most useful information, orginizing it and properly referencing/leveraging it.
|| 2|| Not Started || From scratch || Owner = ScottR
|-
|| Tarball Doc process || Right now tarball docs are frozen shortly before a release. The tarball never gets updated beyond that during subsequent documentation development. However, website docs are periodically updated as changes are made during the next development cycle. We need a documentation process where the tarball docs are updated along with the website docs. Perhaps releasing and building a separate documentation tarball is an answer... This whole scheme needs thought about and something implemented.
|| 3|| Not Started || From scratch || Owner = ScottR
|-
|| OOB documentation || Create an out of box guide for giveaway systems built using Yocto. || 1|| Review || Julie || Owner = ScottR
|}

== Build ==
This section contains requirements related to the build (autobuilder activities, performance, footprint, etc.)
{| border="1"
||'''Feature Name''' ||'''Description''' ||'''Priority''' ||'''Status''' ||'''Source''' ||'''Comments / Bugzilla Links'''
|-
|| Autobuilder maintenance || Bring scripts into configuration or get git repo working for those that can't be brought in.
|bgcolor="yellow"| 1 || Review || Beth || M1; Owner = Beth
|-
|| Meta targets || Part of the challenge of autobuilder is that you have to go into autobuilder, edit script, reconfigure, to change just one build target. This is error prone. What we need is a meta-target where Beth can say she wants to build Poky-image-sato for QEMU x86 and have it just do that. Beth thinks this is done via an override to the web page. (takes ~2 weeks)
|bgcolor="yellow"| 1 || Review || Beth || M2; Owner = Beth
|-
|| License tracking || Get common licenses for all packages and consolidate base file licenses. (takes ~3 days)
|bgcolor="yellow"| 1 || Review || Beth || M1; Owner = Beth
|-
|| License tracking || Build a parser to do license tracking more gracefully and make sure all recipes are correct. (takes ~2 weeks)
|bgcolor="yellow"| 1 || Review || Beth || M2; Owner = Beth
|-
|| Audotbuilder infrastructure || Bring up additional autobuilders and work with sysadmin to configure.
|bgcolor="yellow"| 1 || Review || Beth || M2; Owner = Beth
|-
|| Overall Project || Host a retrospective to discuss what went well and what can be improved in Yocto 1.0.
|bgcolor="yellow"| 1 || Review || Beth || M1; Owner = Beth
|-
|| Release Scripts || Create Release Scripts that can be used for both a weekly release and for OCT 2011 release to be run by autobuilder
|bgcolor="yellow"| 1 || Review || Beth || M3; Owner = Beth
|-
|| Enhanced Performance || Also, environmental requirements/suggestions for expected performance; Goal is to build in under 1 hour || 2 || Review || from 1.0 ||
|-
|| Disk Space Reduction ||
|| 2 || Review || Team ||
|-
|| Share gcc work directories ||
|| 2 || Review || Team ||
|-
|| Patch Test System || Create a machine where developers can upload/test patches before submitting them to master to ensure builds won't break when patches are added.
|| 2 || Review || Team ||
|-
|| build statistics reporting || As someone interested in how long it takes to build different images on different hardware configurations and other assorted build metrics, I would like a web based service, that takes output generated by an extended buildstats.bbclass and stores it, to compare against different machines. The end result should be a way to visualize the collected data. See: https://wiki.yoctoproject.org/wiki/Yocto_Buildbot_Autobuilder_Discussions
|| || Review || eflanagan/Jay7/ka6sox ||
|-
|| BSP builds || Autobuilder git fetcher improvements || 2 || Review || from 1.0 || M1; Owner = Beth
|-
|| Implement Continuous Autobuilds || Build constantly instead of daily || 2 || Review || from 1.0 || M1; Owner = Beth
|}

== Performance and Usability ==
This section contains general Yocto performance as well as usability items.
{| border="1"
||'''Feature Name''' ||'''Description''' ||'''Priority''' ||'''Status''' ||'''Source''' ||'''Comments / Bugzilla Links'''
|-
|| Fast boot time || 2 second boot time target
|| 1|| Review|| Team || M2; Owner = Darren
|-
|| Build Yocto behind firewall || Darren will investigate site.conf and documentation
|| 2 || Review|| Dave||
|-
|| Minimal Image unique || make minimal image smaller || 3 || Review|| Team ||
|-
|| POSIX support || address POSIX failures found in 1.1
|| 2|| Review|| Team ||
|}

== Kernel ==
This section contains items specific to the Yocto kernel.
{| border="1"
||'''Feature Name''' ||'''Description''' ||'''Priority''' ||'''Status''' ||'''Source''' ||'''Comments / Bugzilla Links'''
|-
|| BSP kernel config audit || audit kernel configs for the various BSPS
|| 2|| Review|| Team ||
|-
|| Tracing: perf trace scripting support || we think usability is the direction to focus on, we want to improve usability through documentation || 2 || Review || from 1.0 ||
|-
|| Tracing: tuna, oscilloscope recipes || catch up with Tom, likely to remove || 3 || Review || from 1.0 ||
|}

== Project-Wide Features ==
This section contains features for the entire project or for the project website or mailing lists.
{| border="1"
||'''Feature Name''' ||'''Description''' ||'''Priority''' ||'''Status''' ||'''Source''' ||'''Comments / Bugzilla Links'''
|-
|| Patchwork || is it worth the overhead, are there alternatives || 3 || Review || RP Notes ||
|-
|| Alpha || Begin an alpha program after the stabilization period for M3. || 1 || Review || Team ||
|-
|| Bugzilla to Wiki || Create a script which automatically populates and updates the Wiki based on changes in bugzilla.
|bgcolor="yellow"| ? || Review || Darren ||
|}