Yocto 1.0 Schedule: Difference between revisions

From Yocto Project
Jump to navigationJump to search
(added final status from Scott)
 
(129 intermediate revisions by 7 users not shown)
Line 1: Line 1:
= v1.0 (release date: Apr 15, 2011) =
= v1.0 (release date: Apr 6, 2011) =
----
----
The detailed milestone map for v1.0 is as below.  During the first week of each subsequent milestone past M1 we will have a demonstration of the previous milestone capabilities as well as a planning and design session for the current milestone.<br><br>
The detailed milestone map for v1.0 is as below.  During the first week of each subsequent milestone past M1 we will have a demonstration of the previous milestone capabilities as well as a planning and design session for the current milestone.<br><br>
Line 64: Line 64:
|-
|-
|| Poky Features || environment variables for kernel builds|| switching a branch, or adding a configuration feature (and even changing the kernel repo) is often done during development of a BSP. Having some additional variables that are pass the bitbake environment scrub would be useful. i.e. KBRANCH=foo bitbake -c configure linux-yocto. This goes along with the other BSP bootstrapping suggestions. || 2|| Done || Bruce|| bruceashfield|| Enhancement
|| Poky Features || environment variables for kernel builds|| switching a branch, or adding a configuration feature (and even changing the kernel repo) is often done during development of a BSP. Having some additional variables that are pass the bitbake environment scrub would be useful. i.e. KBRANCH=foo bitbake -c configure linux-yocto. This goes along with the other BSP bootstrapping suggestions. || 2|| Done || Bruce|| bruceashfield|| Enhancement
|-
|| Poky Features || kernel development layer|| The (correct) poky behaviour of building known revisions coupled with the fetcher requiring a BSP branch to already be present means that local modifications (and kernel source tree) are required for kernel development. I already have a layer that overrides/modifies the behaviour when added to the bblayers.conf and configured into an environment. This seems useful for more people to use. || 2|| Done || Bruce|| bruceashfield|| Enhancement
|-
|| Distribution / components|| Zypper/RPM|| RPM Uprev / Zypper Uprev  [lets get to the latest versions]|| 1|| just started, will be in M3, Sprint B|| Mark/Qing|| ||
|-
|-
|| Supported Targets|| ARM Platform Support|| Replace beagleboard with Beagleboard XM - decision || 2|| Done || Bruce|| alex|| Basic Yocto hardware support  
|| Supported Targets|| ARM Platform Support|| Replace beagleboard with Beagleboard XM - decision || 2|| Done || Bruce|| alex|| Basic Yocto hardware support  
|-
|| Distribution / components|| push of all relevant Wind River patchs to Yocto (patch comparison)|| Ensure patches present to packages in WRS are also in Poky|| 1|| 60% done, will be in M3, Sprint A|| Mark|| Mark||
|-
|-
|| Distribution / components|| Security Process|| We need a dedicated person to scan and apply critical security updates to the distro. The MeeGo team already has a similar process with some scripts which may be leveraged. To complete the task, the process should be documented and a first pass over the metadata made to establish the current position on security. Any upgrades needed should be identified and a plan to address them should be in place but doesn't have to be implemented by this point.|| 1|| Done || ScottG|| ktian1|| enhancement
|| Distribution / components|| Security Process|| We need a dedicated person to scan and apply critical security updates to the distro. The MeeGo team already has a similar process with some scripts which may be leveraged. To complete the task, the process should be documented and a first pass over the metadata made to establish the current position on security. Any upgrades needed should be identified and a plan to address them should be in place but doesn't have to be implemented by this point.|| 1|| Done || ScottG|| ktian1|| enhancement
Line 102: Line 96:
{|border="1"
{|border="1"
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''
|-
|| Distribution / components|| Zypper/RPM|| Integration based on design from Sprint B|| 1|| will be M3, Sprint C || Mark/Qing|| sgw|| Functionality
|-
|-
|| Distribution / components|| Distro Audit: Upgrades Completed (Phase 1)|| Update to new versions as per the agreed plan for M2 from Sprint A|| 1|| Done || Saul|| rpurdie|| Continual Maintenance
|| Distribution / components|| Distro Audit: Upgrades Completed (Phase 1)|| Update to new versions as per the agreed plan for M2 from Sprint A|| 1|| Done || Saul|| rpurdie|| Continual Maintenance
Line 110: Line 102:
|-
|-
|| Poky Features || enable KVM with qemu|| today all new Intel processors support VT, which are enabled on most desktop machines which are most frequently used build machine. with VT support, x86/x86-64 qemu target runs faster which is a good thing for emulation environment. This may require some qemu option tweaks and also poky-qemu script enhancement. || 2|| Done || Saul / Edwin|| ktian1|| Enhancement
|| Poky Features || enable KVM with qemu|| today all new Intel processors support VT, which are enabled on most desktop machines which are most frequently used build machine. with VT support, x86/x86-64 qemu target runs faster which is a good thing for emulation environment. This may require some qemu option tweaks and also poky-qemu script enhancement. || 2|| Done || Saul / Edwin|| ktian1|| Enhancement
|-
|| Poky Features || Performance Enhancement Completed ||  Initial changes to reduce disk space || 1|| Will be M3, Sprint A || Saul / Qing, Dongxiao || rpurdie|| Enhancement
|-
|| Distribution / components|| User specified qemu config support|| We'll provide user an edit box which allows advanced qemu user to specify arbitrary qemu configuration to meet their needs, which the poky-qemu scrip will just append the config list towards the end of the list of parameters to bring up qemu,  it also expect the poky-qemu script to do some basic sanity check on the user specifications to catch the obvious mistake || 2|| Work done, will be M3, Sprint A || Saul / criping || criping|| enhancement
|-
|| Documentation Features|| Package report system|| finish major feature development and internal review [setup a package report system in an internal machine. We need push it publicly available. The basic features like search and report have been there. But there're still some enhancements in plan, to make it a fit place to feel Yocto metadata comfortably]|| 2|| Moves to Jon, will be M3, Sprint B || KevinT / Lei || ktian1|| enhancement
|-
|| Tool Development and SDK Features|| SDK Version Control support in SDK generator installer|| If we can expect that yocto SDK has lots of release in the future, we might need to consider SDK version control. Currently, if we un-tar the sdk, it will override the older version. It's not good for app developers since they might need the old version to do something. And also, maybe a finer installer than untar is preferred. Installer will tied to certain SDK version and the installation will go under /opt/poky-versionNo.|| 1|| Versioning is in, some issues with naming, will be M3, Sprint A || Jessica|| criping|| Enhancement-expect planning process by Jessica to handle this task.
|-
|-
|| Kernel || New kernel recipes || dev, -devel, -custom || 3 || Done || Bruce || dvhart ||
|| Kernel || New kernel recipes || dev, -devel, -custom || 3 || Done || Bruce || dvhart ||
Line 123: Line 107:
|| Swabber || Documentation for swabber || || 1 || Done || Alex ||  ||
|| Swabber || Documentation for swabber || || 1 || Done || Alex ||  ||
|-
|-
|| CCB || Defect triage process in public documented and implemented || || 1 || Triage process is documented, out for review. Done || Saul ||  ||
|| CCB || Defect triage process in public documented and implemented || || 1 || Done. Triage process is documented, out for review. || Saul ||  ||
|}
|}


Line 132: Line 116:
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''
|-
|-
|| Kernel || Initial meta-rt layer || PREEMPT_RT kernel and related test-cases and benchmarks || 2 || on track || Darren || dvhart || slipped out from M2
|| Kernel || Initial meta-rt layer || PREEMPT_RT kernel and related test-cases and benchmarks || 2 || Done || Darren || dvhart || slipped out from M2
|-
|-
|| Poky Features || Fetcher Overhaul Phase 1 - SRC_REV enhancement||
|| Poky Features || Fetcher Overhaul Phase 1 - SRC_REV enhancement||
Line 138: Line 122:
* e) Break SRCREVINACTION deadlock. To do this, we need to start using a keyword for automatically increasing SRCREV, e.g. SRCREV = "AUTOINC". The actual revision can be injected into PV using SRCPV.  If we do this there should no longer be a need of the deadlock;  
* e) Break SRCREVINACTION deadlock. To do this, we need to start using a keyword for automatically increasing SRCREV, e.g. SRCREV = "AUTOINC". The actual revision can be injected into PV using SRCPV.  If we do this there should no longer be a need of the deadlock;  
* k) Ensure that we only set __BB_DONT_CACHE when SRCREV = "AUTOREV". This may need a new method call for fetchers to tell whether they're "floating" or locked down.
* k) Ensure that we only set __BB_DONT_CACHE when SRCREV = "AUTOREV". This may need a new method call for fetchers to tell whether they're "floating" or locked down.
|| 1|| on track || Saul / Ke, RP|| rpurdie|| Enhancement, slipped out from M2
|| 1|| Done  || Saul / Ke, RP|| rpurdie|| Enhancement, slipped out from M2
|-
|-
|| Distribution / components|| Distro Audit Upgrades Planned (Phase 2)|| Complete plan for package upgrades in M2|| 1|| on track || Saul|| || Continual Maintenance
|| Distribution / components|| Distro Audit Upgrades Planned (Phase 2)|| Complete plan for package upgrades in M2|| 1|| Done || Saul|| || Continual Maintenance
|-
|| Distribution / components|| MACHINE or Recipe specific sysroots|| Each machine should have its own sysroot. We'll probably have to split do_populate_sysroot into a two step process, creation of the package and than installtion of the package, which the installation of the package being made machine specific (put ${MACHINE} into ${STAMP} and bitbake should do that). Also allowing this to work per recipe would be desireable|| 1|| in progress || Saul / Dongxiao || rpurdie|| Hygiene
|-
|| Distribution / components|| Toolchain Bootstrap Process|| The toolchain as it bootstraps overwrites files like libc.so and libgcc.so in the sysroot directory which causes issues if you just try and rebuild part of the toolchain. Each step of the bootstrap process should use a separate sysroot. Once this is once, sstate file overwriting detection can be added and enabled. || 1|| in progress || Saul / Dexuan || rpurdie|| Hygiene
|-
|-
|| Poky Features || Pseudo Performance || Implement the changes to bitbake based on pseudo's enable/disable switch|| 1|| done || Saul / Qing, Dongxiao || rpurdie|| Enhancement, slipped from M2 due to risk and not having Pseudo's change yet.
|| Poky Features || Pseudo Performance || Implement the changes to bitbake based on pseudo's enable/disable switch|| 1|| done || Saul / Qing, Dongxiao || rpurdie|| Enhancement, slipped from M2 due to risk and not having Pseudo's change yet.
|-
|| || Multilib Support|| || 1|| moves to M3, Sprint D || Richard|| ||
|-
|| Validation|| Alpha testing complete|| 4-5 internal developers unfamiliar with Yocto Project try to do a build and report on the experience and issues encountered|| 1|| moves to M3, Sprint B || PM|| davest||
|-
|-
|| Tool Development and SDK Features|| Fix the issue user target sysroot is owned by root || The ADT installer will use pseudo to extract user target sysroot which ended up owned by root, this need to be fixed || 1|| done || Jessica|| jzhang|| Cleanup  
|| Tool Development and SDK Features|| Fix the issue user target sysroot is owned by root || The ADT installer will use pseudo to extract user target sysroot which ended up owned by root, this need to be fixed || 1|| done || Jessica|| jzhang|| Cleanup  
|-
|-
|| Tool Development and SDK Features|| Eclipse poky tree interfacing (metadata file editor)|| Provide a metadata file editor with some syntax checking and keywords highlight capabilities|| 2|| moves to M3, Sprint B || Jessica|| jzhang|| Enhancement
|| Tool Development and SDK Features|| Eclipse poky tree interfacing (metadata file editor)|| Provide a metadata file editor with some syntax checking and keywords highlight capabilities|| 2|| Done  || Jessica|| jzhang|| Enhancement
|-
|-
|| Tool Development and SDK Features|| IDE Project templates|| Templates for various project types: Clutter GUI, Gtk+ GUI, to help developers get started quickly || 2|| Done || Jessica|| josh|| Enhancement
|| Tool Development and SDK Features|| IDE Project templates|| Templates for various project types: Clutter GUI, Gtk+ GUI, to help developers get started quickly || 2|| Done || Jessica|| josh|| Enhancement
Line 160: Line 136:
|| Tool Development and SDK Features|| push TCF/RSE patches upstream|| work with community to finish up our TCF terminal service, TCF/RSE integration remaining patches taken by upstream. Blocking issues including Eclipse Bug #327865 || 1|| Done || Jessica|| jzhang|| Enhancement
|| Tool Development and SDK Features|| push TCF/RSE patches upstream|| work with community to finish up our TCF terminal service, TCF/RSE integration remaining patches taken by upstream. Blocking issues including Eclipse Bug #327865 || 1|| Done || Jessica|| jzhang|| Enhancement
|-
|-
|| Documentation|| ADT Reference Guide || Done. Outline complete|| High|| WIP || Scott Rifenbark|| 3-4 Weeks|| Documentation
|| Pseudo || Pseudo enhancement to enable on/off switch || || 1 || done || Mark || ||
|-
|-
|| Poky Features || libtool sysroot option|| libtool 2.4 has a sysroot option. We should try and use it, see how it works and whether we can ditch some of our libtool hacks. || 1|| on track, he is piggybacking on work that Khem Raj did on OE, push to M3SA  || Saul / ScottG || rpurdie|| Enhancement
|| Pseudo || Bitbake enhancement for pseudo on/off switch || || 1 || done || Richard || ||
|-
|-
|| Distribution / components|| perl upgrade|| perl is the most cross un-friendly recipe pending upgrade. || 2|| Slipping due to Linaro layer, moves to end of Sprint E || Nitin|| Nitin Kamble|| enhancement
|| bugzilla || Complete restructure of bugzilla categories || || 1 || done || Saul || ||
|-
|-
|| Kernel || Tracing: trace-cmd python binding cleanup || || 3 || on track || Darren || dvhart ||
|| Poky Features || Image creator ground work || Nomenclature determined, existing gui's bug fixed and backend work implemented || 1 || Done || Joshua || ||
|-
|-
|| Kernel || Tracing: KernelShark, tuna, oscillosope recipes || || 3 || on track || Tom || dvhart ||
|| Kernel || Tracing: Initial SystemTap recipe || Works on x86 || 3 || Done || Tom || dvhart ||
|-
|-
|| Pseudo || Pseudo enhancement to enable on/off switch || || 1 || done || Mark || ||
|| Distribution / components|| Distro Audit: Package Description/Summary completed|| Ensure DESCRIPTION/SUMMARY fields are all audited|| 2|| Done || Mark|| Mark|| Hygiene, was M2, Sprint B but missed window
|-
|-
|| Pseudo || Bitbake enhancement for pseudo on/off switch || || 1 || done || Richard || ||
|| Distribution / components|| Zypper/RPM|| Small write-up of the problems we're having w/ Zypper and what we plan to do. (i.e. create a roadmap/design)  - Includes rootfs generation  - Package uprev/install/removal || 1 || Done || Mark/Qing || || was M2, Sprint B
|-
|-
|| Swabber || Complete review of swabber outputs || || 1 || on track || Alex || ||
|| Distribution / components|| Distro Audit: Licence Checksums|| Make the licence checksums fatal if not present || 1|| Done || Saul|| rpurdie|| Hygiene, was M2, Sprint C
|-
|-
|| bugzilla || Complete restructure of bugzilla categories || || 1 || done || Saul || ||
|| Distribution / components|| push of all relevant Wind River patchs to Yocto (patch comparison)|| Ensure patches present to packages in WRS are also in Poky|| 1|| Done || Mark|| Mark|| was M2, Sprint C
|-
|-
|| Poky Features || Image creator ground work || Nomenclature determined, existing gui's bug fixed and backend work implemented || 1 || on track || Joshua || ||
|| Poky Features || Performance Enhancement Completed || Initial changes to reduce disk space (sstate-build-*) || 1|| Done || Saul / Qing, Dongxiao || rpurdie|| Enhancement, was M2, Sprint E
|-
|-
|| Kernel || Tracing: Initial SystemTap recipe || || 3 || on track || Tom || dvhart ||
|| Distribution / components|| User specified qemu config support|| We'll provide user an edit box which allows advanced qemu user to specify arbitrary qemu configuration to meet their needs, which the poky-qemu scrip will just append the config list towards the end of the list of parameters to bring up qemu,  it also expect the poky-qemu script to do some basic sanity check on the user specifications to catch the obvious mistake || 2|| Done || Saul / criping || criping|| enhancement, was M2, Sprint E
|-
|-
|| Distribution / components|| Distro Audit: Package Description/Summary completed|| Ensure DESCRIPTION/SUMMARY fields are all audited|| 2|| unknown || Mark|| Mark|| Hygiene, was M2, Sprint B but missed window
|| Tool Development and SDK Features|| SDK Version Control support in SDK generator installer|| If we can expect that yocto SDK has lots of release in the future, we might need to consider SDK version control. Currently, if we un-tar the sdk, it will override the older version. It's not good for app developers since they might need the old version to do something. And also, maybe a finer installer than untar is preferred. Installer will tied to certain SDK version and the installation will go under /opt/poky-versionNo.|| 1|| Done || Jessica|| criping|| Enhancement-expect planning process by Jessica to handle this task.  Was M2, Sprint E.
|-
|| Distribution / components|| Zypper/RPM|| Small write-up of the problems we're having w/ Zypper and what we plan to do. (i.e. create a roadmap/design)  - Includes rootfs generation  - Package uprev/install/removal || 1 || work is done, needs to be posted || Mark/Qing || || was M2, Sprint B
|}
|}


