Yocto 1.1 Features: Difference between revisions

From Yocto Project
Jump to navigationJump to search
(added additional features brainstormed by team)
Line 1: Line 1:
== Yocto 1.1 Features ==
== Potential Yocto 1.1 Features ==
Yocto 1.1 - Target release = October 2011


This page contains a list of Yocto 1.1 features.  There has been no official call for Yocto 1.1 features, so this list is not completeAt this time, this page simply contains Yocto 1.0 features that have been re-prioritized to Yocto 1.1.
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]].


=== Reprioritized from 1.0 ===
* multi-lib (May come in 1.0.1.)
* multi-lib (May come in 1.0.1.)
* Full-featured Yocto Image Creator
* Full-featured Yocto Image Creator
Line 11: Line 13:
* Package config option enhancement
* Package config option enhancement
* Build BSPs as part of the nightly builds
* Build BSPs as part of the nightly builds
* Disk space reduction
* Continuous build performance improvement
* Also, environmental requirements/suggestions for expected performance (this perhaps better in 1.0 release)


=== QA Items ===
=== QA Items ===
Line 19: Line 25:
* Prepare a workable environment for testing all those newly added features.  (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)
* After sanity test framework is in the upstream, collect data when selecting different kinds of test components. (MeiLei)
* Test case open source
* Automated test infrastructure
=== Meta-data ===
* Sprints for all of our bugs
* Upstream our patches
* Package updates
* Security updates     
* New components?
** 3G, butterfs, …
* Replacement for video/audio players currently in Yocto
** Codec…
* Investigation about replacement of reference UI instead of Sato (may be hard)
** QT?
* Qemugl upstreaming
** Opengl ES support
* Package reporting system enhancement
=== SDK ===
* More test cases about toolchain in autobuilder
* Eclipse-native tools interface (not using oprofile-UI. More integrated with upstream)
=== Miscellaneous ===
* Fast boot time (2s?)
* Build Yocto behind firewall
* More user-friendly customizations
** Develop more sample layers (oriented?)
* Framework to support multiple library versions co-existing (similar to recipe specific sysroot)
* Option level configurability
* Embedded java environment or even JDK support
* WR linux support

Revision as of 02:32, 17 February 2011

Potential Yocto 1.1 Features

Yocto 1.1 - Target release = October 2011

This page contains a list of Yocto 1.1 features. In early March, the Yocto Architect will issue an official call for Yocto 1.1 features. This list contains reprioritized items from 1.0 or features that came up as a result of discussions among Yocto engineers. If you have a feature you would like to see added, send an email to the Yocto Architect with a description of the feature, its impat on the source code, and whether you are willing to help write the code to implement the feature. The Yocto Architect will add this to the potential Yocto 1.1 Features list. The potential Yocto 1.1 Features list will be turned into the Yocto Features List as described in the Program Management Plan.

Reprioritized from 1.0

  • multi-lib (May come in 1.0.1.)
  • Full-featured Yocto Image Creator
  • Recipe-specific sysroot
  • Tracing: perf trace scripting support
  • Tracing: tuna, oscilloscope recipes
  • Handle old versions in WORKDIR
  • Package config option enhancement
  • Build BSPs as part of the nightly builds
  • Disk space reduction
  • Continuous build performance improvement
  • Also, environmental requirements/suggestions for expected performance (this perhaps better in 1.0 release)


QA Items

  • 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)
  • Test case open source
  • Automated test infrastructure

Meta-data

  • Sprints for all of our bugs
  • Upstream our patches
  • Package updates
  • Security updates
  • New components?
    • 3G, butterfs, …
  • Replacement for video/audio players currently in Yocto
    • Codec…
  • Investigation about replacement of reference UI instead of Sato (may be hard)
    • QT?
  • Qemugl upstreaming
    • Opengl ES support
  • Package reporting system enhancement

SDK

  • More test cases about toolchain in autobuilder
  • Eclipse-native tools interface (not using oprofile-UI. More integrated with upstream)

Miscellaneous

  • Fast boot time (2s?)
  • Build Yocto behind firewall
  • More user-friendly customizations
    • Develop more sample layers (oriented?)
  • Framework to support multiple library versions co-existing (similar to recipe specific sysroot)
  • Option level configurability
  • Embedded java environment or even JDK support
  • WR linux support