Yocto 1.1 Features: Difference between revisions

From Yocto Project
Jump to navigationJump to search
(initial version)
 
m (Protected "Yocto 1.1 Features": data will be lost if it is modified in more than one place ([edit=sysop] (indefinite) [move=sysop] (indefinite)))
 
(170 intermediate revisions by 17 users not shown)
Line 1: Line 1:
== Yocto 1.1 Features ==
== Potential Yocto Project 1.1 Features ==
Yocto Project 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 complete.  At this time, this page simply contains Yocto 1.0 features that have been re-prioritized to Yocto 1.1.
== Yocto Project 1.1 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.


* multi-lib (May come in 1.0.1.)
=== Yocto Project 1.1 Objectives ===
* Full-featured Yocto Image Creator
The objectives of the Yocto 1.1 release are to grow participation in Yocto and increase the number of BSPs written for  Yocto and partner products based on Yocto.
* Recipe-specific sysroot
 
* Tracing: perf trace scripting support
=== Yocto Project 1.1 Theme List ===
* Tracing: tuna, oscilloscope recipes
The Yocto Project 1.1 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.
* Enable users to easily and seamlessly build Yocto images - This refers to the effort to complete and integrate the Image Creator work started in 1.0.
* 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 large number of 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"
| align="center" style="background:#f0f0f0;"|'''Feature Name'''
| align="center" style="background:#f0f0f0;"|'''Description'''
| align="center" style="background:#f0f0f0;"|'''Priority'''
| align="center" style="background:#f0f0f0;"|'''Status'''
| align="center" style="background:#f0f0f0;"|'''Source'''
| align="center" style="background:#f0f0f0;"|'''Owner'''
| align="center" style="background:#f0f0f0;"|'''Comments / Bugzilla Links'''
|-
| Layer Tooling||This includes the architectural work plus implementing the changes.||1||Review||Architect||Richard||M1 - Sprint B = design complete<br>M2 - Sprint B = implemented (Paul/Daoxien will help)
|-
| OE-Core||Restructuring, renaming, rebranding||1||Review||RP Notes||Richard||M1, Sprint A
|}
 