Line 192: Line 166:
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''
|-
|-
|| Distribution / components|| Distro Audit Documentation Output|| Audit package documentation output || 2|| Review|| Saul / ScottG || rpurdie|| Hygiene
|| Poky Features || Bitbake multi-threaded parsing|| Bitbake recipe parsing is currently single threaded. I want to make this multithreaded as the speedup would be nice. If I can only take a single task for myself for 1.0, I'm nominating this one as I enjoy this kind of thing and I have ideas on how to do it. || 1|| Done || Richard|| rpurdie|| Enhancement
|-
|-
|| Poky Features || Bitbake multi-threaded parsing|| Bitbake recipe parsing is currently single threaded. I want to make this multithreaded as the speedup would be nice. If I can only take a single task for myself for 1.0, I'm nominating this one as I enjoy this kind of thing and I have ideas on how to do it. || 1|| Review|| Richard|| rpurdie|| Enhancement
|| Distribution / components|| Lock in Kernel/Toolchain version|| Locked in 2.6.37 and gcc 4.5.1. Pending decision to move to 4.5.2 and Linaro || || Done || || Richard|| ||  
|-
|-
|| Distribution / components|| Lock in Kernel/Toolchain version|| || || || Richard|| ||  
|| Distribution / components|| License Update|| For each of the licences we support, I'd really like to have a licences directory with a copy of that license contained within. When it comes to deciding what a given LICENSE field means, this would be the reference. It also means we can include the licences a given image includes with the image. This continues to make our license handling world class and ahead of the field. || 2|| Done || Beth|| rpurdie|| Hygiene
|-
|-
|| Distribution / components|| License Update|| For each of the licences we support, I'd really like to have a licences directory with a copy of that license contained within. When it comes to deciding what a given LICENSE field means, this would be the reference. It also means we can include the licences a given image includes with the image. This continues to make our license handling world class and ahead of the field. || 2|| Review|| Beth|| rpurdie|| Hygiene
|| Tool Development and SDK Features|| Qemu configuration change|| Provice edit box for advanced user to specify qemu configurations|| 2|| Done || Jessica|| criping||  
|-
|-
|| Poky Features || DSO linking changes|| "By the default the gcc linker will automatically link any dependant objects/libraries. ""Inherited"" linkages can cause issues, for example, where a shared object changes its dependencies but a program has come to rely on symbols from an implicitly linked library. Fedora implemented this change in F13, seems like it would be useful to have in Poky too. "|| 2|| Review|| Saul / Nitin || josh|| bug#516
|| Tool Development and SDK Features|| Lock down Eclipse+CDT+TCF version|| Will use Eclipse Halo 3.6 || 1|| Done || Jessica|| ||  
|-
|-
|| Distribution / components|| rootless X|| rootless x server has better security than x server launched by root. MeeGo already enable this feature. it would be nice for Yocto to also enable it. || 2|| Review|| Saul / Ke || yuke|| enhancement
|| Demo|| Finalize on demo plans for v1.0 launch || || 1|| Done || Dave || ||  
|-
|-
|| Poky Features || Fetcher Overhaul Phase 2 - API reorg||
|| Release || Release plans for v1.0 launch || Fill out the M4 plan with the necessary release activities and timings || 1|| Done || Beth || ||
* f) Add a generic unpack funciton to __init__.py based on the unpack task in Poky ;
|-
* g) Split go() methods into the following steps: i) download() - do whatever transfer is necessary to get the sources locally  ii) build_mirror_data() - generate any data that would be needed to construct a source mirror iii) unpack() - takes a directory as an argument of where to place extracted sources;
|| Poky Features || Basic image creator GUI || Functional UI missing some Advanced features || 1 || In replan || Joshua || ||  
The existing go() methods should be replaced with a set of calls to  the above sections of functionality as appropriate in the individual  fetchers. Some of these categories of function make no sense in  certain fetchers, in which case they shouldn't need to implement  them. Functions are only executed if the method is present.
|-
* h) Change Poky's unpack to call an unpack method in the fetchers.
|| Tool Development and SDK Features|| Yocto Installer for SDK Generator Installation functions support||Detailed feature request can be found at: http://bugzilla.pokylinux.org/show_bug.cgi?id=589|| 1|| Done || Jessica|| rpurdie|| Enhancement
* i) Change Poky's fetch task to call a "download" method in the fetcher instead of go().
|| 1|| slipped out from M2 || Saul / Ke, RP|| rpurdie|| Enhancement
|-
|-
|| Tool Development and SDK Features|| Qemu configuration change|| Provice edit box for advanced user to specify qemu configurations|| 2|| Accept|| Jessica|| criping||  
|| Kernel || Tracing: trace-cmd python binding cleanup || || 3 || Done || Darren || dvhart ||
|}
 
