User:Erikos/Planning 12 1 0
Scope and aims
- Fix remaining issues for the XO-1.75 support
- 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 the 8th of May 2012, Feature proposal did start, next FUDCon will be in Blacksburg
- 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 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 will likely have been released by that date (according to the release schedule that is the 5th of May).
- 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