== Core/Bitbake ==
This section contains features for the Core/Bitbake infastructure.
{| border="1"
| align="center" style="background:#f0f0f0;"|'''Feature Name'''
| align="center" style="background:#f0f0f0;"|'''Description'''
| align="center" style="background:#f0f0f0;"|'''Priority'''
| align="center" style="background:#f0f0f0;"|'''Status'''
| align="center" style="background:#f0f0f0;"|'''Source'''
| align="center" style="background:#f0f0f0;"|'''Owner'''
| align="center" style="background:#f0f0f0;"|'''Comments / Bugzilla Links'''
|-
| Error handling in bitbake||desc||1||Review||RP Notes||Saul (Scott G)||M2, Sprint B
|-
| crazygit fetcher||TI issues with fetch2 - per LCS - should this be a P1?||2||Review||RP Notes||Saul (Ke)||M1, Sprint B (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||Richard (Qing)||\"M1
<br>Sprint 2 - need infrastructure in place (bbclass extend and multilib toolchain changes);
<br>Sprint 3 - RPM support for multilib
<br>Sprint 4 - complete\"
|-
| Image Creator|| finish the Image Creator to add features pushed out from 1.0 as well as polish and refine - See https://wiki.yoctoproject.org/wiki/BitBake/GUI/PostOneOh for details||1||Review||from 1.0||Joshua||\"M1, Sprint 4 - complete all planned items from 1.0
<br>M2, Sprint 4 - polish Image Creator and address all usability issues\"
|-
| Web-based Image Creator||Create a web-based interface that does what the Image Creator does.||TBD||Review||LCS||||not in schedule
|-
| Recipe-specific sysroot||||3||Review||from 1.0||Saul (Dongxiao)||will not schedule for 1.1 (will take 1 month)
|-
| Handle old versions in WORKDIR||||3||Review||from 1.0||||Not scheduled at this time
|-
| Package config option enhancement - Plan||Plan our approach to package config option enhancement||2||Review||from 1.0||Richard||M1, Sprint C
|-
| Package config option enhancement - Implement||Implement approach defined in plan for package config option enhancement||2||Review||from 1.0||Saul||M2, Sprint B
|-
| 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. Beth will work on License Warnings, team will look at other logfile warnings||2||Review||davest and RP||Saul||M2, Sprint D
|-
| 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||WR Distro Team||M2, Sprint C
|-
| Publish Shared State||Publish the shared state information.||TBD||Review||LCS||||not in schedule
|-
| Ease of package repository publication||Make it very easy for your team lead to publish a package repository for the rest of the team to use (this needs to be clearly documented)||TBD||Review||LCS||||moved into Automatically Generate Package Repos
|-
| Executable images||Create images that are executable - for example a pre-installed Ubuntu image with YP installed||TBD||Review||LCS||||not in schedule
|-
| Self-hosting image||Create customizable chroot; Build an image that would be self-hosting||TBD||Review||LCS||||not in schedule
|-
| Yocto OOPS-type messages||add the equivalent of kernel OOPS to Yocto||TBD||Review||LCS||||not in schedule
|-
| Reduced depth revision history||Decrease the depth of the revision history||TBD||Review||LCS||||not in schedule
|-
| Ability to archive work dir||Add the ability to archive the work directory to handle the GPL compliance issue.||TBD||Review||LCS||||not in schedule
|-
| Selective pull back archive||Selectively turn on the ability to pull back a revision tag archive||TBD||Review||LCS||||covered by crazygit fetcher changes
|-
| Address rebase issue||Address the issue that can occur when the upstream is rebasing and there is lost information in the local git.||TBD||Review||LCS||||covered by crazygit fetcher changes
|}
 
== QA Items ==
{| border="1"
| align="center" style="background:#f0f0f0;"|'''Feature Name'''
| align="center" style="background:#f0f0f0;"|'''Description'''
| align="center" style="background:#f0f0f0;"|'''Priority'''
| align="center" style="background:#f0f0f0;"|'''Status'''
| align="center" style="background:#f0f0f0;"|'''Source'''
| align="center" style="background:#f0f0f0;"|'''Owner'''
| align="center" style="background:#f0f0f0;"|'''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||Jiajun/Meilei||M1; April 29th
|-
| Open Source Test Cases||Perform technical, legal, and QA steps necessary to move test cases into open source.||3||Review||QA||||may have no resource to do this task
|-
| Test framework||this is a test framework that we can include in the distribution||3||Review||RP Notes||||may have no resource to do this task;Is it the TI’s test framework we discussed before?
|-
| 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||Jiajun||M1, M2, M3, check latest distribution 1 week before milestone completes and test them in milestone testing; Should we include more Distributions, besides fedora, ubuntu and opensuse?
|-
| Test Plan||Create an overall Test Plan for 1.1 and post on Wiki||1||Accept||Jiajun||Jiajun||M1; May 6th
|-
| Test Execution Plan||Create a Test Execution Plan for the milestone and send to developers||1||Accept||Jiajun||Jiajun||M1, M2, M3, 1 week before milestone completes
|}
 
== Meta-data ==
{| border="1"
| align="center" style="background:#f0f0f0;"|'''Feature Name'''
| align="center" style="background:#f0f0f0;"|'''Description'''
| align="center" style="background:#f0f0f0;"|'''Priority'''
| align="center" style="background:#f0f0f0;"|'''Status'''
| align="center" style="background:#f0f0f0;"|'''Source'''
| align="center" style="background:#f0f0f0;"|'''Owner'''
| align="center" style="background:#f0f0f0;"|'''Comments / Bugzilla Links'''
|-
| Upstream our patches||Three phases:
<br> 1) Have upstream status updated on 90% of patches (so that we can have a status update)
<br>2) Everyone has attempted upstreams for patches defined from item 1)
<br>3) Another round of updates with upstream progress
|1||Review||Meta-data||Saul||M1, Sprint C for item 1)
<br>M2, Sprint B for item 2)
<br>M3, Sprint A for item 3)
|-
| 3G||We have an ofono recipe but need some integration work doing||2||Review||Meta-data||Saul (Dongxiao)||\"Need hardware and infrastructure to test 3G (MeeGo team has this)
<br>M1, Sprint C - status check, design update, HW received
<br>M2, Sprint D - complete\"
|-
| btrfs||||2||Review||Meta-data||Saul (Nitin)||M2, Sprint C
|-
| Other components?||Saul will investigate other components.||2||Review||Meta-data||Saul||
|-
| Replacement for video/audio players currently in Yocto||Codecc||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||Saul (Edwin)||\"M1, Sprint B = status check;
<br>M1, Sprint D = complete\"
|-
| Package reporting system enhancement||||2||Review||Meta-data||Saul (Lei)||M1, Sprint C or D (need additional definition of this item)
|-
| pam patch integration||add PAM patches throughout the system switchable via the PAM feature (Mark H)||2||Review||Meta-data||WR Distro Team ?|| Here is the information from Mark H: The concept is simply to check Fedora and look for Pam patches, integrating them as appropriate into OE-core.
(why fedora?  In my experience Fedora has a better/more consistent set of Pam patches then other distributions I've looked at before.)
We also need to do some source code investigation and look for uses of the password and group files within the system to see if there is anything else that should be using Pam.
Finally as part of the integration are the individual Pam configuration files.  They should only be installed onto the filesystem if Pam support is enabled.
|-
| 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||WR Distro Team||\"M1, Sprint B - QT3 work complete
<br>M1, Sprint D - complete\"
|-
| 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||Mark||M1, Sprint D
|-
| Framework to support multiple library versions co-existing||similar to recipe specific sysroot; needs documentation||3||Review||Team||Saul (Dongxiao?)||Not for 1.1; we just need to document how to use multiple versions of a library using clutter as the example
|-
| 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||Saul (Dexuan)||M1, Design - discussion with Richard complete and schedule defined
|-
| MeeGo GPLv2 Sync||compare with Yocto, sync any patches||2||Review||RP Notes||Saul (Ke)||M2, Sprint B
|-
| Incompatible License||||2||Review||Paul||Paul||M1, Sprint B - design and review
|-
| End of package revision||replace with a network service||2||Review||RP Notes||Jessica||M1, Sprint D
|-
| Target module build||Allow for building kernel modules on the target device||2||Review||RP Notes||Darren||Darren will put this onto the Janitor\'s list
|-
| Live images||make live images their own image type||2||Review||RP Notes||Saul||M2, Sprint A
|-
| multiple update-alternatives||fixed - team thinks it\'s fixed||3||Review||RP Notes||Saul||DONE
|-
| init scripts||provide an image/recipe skeleton as a canonical example||3||Review||RP Notes||WR Distro Team||M1; Sprint B
|-
| running post installs at rootfs gen time||||2||Review||RP Notes||Saul (Dexuan)||M2, Sprint D
|-
| remove gnome-vfs||||3||Review||RP Notes||Saul (Edwin)||M2, Sprint D
|-
| 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||Mark||M2, Sprint C
|-
| Sanity checks on per recipe basis||||2||Review||RP Notes Bug#405||Saul (Scott G)||M3, Sprint A
|-
| x32||layer to support toolchain, libc, and kernel||2||Review||RP Notes||Saul (Nitin)||\"M1, Sprint D - plan created
<br>M2, Sprint D - x32 complete\"
|-
| User Creation at preinstall||||1||Review||RP Notes||Mark (ScottG)||\"M1, Sprint A - design status check
<br>M1, Sprint C - complete\"
|-
| Directory Ownership||||1.5||Review||RP Notes||Mark (w/Qing)||M2, Sprint B
|-
| Optimise Configure||||2||Review||RP Notes||Saul (Dongxiao)||M1, Sprint A - Richard writes down his thoughts (Dongxiao determines finish date at this time)
|-
| Ability to build SRPM||||3||Review||RP Notes||Jeff Polk/Mark||M3, Sprint A - Julie to check with Jeff
|-
| Check SRCREV in recipe files||should work, may need dev||2||Review||RP Notes||Richard/Ke||M1, Sprint A - planning complete (may evaporate after this)
|-
| Add Directfb (license LGPL) function||Test the exist Directfb, qt-embedded, webkit(may have error from upstream's plugin) and gtk over directfb||3||Review||Meta-data||WR Distro Team|| M2, Sprint D.
|}
 
== BSPs ==
{| border="1"
| align="center" style="background:#f0f0f0;"|'''Feature Name'''
| align="center" style="background:#f0f0f0;"|'''Description'''
| align="center" style="background:#f0f0f0;"|'''Priority'''
| align="center" style="background:#f0f0f0;"|'''Status'''
| align="center" style="background:#f0f0f0;"|'''Source'''
| align="center" style="background:#f0f0f0;"|''''''
| align="center" style="background:#f0f0f0;"|'''Comments / Bugzilla Links'''
|-
| Support for AVX as in kernel 2.6.30. - Already in 1.0||Any toolchain support needed?||1||Review||Jay||Nitin||DONE
|-
| Upgrade to gcc 4.6||Need to upgrade toolchain to gcc 4.6||1||Accept||Nitin||Nitin||M1, Sprint C or D
|-
| 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||Tom/Darren||M1, Sprint B, C, D
|-
| 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||Tom||M3, Sprint A
|-
| 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||Tom||Tom will create an on-going task list
|-
| Upgrade EMGD||EMGD needs to be upgraded to the latest version (1.52).  A big part of this should also be to make sure everything gets tested and works e.g. 3-d games, video acceleration, etc||2||Accept||Tom||Tom||M1, Sprint B and C
|-
| Refactor BSPs to use topic branches|| crownbay and fish river island BSP need to be changed to make use of the new eg20t/emgd/gma500 topic branches ||2||Accept||Tom||Tom||M1, Sprint A
|-
| BBXM||Pull in bits from OE (kernel and uboot)||1||Accept||Darren||Darren||M1, Sprint D
|-
| Additional config options||\"The following configurations need to be enabled to support DPDK:
<br> glibc > 2.7 (for features related to cpuset)
<br> kernel configuration:
<br> HPET and HPET MMAP configuration options enabled
<br> all UIO kernel options enabled
<br> HUGETLBFS enabled
<br> PROC_PAGE_MONITOR enabled\"
|1||Review||Rahul||Tom?||M1, Sprint A
|-
| BSP update/intro||determine and integrate / create arch reference BSPs (e500, Cortex, ARM, MIPs)||2||Accept||Bruce/Richard/team||Bruce||Owner: Bruce, M2, 4th Sprint
|}
 
== ADT ==
{| border="1"
| align="center" style="background:#f0f0f0;"|'''Feature Name'''
| align="center" style="background:#f0f0f0;"|'''Description'''
| align="center" style="background:#f0f0f0;"|'''Priority'''
| align="center" style="background:#f0f0f0;"|'''Status'''
| align="center" style="background:#f0f0f0;"|'''Source'''
| align="center" style="background:#f0f0f0;"|'''Owner'''
| align="center" style="background:#f0f0f0;"|'''Comments / Bugzilla Links'''
|-
| More test cases about toolchain in autobuilder||||2||Review||ADT Team||Jessica||\"Status check in M2, Sprint A,
<br>M3, Sprint A\"
|-
| 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||Jessica||M1, Sprint D
|-
| Indigo update||Update to the latest Eclipse release (Indigo)||2||Review||ADT Team||Jessica||\"Status check in M2, Sprint A,
<br>M3, Sprint A\"
|-
| Changes for Image Creator||\"Phase 1:  add mechanism to enable selection of server backend at runtime
<br>Phase 2:  Bug fix for 7.70
<br>Phase 3:  package format job done + image output type job done
<br>Phase 4: complete plug-in\"
|1||Review||ADT Team||Jessica||\"Phase 1:  M1, Sprint B
<br>Phase 2:  M1, Sprint D
<br>Phase 3:  M2, Sprint B
<br>Phase 4:  M2, Sprint D\"
|-
| Secure login||||2||Review||ADT Team||Jessica||Mx - may not make it into 1.1
|-
| 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||Jessica||This functionality looks to have been provided by sstate packages?
|-
| 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||Jessica||\"Status check in M2, Sprint A,
<br>M3, Sprint A\"
|-
| \'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||Jessica||\"Status check in M2, Sprint A,
<br>M3, Sprint A\"
|-
| 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||Jessica||M2 Sprint D
|}
 
== Documentation ==
{| border="1"
| align="center" style="background:#f0f0f0;"|'''Feature Name'''
| align="center" style="background:#f0f0f0;"|'''Description'''
| align="center" style="background:#f0f0f0;"|'''Priority'''
| align="center" style="background:#f0f0f0;"|'''Status'''
| align="center" style="background:#f0f0f0;"|'''Source'''
| align="center" style="background:#f0f0f0;"|'''Owner'''
| align="center" style="background:#f0f0f0;"|'''Comments / Bugzilla Links'''
|-
| Package Documentation Audit||Make changes defined in the package documentation audit from Yocto 1.0||2||Review||from 1.0||Scott G||M1, Julie ask Scott re: Sprint
|-
| 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||ScottR||on-going; Julie/Scott will work off-line on a more detailed schedule
|-
| 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||ScottR||EO M2 complete - Scott/Julie work off-line on additional milestones
|-
| 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||ScottR||M4, ScottR/Darren will discuss how this ties into the Janitor work.  Needs more definition.
|-
| 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||ScottR||M3, ScottR will work with Richard on this
|-
| OOB documentation||Create an out of box guide for giveaway systems built using Yocto.||1||Review||Julie||ScottR||Julie to research timing on this.
|-
| 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||Accept||Tom||Tom||M2
|}
 
== Build ==
This section contains requirements related to the build (autobuilder activities, performance, footprint, etc.)
{| border="1"
| align="center" style="background:#f0f0f0;"|'''Feature Name'''
| align="center" style="background:#f0f0f0;"|'''Description'''
| align="center" style="background:#f0f0f0;"|'''Priority'''
| align="center" style="background:#f0f0f0;"|'''Status'''
| align="center" style="background:#f0f0f0;"|'''Source'''
| align="center" style="background:#f0f0f0;"|'''Owner'''
| align="center" style="background:#f0f0f0;"|'''Comments / Bugzilla Links'''
|-
| OE Autobuilder rename||||1||Accept||Beth||Beth||M1, Design
|-
| Strip out LSB, non-LSB build work||Remove the LSB, non-LSB build work done at the end of 1.0 and re-incorporate it with sstate||1||Accept||Beth||Beth||M1, Design
|-
| Additions to build stats||||1||Accept||Beth||Beth||M3, Sprint A
|-
| Autobuilder maintenance||Bring scripts into configuration or get git repo working for those that can\'t be brought in. (takes 2 days)||1||Accept||Beth||Beth||M1, Sprint A
|-
| Retrospective||Hold a retrospective to discuss what went well and what can be improved in 1.1||1||Accept||Beth||Beth||M1, Sprint A
|-
| 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)||1||Accept||Beth||Beth||M2, Sprint B
|-
| License tracking||Get common licenses for all packages and consolidate base file licenses. (takes ~3 days)||1||Accept||Beth||Beth||M1, Sprint C
|-
| License tracking||Build a parser to do license tracking more gracefully and make sure all recipes are correct. (takes ~2 weeks)||1||Accept||Beth||Beth||M1, Sprint D
|-
| Audotbuilder infrastructure||Bring up additional autobuilders and work with sysadmin to configure.||1||Accept||Beth||Beth||M1, Sprint C (dependent on us having a system admin)
|-
| Overall Project||Host a retrospective to discuss what went well and what can be improved in Yocto 1.0. (questions on this?)||1||Accept||Beth||Beth||M1, Sprint A
|-
| 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)||1||Accept||Beth||Beth||M1, Sprint B
|-
| Enhanced Performance||Also, environmental requirements/suggestions for expected performance; Goal is to build in under 1 hour||1||Review||from 1.0||||
|-
| Disk Space Reduction||||2||Review||Team||WR Distro Team ?||Owner = TBD - WR distro team might be willing to own if they know what is required
|-
| Share gcc work directories||||2||Review||Team||WR Distro Team ?||Owner = TBD - WR distro team might be willing to own if they know what is required
|-
| 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||Jiajun ?||
|-
| 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||||Accept||eflanagan/Jay7/ka6sox||Beth/Jay||M1, Sprint B and C (or two weeks in here)
|-
| BSP builds||Autobuilder git fetcher improvements (3 days)||2||Accept||from 1.0||Beth||M2, Sprint D
|-
| Implement Continuous Autobuilds||Build constantly instead of daily (need fuzz builds for this. once fuzz builds are implemented, this is trivial)||2||Accept||from 1.0||Beth||M2, Sprint C
|-
| non-GPLv3 to Autobuilder||non-GPLv3 build added to autobuilder||1||Accept||Beth||Beth||M3, ww30 (Stabilization)
|}
 
== Performance and Usability ==
This section contains general Yocto performance as well as usability items.
{| border="1"
| align="center" style="background:#f0f0f0;"|'''Feature Name'''
| align="center" style="background:#f0f0f0;"|'''Description'''
| align="center" style="background:#f0f0f0;"|'''Priority'''
| align="center" style="background:#f0f0f0;"|'''Status'''
| align="center" style="background:#f0f0f0;"|'''Source'''
| align="center" style="background:#f0f0f0;"|'''Owner'''
| align="center" style="background:#f0f0f0;"|'''Comments / Bugzilla Links'''
|-
| Fast boot analysis||Perform analysis to determine how best to implement a 2 second boot time||1||Accept||Darren||Darren||M1, Sprint B
|-
| Fast boot time||2 second boot time target||1||Review||Team||Darren||\"M3 - analysis will be complete to show where slowdown is coming from (BIOS or elsewhere); the earliest we can get a system that can use BLDK is August 1st, so getting to the 2s target in 1.1 is not likely\"
|-
| kernel bloat||target = boot a minimal image in < 8M||1||Accept||Darren||Darren||\"M2, Sprint B - analysis complete
<br>M2, Sprint D - development complete\"
|-
| Build Yocto behind firewall||Darren will investigate site.conf and documentation||2||Review||Dave||||
|-
| Minimal Image unique||make minimal image smaller||3||Review||Team||WR Distro Team||M2,Sprint D
|-
| POSIX support||address POSIX failures found in 1.1||2||Review||Team||||
|}
 
== Kernel ==
This section contains items specific to the Yocto kernel.
{| border="1"
| align="center" style="background:#f0f0f0;"|'''Feature Name'''
| align="center" style="background:#f0f0f0;"|'''Description'''
| align="center" style="background:#f0f0f0;"|'''Priority'''
| align="center" style="background:#f0f0f0;"|'''Status'''
| align="center" style="background:#f0f0f0;"|'''Source'''
| align="center" style="background:#f0f0f0;"|'''Owner'''
| align="center" style="background:#f0f0f0;"|'''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||Accept||Team||Bruce||Owner = Bruce, M1, 4th Sprint
|-
| Kernel Tools||Figure out plan for kernel tools (are they merged into main repo or their own project?)||1||Accept||Bruce/Mark||Bruce||Owner = Bruce, M1, 3rd Sprint
|-
| Kernel Tools||Implement plan for kernel tools||1||Accept||Bruce/Mark||Bruce||Owner = Bruce, M1, 4th Sprint
|-
| Kernel Build||auto yoctization. allow the building of arbitrary repos and kernel versions via the yocto kernel meta data||1||Accept||Bruce||Bruce||Owner = Bruce, M1, 2nd Sprint
|-
| Kernel Update||kernel dev/next repo created. feature merges (fs, boot, tiny, controllers, etc). reference tree merges (omap, davinci, etc)||1||Accept||Bruce||Bruce||Owner = Bruce, M1, 3rd Sprint
|-
| Kernel Version||Confirm kernel version||1||Accept||Bruce||Bruce||Owner = Bruce, 6 weeks before dev done
|-
| BSP config cleanup||BSP config cleanup/refactoring. Update to new kernel rev. Investigate Kconfig alignment||1||Accept||Bruce||Bruce||Owner = Bruce, M2, 4th Sprint
|-
| inter-core comms||investigate/report/merge intercore communication methods (mcapi, dsplink,etc). extend as appropriate||2||Accept||Bruce||Bruce||Owner = Bruce, M2, 1st Sprint
|-
| use cases||BSP config streamlining, building the kernel standalone, yoctoization, meta data sharing||1||Accept||Bruce||Bruce||Owner = Bruce, M3, 1st Sprint
|-
| 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||Bruce||Owner = Bruce, M2 4th Sprint
|-
| kernel port to 2.6.37||Port the kernel to 2.6.37||1||Accept||Darren||Darren||M1, Sprint C
|-
| 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||Tom||M1, Sprint D
|-
| Tracing: Add Systemtap support for userspace tracing||Add utrace, etc||2||Review||Tom||Tom||M1, Sprint C
|-
| 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||Tom||M2, Sprint D
|-
| Tracing: tuna, oscilloscope recipes||catch up with Tom, likely to remove||3||Review||from 1.0||||not scheduled at this time
|-
| Lock kernel version||lock the kernel version||1||Accept||Team||Darren||M2, Stabilize (ww29)
|}
 
== Project-Wide Features ==
This section contains features for the entire project or for the project website or mailing lists.
{| border="1"
| align="center" style="background:#f0f0f0;"|'''Feature Name'''
| align="center" style="background:#f0f0f0;"|'''Description'''
| align="center" style="background:#f0f0f0;"|'''Priority'''
| align="center" style="background:#f0f0f0;"|'''Status'''
| align="center" style="background:#f0f0f0;"|'''Source'''
| align="center" style="background:#f0f0f0;"|'''Owner'''
| align="center" style="background:#f0f0f0;"|'''Comments / Bugzilla Links'''
|-
| Patchwork||is it worth the overhead, are there alternatives||3||Review||RP Notes|||| not scheduled at this time
|-
| Alpha||Begin an alpha program after the stabilization period for M3.||1||Accept||Team||Julie||M3, Sprint A
|-
| Demo||Need to determine what we will do for demo and find an owner||1||Accept||Team||Julie||Julie to work with team on details and find correct owner.
|-
| Bugzilla to Wiki||Create a script which automatically populates and updates the Wiki based on changes in bugzilla.|| 2.5||Review||Darren|||| not scheduled at this time
|}
 
== 1.0.1 Schedule ==
This section contains the first draft of the 1.0.1 Yocto 1.0 point release schedule.
{| border="1"
| align="center" style="background:#f0f0f0;"|'''Feature Name'''
| align="center" style="background:#f0f0f0;"|'''Description'''
| align="center" style="background:#f0f0f0;"|'''Priority'''
| align="center" style="background:#f0f0f0;"|'''Status'''
| align="center" style="background:#f0f0f0;"|'''Source'''
| align="center" style="background:#f0f0f0;"|'''Owner'''
| align="center" style="background:#f0f0f0;"|'''Comments / Bugzilla Links'''
|-
| Development complete||All bugs targeted for 1.0.1 are in the 1.0.1 build.||1||Accept||Team||All||M1, Sprint3 to M1, Stabilize
|-
| 1.0.1 built||1.0.1 is built||1||Accept||Team||Beth||M1, Release
|-
| 1.0.1 QA||QA pass on 1.0.1||1||Accept||Team||Jiajun||M2, Sprint 1
|-
| 1.0.1 Release||1.0.1 is released||1||Accept||Team||Beth||M2, Sprint 2
|}

Latest revision as of 00:38, 5 May 2011

Potential Yocto Project 1.1 Features

Yocto Project 1.1 - Target release = October 2011

Yocto Project 1.1 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 1.1 Objectives

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

Yocto Project 1.1 Theme List

The Yocto Project 1.1 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.
  • Enable users to easily and seamlessly build Yocto images - This refers to the effort to complete and integrate the Image Creator work started in 1.0.
  • 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 large number of 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.

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

Feature Name Description Priority Status Source Owner Comments / Bugzilla Links
Layer Tooling This includes the architectural work plus implementing the changes. 1 Review Architect Richard M1 - Sprint B = design complete
M2 - Sprint B = implemented (Paul/Daoxien will help)
OE-Core Restructuring, renaming, rebranding 1 Review RP Notes Richard M1, Sprint A

Core/Bitbake

This section contains features for the Core/Bitbake infastructure.

Feature Name Description Priority Status Source Owner Comments / Bugzilla Links
Error handling in bitbake desc 1 Review RP Notes Saul (Scott G) M2, Sprint B
crazygit fetcher TI issues with fetch2 - per LCS - should this be a P1? 2 Review RP Notes Saul (Ke) M1, Sprint B (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 Richard (Qing) \"M1


Sprint 2 - need infrastructure in place (bbclass extend and multilib toolchain changes);
Sprint 3 - RPM support for multilib
Sprint 4 - complete\"

Image Creator finish the Image Creator to add features pushed out from 1.0 as well as polish and refine - See https://wiki.yoctoproject.org/wiki/BitBake/GUI/PostOneOh for details 1 Review from 1.0 Joshua \"M1, Sprint 4 - complete all planned items from 1.0


M2, Sprint 4 - polish Image Creator and address all usability issues\"

Web-based Image Creator Create a web-based interface that does what the Image Creator does. TBD Review LCS not in schedule
Recipe-specific sysroot 3 Review from 1.0 Saul (Dongxiao) will not schedule for 1.1 (will take 1 month)
Handle old versions in WORKDIR 3 Review from 1.0 Not scheduled at this time
Package config option enhancement - Plan Plan our approach to package config option enhancement 2 Review from 1.0 Richard M1, Sprint C
Package config option enhancement - Implement Implement approach defined in plan for package config option enhancement 2 Review from 1.0 Saul M2, Sprint B
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. Beth will work on License Warnings, team will look at other logfile warnings 2 Review davest and RP Saul M2, Sprint D
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 WR Distro Team M2, Sprint C
Publish Shared State Publish the shared state information. TBD Review LCS not in schedule
Ease of package repository publication Make it very easy for your team lead to publish a package repository for the rest of the team to use (this needs to be clearly documented) TBD Review LCS moved into Automatically Generate Package Repos
Executable images Create images that are executable - for example a pre-installed Ubuntu image with YP installed TBD Review LCS not in schedule
Self-hosting image Create customizable chroot; Build an image that would be self-hosting TBD Review LCS not in schedule
Yocto OOPS-type messages add the equivalent of kernel OOPS to Yocto TBD Review LCS not in schedule
Reduced depth revision history Decrease the depth of the revision history TBD Review LCS not in schedule
Ability to archive work dir Add the ability to archive the work directory to handle the GPL compliance issue. TBD Review LCS not in schedule
Selective pull back archive Selectively turn on the ability to pull back a revision tag archive TBD Review LCS covered by crazygit fetcher changes
Address rebase issue Address the issue that can occur when the upstream is rebasing and there is lost information in the local git. TBD Review LCS covered by crazygit fetcher changes

QA Items

Feature Name Description Priority Status Source Owner 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 Jiajun/Meilei M1; April 29th
Open Source Test Cases Perform technical, legal, and QA steps necessary to move test cases into open source. 3 Review QA may have no resource to do this task
Test framework this is a test framework that we can include in the distribution 3 Review RP Notes may have no resource to do this task;Is it the TI’s test framework we discussed before?
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 Jiajun M1, M2, M3, check latest distribution 1 week before milestone completes and test them in milestone testing; Should we include more Distributions, besides fedora, ubuntu and opensuse?
Test Plan Create an overall Test Plan for 1.1 and post on Wiki 1 Accept Jiajun Jiajun M1; May 6th
Test Execution Plan Create a Test Execution Plan for the milestone and send to developers 1 Accept Jiajun Jiajun M1, M2, M3, 1 week before milestone completes

Meta-data

Feature Name Description Priority Status Source Owner Comments / Bugzilla Links
Upstream our patches Three phases:


1) Have upstream status updated on 90% of patches (so that we can have a status update)
2) Everyone has attempted upstreams for patches defined from item 1)
3) Another round of updates with upstream progress