=== Sprint C (closes Jan 14, 11:59pm PDT -- pull request sent, initially reviewed) ===
 
{|border="1"
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''
|-
|-
|| Tool Development and SDK Features|| Eclipse Poky tree interfacing (bitbake commands support)|| Support user run bitbake commands within CDT console|| 2|| Review|| Jessica|| jzhang|| Enhancement
|| Poky Features || kernel development layer|| The (correct) poky behaviour of building known revisions coupled with the fetcher requiring a BSP branch to already be present means that local modifications (and kernel source tree) are required for kernel development. I already have a layer that overrides/modifies the behaviour when added to the bblayers.conf and configured into an environment. This seems useful for more people to use. || 2|| Done || Bruce|| bruceashfield|| Enhancement, was M2, Sprint C
|-
|-
|| Tool Development and SDK Features|| Lock down Eclipse+CDT+TCF version|| || 1|| Accept|| Jessica|| ||  
|| Distribution / components|| Zypper/RPM|| RPM Up-rev / Zypper Up-rev  [lets get to the latest versions]|| 1|| Done || Mark/Qing|| || was M2, Sprint C
|-
|-
|| Tool Development and SDK Features|| Eclipse poky tree interfacing (git support)|| Use Eclipse git capability to install poky tree from git repo and able to interact with git repo at file level within Poky tree || 2|| Review|| Jessica|| jzhang|| Enhancement
|| Supported Targets|| Intel Platform Support|| JasperForest|| 2|| Basic support in place; DPDK evaluation in process, overall BSP plan still TBD || Tom|| davest|| Basic ECG support (Moved from Sprint A)
|-
|-
|| Tool Development and SDK Features|| Eclipse poky tree interfacing (git support)|| Use Eclipse git capability to install poky tree from git repo and able to interact with git repo at file level within Poky tree || 2|| Done || Jessica|| jzhang|| Enhancement


|| Documentation|| Migration chapter in the Poky Reference Manual|| This chapter would cover the four identified use-cases for migrating up to the most recent version of Yocto Project.  Additionally, it would cover migration scenarios from other development systems.  The chapter does not yet exist.  The chapter has not been scoped outside of having a meeting that identified four use-cases that did not include migration from a development system outside of Yocto Project.  It will take some more scoping time to cover those areas (a day or two).  Again, I have no idea of the length.  See earlier entries for standard industry writing estimates for software documentation|| Medium|| Not Started|| Scott Rifenbark|| 3-4 Weeks|| Documentation
|-
|-
|| Supported Targets|| Intel Platform Support|| JasperForest|| 2|| Accept|| Tom|| davest|| Basic ECG support (Moved from Sprint A)
|| Poky Features || Poky Image Creator|| A standalone application you can run which asks you to select a distro and machine, then presents a list of packages you can select. Once the selection is made, it goes off and bakes you an image which is then presented to you. Implementation wise, it should use the sstate packages, be a bitbake UI and use the usual poky bbclass files to do the image construction behind the scenes. || 1|| Re-plan || Joshua|| rpurdie|| Enhancement
|-
|-
|| Demo|| Finalize on demo plans for v1.0 launch || || 1|| Accept|| Dave || ||  
|| Distribution / components|| LSB Sanity|| execute LSB Test and improve passing rate and document failures with clear understanding|| 2|| Done || MarkH/Saul|| sgw|| Hygiene
|-
|-
|| Release || Release plans for v1.0 launch || Fill out the M4 plan with the necessary release activities and timings || 1|| initial documentation in RFC process || Beth || ||  
|| Tool Development and SDK Features|| Image creator integration with Eclipse || || 2|| replan|| Jessica|| jzhang|| Enhancement
|-
|-
|| Poky Features || Basic image creator GUI || Functional UI missing some Advanced features || 1 || accepted || Joshua || ||
|| Kernel || Tracing: perf trace marker support || This is from feedback to the new trace command. Ingo appears to have this nearly complete already. || 3 || Done || Darren || dvhart ||
|-
|-
|| Tool Development and SDK Features|| Yocto Installer for SDK Generator Installation functions support||Detailed feature request can be found at: http://bugzilla.pokylinux.org/show_bug.cgi?id=589|| 1|| Initial implementation is done. Under review and refinement|| Jessica|| rpurdie|| Enhancement
|| Cleanup || bitbake user experience error handling validation completed || || 2 || Done || Richard ||  ||
|-
|| Cleanup || variable scrub - ensure all metadata variables are documented || Script with a histogram of variable use done, identified 50 variables to document; Add task for actual documentation update is low on the list || 2 || Done || Scott/Darren ||  ||
|-
|| Kernel || Tracing: package kernelshark || || 3 || Done || Darren || dvhart ||
|}
|}


=== Sprint C (closes Jan 14, 11:59pm PDT -- pull request sent, initially reviewed) ===
=== Sprint D (closes Jan 21, 11:59pm PDT -- pull request sent, initially reviewed) ===


{|border="1"
{|border="1"
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''
|-
|-
|| Poky Features || Poky Image Creator|| A standalone application you can run which asks you to select a distro and machine, then presents a list of packages you can select. Once the selection is made, it goes off and bakes you an image which is then presented to you. Implementation wise, it should use the sstate packages, be a bitbake UI and use the usual poky bbclass files to do the image construction behind the scenes. || 1|| Accepted || Joshua|| rpurdie|| Enhancement
|| Poky Features || Fetcher Overhaul Phase 2 - API reorg||
* f) Add a generic unpack funciton to __init__.py based on the unpack task in Poky ;
* g) Split go() methods into the following steps: i) download() - do whatever transfer is necessary to get the sources locally  ii) build_mirror_data() - generate any data that would be needed to construct a source mirror  iii) unpack() - takes a directory as an argument of where to place extracted sources;
The existing go() methods should be replaced with a set of calls to  the above sections of functionality as appropriate in the individual  fetchers. Some of these categories of function make no sense in  certain fetchers, in which case they shouldn't need to implement  them. Functions are only executed if the method is present.
* h) Change Poky's unpack to call an unpack method in the fetchers.
* i) Change Poky's fetch task to call a "download" method in the fetcher instead of go().
|| 1|| Done || Saul / Ke, RP|| rpurdie|| Enhancement
|-
|-
|| Poky Features || Fetcher Overhaul Phase 3 - git enhancement||
|| Poky Features || Fetcher Overhaul Phase 3 - git enhancement||
Line 247: Line 235:
* m) Add multiple branch/srcrev support for git fetcher. These would be of the form: git://somelocation/somerepo.git;name=ref1;branch=foo;name=ref2;branch=bar    SRCREV_ref1 = "hash1"    SRCREV_ref2 = "hash2"  which would ensure both hash1 and hash2 were in the final repo.  
* m) Add multiple branch/srcrev support for git fetcher. These would be of the form: git://somelocation/somerepo.git;name=ref1;branch=foo;name=ref2;branch=bar    SRCREV_ref1 = "hash1"    SRCREV_ref2 = "hash2"  which would ensure both hash1 and hash2 were in the final repo.  
* n) Change git fetcher to default to git protocol instead of rsync
* n) Change git fetcher to default to git protocol instead of rsync
|| 1|| slipped out from M2 || Saul / Ke, RP|| rpurdie|| Enhancement
|| 1|| Done || Saul / Ke, RP|| rpurdie|| Enhancement
 
