User:Erikos/Planning 12 1 0

From OLPC
Jump to navigation Jump to search

Scope and aims

  • Better support for the XO-1.75
  • Include Sugar 0.96, to be released the 28th of March 2012 (see Schedule)
  • Move to new Fedora base Fedora 17, planned to be released in May 2012 (no schedule yet Schedule)
  • 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).

Development stage

  • Duration: Approximately 6 weeks

Normal, open development. Features (of limited scope and risk) are accepted. OLPC plan to implement the features described below according to the priorities they have been given.

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.

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

Fedora 14 updates will continue to be applied, which (according to Fedora guidelines) are compatible with the "bug fixes only" mindset.

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.

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