12.1.0/Release plan

From OLPC
< 12.1.0
Revision as of 17:35, 14 March 2012 by DanielDrake (talk | contribs) (Created page with '== Scope and aims == * Update to [http://wiki.sugarlabs.org/go/0.96/Notes Sugar 0.96] * Update base system to Fedora 17 * Fix remaining XO-1.75 software issues * Continued u…')
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

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

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
  • F17 rebase
  • sugar gtk3

The XO-1.75 team will work on the remaining issues for the ARM port, including porting Fedora 17 to ARM, finishing a kernel for XO-1.75, and so on.

Risk areas

F17, systemd

ARM support for F17

Another area of risk is the switch to Sugar 0.96 and GNOME 3 technologies as it will see major changes. So, we will have more than enough time to compensate for a largely delayed release (0.96 schedule).

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

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.