|-
|-
|| Validation|| Boottime/Performance Analysis|| Compare Yocto Project performance to other projects such as MeeGo|| 1|| Review|| Tom|| davest|| project commitment
|| Poky Features || DSO linking changes|| "By the default the gcc linker will automatically link any dependant objects/libraries. ""Inherited"" linkages can cause issues, for example, where a shared object changes its dependencies but a program has come to rely on symbols from an implicitly linked library. Fedora implemented this change in F13, seems like it would be useful to have in Poky too. "|| 2|| Done || Saul / Nitin || josh|| bug#516
|-
|-
|| Distribution / components|| LSB Sanity|| execute LSB Test and improve passing rate and document failures with clear understanding|| 2|| Review|| MarkH/Saul|| sgw|| Hygiene
|| Poky Features || libtool sysroot option|| libtool 2.4 has a sysroot option. We should try and use it, see how it works and whether we can ditch some of our libtool hacks. || 1|| Done  || Saul / ScottG || rpurdie|| Enhancement
|-
|-
|| Distribution / components|| Review & Fix Standards Tests|| Review the results from LTP, POSIX and asses the result, fix as appropriate and clearly document failures.|| 2|| Review|| Saul|| sgw|| Hygiene
|| Distribution / components|| MACHINE or Recipe specific sysroots|| Each machine should have its own sysroot. We'll probably have to split do_populate_sysroot into a two step process, creation of the package and than installtion of the package, which the installation of the package being made machine specific (put ${MACHINE} into ${STAMP} and bitbake should do that). Also allowing this to work per recipe would be desireable|| 1|| Done|| Saul / Dongxiao || rpurdie|| Hygiene
|-
|-
|| Tool Development and SDK Features|| (Bitbake commander)Poky tree interfacing integration|| Integrate all the features to support poky tree interfacing withing Eclipse IDE: poky tree install from git repo, edit metadata file using editor, commit back changes to git repo, and run bitbake commands withing CDT console|| 2|| Review|| Jessica|| jzhang|| Enhancement
|| Distribution / components|| Toolchain Bootstrap Process|| The toolchain as it bootstraps overwrites files like libc.so and libgcc.so in the sysroot directory which causes issues if you just try and rebuild part of the toolchain. Each step of the bootstrap process should use a separate sysroot. Once this is once, sstate file overwriting detection can be added and enabled. || 1|| Done || Saul / Dexuan || rpurdie|| Hygiene
|-
|-
|| Kernel || Tracing: perf trace marger support || This is from feedback to the new trace command. Ingo appears to have this nearly complete already. || 3 || || Darren || dvhart ||
|| Distribution / components||Add headers and libraries to qemu images ||Since we'll be using qemu images as target sysroot, need to create a set of qemu images for minimal, sato, LSB that contains target header and libraries.|| 2|| Done || Saul ||jzhang|| Enhancement
|-
|-
|| Kernel || Tracing: perf trace scripting support || || 3 || || Tom || dvhart ||
|| Distribution / components|| push of all relevant Wind River patchs to Yocto (patch comparison)|| Update any additional patches needed since M2.|| 1|| Done || Mark|| Mark||
|}
 
=== Sprint E (closes Jan 28, 11:59pm PDT -- pull request sent, initially reviewed) ===
 
{|border="1"
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''
|-
|-
|| Cleanup || bitbake user experience error handling validation completed || || 2 || || Richard || ||
|| Distribution / components|| perl upgrade|| perl is the most cross un-friendly recipe pending upgrade. || 2|| Done || Nitin|| Nitin Kamble|| enhancement
|-
|-
|| Cleanup || variable scrub - ensure all metadata variables are documented || || 2 || || Scott/Darren || ||
|| Kernel || Final linux-yocto_git.bb || With 2.6.37 kernel || 1 || Done || Bruce || dvhart ||
|}
|}


=== Sprint D (closes Jan 21, 11:59pm PDT -- pull request sent, initially reviewed) ===
=== Sprint F (closes Feb 03 (THURSDAY), 11:59pm PDT -- pull request sent, initially reviewed) :: NOTE: China New Year Holiday ===


{|border="1"
{|border="1"
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''
|-
|-
|| Documentation Features|| Package report system|| move to public server [setup a package report system in an internal machine. We need push it publicly available. The basic features like search and report have been there. But there're still some enhancements in plan, to make it a fit place to feel Yocto metadata comfortably]|| 2|| Review|| KevinT|| ktian1|| enhancement
|| Documentation|| ADT Reference Guide Draft out for review || Outline complete|| High|| Done || Scott Rifenbark|| jzhang|| Documentation
|-
|| Distribution / components||Add headers and libraries to qemu images ||Since we'll be using qemu images as target sysroot, need to create a set of qemu images for minimal, sato, LSB that contains target header and libraries.|| 2|| Review|| Saul ||jzhang|| Enhancement
|-
|| Distribution / components|| push of all relevant Wind River patchs to Yocto (patch comparison)|| Update any additional patches needed since M2.|| 1|| Review|| Mark|| Mark||
|-
|| Distribution / components|| mklibs|| mklibs is a tool to optimize size of [e]glibc for a perticular root file system image. It is useful to save disk space on small devices. || 2|| Review|| Saul|| Nitin Kamble|| enhancement
|-
|| Distribution / components|| performance indicators|| define some indicators (boot time, footprint, build time, power, component benchmarks, etc.) and then collect them for tracking purpose. The result could be posted on the wiki site, and the initial indicators can be easy ones which can be easily retrieved from autobuilder or weekly qa report). This way we have a clear track about the healthy of the Yocto project, and also identify weak areas. We can include qemu targets and several representational boards as the targets. || 2|| Review|| Beth/Jiajun|| ktian1|| enhancement
|-
|-
|| || || || || || || ||
|}
|}


=== Sprint E (closes Jan 28, 11:59pm PDT -- pull request sent, initially reviewed) ===
== M4 (Feb 07 to Apr 15 -- Stabilize Complete Mar 18, Release Complete Apr 01, Contingency to Apr 15) ==
 
This sprint is the [[Yocto Project v. 1.0 Release Cycle]].
 
During this sprint, we will track the [[Yocto Project v1.0 Release Criteria]].


=== Stabilization Phase Features and Activities ===
<font color="red">Red items are must-do prior to Feature Complete.
{|border="1"
{|border="1"
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''
|-
|-
|| Supported Targets|| Intel Platform Support|| Sandybridge|| 2|| Accept|| Tom|| davest|| Basic ECG support
|| <font color="red">Fetcher|| Additional || All planned enhancements are complete, but this is a placeholder for additional fetcher improvements being worked on prior to freeze. || 1 || Done || RP|| RP ||
|-
|-
|| Tool Development and SDK Features|| SDK user workshop|| Have some developers sit down and use our tools to develop demo software for Yocto. || 2|| Review|| Jessica|| josh|| Enhancement
|| <font color="red">Distribution / components|| performance indicators|| define some indicators (boot time, footprint, build time, power, component benchmarks, etc.) and then collect them for tracking purpose. The result could be posted on the wiki site, and the initial indicators can be easy ones which can be easily retrieved from autobuilder or weekly qa report). This way we have a clear track about the healthy of the Yocto project, and also identify weak areas. We can include qemu targets and several representational boards as the targets. || 2|| Done || Beth/Jiajun|| ktian1|| enhancement
|-
|-
|| Documentation|| SDK Reference Guide|| This would be a guide for developers using the SDK.  Ideally, the manual would be a sub-manual that would be referenced and architected into the Yocto Project Development Guide.  The manual has not been scoped and would take a week to scope.  I have no idea of the length.  Industry writing standards dictate that three to four pages of a manual can be developed per day.  So, a 30 to 40 page manual would take a couple of weeks.  However, these are just standards that are use for general estimates and assume dedicated, non-interrupted time.|| High|| Not Started|| Scott Rifenbark|| 3-4 Weeks|| Documentation
|| Swabber || Review || Complete review of swabber outputs || 1 || Done || Alex || ||
|-
|-
|| Kernel || Final linux-yocto_git.bb || With 2.6.37 kernel || 1 || || Bruce || dvhart ||
|| Poky Features || Performance Enhancement || reduce disk space (hardlink) || 1 || Done || Saul / Qing, Dongxiao || rpurdie || Enhancement
|-
|-
|| Kernel || Final meta-linaro layer || || || || Darren || dvhart ||
|| Kernel || Final meta-linaro layer || || 1 || Done || || Darren || dvhart ||
|-
|-
|| Kernel || Final meta-rt layer || || || || Darren || dvhart ||
|| Kernel || Final meta-linaro layer documentation needs to be merged into master || || 1 || Done || || Darren || dvhart ||
|-
|-
|| Kernel || Sandy Bridge || || 1 || || Tom || dvhart ||
|| Kernel || Sandy Bridge || || 1 || Done || Tom || dvhart ||
|}
|-
 
|| Validation|| Boottime/Performance Analysis|| Compare Yocto Project performance to other projects such as MeeGo|| 1|| Initial report on where we are by EO March || Darren|| davest|| project commitment
=== Sprint F (closes Feb 03 (THURSDAY), 11:59pm PDT -- pull request sent, initially reviewed) :: NOTE: China New Year Holiday ===
|-
 