1 Review Meta-data Saul M1, Sprint C for item 1)


M2, Sprint B for item 2)
M3, Sprint A for item 3)

3G We have an ofono recipe but need some integration work doing 2 Review Meta-data Saul (Dongxiao) \"Need hardware and infrastructure to test 3G (MeeGo team has this)


M1, Sprint C - status check, design update, HW received
M2, Sprint D - complete\"

btrfs 2 Review Meta-data Saul (Nitin) M2, Sprint C
Other components? Saul will investigate other components. 2 Review Meta-data Saul
Replacement for video/audio players currently in Yocto Codecc 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 Saul (Edwin) \"M1, Sprint B = status check;


M1, Sprint D = complete\"

Package reporting system enhancement 2 Review Meta-data Saul (Lei) M1, Sprint C or D (need additional definition of this item)
pam patch integration add PAM patches throughout the system switchable via the PAM feature (Mark H) 2 Review Meta-data WR Distro Team ? Here is the information from Mark H: The concept is simply to check Fedora and look for Pam patches, integrating them as appropriate into OE-core.

(why fedora? In my experience Fedora has a better/more consistent set of Pam patches then other distributions I've looked at before.) We also need to do some source code investigation and look for uses of the password and group files within the system to see if there is anything else that should be using Pam. Finally as part of the integration are the individual Pam configuration files. They should only be installed onto the filesystem if Pam support is enabled.

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 WR Distro Team \"M1, Sprint B - QT3 work complete


M1, Sprint D - complete\"

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 Mark M1, Sprint D
Framework to support multiple library versions co-existing similar to recipe specific sysroot; needs documentation 3 Review Team Saul (Dongxiao?) Not for 1.1; we just need to document how to use multiple versions of a library using clutter as the example
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 Saul (Dexuan) M1, Design - discussion with Richard complete and schedule defined
MeeGo GPLv2 Sync compare with Yocto, sync any patches 2 Review RP Notes Saul (Ke) M2, Sprint B
Incompatible License 2 Review Paul Paul M1, Sprint B - design and review
End of package revision replace with a network service 2 Review RP Notes Jessica M1, Sprint D
Target module build Allow for building kernel modules on the target device 2 Review RP Notes Darren Darren will put this onto the Janitor\'s list
Live images make live images their own image type 2 Review RP Notes Saul M2, Sprint A
multiple update-alternatives fixed - team thinks it\'s fixed 3 Review RP Notes Saul DONE
init scripts provide an image/recipe skeleton as a canonical example 3 Review RP Notes WR Distro Team M1; Sprint B
running post installs at rootfs gen time 2 Review RP Notes Saul (Dexuan) M2, Sprint D
remove gnome-vfs 3 Review RP Notes Saul (Edwin) M2, Sprint D
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 Mark M2, Sprint C
Sanity checks on per recipe basis 2 Review RP Notes Bug#405 Saul (Scott G) M3, Sprint A
x32 layer to support toolchain, libc, and kernel 2 Review RP Notes Saul (Nitin) \"M1, Sprint D - plan created


M2, Sprint D - x32 complete\"

User Creation at preinstall 1 Review RP Notes Mark (ScottG) \"M1, Sprint A - design status check


M1, Sprint C - complete\"

Directory Ownership 1.5 Review RP Notes Mark (w/Qing) M2, Sprint B
Optimise Configure 2 Review RP Notes Saul (Dongxiao) M1, Sprint A - Richard writes down his thoughts (Dongxiao determines finish date at this time)
Ability to build SRPM 3 Review RP Notes Jeff Polk/Mark M3, Sprint A - Julie to check with Jeff
Check SRCREV in recipe files should work, may need dev 2 Review RP Notes Richard/Ke M1, Sprint A - planning complete (may evaporate after this)
Add Directfb (license LGPL) function Test the exist Directfb, qt-embedded, webkit(may have error from upstream's plugin) and gtk over directfb 3 Review Meta-data WR Distro Team M2, Sprint D.

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 Nitin DONE
Upgrade to gcc 4.6 Need to upgrade toolchain to gcc 4.6 1 Accept Nitin Nitin M1, Sprint C or D
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 Tom/Darren M1, Sprint B, C, D
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 Tom M3, Sprint A
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 Tom Tom will create an on-going task list
Upgrade EMGD EMGD needs to be upgraded to the latest version (1.52). A big part of this should also be to make sure everything gets tested and works e.g. 3-d games, video acceleration, etc 2 Accept Tom Tom M1, Sprint B and C
Refactor BSPs to use topic branches crownbay and fish river island BSP need to be changed to make use of the new eg20t/emgd/gma500 topic branches 2 Accept Tom Tom M1, Sprint A
BBXM Pull in bits from OE (kernel and uboot) 1 Accept Darren Darren M1, Sprint D
Additional config options \"The following configurations need to be enabled to support DPDK:


glibc > 2.7 (for features related to cpuset)
kernel configuration:
HPET and HPET MMAP configuration options enabled
all UIO kernel options enabled
HUGETLBFS enabled
PROC_PAGE_MONITOR enabled\"

1 Review Rahul Tom? M1, Sprint A
BSP update/intro determine and integrate / create arch reference BSPs (e500, Cortex, ARM, MIPs) 2 Accept Bruce/Richard/team Bruce Owner: Bruce, M2, 4th Sprint

ADT

Feature Name Description Priority Status Source Owner Comments / Bugzilla Links
More test cases about toolchain in autobuilder 2 Review ADT Team Jessica \"Status check in M2, Sprint A,


M3, Sprint A\"

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 Jessica M1, Sprint D
Indigo update Update to the latest Eclipse release (Indigo) 2 Review ADT Team Jessica \"Status check in M2, Sprint A,


M3, Sprint A\"

Changes for Image Creator \"Phase 1: add mechanism to enable selection of server backend at runtime


Phase 2: Bug fix for 7.70
Phase 3: package format job done + image output type job done
Phase 4: complete plug-in\"

1 Review ADT Team Jessica \"Phase 1: M1, Sprint B


Phase 2: M1, Sprint D
Phase 3: M2, Sprint B
Phase 4: M2, Sprint D\"

Secure login 2 Review ADT Team Jessica Mx - may not make it into 1.1
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 Jessica This functionality looks to have been provided by sstate packages?
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 Jessica \"Status check in M2, Sprint A,


M3, Sprint A\"

\'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 Jessica \"Status check in M2, Sprint A,


M3, Sprint A\"

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 Jessica M2 Sprint D

Documentation

Feature Name Description Priority Status Source Owner Comments / Bugzilla Links
Package Documentation Audit Make changes defined in the package documentation audit from Yocto 1.0 2 Review from 1.0 Scott G M1, Julie ask Scott re: Sprint
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 ScottR on-going; Julie/Scott will work off-line on a more detailed schedule
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 ScottR EO M2 complete - Scott/Julie work off-line on additional milestones
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 ScottR M4, ScottR/Darren will discuss how this ties into the Janitor work. Needs more definition.
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 ScottR M3, ScottR will work with Richard on this
OOB documentation Create an out of box guide for giveaway systems built using Yocto. 1 Review Julie ScottR Julie to research timing on this.
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 Accept Tom Tom M2

Build

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

Feature Name Description Priority Status Source Owner Comments / Bugzilla Links
OE Autobuilder rename 1 Accept Beth Beth M1, Design
Strip out LSB, non-LSB build work Remove the LSB, non-LSB build work done at the end of 1.0 and re-incorporate it with sstate 1 Accept Beth Beth M1, Design
Additions to build stats 1 Accept Beth Beth M3, Sprint A
Autobuilder maintenance Bring scripts into configuration or get git repo working for those that can\'t be brought in. (takes 2 days) 1 Accept Beth Beth M1, Sprint A
Retrospective Hold a retrospective to discuss what went well and what can be improved in 1.1 1 Accept Beth Beth M1, Sprint A
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) 1 Accept Beth Beth M2, Sprint B
License tracking Get common licenses for all packages and consolidate base file licenses. (takes ~3 days) 1 Accept Beth Beth M1, Sprint C
License tracking Build a parser to do license tracking more gracefully and make sure all recipes are correct. (takes ~2 weeks) 1 Accept Beth Beth M1, Sprint D
Audotbuilder infrastructure Bring up additional autobuilders and work with sysadmin to configure. 1 Accept Beth Beth M1, Sprint C (dependent on us having a system admin)
Overall Project Host a retrospective to discuss what went well and what can be improved in Yocto 1.0. (questions on this?) 1 Accept Beth Beth M1, Sprint A
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) 1 Accept Beth Beth M1, Sprint B
Enhanced Performance Also, environmental requirements/suggestions for expected performance; Goal is to build in under 1 hour 1 Review from 1.0
Disk Space Reduction 2 Review Team WR Distro Team ? Owner = TBD - WR distro team might be willing to own if they know what is required
Share gcc work directories 2 Review Team WR Distro Team ? Owner = TBD - WR distro team might be willing to own if they know what is required
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 Jiajun ?
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 Accept eflanagan/Jay7/ka6sox Beth/Jay M1, Sprint B and C (or two weeks in here)
BSP builds Autobuilder git fetcher improvements (3 days) 2 Accept from 1.0 Beth M2, Sprint D
Implement Continuous Autobuilds Build constantly instead of daily (need fuzz builds for this. once fuzz builds are implemented, this is trivial) 2 Accept from 1.0 Beth M2, Sprint C
non-GPLv3 to Autobuilder non-GPLv3 build added to autobuilder 1 Accept Beth Beth M3, ww30 (Stabilization)

