Yocto 1.1 Features: Difference between revisions

From Yocto Project
Jump to navigationJump to search
(added owners, milestones)
(added priorities)
Line 207: Line 207:
||'''Feature Name''' ||'''Description''' ||'''Priority''' ||'''Status''' ||'''Source''' ||'''Comments / Bugzilla Links'''
||'''Feature Name''' ||'''Description''' ||'''Priority''' ||'''Status''' ||'''Source''' ||'''Comments / Bugzilla Links'''
|-
|-
|| MeeGo GPLv2 Sync || compare with Yocto, sync any patches || ? || || RP Notes || ||
|| MeeGo GPLv2 Sync || compare with Yocto, sync any patches || 2 || Review || RP Notes || ||
|-
|-
|| Incompatible License || || ? || || Paul || ||
|| Incompatible License || || 2 || Review  || Paul || ||
|-
|-
|| GUIs || Eclipse tooling and image builder || ? || || RP Notes || ||
|| OE-Core || Restructuring, renaming, rebranding || 1 || Review || RP Notes || M1; Owner = Richard ||
|-
|-
|| Bug Week || Break in deliverables to allow for focus on bugs || ? || || RP Notes || ||
|| Patchwork || is it worth the overhead, are there alternatives || 3 || Review || RP Notes || ||
|-
|-
|| Images Week || Break in deliverables to allow for focus on using images || ? || || RP Notes || ||
|| End of package revision || replace with a network service || 2 || Review || RP Notes || Owner = Jessica ||
|-
|-
|| Version upgrades || ? || ? || || RP Notes || ||
|| Target module build || Allow for building kernel modules on the target device || 2 || Review || RP Notes || Owner = Darren ||
|-
|-
|| OE-Core || Realtionship building || ? || || RP Notes || ||
|| Live images || make live images their own image type || 2 || Review || RP Notes || Owner = Saul ||
|-
|-
|| Patchwork || is it worth the overhead, are there alternatives || ? || || RP Notes || ||
|| Error handling in bitbake || desc || 1 || Review || RP Notes || M2; Owner = Saul ||
|-
|-
|| End of PR || replace with a network service || ? || || RP Notes || ||
|| crazygit fetcher || TI issues with fetch2 || 2 || Review || RP Notes || ||
|-
|-
|| Target module build || Allow for building kernel modules on the target device || ? || || RP Notes || ||
|| Test framework || this is a test framework that we can include in the distribution || 3 || Review || RP Notes || ||
|-
|-
|| Live images || make live images their own image type || ? || || RP Notes || ||
|| multiple update-alternatives || fixed? || 3 || Review || RP Notes || ||
|-
|-
|| Error handling in bitbake || desc || ? || || RP Notes || ||
|| init scripts || provide an image/recipe skeleton as a canonical example || 3 || Review || RP Notes || ||
|-
|-
|| crazygit fetcher || TI issues with fetch2 || ? || || RP Notes || ||
|| running post installs at rootfs gen time || || 2 || Review || RP Notes || ||
|-
|-
|| package config option support improvements || ? || ? || || RP Notes || ||
|| remove gnome-vfs || || 3 || Review || RP Notes || ||
|-
|-
|| Test framework? || ? || ? || || RP Notes || ||
|| gtk+ sato filechooser patch || || 3 || Review || RP Notes || ||
|-
|-
|| multiple update-alternatives || fixed? || ? || || RP Notes || ||
|| sato refresh || || 3 || Review || RP Notes || ||
|-
|-
|| init scripts || provide an image/recipe skeleton as a canonical example || ? || || RP Notes || ||
|| adding eglibc config control  || this goes with the package config options || 1.5 || Review || RP Notes || M2; Owner = Mark ||
|-
|-
|| running post installs at rootfs gen time || || ? || || RP Notes || ||
|| Sanity checks on per recipe basis || || 2 || Review || RP Notes || ||
|-
|-
|| remove gnome-vfs || || ? || || RP Notes || ||
|| x32 || layer to support toolchain, libc, and kernel || 2 || Review || RP Notes || ||
|-
|-
|| gtk+ sato filechooser patch || || ? || || RP Notes || ||
|| User Creation at postinstall || || 1 || Review || RP Notes || M1; Owner = Mark ||
|-
|-
|| sato refresh || || ? || || RP Notes || ||
|| Directory Ownership || || 1.5 || Review || RP Notes || M2; Owner = Mark ||
|-
|-
|| P1 adding eglic config control  || || ? || || RP Notes || ||
|| Optimise Configure || || 2 || Review || RP Notes || Performance idea ||
|-
|-
|| Sanity checks on per recipe basis || || ? || || RP Notes || ||
|| Ability to build SRPM  || || 3 || Review || RP Notes || ||
|-
|-
|| x32 || layer to support toolchain, libc, and kernel || ? || || RP Notes || ||
|| Check SRCREV in recipe files || should work, may need dev || 2 || Review || RP Notes || ||
|-
|| User Creation at postinstall || || ? || || RP Notes || ||
|-
|| Directory Ownership || || ? || || RP Notes || ||
|-
|| Opitmise Configure || || ? || || RP Notes || ||
|-
|| P3 Ability to build SRPM  || || ? || || RP Notes || ||
|-
|| Check SRCREV in recipe files || should work, may need dev || ? || || RP Notes || ||
|-
|-


|}
|}

Revision as of 14:51, 14 March 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 1, 2, or 3 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 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
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
Handle old versions in WORKDIR 3 Review from 1.0
BSP builds Autobuilder git fetcher improvements 2 Review from 1.0 M1; Owner = Beth
Package config option enhancement need to plan and then implement 2 Review from 1.0
Implement Continuous Autobuilds Build constantly instead of daily 2 Review from 1.0 M1; Owner = Beth

Architecture

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

QA Items

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)
 ?? 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

Meta-data

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 2 Review Meta-data
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

BSPs

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

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

Documentation

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 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. 2 Review from 1.0

Build

This section contains requirements related to the build (performance, footprint, etc.)

Feature Name Description Priority Status Source Comments / Bugzilla Links
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

Miscellaneous

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
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
Minimal Image unique make minimal image smaller 3 Review Team
BSP kernel config audit audit kernel configs for the various BSPS 2 Review Team
POSIX support address POSIX failures found in 1.1 2 Review Team

Brainstorming (Needs categorizing)

Feature Name Description Priority Status Source Comments / Bugzilla Links
MeeGo GPLv2 Sync compare with Yocto, sync any patches 2 Review RP Notes
Incompatible License 2 Review Paul
OE-Core Restructuring, renaming, rebranding 1 Review RP Notes M1; Owner = Richard
Patchwork is it worth the overhead, are there alternatives 3 Review RP Notes
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
Error handling in bitbake desc 1 Review RP Notes M2; Owner = Saul
crazygit fetcher TI issues with fetch2 2 Review RP Notes
Test framework this is a test framework that we can include in the distribution 3 Review RP Notes
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
Retrieved from "https://wiki.yoctoproject.org/wiki/index.php?title=Yocto_1.1_Features&oldid=926"