|| Validation|| Alpha testing complete|| 4-5 developers unfamiliar with Yocto Project try to do a build and report on the experience and issues encountered|| 1|| Done  || Julie|| davest||
{|border="1"
|-
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''
|| Distribution / components|| Distro Audit Documentation Output|| Audit package documentation output; email sent (status tracking will be done in 1.1) || 2|| Done || Saul / ScottG || rpurdie|| Hygiene
|-
|| Documentation Features|| Package report system|| move to public server [setup a package report system in an internal machine. We need push it publicly available. The basic features like search and report have been there. But there're still some enhancements in plan, to make it a fit place to feel Yocto metadata comfortably]|| 2|| Done || Saul (Jon) || ktian1|| enhancement
|-
|| Distribution / components|| mklibs|| mklibs is a tool to optimize size of [e]glibc for a perticular root file system image. It is useful to save disk space on small devices. || 2|| Done || Saul|| Nitin Kamble|| enhancement
|-
|| BSP || 2.6.37 Crown Bay Support || || 2 || Done || Tom || dvhart ||
|-
|| BSP || 2.6.37 Emenlow Support || || 2 || Done || Tom || dvhart ||
|-
|| Supported Targets|| Intel Platform Support|| Sandybridge|| 2|| Done || Tom|| davest|| Basic ECG support
|-
|| Distribution / components|| Review & Fix Standards Tests|| Review the results from LTP, POSIX and assess the result, fix as appropriate and clearly document failures.|| 2|| Done || Saul/Kevin || sgw|| Hygiene
|-
|-
|| || || || || || || ||  
|| Distribution / components|| rootless X|| rootless x server has better security than x server launched by root. MeeGo already enable this feature. it would be nice for Yocto to also enable it. || 2|| Done || Saul / Ke || yuke|| enhancement
|-
|| BSP || Beagleboard XM Support || || 3 || Done (our part). Darren to ask the community to finish it up. || Darren || dvhart ||
|-
|| Debug || Debug file changes || Improvements to debug files to enable better debug || 3 || Done || Mark H || Mark H||
|}
|}


== M4 (Feb 07 to Apr 15 -- Stabilize Complete Mar 18, Release Complete Apr 01, Contingency to Apr 15) ==
=== Documentation Deliverables ===
 
This sprint is the [[Yocto Project v. 1.0 Release Cycle]].
 
 
{|border="1"
{|border="1"
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''
|| '''Group''' || '''Feature Name''' || '''Description''' || '''Priority''' || '''Status''' || '''Owner''' || '''Source''' || '''Comments / Bugzilla Links'''
|-
|-
|| Documentation|| 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, etcScoping would be about two weeks and length would probably be about 40 pagesOverall development time would likely be a month of uniterruped time.|| Medium|| Not Started|| Scott Rifenbark|| 3 Weeks|| Documentation
|| Documentation|| Migration chapter in the Poky Reference Manual|| This chapter would cover the four identified use-cases for migrating up to the most recent version of Yocto Project.  Additionally, it would cover migration scenarios from other development systems.  The chapter does not yet exist.  The chapter has not been scoped outside of having a meeting that identified four use-cases that did not include migration from a development system outside of Yocto ProjectIt will take some more scoping time to cover those areas (a day or two)Again, I have no idea of the length. See earlier entries for standard industry writing estimates for software documentation|| Medium|| Moved to 1.1 || Scott Rifenbark|| 3-4 Weeks|| Documentation
|-
|-
|| || || || || || || ||  
|| Documentation|| ADT Reference Guide finished manual || Outline complete|| High|| Done || Scott Rifenbark|| jzhang|| Documentation
|}
|}



Latest revision as of 16:14, 22 March 2011

v1.0 (release date: Apr 6, 2011)


The detailed milestone map for v1.0 is as below. During the first week of each subsequent milestone past M1 we will have a demonstration of the previous milestone capabilities as well as a planning and design session for the current milestone.

M2 (Nov 08 to Dec 24 -- Dev Complete Dec 10, Stabilize Complete Dec 17, Release Complete Dec 24)

Sprint A (closes Nov 12, 11:59pm PDT -- pull request sent, initially reviewed)

Group Feature Name Description Priority Status Owner Source Comments / Bugzilla Links
Poky Features Kernel interactive targets To support incremental kernel development having the ability to run menuconfig (or xconfig, etc) directly is a common request. We'll need to add this for commercialization anyway. i.e. bitbake -c menuconfig. This fuctionality already exists. 1 Done Richard bruceashfield Enhancement
Distribution / components Distro Audit: Upgrades Planned (Phase 1) Complete plan for package upgrades in M2 1 Done Saul Continual Maintenance
Validation Runtime testing Runtime testing of images as part of the autobuilder 1 Done Jiajun/ScottG rpurdie project commitment
Poky Image Creator Wireframe/Interaction Plans Complete 1 Done Josh
SDK Generator Interaction: Plans Complete 1 Done Jessica
Tracing/Profiling Planning Complete This needs to cover where we're at now, what we're missing and also propose the future enhancements that may be needed. M2 targets getting existing tools integrated and documented. F2f discussion n the future enhancements Done Tom
Swabber. (Still needs to be integrated into weekly build by default) 1 Done Josh
Build/Release Release process documentation Done Beth
Validation Test plan for v1.0 (to address any deficiencies in coverage from v0.9) 1 Done Jiajun

Sprint B (closes Nov 19, 11:59pm PDT -- pull request sent, initially reviewed)

Group Feature Name Description Priority Status Owner Source Comments / Bugzilla Links
Distribution / components Distro Audit: World Packages Audit world packages making sure it all build, making sure all are packages are required 2 Done Saul sgw Hygiene
Tool Development and SDK Features SDK Generator Installer UI Look at different ways of Installer UI (GTK+ and ncurses) seems none of them is the right choice, decide to go with script to implement all the functionalities of installer and later add UI part on top of it 1 Done Jessica jzhang Enhancement
Tool Development and SDK Features Customize sysroot setup Add and test out "--sysroot" config option to cross compiler within Eclipse IDE 1 Done Jessica jzhang Enhancement
Tool Development and SDK Features SDK Generator Installer design revision Close all open questions regarding Yocto SDK Generator Installer function design and come up HLD 1 Done Jessica jzhang Enhancement
Distribution / components kernel version keeping 2.6.34 as a -stable kernel is the best option. I've also got a newer -devel tree that can be made available or made the default. 3 Done Bruce bruceashfield enhancement
assign Yocto Project PM acquire and assign a program manager for Yocto Project Done DaveST
assign Yocto Project Sys Admin Done Saul
Tool Development and SDK Features oprofileUI Fixing various bugs of the oprofileUI to make it workable on big endian host.(i.e. ppc, mips) 2 Done Jessica lianhao.lu Bug #382 / Bug #493
Poky Feature SDK Version Control If we can expect that yocto SDK has lots of release in the future, we might need to consider SDK version control. Currently, every thing installed under /opt/poky which leads to things be overriden, we need to be able to use a scheme like /opt/poky-1.0, /opt/poky-2.0 to distiguish things. 2 Done Josh jzhang Enhancement
Kernel Kernel plan complete Flesh our kernel deliverables and add to Yocto 1.0 schedule Done Darren dvhart

Sprint C (closes Nov 26, 11:59pm PDT -- pull request sent, initially reviewed) :: NOTE: this is US Thanksgiving week

Group Feature Name Description Priority Status Owner Source Comments / Bugzilla Links
Distribution / components Distro Audit: Licence Checksums licence checksums 1 Done Saul rpurdie Hygiene
Poky Features Performance Analysis Completed "I'd like someone to instrument a green release build, see where it spends time (hot/cold parsing time, individual task building time) and then compare this with our 0.9 release build. I'd also like to compare the disk usage between the two. Once we have a blame list we can then set about fixing it. Some things I know will come up: a) pseudo, b) checksums/signature code, c) exec() vs fork for executing tasks, d) task based prebuilds increasing disk usage, e) rpm dependency calculations, f) using rpm vs. ipk but I may be wrong and there may be others. We need numbers. " 1 Done Saul / Qing, Dongxiao rpurdie Enhancement
Poky Features environment variables for kernel builds switching a branch, or adding a configuration feature (and even changing the kernel repo) is often done during development of a BSP. Having some additional variables that are pass the bitbake environment scrub would be useful. i.e. KBRANCH=foo bitbake -c configure linux-yocto. This goes along with the other BSP bootstrapping suggestions. 2 Done Bruce bruceashfield Enhancement
Supported Targets ARM Platform Support Replace beagleboard with Beagleboard XM - decision 2 Done Bruce alex Basic Yocto hardware support
Distribution / components Security Process We need a dedicated person to scan and apply critical security updates to the distro. The MeeGo team already has a similar process with some scripts which may be leveraged. To complete the task, the process should be documented and a first pass over the metadata made to establish the current position on security. Any upgrades needed should be identified and a plan to address them should be in place but doesn't have to be implemented by this point. 1 Done ScottG ktian1 enhancement
Tool Development and SDK Features SDK Generator Installer Opkg repo design Come up a opkg repo design that will mimic the final Yocto package repo layout to be used by SDK Generator Installer to test against 2 Done Jessica jzhang
Tool Development and SDK Features Yocto Installer tar creaion Create a Yocto Installer tar ball which contains Installer script and supported opkg component that will be used for installing other Yocto components 2 Done Jessica jzhang
Documentation Kernel Framework Paper from WR The paper from WR needs to be re-written and then posted somewhere on the Yocto Project site. This will involve examiniation of the text and re-writing and formatting for presentation. Currently it is simply a text document. Completion time assuming uninterrupted time is one week. High Done Scott Rifenbark 1 Week Documentation
Documentation Poky Reference Manual This guide exists in the 0.9 form. The re-write of the text needs to be completed. So far, all the chapters have been rewritten but not re-posted on the site. Only the appendices remain for a text scrub. Time to complete this would be a week of uninterrupted time. Ideally, the manual would be a sub-manual that would be referenced and architected into the Yocto Project Development Guide. Medium Done Scott Rifenbark 1 Week Documentation
Kernel Initial meta-linaro layer meta-linaro layer providing a kernel, tool-chain, and uboot loader. This deliverable is primarily to get the infrastructure in place and have a buildable kernel. Toolchain on best effort basis. Done Darren dvhart Moderate risk of slippage due to holidays.
Kernel Tracing: blktrace and sysprof recipes Done Tom dvhart

