12.1.0/Release plan

Scope and aims

• Update to Sugar 0.96
• Update base system to Fedora 17
• Fix remaining XO-1.75 software issues
• Continued updates, fixes and improvements

Schedule

Like 11.3.0, we aim to follow the general and slowly evolving Release Process (that page includes more details about all of the stages outlined below). The schedule is based carefully around the Fedora 17 and Sugar 0.96 schedules.

Development stage

• Start: November 2011
• Duration: 6 months

Bug-fixing stage

• Start: May 7th 2012
• Duration: 4 weeks
• Focus on stability. No new features are accepted at this point, as we move into "bug fixes only" mode.

Upstream state:

• Fedora 17 is scheduled to be released on May 8th - right at the start of this period
• Sugar 0.96 is already released, including the first bugfix update.

Guidelines:

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

Regression fixing stage

• Start date: June 4th 2012 June 11th 2012
• 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.

Guidelines:

• All builds are now signed.
• Fedora 17 should have been released by that date. 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.
• We may also take trivial fixes to important problems (e.g. one-line fixes) where the risk is low.

Final release

• Date: July 2nd 2012 July 9th 2012

Work plan

OLPC plan to implement the following items during the development phase. Features that do not make the development stage will be deferred til the next release cycle. As always, we will continue to take contributions from the community in other areas, providing that they fit with our schedule.

• Any XO-1.75 rough edges from the previous release cycle will be tackled.
• XO-1.75 will move from soft floating point to hard floating point (hardfp) for improved performance.
• The base system will be updated to Fedora 17. This will take advantage of the latest upstream developments at the system level and keep us up to date with the open source world.
• We'll contribute to development of Sugar-0.96, including a partial technology shift to GNOME 3 technologies.
• Smaller scope general improvements will be made across the stack, as is usual in our release cycles.

Risk areas

The move from Fedora 14 to Fedora 17 includes a technology shift to systemd which will affect us in a number of ways. However, a large amount of this work has been done before this release plan was formalised, and things already were in reasonable shape at that time.

We are relying on the Fedora ARM efforts to build F17 going smoothly. However, again, at time of release plan formalisation, only a handful of required packages are pending in this rebuild effort.

The move to Sugar-0.96 and its move to GNOME 3 technologies involve major changes and naturally adds risk. OLPC's Sugar developers will focus heavily on this throughout the cycle. There is room for a delay in the Sugar-0.96 release date.

Maintainability

Apart from exceptional circumstances, no new packages will be forked. This means all features have to go in through upstream channels. An upstream-first mentality will be maintained for the Sugar work:

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

Trac conventions

Sugar and Sugar activity bugs must be filed on http://bugs.sugarlabs.org. All other bugs (or if uncertain) go to http://dev.laptop.org.

dev.laptop.org

Bugs on dev.laptop.org are marked as "add to build" when the solution has been packaged, and then set to "test in build" by the release manager once a build has been made. Sam Greenfeld (QA lead) is in charge of watching and closing those tickets.

In recent release cycles, the release milestone in trac has become a bit of a dumping ground for ideas-of-the-minute and miscellaneous bugs (e.g. bugs not related to current development efforts). As such the milestone's bug listing has been of limited value and hard to utilise by those who do not work on the release specifics every day. In this release cycle, the release manager will attempt to improve on this situation with the following measures:

• All bugs in the milestone will have a correct and accurate assignee who understands the responsibility to work on the issue according to the schedule in this release plan.
• The release manager will triage incoming bugs roughly according to the following criteria:
  • Regressions caused by work in this release cycle will be included in the milestone and assigned accordingly
  • All other tickets will be triaged into Future Release (for things we want, but will not necessarily commit to working on it immediately) and Opportunity (for nice-to-haves).
  • All tickets triaged to Future Release and Opportunity will have at least 1 core release team member as assignee or CC. This way, any bad triaging decisions can be raised and discussed in the weekly release meeting.
• Developers are welcome to take tickets from Future Release and Opportunity milestones and move them into the release milestone, as and when they have time available to dedicate to such work.
• The resultant succinct, clean ticket listing in the milsetone will be useful for release management, allowing for early identification of release blockers, easy progress tracking, and lets us easily see that nobody is overloaded with work.

bugs.sugarlabs.org

Bugs on bugs.sugarlabs.org are marked as fixed when the fix is committed to git, but tickets that deserve OLPC QA are keyworded with olpc-test-pending (even in the fixed state). The developer committing the fix is in charge of closing the ticket.

Sam Greenfeld (QA lead) is in charge of watching those tickets. If testing passes, the olpc-test-pending keyword is removed, and the olpc-test-passed keyword is added. If testing fails, the bug is reopened.

One imperfection with this system is that a ticket will be marked as olpc-test-pending before the fix is available for testing in a build. It is up to the tester to determine if a given olpc-test-pending ticket can be tested yet. We think this may be doable just through keeping an eye on the mailing lists (release announcements, etc), but we will monitor the situation and look for other solutions if things get out of hand.

Release management

Daniel Drake will act as release manager, applying/enforcing the guidelines and milestones as above, approving the inevitable handful of exceptions, coordinating builds and release notes. Peter Robinson will produce and announce builds during the development phase.