13.1.0/Release plan

Scope and aims

• Add support for XO-4
• Add support for touch
• Update base system to Fedora 18
• Update to Linux 3.5 on XO-1.75
• Continued updates, fixes and improvements

Schedule

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 around the production requirements for XO-4.

Development stage

• Start: July 2012
• Duration: 3 months

Bug-fixing stage

• Start: October 11th 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 18 beta is due to be released shortly before we enter this stage

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: November 8th 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 18 should have been released by this date, if it doesn't slip. 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: December 6th 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.

• XO-4 support
• Sugar
  • Port various activities to GTK3
  • Port shell to GTK3
  • Add touch support
• The base system will be updated to Fedora 18. This will take advantage of the latest upstream developments at the system level and keep us up to date with the open source world.
• Smaller scope general improvements will be made across the stack, as is usual in our release cycles.

Risk areas

The move from Fedora 17 to Fedora 18 has some risks. However the new features do not seem particularly risky for us. The ARM builders are already doing a good job on Fedora 18.

A lot of work is needed for the Sugar GTK3 and touch efforts. Alignment with the proposed Sugar-0.98 release cycle aims to maximize the development time available while also leaving time for stabilisation.

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.98 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 earlier 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 maintain the cleanliness of the 12.1 cycle 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. We hope to count on Peter Robinson's help on the build front.