Sprint D (closes Dec 3, 11:59pm PDT -- pull request sent, initially reviewed) :: NOTE: week of the F2F planning meeting

Group Feature Name Description Priority Status Owner Source Comments / Bugzilla Links
Kernel Kernel git branching structure revamped 1 Done Bruce dvhart
Kernel Tunnel Creek (Crown Bay) 1 Done Tom dvhart

Sprint E (closes Dec 9 (THURSDAY), 11:59pm PDT -- pull request sent, initially reviewed)

Group Feature Name Description Priority Status Owner Source Comments / Bugzilla Links
Distribution / components Distro Audit: Upgrades Completed (Phase 1) Update to new versions as per the agreed plan for M2 from Sprint A 1 Done Saul rpurdie Continual Maintenance
Distribution / components Distro Audit: Src Checksums Make sure all SRC_URI components have checksums too 1 Done Saul rpurdie Hygiene
Poky Features enable KVM with qemu today all new Intel processors support VT, which are enabled on most desktop machines which are most frequently used build machine. with VT support, x86/x86-64 qemu target runs faster which is a good thing for emulation environment. This may require some qemu option tweaks and also poky-qemu script enhancement. 2 Done Saul / Edwin ktian1 Enhancement
Kernel New kernel recipes dev, -devel, -custom 3 Done Bruce dvhart
Swabber Documentation for swabber 1 Done Alex
CCB Defect triage process in public documented and implemented 1 Done. Triage process is documented, out for review. Saul

M3 (Dec 20 to Feb 08 -- Dev Complete Feb 04, Stabilize Complete Feb 11, Release Complete Feb 18)

Sprint A (closes Dec 24, 11:59pm PDT -- pull request sent, initially reviewed)

Group Feature Name Description Priority Status Owner Source Comments / Bugzilla Links
Kernel Initial meta-rt layer PREEMPT_RT kernel and related test-cases and benchmarks 2 Done Darren dvhart slipped out from M2
Poky Features Fetcher Overhaul Phase 1 - SRC_REV enhancement
  • a) Add code in FetchData::__init__() which will check if the selected fetcher supports srcrev and the automatically call a function to set the src rev value instead of each fetcher doing this.\n
  • e) Break SRCREVINACTION deadlock. To do this, we need to start using a keyword for automatically increasing SRCREV, e.g. SRCREV = "AUTOINC". The actual revision can be injected into PV using SRCPV. If we do this there should no longer be a need of the deadlock;
  • k) Ensure that we only set __BB_DONT_CACHE when SRCREV = "AUTOREV". This may need a new method call for fetchers to tell whether they're "floating" or locked down.
1 Done Saul / Ke, RP rpurdie Enhancement, slipped out from M2
Distribution / components Distro Audit Upgrades Planned (Phase 2) Complete plan for package upgrades in M2 1 Done Saul Continual Maintenance
Poky Features Pseudo Performance Implement the changes to bitbake based on pseudo's enable/disable switch 1 done Saul / Qing, Dongxiao rpurdie Enhancement, slipped from M2 due to risk and not having Pseudo's change yet.
Tool Development and SDK Features Fix the issue user target sysroot is owned by root The ADT installer will use pseudo to extract user target sysroot which ended up owned by root, this need to be fixed 1 done Jessica jzhang Cleanup
Tool Development and SDK Features Eclipse poky tree interfacing (metadata file editor) Provide a metadata file editor with some syntax checking and keywords highlight capabilities 2 Done Jessica jzhang Enhancement
Tool Development and SDK Features IDE Project templates Templates for various project types: Clutter GUI, Gtk+ GUI, to help developers get started quickly 2 Done Jessica josh Enhancement
Tool Development and SDK Features push TCF/RSE patches upstream work with community to finish up our TCF terminal service, TCF/RSE integration remaining patches taken by upstream. Blocking issues including Eclipse Bug #327865 1 Done Jessica jzhang Enhancement
Pseudo Pseudo enhancement to enable on/off switch 1 done Mark
Pseudo Bitbake enhancement for pseudo on/off switch 1 done Richard
bugzilla Complete restructure of bugzilla categories 1 done Saul
Poky Features Image creator ground work Nomenclature determined, existing gui's bug fixed and backend work implemented 1 Done Joshua
Kernel Tracing: Initial SystemTap recipe Works on x86 3 Done Tom dvhart
Distribution / components Distro Audit: Package Description/Summary completed Ensure DESCRIPTION/SUMMARY fields are all audited 2 Done Mark Mark Hygiene, was M2, Sprint B but missed window
Distribution / components Zypper/RPM Small write-up of the problems we're having w/ Zypper and what we plan to do. (i.e. create a roadmap/design) - Includes rootfs generation - Package uprev/install/removal 1 Done Mark/Qing was M2, Sprint B
Distribution / components Distro Audit: Licence Checksums Make the licence checksums fatal if not present 1 Done Saul rpurdie Hygiene, was M2, Sprint C
Distribution / components push of all relevant Wind River patchs to Yocto (patch comparison) Ensure patches present to packages in WRS are also in Poky 1 Done Mark Mark was M2, Sprint C
Poky Features Performance Enhancement Completed Initial changes to reduce disk space (sstate-build-*) 1 Done Saul / Qing, Dongxiao rpurdie Enhancement, was M2, Sprint E
Distribution / components User specified qemu config support We'll provide user an edit box which allows advanced qemu user to specify arbitrary qemu configuration to meet their needs, which the poky-qemu scrip will just append the config list towards the end of the list of parameters to bring up qemu, it also expect the poky-qemu script to do some basic sanity check on the user specifications to catch the obvious mistake 2 Done Saul / criping criping enhancement, was M2, Sprint E
Tool Development and SDK Features SDK Version Control support in SDK generator installer If we can expect that yocto SDK has lots of release in the future, we might need to consider SDK version control. Currently, if we un-tar the sdk, it will override the older version. It's not good for app developers since they might need the old version to do something. And also, maybe a finer installer than untar is preferred. Installer will tied to certain SDK version and the installation will go under /opt/poky-versionNo. 1 Done Jessica criping Enhancement-expect planning process by Jessica to handle this task. Was M2, Sprint E.

Sprint B (closes Jan 07, 11:59pm PDT -- pull request sent, initially reviewed)

Group Feature Name Description Priority Status Owner Source Comments / Bugzilla Links
Poky Features Bitbake multi-threaded parsing Bitbake recipe parsing is currently single threaded. I want to make this multithreaded as the speedup would be nice. If I can only take a single task for myself for 1.0, I'm nominating this one as I enjoy this kind of thing and I have ideas on how to do it. 1 Done Richard rpurdie Enhancement
Distribution / components Lock in Kernel/Toolchain version Locked in 2.6.37 and gcc 4.5.1. Pending decision to move to 4.5.2 and Linaro Done Richard
Distribution / components License Update For each of the licences we support, I'd really like to have a licences directory with a copy of that license contained within. When it comes to deciding what a given LICENSE field means, this would be the reference. It also means we can include the licences a given image includes with the image. This continues to make our license handling world class and ahead of the field. 2 Done Beth rpurdie Hygiene
Tool Development and SDK Features Qemu configuration change Provice edit box for advanced user to specify qemu configurations 2 Done Jessica criping
Tool Development and SDK Features Lock down Eclipse+CDT+TCF version Will use Eclipse Halo 3.6 1 Done Jessica
Demo Finalize on demo plans for v1.0 launch 1 Done Dave
Release Release plans for v1.0 launch Fill out the M4 plan with the necessary release activities and timings 1 Done Beth
Poky Features Basic image creator GUI Functional UI missing some Advanced features 1 In replan Joshua
Tool Development and SDK Features Yocto Installer for SDK Generator Installation functions support Detailed feature request can be found at: http://bugzilla.pokylinux.org/show_bug.cgi?id=589 1 Done Jessica rpurdie Enhancement
Kernel Tracing: trace-cmd python binding cleanup 3 Done Darren dvhart

Sprint C (closes Jan 14, 11:59pm PDT -- pull request sent, initially reviewed)

Group Feature Name Description Priority Status Owner Source Comments / Bugzilla Links
Poky Features kernel development layer The (correct) poky behaviour of building known revisions coupled with the fetcher requiring a BSP branch to already be present means that local modifications (and kernel source tree) are required for kernel development. I already have a layer that overrides/modifies the behaviour when added to the bblayers.conf and configured into an environment. This seems useful for more people to use. 2 Done Bruce bruceashfield Enhancement, was M2, Sprint C
Distribution / components Zypper/RPM RPM Up-rev / Zypper Up-rev [lets get to the latest versions] 1 Done Mark/Qing was M2, Sprint C
Supported Targets Intel Platform Support JasperForest 2 Basic support in place; DPDK evaluation in process, overall BSP plan still TBD Tom davest Basic ECG support (Moved from Sprint A)
Tool Development and SDK Features Eclipse poky tree interfacing (git support) Use Eclipse git capability to install poky tree from git repo and able to interact with git repo at file level within Poky tree 2 Done Jessica jzhang Enhancement
Poky Features Poky Image Creator A standalone application you can run which asks you to select a distro and machine, then presents a list of packages you can select. Once the selection is made, it goes off and bakes you an image which is then presented to you. Implementation wise, it should use the sstate packages, be a bitbake UI and use the usual poky bbclass files to do the image construction behind the scenes. 1 Re-plan Joshua rpurdie Enhancement
Distribution / components LSB Sanity execute LSB Test and improve passing rate and document failures with clear understanding 2 Done MarkH/Saul sgw Hygiene
Tool Development and SDK Features Image creator integration with Eclipse 2 replan Jessica jzhang Enhancement
Kernel Tracing: perf trace marker support This is from feedback to the new trace command. Ingo appears to have this nearly complete already. 3 Done Darren dvhart
Cleanup bitbake user experience error handling validation completed 2 Done Richard
Cleanup variable scrub - ensure all metadata variables are documented Script with a histogram of variable use done, identified 50 variables to document; Add task for actual documentation update is low on the list 2 Done Scott/Darren
Kernel Tracing: package kernelshark 3 Done Darren dvhart

