The detailed milestone map for the 1.1 release of Yocto Project is as below.
To view the Yocto schedule-at-a-glance, view File:Yocto Schedule.xls--> "Schedule" tab.
pre-M1 (March 14 to April 18 -- Feature List and Schedule Defined April 18)
Features Submitted to web - by April 1st
Features prioritized and added to schedule - by April 12th
pre-M1 COMPLETED
M1 (Apr 18 to Jun 13 -- Design Complete Apr 25, Dev Complete May 23, Stabilize Complete Jun 6, Release Complete Jun 13)
M1 Design (Apr 18 to Apr 22)
Feature Name
Description
Priority
Status
Source
Owner
Comments / Bugzilla Links
Automatically generate package repos - design
automatically generate package repositories (and be able to \"use them\" -- to be defined) for both ipk and rpm/zypper combinations; also, documentation of this process is essential; this stage is the design phase.
2
Complete
Team
Saul (Dexuan)
M1, Design
OE Autobuilder rename
1
Done
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
Testing
Beth
Beth
M1, Design
M1 Sprint A (Apr 25 to Apr 29)
Feature Name
Description
Priority
Status
Source
Owner
Comments / Bugzilla Links
OE-Core
Restructuring, renaming, rebranding
1
at 90%
RP Notes
Richard
M1, Sprint A
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
Saul will get update by Wed
QA
Jiajun/Meilei
M1, Sprint A
User Creation at preinstall - status check
Design status check
1
29-Apr
RP Notes
Mark (ScottG)
M1, Sprint A
Optimise Configure
2
Saul will get update by Wed
RP Notes
Saul (Dongxiao)
M1, Sprint A - Richard writes down his thoughts (Dongxiao determines finish date at this time)
Check SRCREV in recipe files
should work, may need dev
2
next time pull done
RP Notes
Richard/Ke
M1, Sprint A - planning complete (may evaporate after this) - Ke needs to check in with Richard to get a go/no-go decision. We just need to ensure SRCREVs are the individual recipe files rather than the group file.
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
29-Apr
Tom
Tom
M1, Sprint A
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
29-Apr
Rahul
Tom?
M1, 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
3-May
Beth
Beth
M1, Sprint A
Retrospective
Hold a retrospective to discuss what went well and what can be improved in 1.1
1
Done
Beth
Beth
M1, Sprint A
M1 Sprint B (May 2 to May 6)
Feature Name
Description
Priority
Status
Source
Owner
Comments / Bugzilla Links
Layer Tooling - Design
Design/Architect the Layer Tooling approach
1
Accept
Architect
Richard
M1 Sprint B
crazygit fetcher
TI issues with fetch2 - per LCS - should this be a P1?
2
Accept
RP Notes
Saul (Ke)
M1, Sprint B (timescale = 2-3 days)
multi-lib infrastructure
multi-lib support for 32-bit & 64-bit and capable of being installed at the same time - infrastructure in place (bbclass extend and multilib toolchain changes)
1
Accept
from 1.0
Richard (Qing)
M1, Sprint B
Test Plan
Create an overall Test Plan for 1.1 and post on Wiki
1
Accept
Jiajun
Jiajun
M1, Sprint B
Sync qemugl with MeeGo - Status check
This is a status check on how the work to sync qemugl with MeeGo is going. Completion set for M1, Sprint D.
2
Accept
Meta-data
Saul (Edwin)
M1, Sprint B
Finish LSB \"distribution\" work - QT3
QT3 work is complete.
2
Accept
Meta-data
WR Distro Team
M1, Sprint B
Incompatible License
2
Accept
Paul
Paul
M1, Sprint B - design and review
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
Accept
Tom
Tom/Darren
M1, Sprint B, C, D
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
Changes for Image Creator - phase 1
Phase 1: add mechanism to enable selection of server backend at runtime
1
Accept
ADT Team
Jessica
M1, Sprint B
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
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)
Fast boot analysis
Perform analysis to determine how best to implement a 2 second boot time
1
Accept
Darren
Darren
M1, Sprint B
Build Yocto behind firewall - plan
Josh/Darren define plan
2
Review
Dave
Darren, Joshua
M1, Sprint B
M1 Sprint C (May 9 to May 13)
Feature Name
Description
Priority
Status
Source
Owner
Comments / Bugzilla Links
Package config option enhancement - Plan
Plan our approach to package config option enhancement
2
Accept
from 1.0
Richard
M1, Sprint C
Upstream our patches - phase 1
Have upstream status updated on 90% of patches (so that we can have a status update)
1
Accept
Meta-data
Saul
M1, Sprint C
3G - Design
We have an ofono recipe but need some integration work done. This milestone is a status check and design update. HW needs to be received at this time.
2
Accept
Meta-data
Saul (Dongxiao)
M1, Sprint C Need hardware and infrastructure to test 3G (MeeGo team has this)
Package reporting system enhancement
2
Accept
Meta-data
Saul (Lei)
M1, Sprint C or D (need additional definition of this item)
Automatically generate package repos - complete
automatically generate package repositories (and be able to \"use them\" -- to be defined) for both ipk and rpm/zypper combinations as discussed during the Design phase; also, documentation of this process is essential
2
Accept
Team
Saul (Dexuan)
M1, Sprint C
User Creation at preinstall - complete
Deliverable completed
1
Accept
RP Notes
Mark (ScottG)
M1, Sprint C
Upgrade to gcc 4.6
Need to upgrade toolchain to gcc 4.6
1
Accept
Nitin
Nitin
M1, Sprint C or D
License tracking
Get common licenses for all packages and consolidate base file licenses. (takes ~3 days)
1
Accept
Beth
Beth
M1, Sprint C
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)
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 C
kernel port to 2.6.37
Port the kernel to 2.6.37
1
Accept
Darren
Darren
M1, Sprint C
Tracing: Add Systemtap support for userspace tracing
Add utrace, etc
2
Accept
Tom
Tom
M1, Sprint C
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.
1
Accept
From scratch
ScottR
M1, Sprint C - Scott will work with Richard on this
M1 Sprint D (May 16 to May 20)
Feature Name
Description
Priority
Status
Source
Owner
Comments / Bugzilla Links
multi-lib complete
multi-lib support for 32-bit & 64-bit and capable of being installed at the same time fully complete
Identify issues in order to: Merge patches which are pushed during yocto 1.0. Add packages(qt3,xdg-* ...) LSB Test Suite need. Hardware platform x86 and ppc32(if qt4 can be supported) can be finished.
2
Accept
Meta-data
WR Distro Team
M1, Sprint D
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
Accept
Meta-data
Mark
M1, Sprint D
End of package revision
replace with a network service
2
Accept
RP Notes
Jessica
M1, Sprint D
x32 - plan
layer to support toolchain, libc, and kernel - Plan created
2
Accept
RP Notes
Saul (Nitin)
M1, Sprint D
BBXM
Pull in bits from OE (kernel and uboot)
1
Accept
Darren
Darren
M1, Sprint D
Eclipse-native tools interface
More integrated with upstream once there\'s integrated Linux tools that meets our need, e.g. lttng-remote
2
Accept
ADT Team
Jessica
M1, Sprint D
Changes for Image Creator - phase 2
Phase 2: Bug fix for 7.70
1
Accept
ADT Team
Jessica
M1, Sprint D
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
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
Accept
from 1.0
Tom
M1, Sprint D
M1 Stabilize (May 23 to June 3)
Feature Name
Description
Priority
Status
Source
Owner
Comments / Bugzilla Links
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
Accept
Joshua
Jiajun
check latest distribution in M1 Stabilize, M2 Stabilize, and M3 Stabilize and test them in milestone testing; Should we include more Distributions, besides fedora, ubuntu and opensuse?
Test Execution Plan
Create a Test Execution Plan for the milestone and send to developers
1
Accept
Jiajun
Jiajun
M1 Stabilize; M2 Stabilize; M3 Stabilize
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
Stabilize schedule
Week 1
Day 1, 2: Weekly test pass
Day 3: Pre-Release Readiness meeting
If there are issues:
Day 4, 5: Fix issues and repeat Week 1
If there are not issues:
Day 4, 5 and beginning of Week 2: Complete a full test pass
Week 2
Day 1, 2, 3: Complete full test pass
Day 4: Release Readiness meeting
If there are issues, fix and repeat from Week 1
If there are not issues, proceed to Release phase
M1 Release (June 6 to June 13)
Follow Release Checklist, which includes:
Release is packaged
Release is pushed to mirrors
Release is announced to community via mailing lists and blog
M2 (May 30 to Jul 25 -- Design Complete Jun 6, Dev Complete Jul 4, Stabilize Complete Jul 18, Release Complete Jul 25)
M2 Design (May 30 to June 3)
* Working week. No tasks complete this week.
M2 Sprint A (June 6 to June 10)
Feature Name
Description
Priority
Status
Source
Owner
Comments / Bugzilla Links
Live images
make live images their own image type
2
Accept
RP Notes
Saul
M2, Sprint A
More test cases about toolchain in autobuilder
2
Accept
ADT Team
Jessica
Status check in M2, Sprint A, M3, Sprint A
Indigo update
Update to the latest Eclipse release (Indigo)
2
Accept
ADT Team
Jessica
Status check in M2, Sprint A, M3, Sprint A
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
Accept
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
Accept
Tom
Jessica
Status check in M2, Sprint A, M3, Sprint A
Finish LSB \"distribution\" work - complete
Complete all work: Merge patches which are pushed during yocto 1.0. Add packages(qt3,xdg-* ...) LSB Test Suite need. Hardware platform x86 and ppc32(if qt4 can be supported) can be finished.
2
Accept
Meta-data
WR Distro Team
M2, Sprint A
M2 Sprint B (June 13 to June 17)
Feature Name
Description
Priority
Status
Source
Owner
Comments / Bugzilla Links
Layer Tooling - Architecture
Implement Layer Tooling changes
1
Accept
Architect
Richard (Paul/Daoxien will help)
M2 Sprint B
Error handling in bitbake
desc
1
Accept
RP Notes
Saul (Scott G)
M2, Sprint B
Package config option enhancement - Implement
Implement approach defined in plan for package config option enhancement
2
Accept
from 1.0
Saul
M2, Sprint B
Upstream our patches - phase 2
Everyone has attempted upstreams for patches defined from phase 1
1
Accept
Meta-data
Saul
M2, Sprint B
MeeGo GPLv2 Sync
compare with Yocto, sync any patches
2
Accept
RP Notes
Saul (Ke)
M2, Sprint B
Directory Ownership
1.5
Accept
RP Notes
Mark (w/Qing)
M2, Sprint B
Changes for Image Creator - phase 3
Phase 3: package format job done + image output type job done
1
Accept
ADT Team
Jessica
M2, Sprint B
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
kernel bloat - analysis
target = boot a minimal image in < 8M - analysis complete
1
Accept
Darren
Darren
M2, Sprint B
M2 Sprint C (June 20 to June 24)
Feature Name
Description
Priority
Status
Source
Owner
Comments / Bugzilla Links
btrfs
2
Accept
Meta-data
Saul (Nitin)
M2, Sprint C
adding eglibc config control
this goes with the package config options
1.5
Accept
RP Notes
Mark
M2, Sprint C
Implement Continuous Autobuilds
Build constantly instead of daily (need fuzz builds for this. once fuzz builds are implemented, this is trivial)
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
Accept
davest and RP
Saul
M2, Sprint D
3G - Complete
We have an ofono recipe but need some integration work done - This milestone checks that 3G is complete.
2
Accept
Meta-data
Saul (Dongxiao)
M2, Sprint D
running post installs at rootfs gen time
2
Accept
RP Notes
Saul (Dexuan)
M2, Sprint D
remove gnome-vfs
3
Accept
RP Notes
Saul (Edwin)
M2, Sprint D
x32 - complete
layer to support toolchain, libc, and kernel - x32 is complete
2
Accept
RP Notes
Saul (Nitin)
M2, Sprint D
Changes for Image Creator - phase 4
Phase 4: complete plug-in
1
Accept
ADT Team
Jessica
M2, Sprint D
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
Accept
Lianhao
Jessica
M2 Sprint D
BSP builds
Autobuilder git fetcher improvements (3 days)
2
Accept
from 1.0
Beth
M2, Sprint D
kernel bloat - development
target = boot a minimal image in < 8M - development complete
1
Accept
Darren
Darren
M2, Sprint D
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
Accept
Tom
Tom
M2, Sprint D
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, Sprint D
M2 Stabilize (July 4 to July 15)
Feature Name
Description
Priority
Status
Source
Owner
Comments / Bugzilla Links
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
Accept
Joshua
Jiajun
check latest distribution in M1 Stabilize, M2 Stabilize, and M3 Stabilize and test them in milestone testing; Should we include more Distributions, besides fedora, ubuntu and opensuse?
Test Execution Plan
Create a Test Execution Plan for the milestone and send to developers
1
Accept
Jiajun
Jiajun
M1 Stabilize; M2 Stabilize; M3 Stabilize
Lock kernel version
lock the kernel version
1
Accept
Team
Darren
M2, Stabilize (ww29)
Stabilize schedule
Week 1
Day 1, 2: Weekly test pass
Day 3: Pre-Release Readiness meeting
If there are issues:
Day 4, 5: Fix issues and repeat Week 1
If there are not issues:
Day 4, 5 and beginning of Week 2: Complete a full test pass
Week 2
Day 1, 2, 3: Complete full test pass
Day 4: Release Readiness meeting
If there are issues, fix and repeat from Week 1
If there are not issues, proceed to Release phase
M2 Release (July 18 to July 22)
Follow Release Checklist, which includes:
Release is packaged
Release is pushed to mirrors
Release is announced to community via mailing lists and blog
M3 (Jul 11 to Aug 15 -- Design Complete Jul 18, Dev Complete Jul 25, Stabilize Complete Aug 8, Release Complete Aug 15)
M3 Design (Jul 11 to Jul 15)
* Working week. No tasks complete this week.
M3 Sprint A (Jul 18 to Jul 22)
Feature Name
Description
Priority
Status
Source
Owner
Comments / Bugzilla Links
Upstream our patches - phase 3
Another round of updates is complete
1
Accept
Meta-data
Saul
M3, Sprint A
Sanity checks on per recipe basis
2
Accept
RP Notes Bug#405
Saul (Scott G)
M3, Sprint A
Ability to build SRPM
3
Accept
RP Notes
Jeff Polk/Mark
M3, Sprint A - Julie to check with Jeff
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
Accept
Tom
Tom
M3, Sprint A
More test cases about toolchain in autobuilder
2
Accept
ADT Team
Jessica
Status check in M2, Sprint A, M3, Sprint A
Indigo update
Update to the latest Eclipse release (Indigo)
2
Accept
ADT Team
Jessica
Status check in M2, Sprint A, M3, Sprint A
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
Accept
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
Accept
Tom
Jessica
Status check in M2, Sprint A, M3, Sprint A
Additions to build stats
1
Accept
Beth
Beth
M3, Sprint A
Alpha
Begin an alpha program after the stabilization period for M3.
1
Accept
Team
Julie
M3, Sprint A
Publish Shared State
Publish the shared state information.
2
Review
LCS
Beth
M3, Sprint A if Richard confirms some answers to questions
Fast boot time
2 second boot time target
1
Accept
Team
Darren
M3, Sprint A - 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
M3 Stabilize (Jul 25 to Aug 5)
Feature Name
Description
Priority
Status
Source
Owner
Comments / Bugzilla Links
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
Accept
Joshua
Jiajun
check latest distribution in M1 Stabilize, M2 Stabilize, and M3 Stabilize and test them in milestone testing; Should we include more Distributions, besides fedora, ubuntu and opensuse?
Test Execution Plan
Create a Test Execution Plan for the milestone and send to developers
1
Accept
Jiajun
Jiajun
M1 Stabilize; M2 Stabilize; M3 Stabilize
Stabilize schedule
Week 1
Day 1, 2: Weekly test pass
Day 3: Pre-Release Readiness meeting
If there are issues:
Day 4, 5: Fix issues and repeat Week 1
If there are not issues:
Day 4, 5 and beginning of Week 2: Complete a full test pass
Week 2
Day 1, 2, 3: Complete full test pass
Day 4: Release Readiness meeting
If there are issues, fix and repeat from Week 1
If there are not issues, proceed to Release phase
M3 Release (Aug 8 to Aug 15)
Follow Release Checklist, which includes:
Release is packaged
Release is pushed to mirrors
Release is announced to community via mailing lists and blog
M4 (Aug 15 to Oct 6 -- Stabilize Complete Aug 29, Release Complete Oct 3)
Feature Name
Description
Priority
Status
Source
Owner
Comments / Bugzilla Links
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
M4, Scott will send the more detailed milestones
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
Q3 at the earliest
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, this is part of the Yocto Development Guide
OOB documentation
Create an out of box guide for giveaway systems built using Yocto.
1
Accept
Julie
ScottR
Julie to research timing on this. ~Q3 is current thinking.
