13.2.0/Release plan

Scope and aims

• Offer a way of allowing teachers to hand out work in a classroom, and collect student assignments, implemented in a way that is non-intrusive and not overly time consuming.
• Make RTC reset behaviour consistent and good across all platforms
• Stabilize XO-4 power management (including the instabilities caused by mwifiex)
• Stabilize XO-4 graphics
• Allow the XO-4 bluetooth driver to be loaded (<trac>12657</trac>).
• vmeta support on XO-4
• Latest Sugar activity versions
• Latest Sugar-0.98 bugfixes
• Continued fixes and improvements where available
• Apart from items mentioned above, we will not be implementing new features during this cycle.

Schedule

We aim to follow the general and slowly evolving Release Process (that page includes more details about all of the stages outlined below). However, in this case, the release will be driven primarily by the inclusion items listed above. The release dates (when defined) will therefore be somewhat flexible.

Development stage

• Start: March 2013

Regression fixing stage

• 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 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.

Risk areas

Updated Fedora packages could introduce regressions. We can mitigate this with shipping old versions if solutions cannot be found in a timely manner.

Updated activities could cause disruption, needs testing.

Maintainability

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

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").

The release manager will aim to keep the trac milestone clean with the following in mind:

• 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.