Sprint D (closes Jan 21, 11:59pm PDT -- pull request sent, initially reviewed)

Group Feature Name Description Priority Status Owner Source Comments / Bugzilla Links
Poky Features Fetcher Overhaul Phase 2 - API reorg
  • f) Add a generic unpack funciton to __init__.py based on the unpack task in Poky ;
  • g) Split go() methods into the following steps: i) download() - do whatever transfer is necessary to get the sources locally ii) build_mirror_data() - generate any data that would be needed to construct a source mirror iii) unpack() - takes a directory as an argument of where to place extracted sources;

The existing go() methods should be replaced with a set of calls to the above sections of functionality as appropriate in the individual fetchers. Some of these categories of function make no sense in certain fetchers, in which case they shouldn't need to implement them. Functions are only executed if the method is present.

  • h) Change Poky's unpack to call an unpack method in the fetchers.
  • i) Change Poky's fetch task to call a "download" method in the fetcher instead of go().
1 Done Saul / Ke, RP rpurdie Enhancement
Poky Features Fetcher Overhaul Phase 3 - git enhancement
  • j) Optimize git fetcher for the new layout so for a git checkout, we clone the repository in download(), then unpack just does a clone with references to the original repo.
  • k) Ensure that we only set __BB_DONT_CACHE when SRCREV = "AUTOREV". This may need a new method call for fetchers to tell whether they're "floating" or locked down.
  • l) Add a new "BB_NO_NETWORK" variable which the fetchers check before peforming an operation which hits anything remote. This means adding in error messages about why network access is needed at various points (e.g. SRCREV = "AUTOREV" for a given recipe)
  • m) Add multiple branch/srcrev support for git fetcher. These would be of the form: git://somelocation/somerepo.git;name=ref1;branch=foo;name=ref2;branch=bar SRCREV_ref1 = "hash1" SRCREV_ref2 = "hash2" which would ensure both hash1 and hash2 were in the final repo.
  • n) Change git fetcher to default to git protocol instead of rsync
1 Done Saul / Ke, RP rpurdie Enhancement
Poky Features DSO linking changes "By the default the gcc linker will automatically link any dependant objects/libraries. ""Inherited"" linkages can cause issues, for example, where a shared object changes its dependencies but a program has come to rely on symbols from an implicitly linked library. Fedora implemented this change in F13, seems like it would be useful to have in Poky too. " 2 Done Saul / Nitin josh bug#516
Poky Features libtool sysroot option libtool 2.4 has a sysroot option. We should try and use it, see how it works and whether we can ditch some of our libtool hacks. 1 Done Saul / ScottG rpurdie Enhancement
Distribution / components MACHINE or Recipe specific sysroots Each machine should have its own sysroot. We'll probably have to split do_populate_sysroot into a two step process, creation of the package and than installtion of the package, which the installation of the package being made machine specific (put ${MACHINE} into ${STAMP} and bitbake should do that). Also allowing this to work per recipe would be desireable 1 Done Saul / Dongxiao rpurdie Hygiene
Distribution / components Toolchain Bootstrap Process The toolchain as it bootstraps overwrites files like libc.so and libgcc.so in the sysroot directory which causes issues if you just try and rebuild part of the toolchain. Each step of the bootstrap process should use a separate sysroot. Once this is once, sstate file overwriting detection can be added and enabled. 1 Done Saul / Dexuan rpurdie Hygiene
Distribution / components Add headers and libraries to qemu images Since we'll be using qemu images as target sysroot, need to create a set of qemu images for minimal, sato, LSB that contains target header and libraries. 2 Done Saul jzhang Enhancement
Distribution / components push of all relevant Wind River patchs to Yocto (patch comparison) Update any additional patches needed since M2. 1 Done Mark Mark

Sprint E (closes Jan 28, 11:59pm PDT -- pull request sent, initially reviewed)

Group Feature Name Description Priority Status Owner Source Comments / Bugzilla Links
Distribution / components perl upgrade perl is the most cross un-friendly recipe pending upgrade. 2 Done Nitin Nitin Kamble enhancement
Kernel Final linux-yocto_git.bb With 2.6.37 kernel 1 Done Bruce dvhart

Sprint F (closes Feb 03 (THURSDAY), 11:59pm PDT -- pull request sent, initially reviewed) :: NOTE: China New Year Holiday

Group Feature Name Description Priority Status Owner Source Comments / Bugzilla Links
Documentation ADT Reference Guide Draft out for review Outline complete High Done Scott Rifenbark jzhang Documentation

M4 (Feb 07 to Apr 15 -- Stabilize Complete Mar 18, Release Complete Apr 01, Contingency to Apr 15)

This sprint is the Yocto Project v. 1.0 Release Cycle.

During this sprint, we will track the Yocto Project v1.0 Release Criteria.

Stabilization Phase Features and Activities

Red items are must-do prior to Feature Complete.

