User:Erikos/Planning 12 1 0

From OLPC
Jump to navigation Jump to search

Scope and aims

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 17 schedule and Sugar 0.96 schedule.

Development stage

  • Start: November 2011
  • Duration: 6 months

Differently to the previous 11.3.0 release the development phase is not only limited to small Features. Switching to Sugar 0.96 and GNOME 3 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: 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 Beta should have been released by that date (according to previous release schedules).
  • Sugar 0.96 has been released by that date already and the first bug fix release has been made.

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

Upstream State:

  • Fedora 17 should have been released by that date (according to previous release schedules). 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: 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.

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

One risky area is the move to Fedora 17, as of today there is no schedule yet for the release, it is planned for May 2012. We need to make sure our window is large enough to compensate for a potentially delayed release. Switching to Fedora 16 has the issue of having likely no ARM support as the Fedora ARM team is leaning towards skipping F16 and moving to F17 directly.

Another area of risk is the switch to Sugar 0.96 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

to be defined

Links

Retrieved from "http://wiki.laptop.org/mediawiki/index.php?title=User:Erikos/Planning_12_1_0&oldid=262858"