Yocto 1.1 Features: Difference between revisions

From Yocto Project
Jump to navigationJump to search
Line 4: Line 4:
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]].
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 ===
== Process for Entering New Feature Requests ==
* multi-lib (32-bit & 64-bit capable of being installed at the same time!) (May come in 1.0.1.)
 
* Full-featured Yocto Image Creator
* Create a new entry in the appropriate feature table below (Poky, SDK, Hardware)
* Recipe-specific sysroot
** Suggestion:  start by copying an existing request as a template
* Tracing:  perf trace scripting support
* Give the feature a short, descriptive name
* Tracing:  tuna, oscilloscope recipes
* Provide a one or two sentence brief description of the feature
* Handle old versions in WORKDIR
* Set the priority as appropriate (see the legend below)
* Package config option enhancement
* Set the Status to "Review"
* Build BSPs as part of the nightly builds
* 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
* Disk space reduction
* In the Comments / Bugzilla field, provide any additional information for the request, such as a link to a bugzilla entry
* Continuous build performance improvement
* Preview your Entry to make sure it looks ok and then save it
* Also, environmental requirements/suggestions for expected performance (this perhaps better in 1.0 release)
 
''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 ||31 || Review|| name|| Comment
|}
 
== Reprioritized from 1.0 ==
{| border="1"
||'''Feature Name''' ||'''Description''' ||'''Priority''' ||'''Status''' ||'''Source''' ||'''Comments / Bugzilla Links'''
|-
|| multi-lib || multi-lib support for 32-bit & 64-bit and capable of being installed at the same time || 1 || Accept || from 1.0 || may come in a 1.0.1 release
|-
|| Image Creator || finish the Image Creator to add features pushed out from 1.0 || 1 || Accept || from 1.0 ||
|-
|| Recipe-specific sysroot || || 1 || Accept || from 1.0 ||
|-
|| Tracing:  perf trace scripting support || || 1 || Accept || from 1.0 ||
|-
|| Tracing:  tuna, oscilloscope recipes || || 1 || Accept || from 1.0 ||
|-
|| Handle old versions in WORKDIR || || 1 || Accept || from 1.0 ||
|-
|| BSP builds || Build BSPs as part of the nightly builds || 1 || Accept || from 1.0 ||
|-
|| Disk space reduction || || 1 || Accept || from 1.0 ||
|-
|| Package config option enhancement || || 1 || Accept || from 1.0 ||
|-
|| Continuous build performance improvement || || 1 || Accept || from 1.0 ||
|-
|| Enhanced Performance || Also, environmental requirements/suggestions for expected performance|| 1 || Accept || from 1.0 ||
|}


=== QA Items ===
=== QA Items ===

Revision as of 21:58, 23 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.

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.

Feature Name Description Priority Status Source Comments / Bugzilla Links
Placeholder feature name Placeholder description of the feature 31 Review name Comment

Reprioritized from 1.0

Feature Name Description Priority Status Source Comments / Bugzilla Links
multi-lib multi-lib support for 32-bit & 64-bit and capable of being installed at the same time 1 Accept from 1.0 may come in a 1.0.1 release
Image Creator finish the Image Creator to add features pushed out from 1.0 1 Accept from 1.0
Recipe-specific sysroot 1 Accept from 1.0
Tracing: perf trace scripting support 1 Accept from 1.0
Tracing: tuna, oscilloscope recipes 1 Accept from 1.0
Handle old versions in WORKDIR 1 Accept from 1.0
BSP builds Build BSPs as part of the nightly builds 1 Accept from 1.0
Disk space reduction 1 Accept from 1.0
Package config option enhancement 1 Accept from 1.0
Continuous build performance improvement 1 Accept from 1.0
Enhanced Performance Also, environmental requirements/suggestions for expected performance 1 Accept from 1.0

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
  • pam patch integration (add PAM patches throughout the system switchable via

the PAM feature)

  • selinux patch integration (add SE Linux patches in a similar way to PAM)
  • Finish LSB "distribution" work
  • Compare Yocto core set against integration work in OE and other distributions looking for bug fixes, (relevant) feature enhancements, and integration/policy hints.

SDK

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

Documentation

  • Make changes defined in the package documentation audit from Yocto 1.0

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
  • automatically generate package repositories (and be able to "use them" -- to be defined) for both ipk and rpm/zypper combinations
  • make minimal a unique thing, smaller, static, uclibc, etc.
  • audit kernel configs for the various BSPS
  • address POSIX failures found in 1.1
Retrieved from "https://wiki.yoctoproject.org/wiki/index.php?title=Yocto_1.1_Features&oldid=807"