Group Feature Name Description Priority Status Owner Source Comments / Bugzilla Links
Fetcher Additional All planned enhancements are complete, but this is a placeholder for additional fetcher improvements being worked on prior to freeze. 1 Done RP RP
Distribution / components performance indicators define some indicators (boot time, footprint, build time, power, component benchmarks, etc.) and then collect them for tracking purpose. The result could be posted on the wiki site, and the initial indicators can be easy ones which can be easily retrieved from autobuilder or weekly qa report). This way we have a clear track about the healthy of the Yocto project, and also identify weak areas. We can include qemu targets and several representational boards as the targets. 2 Done Beth/Jiajun ktian1 enhancement
Swabber Review Complete review of swabber outputs 1 Done Alex
Poky Features Performance Enhancement reduce disk space (hardlink) 1 Done Saul / Qing, Dongxiao rpurdie Enhancement
Kernel Final meta-linaro layer 1 Done Darren dvhart
Kernel Final meta-linaro layer documentation needs to be merged into master 1 Done Darren dvhart
Kernel Sandy Bridge 1 Done Tom dvhart
Validation Boottime/Performance Analysis Compare Yocto Project performance to other projects such as MeeGo 1 Initial report on where we are by EO March Darren davest project commitment
Validation Alpha testing complete 4-5 developers unfamiliar with Yocto Project try to do a build and report on the experience and issues encountered 1 Done Julie davest
Distribution / components Distro Audit Documentation Output Audit package documentation output; email sent (status tracking will be done in 1.1) 2 Done Saul / ScottG rpurdie Hygiene
Documentation Features Package report system move to public server [setup a package report system in an internal machine. We need push it publicly available. The basic features like search and report have been there. But there're still some enhancements in plan, to make it a fit place to feel Yocto metadata comfortably] 2 Done Saul (Jon) ktian1 enhancement
Distribution / components mklibs mklibs is a tool to optimize size of [e]glibc for a perticular root file system image. It is useful to save disk space on small devices. 2 Done Saul Nitin Kamble enhancement
BSP 2.6.37 Crown Bay Support 2 Done Tom dvhart
BSP 2.6.37 Emenlow Support 2 Done Tom dvhart
Supported Targets Intel Platform Support Sandybridge 2 Done Tom davest Basic ECG support
Distribution / components Review & Fix Standards Tests Review the results from LTP, POSIX and assess the result, fix as appropriate and clearly document failures. 2 Done Saul/Kevin sgw Hygiene
Distribution / components rootless X rootless x server has better security than x server launched by root. MeeGo already enable this feature. it would be nice for Yocto to also enable it. 2 Done Saul / Ke yuke enhancement
BSP Beagleboard XM Support 3 Done (our part). Darren to ask the community to finish it up. Darren dvhart
Debug Debug file changes Improvements to debug files to enable better debug 3 Done Mark H Mark H

Documentation Deliverables

Group Feature Name Description Priority Status Owner Source Comments / Bugzilla Links
Documentation Migration chapter in the Poky Reference Manual This chapter would cover the four identified use-cases for migrating up to the most recent version of Yocto Project. Additionally, it would cover migration scenarios from other development systems. The chapter does not yet exist. The chapter has not been scoped outside of having a meeting that identified four use-cases that did not include migration from a development system outside of Yocto Project. It will take some more scoping time to cover those areas (a day or two). Again, I have no idea of the length. See earlier entries for standard industry writing estimates for software documentation Medium Moved to 1.1 Scott Rifenbark 3-4 Weeks Documentation
Documentation ADT Reference Guide finished manual Outline complete High Done Scott Rifenbark jzhang Documentation

Features needed and to be put into sprints by assigned owners:

Group Feature Name Description Priority Status Owner Source Comments / Bugzilla Links
Poky Features package config option enhancement there're several enhancements we may do here: * allow users setting specific config options (local or global) from external tool, such as poky image creator, instead of changing recipes manually. Need a mechanism to convert from variable assignments into exact config options (e.g. feature_${PN} = ""1"" -> ""--enable-feature""). Consequently dependency chain needs update with option status. * host contamination check. We have swabber to check host contamination, but I'm not sure whether it covers configuration phase. If not, this is one area to improve, as not ususually we see configure script checks host bits for available features * conditional option manipulation. In many recipes we enable/disable one option based on availability of other packages. Now this is done manually and not flexible. this should be made automatically though some new annotation to indicate condition, or just base_contains (not convenient: long line, need define distro features) 2 Review Richard/MarkH ktian1 Enhancement
Media Yocto Project Awareness Video This 2.5 minute video would introduce and describe the benefits of Yocto Project. The video would use entertaining animations that described concepts and benefits. The result would be suitable for YouTube, conferences, and the website. The production is called an "Epipheo" and will be created by Epipheo Studios. The engagement process has begun and the kick-off meeting will be soon. The PO is in place. Time for development is 10 weeks. High Kick-off Imminent Scott Rifenbark 10 Weeks Media
Documentation Yocto Project Debugging Guide This would be a guide for the debugging and bug tracking process in Yocto Project. Originally, the thought was that we needed a Bugzilla User's Manual. However, since we don't own Bugzilla it doesn't make sense to produce documentation for it. Rather, we should document the process as it fits into the Yocto Project environment. Ideally, the manual would be a sub-manual that would be referenced and architected into the Yocto Project Development Guide. The manual has not been scoped and would take a week to scope. Again, I have no idea of the length. See the previous item for standard industry writing estimates for software documenation. Medium Not Started Scott Rifenbark 3-4 Weeks Documentation
Website Yocto Project Website The 0.9 website is in place but needs updates. Items for consideration are the left-panel naviagation scheme, a contributions guidance page, color-scheming and theme (possibly). Medium Not Started Scott Rifenbark 1-2 Weeks Website

Features not believed to be needed in v1.0:

Group Feature Name Description Priority Status Owner Source Comments / Bugzilla Links
Poky Features OpenEmbedded/Bitbake Upstreaming "We firstly need to review where we are and where OE is. We then need to make a plan about what we're going to push upstream and what we're not. I'd suggest when we're in PRC, we do a crash course in ""dealing with OE"" and then many dedicate a block of time (a week) where the distro team comes up with a patch set we then propose and get merged into OE. I'd like to find a couple of interested people to monitor OE more regularly and start a workflow of things between Poky/OE where appropriate. The key thing to remember is we need to keep the architectures compatible. The team is now at the point where I'm happy for them to actually try building OpenEmbedded and not worry about it tainting them! " 2 Review rpurdie Process
Poky Features Handle old versions in WORKDIR an incremental build directory may finally include many old versions WORKDIRS. It'll be good to have those old versions tracked in the cache, which can then either generate a report or allow selectively cleaning up an specific version WORKDIR. Or else it's difficult to figure it out when people want to keep the whole tmp directory but like to cleanup some old bits when disk usage is under pressure. If it's not easy to do in bitbake, perhaps some separate scripts would be also helpful 3 Review ktian1 Enhancement
Poky Features run bitbake w/o rebuilding the cache "sometimes it's useful to allow run bitbake w/o re-parsing recipes, if we know nothing metadata is changed. we can just allow reusing existing persistent cache. this is useful when people is debugging WORKDIR w/o metadata change. also sometimes ""bitbake -e"" is used frequently to check poky variable information. with existing cache, several seconds can be saved which are not negligible for a developer daily working on Yocto " 2 Review ktian1 Enhancement
Poky Features parallel make improvement parallel make experience is not good, especially when bb threads and make threads are increased larger than 8. So far we either try to fix package makefile or mark the recipe as no parallel make, when build faiures are reported. But this greatly impacts user experience for a successfully continuous build process. Could we define a safe number we do want to support for 1.0 release? and then have our autobuilder, QA test, and developers cover that number immediately and fix any issues accordingly. Then the safe number can be suggested to the Yocto user 2 Review ktian1 Enhancement
Poky Features Dependency packages rebuild/clean It is a mechanism to rebulid or clean a package and all other packages which have build/runtime dependency on it. With this change, we can find potential influences of package upgrade to its related packages, which can make the incremental build more trustable. For example, if we upgrade a package to a new vesion which changes its API, this mechanism can easily find out the incompatibility to other packages which have dependency on it. 2 Review dongxiao.xu Enhancement, replaced by checksum feature
Distribution / components FOSSology This may be similar to License Update above, but start to use FOSSology to track licenses. 2 Review sgw Hygiene
Distribution / components Package Developer Tools Create a set of Init scripts template and then review our current init scripts and modify them to confirm to the template. 2 Review sgw Easy of Use
Distribution / components Package Website Complete the work the intern has started on generating the distro tracking information and get it out on the external site. 2 Review sgw "Hygiene, duplicate of ""Package report system"""
Distribution / components Bluetooth UI support Currently we have bluez package in poky, and we need to have a workable graphic user interface to connect/configure BT devices. One choice may be gnome-bluetooth-applet. 3 Review dongxiao.xu enhancement
Distribution / components Connman-gnome enhancement features Enable connman-gnome to support features like, WPA Enterprise connection, hidden SSID, etc. 3 Review dongxiao.xu enhancement
Distribution / components Java Running Environment support Since most embedded systems support java applications running in it, maybe we'd better consider supporting some kinds of JVMs(Embeded JVM). The JVM may not run by default, but user can launch it if running java applications. Compared with GTK/QT, java user number is not small too. 3 Review criping enhancement
Distribution / components create more use cases UPnP demo is one really good use case showing how Yocto is utilized to make real functionality. and we could create more to show how Yocto is easily adapted to real use cases. Those use cases can be either maintained as seperate demo layers in yocto repo, or in seperate branches for reference. We can also call for community's contribution on this which would make 1.0 full-fledged. Or else the newbies to Yocto may be in puzzle how our sample profiles can satisfy their requirements. 2 Review ktian1 enhancement
Distribution / components i18n support internationalization is an important system wide feature. Many component like font, locale affect the i18n. Yocto alreay has some i18n related package like pango, but so far did not consider i18n systematically. so this is place holder to systematically add i18n support. 2 Review yuke/qing enhancement
Distribution / components more demos demos are a good way to educate, push the envelope, and at the same time tout the strengths of the platform. This item just records a current set of ideas from various sources which could/should be implemented: * face-recognition/face-finding, * robotic control/application of face-finding to 'camera-as-sensor' (hexbug demo), * others [tbd, add here] 2 Review tzanussi enhancement
Tool Development and SDK Features Yocto Installer support for image-creator and needed yocto-metadata design Come up design what need to be created as packages to support using "opkg install" for image-creator and needed yocto-metadata 2 WIP, pending comments from RP regarding how to packaging metadata Jessica rpurdie Enhancement
Tool Development and SDK Features Yocto Installer image-creator and needed poky-metadata support The poky build system will build packages for image-creator and needed poky-metadata, which the Yocto Installer will be able to use "opkg install" to install them 2 Review Jessica rpurdie Enhancement
Tool Development and SDK Features Provide qemu management UI In current eclipse plugin, QEMU settings are put together with project configuration. So we can only have limited settings. If we can have a separate QEMU management UI, the end user could firstly create a QEMU config, such as (env file of arch, image location, unfs or not, sato or lsb, mem size, disk size). And then he can launch a QEMU with a specific config. The dependency between project configuration and QEMU config will be resolved. After all QEMU has nothing to do project configuration. Need to careful review the UI to ensure minimal impact to testing matrix. 3 Review criping "Enhancement, duplicate of ""Qemu mem/disk size can be adjusted"""
Tool Development and SDK Features QT plugin For Eclipse Integrate QT Ecplise plugin and extend for Yocto Project 3 Review jzhang Enhancement
Tool Development and SDK Features Profiling/Trace GUI's We have a wealth of great tracing and profiling tools but the UI's for them are all extremely minimal and usually quite ugly. Would be great if we could compete with, or even better, Apple's offerings here. We have the technology! 2 Review josh "Enhancement, duplicate of ""Tracing/Profiling Planning Complete"""
Tool Development and SDK Features Other profiling tools Complete Tom's review of profiling tools and architecture 2 Review josh "Enhancement, duplicate of ""Tracing/Profiling Planning Complete"""
Tool Development and SDK Features Design next-gen tracing/profiling tools Yocto 1.0 will include all the essential existing tracing/profiling tools expected by users, and Josh has proposed a UI integration of all those tools as far as it's possible to do so. That level of integration, basically a 'plugin-level' integration is necessary and useful, but doesn't go far enough. A next-generation tracing tool would integrate at a much more fundamental level; if done properly, it would provide unmatched levels of power and usability to users, and would allow Yocto to distinguish itself in the embedded tracing/profiling space in a way also unmatched by any other distro/build-tool. The implementation would of course not be available for Yocto 1.0, but a coherent design, including prototypes, that could be taken to the community and implemented in a V 1.5 or 2.0 should be done in that time frame. 1 Review tzanussi "Enhancement, duplicate of ""Tracing/Profiling Planning Complete"""
Documentation Features Self Documentation of image contents "I'd like to see the -doc packages Poky builds being combined into some kind of large documentation index representing the collective API docs of the target being built. This can then be placed on a webserver and viewed over the web. We'd have a demonstration of this for a ""bitbake world"" target. Part of the idea here is to start making good use of the docs as if developers see this they might start writing better docs too. Aim is to lead the field :). There are a number of places poky packages disable doc generation due to missing tools so we'd need to add these so we can enable the doc generation. Many packages already have many docs though too. " 2 Review rpurdie enhancement
Validation Testing Framework Add a framework for doing automated testing in the project 1 Review davest project commitment
Validation more SDK builds on autobuilder enable more SDK related tests on autobuilder such as meta-ide-support, etc. 2 Review ktian1 project commitment, addressed by test plan (?)
Validation more people should try using SDK this may not be a feature, but a requirement. SDK including meta-toolchain is one key factor impacting user experience on Yocto. It's not enough to have only SDK team play with it 2 Review ktian1 project commitment, addressed by test plan (?)
Validation Unit Testing Framework Add a mechanism to bitbake to parse source packages that have unit tests and then execute them on the target 3 Review sgw "project commitment, duplicate of ""Testing Framework"""
Validation Test Case open source Open source Yocto test cases with xml format 1 Review yyou "project commitment, duplicate of ""Testing Framework"""