Performance and Usability

This section contains general Yocto performance as well as usability items.

Feature Name Description Priority Status Source Owner Comments / Bugzilla Links
Fast boot analysis Perform analysis to determine how best to implement a 2 second boot time 1 Accept Darren Darren M1, Sprint B
Fast boot time 2 second boot time target 1 Review Team Darren \"M3 - analysis will be complete to show where slowdown is coming from (BIOS or elsewhere); the earliest we can get a system that can use BLDK is August 1st, so getting to the 2s target in 1.1 is not likely\"
kernel bloat target = boot a minimal image in < 8M 1 Accept Darren Darren \"M2, Sprint B - analysis complete


M2, Sprint D - development complete\"

Build Yocto behind firewall Darren will investigate site.conf and documentation 2 Review Dave
Minimal Image unique make minimal image smaller 3 Review Team WR Distro Team M2,Sprint D
POSIX support address POSIX failures found in 1.1 2 Review Team

Kernel

This section contains items specific to the Yocto kernel.

Feature Name Description Priority Status Source Owner 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 Accept Team Bruce Owner = Bruce, M1, 4th Sprint
Kernel Tools Figure out plan for kernel tools (are they merged into main repo or their own project?) 1 Accept Bruce/Mark Bruce Owner = Bruce, M1, 3rd Sprint
Kernel Tools Implement plan for kernel tools 1 Accept Bruce/Mark Bruce Owner = Bruce, M1, 4th Sprint
Kernel Build auto yoctization. allow the building of arbitrary repos and kernel versions via the yocto kernel meta data 1 Accept Bruce Bruce Owner = Bruce, M1, 2nd Sprint
Kernel Update kernel dev/next repo created. feature merges (fs, boot, tiny, controllers, etc). reference tree merges (omap, davinci, etc) 1 Accept Bruce Bruce Owner = Bruce, M1, 3rd Sprint
Kernel Version Confirm kernel version 1 Accept Bruce Bruce Owner = Bruce, 6 weeks before dev done
BSP config cleanup BSP config cleanup/refactoring. Update to new kernel rev. Investigate Kconfig alignment 1 Accept Bruce Bruce Owner = Bruce, M2, 4th Sprint
inter-core comms investigate/report/merge intercore communication methods (mcapi, dsplink,etc). extend as appropriate 2 Accept Bruce Bruce Owner = Bruce, M2, 1st Sprint
use cases BSP config streamlining, building the kernel standalone, yoctoization, meta data sharing 1 Accept Bruce Bruce Owner = Bruce, M3, 1st Sprint
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 Bruce Owner = Bruce, M2 4th Sprint
kernel port to 2.6.37 Port the kernel to 2.6.37 1 Accept Darren Darren M1, Sprint C
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 Tom M1, Sprint D
Tracing: Add Systemtap support for userspace tracing Add utrace, etc 2 Review Tom Tom M1, Sprint C
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 Tom M2, Sprint D
Tracing: tuna, oscilloscope recipes catch up with Tom, likely to remove 3 Review from 1.0 not scheduled at this time
Lock kernel version lock the kernel version 1 Accept Team Darren M2, Stabilize (ww29)

