User:Erikos/Planning 12 2 0

Scope and aims

• Include Sugar 0.98, to be released the 28th of September 2012 (see Schedule)
• Move to new Fedora base Fedora 18, to be released at the end of October early November 2012 looking at the Fedora 16 schedule, FUDCon for Fedora 18?
• Solve some known issues

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 highly adopted to the Fedora 18 schedule and Sugar 0.98 schedule.

Development stage

• Start: June 2012
• Duration: 4 months

Differently to the previous 11.3.0 release the development phase is not only limited to small Features. Switching to Sugar 0.98 is a major task. As well the update of the Fedora stack is a major task, hence the much longer development phase.

Bug-fixing stage

• Start: October 17th 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 will be released during that phase.

• Sugar 0.98 has been released by that date already and the first bug fix release will be made at the beginning of this cycle.

Guidelines:

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

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

Regression fixing stage

• Start date: November 14th 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.

Upstream State:

• Fedora 18 has been released by that date. Fedora updates will only be taken (selectively) when shown to fix regressions.

Guidelines:

• All builds are now signed.

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

Risk areas

• porting the Shell to GTK3/gobject-introspection
• poritng the core Activities to GTK3/gobject-introspection
• Gstreamer 1.0, GStreamer through gobject-introspection (Record, Jukebox, Read) gstreamer bug, Read bug

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

Testing

to be defined

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.

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.

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 (even in the fixed state). Sam Greenfeld (QA lead) is in charge of watching those tickets and to remove the keyword when his testing passed successfully or reopen the bug if failed. The developer committing the fix is in charge of closing the ticket.

Release management

to be defined