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 |
|
1 |
Review |
Jay |
|
ADT
| Feature Name |
Description |
Priority |
Status |
Source |
Comments / Bugzilla Links
|
| More test cases about toolchain in autobuilder |
|
1 |
Review |
ADT Team |
|
| 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) |
1 |
Review |
ADT Team |
|
| Changes for Image Creator |
Eclipse changes pending Image Creator |
1 |
Review |
ADT Team |
|
| 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
|
?? |
Review |
from 1.0 |
|
| 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 |
|
?? |
Review |
Team |
|
| Share gcc work directories |
|
?? |
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 |
|
| Share gcc work directories |
|
?? |
Review |
Team |
|
Miscellaneous
| Feature Name |
Description |
Priority |
Status |
Source |
Comments / Bugzilla Links
|
| Fast boot time |
2 second boot time
|
1 |
Review |
Team |
|
| Build Yocto behind firewall |
Darren will investigate site.conf and documentation
|
1 |
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 |
? |
|
RP Notes |
|
|
| Incompatible License |
|
? |
|
Paul |
|
|
| GUIs |
Eclipse tooling and image builder |
? |
|
RP Notes |
|
|
| Bug Week |
Break in deliverables to allow for focus on bugs |
? |
|
RP Notes |
|
|
| Images Week |
Break in deliverables to allow for focus on using images |
? |
|
RP Notes |
|
|
| Version upgrades |
? |
? |
|
RP Notes |
|
|
| OE-Core |
Realtionship building |
? |
|
RP Notes |
|
|
| Patchwork |
is it worth the overhead, are there alternatives |
? |
|
RP Notes |
|
|
| End of PR |
replace with a network service |
? |
|
RP Notes |
|
|
| Target module build |
Allow for building kernel modules on the target device |
? |
|
RP Notes |
|
|
| Live images |
make live images their own image type |
? |
|
RP Notes |
|
|
| Error handling in bitbake |
desc |
? |
|
RP Notes |
|
|
| crazygit fetcher |
TI issues with fetch2 |
? |
|
RP Notes |
|
|
| package config option support improvements |
? |
? |
|
RP Notes |
|
|
| Test framework? |
? |
? |
|
RP Notes |
|
|
| multiple update-alternatives |
fixed? |
? |
|
RP Notes |
|
|
| init scripts |
provide an image/recipe skeleton as a canonical example |
? |
|
RP Notes |
|
|
| running post installs at rootfs gen time |
|
? |
|
RP Notes |
|
|
| remove gnome-vfs |
|
? |
|
RP Notes |
|
|
| gtk+ sato filechooser patch |
|
? |
|
RP Notes |
|
|
| sato refresh |
|
? |
|
RP Notes |
|
|
| P1 adding eglic config control |
|
? |
|
RP Notes |
|
|
| Sanity checks on per recipe basis |
|
? |
|
RP Notes |
|
|
| x32 |
layer to support toolchain, libc, and kernel |
? |
|
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 |
|
|
