11.2.0/Release plan

This plan will be updated as development goes on, but should retain the basic form outlined below.

Scope and aims

• XO-1, XO-1.5 and XO-1.5 High School edition
• Rebase platform on recent upstream developments in Sugar, Fedora and Linux
• Add new features
• Maintain/improve stability and maintainability

Timeline and work plan

Milestone 1 - basic system functionality

• Start date: September 2010
• Completed in December 2010

System boots, basic system level functionality (audio, video, network, ...) appears functional

Milestone 2 - improve testing coverage

• Start date: 17th January 2011
• Duration: 3 weeks

At the end of milestone 1, there are various bugs in the higher layers (Sugar, Sugar activities) preventing testing from even being started in certain places, e.g. various Sugar activities do not launch.

Fix these big showstoppers to increase testing coverage.

Take a first pass at incorporating pending Sugar bugfixes from the community.

Milestone 3 - features

• Start date: February 7th 2011
• Duration: 10 weeks

Implement features according to the Feature plan section of this document. This milestone will be completed on a time basis (rather than a specific set of features). The feature plan assignies priorities to features to guide development.

Features that aren't fully implemented during the timespan of this milestone will be dropped, but significant features that are "nearly ready" can extend this milestone by a maximum of 2 weeks, delaying the rest of the schedule, while their development is completed (better to release slightly late than to make a disappointing release).

Milestone 4 - bug fixes only

• Start date: April 18th 2011
• Duration: 4 weeks

Focus on stability.

No new features are accepted at this point, as we move into "bug fixes only" mode.

Translation updates are accepted.

Sugar activities are frozen at the start of this milestone, but new versions will be taken when demonstrated to fix bugs.

Fedora 14 updates will continue to be applied, which (according to Fedora guidelines) are compatible with the "bug fixes only" mindset.

If the rate of change drops low enough, builds will begin to be signed by OLPC.

Milestone 5 - regression fixes only

• Start date: May 16th 2011
• Duration: 4 weeks

At this point, the project should have the "ready for release" feel. This final milestone is reserved for final testing. The only changes accepted here are fixes for regressions over previous OLPC OS releases.

All builds are now signed.

Fedora updates will only be taken (selectively) when shown to fix regressions.

Sugar activity updates will only be taken (selectively) when shown to fix regressions.

Final Release

• Date: June 13th 2011

Feature plan

(this list needs prioritizing, feel free to add more details and reorganise)

1. Upstream 10.1.3 leftovers
2. Make activity updater use microformat
3. Activity startup: Start New vs Resume redesign
4. Replace "Keep" with "Save to Journal" functionality
5. Rework naming alert
6. Read activity: text files, text to speech
7. Library activity for book and content organisation
8. Refreshed selection of default activities
9. New toolbars in all activities
10. Translation infrastructure work and call to arms
11. mock.laptop.org rework
12. Process documentation
13. Robotics
14. Early boot: fsck and resize
15. Antitheft control panel
16. Backup/restore control panel
17. New chrome video driver

Features that don't arrive within the milestone 3 timeframe (even if started but incomplete) are dropped, with the aim of picking them up in the next cycle. However, there is some flexibility on the end date of this milestone (see the above timeline).

Risk areas

We've identified a few areas that deserve heightened attention throughout the cycle:

• Sugar collaboration - this was recently refactored
• Sugar with metacity window management - this is a fundamental change in Sugar
• Filesystem changes - XO-1 now uses ubifs, XO-1.5 now uses ext4
• Activity toolbar changes - we'll aim to ship only activities with the new Sugar toolbars, for a consistent UI experience. The toolbar change introduces fundamental design changes to some activities.
• Pootle - this does not really have a maintainer, and should be monitored closely throughout the cycle.

Maintainability

Apart from exceptional circumstances, no new packages will be forked. This means all features have to go in through upstream channels.

Sugar components

In the 10.1 cycle, OLPC had full control over the Sugar 0.84 branch, meaning that fixes/features could be backported from newer versions, and releases could be made at will.

In light of having less control over Sugar 0.90, it is likely that OLPC will add patches to Sugar on the package level. However, an upstream-first mentality will be maintained:

• Bug fix patches must already be in the relevant 0.90 branch of upstream git
• Feature patches must already be in the relevant master branch of upstream git

It is possible that SugarLabs would grant OLPC permission to take over the 0.90 branches (similar to the 0.84 takeover) if a strict "master first" policy is applied. This is something that may be investigated during the cycle.

Following development cycle

After milestone 3, non-bugfixes will be rejected. This tightens further after milestone 4, where the only fixes accepted are regression fixes. To provide a home for features and fixes that will inevitably pop up during this time, a new development stream based on a future version of Fedora, will open soon after milestone 4 is started.

This stream probably won't be very usable and might only exist as a few branches, but will act as a home for developments that are too late for inclusion in this release.

At the point when this stream is opened, fixes going into this release will be expected to be in the new development stream as well, ideally a few days beforehand. As the rate of change should slow significantly, this isn't likely to be a drain on resources.

Release management

Daniel Drake will act as release manager, applying/enforcing the guidelines and milestones as above, approving the inevitable handful of exceptions, producing/announcing development builds, and coordinating release notes.