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: 5 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
• Sugar-0.98 beta is due to be released the day before

Guidelines:

• Fedora updates continue to be included
• Sugar activities are frozen at the start of this milestone, but new versions will be taken when they pass basic sanity checks (no major changes, no obvious bugs on quick testing) by the release manager
  • The lengthier process employed in previous release cycles (where activity changes must be explicitly requested and carefully reviewed and tested) will not be in place this cycle, until the following stage.

Regression fixing stage

• Start date: November 8th 2012 November 15th 2012 December 3rd 2012
• Duration: 5 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.
• Work for XO-4 production blockers can continue as normal; most of this work is to fix regressions over previous laptop models anyhow.

Upstream state:

• Fedora 18 will be heading towards beta release
• Sugar-0.98 should have been released the day before

Guidelines:

• All builds are now signed.
• In order to meet production deadlines, we will be stricter than before when taking changes during this time.
• 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 will be strict here. Random bug-fixes or miscellaneous translation updates will not be accepted. Only things that fix actual 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 December 13th 2012 January 7th 2013

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 in activities and shell (like on-screen keyboard, gestures)
    • Design_Team/Activity_Touch_Input
    • User:Godiard/Touch_plan_activities
    • Design_Team/Sugar_Shell_Touch_Input
    • Features/Touch/Development
• 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. However the Sugar cycle is aligned to a later point in this plan, meaning risk is improved: we have very little room for delay, and we can't slip on implementing major features or fixing major issues.

Risk in general is mitigated by the possibility of delaying the whole release cycle if hardware production delays become known.

• A delay that is known before October 11th could extend the whole cycle
• A delay that is known after October 11th but before November 8th could extend the bug-fixing and regression-fixing stages
• A delay that is known after November 8th but before December 6th could extend the regression-fixing stages

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.

During development, when the list of test-in-build tickets is long, the release manager may close some tickets without testing (e.g. when the change is small and it has already been tested by a reviewer). During stabilisation, Sam must close all test-in-build tickets himself (and will schedule his time accordingly for this "hot period").

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.

Daniel will look at incoming bugs on a daily basis and tag them under the 0.98 milestone (with default owner erikos) if they would appear of importance to OLPC's release. He'll err on the side of safety (over-tagging). Tickets that belong in the milestone but don't fall directly within our work plan can be assigned to non-team members or can have the owner field deleted. Sugar developers should feel free to untag any that don't fit into the scope of the release.

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.