Project-Wide Features

This section contains features for the entire project or for the project website or mailing lists.

Feature Name Description Priority Status Source Owner Comments / Bugzilla Links
Patchwork is it worth the overhead, are there alternatives 3 Review RP Notes not scheduled at this time
Alpha Begin an alpha program after the stabilization period for M3. 1 Accept Team Julie M3, Sprint A
Demo Need to determine what we will do for demo and find an owner 1 Accept Team Julie Julie to work with team on details and find correct owner.
Bugzilla to Wiki Create a script which automatically populates and updates the Wiki based on changes in bugzilla. 2.5 Review Darren not scheduled at this time

1.0.1 Schedule

This section contains the first draft of the 1.0.1 Yocto 1.0 point release schedule.

Feature Name Description Priority Status Source Owner Comments / Bugzilla Links
Development complete All bugs targeted for 1.0.1 are in the 1.0.1 build. 1 Accept Team All M1, Sprint3 to M1, Stabilize
1.0.1 built 1.0.1 is built 1 Accept Team Beth M1, Release
1.0.1 QA QA pass on 1.0.1 1 Accept Team Jiajun M2, Sprint 1
1.0.1 Release 1.0.1 is released 1 Accept Team Beth M2, Sprint 2
Retrieved from "https://wiki.yoctoproject.org/wiki/index.php?title=Yocto_1.1_Features&oldid=1608"