12.1.0

12.1.0 an in-development OLPC OS release, focusing on shifting parts of the Sugar UI to the GTK+ 3 toolkit and to new system technologies present in Fedora 17. The target platforms are Target platforms::XO-1, Target platforms::XO-1.5 (including XO-1.5 High School Edition) and Target platforms::XO-1.75.

The release plan can be found at /Release plan.

Status

Status: Status::in development (see /Release plan and Release Process).

To be released on: Release date::2012-09-01

Release notes: Release notes::Release notes/12.1.0

Download and installation

Download and installation instructions can now be found in the release notes.

Developers

The release is built with Build system::OS Builder version Build system version::5.0.x (master) under Build platform::Fedora 17, using f17-xo1.ini, f17-xo1.5.ini and f17-xo1.75.ini at this point in the development process. The f17, f17-xo1, f17-xo1.5 and f17-xo1.75 RPM dropboxes are used.

Fedora package inclusion process

For contributions in the form of updated RPM packages that are part of Fedora, the process is a little complicated due to the fact we work with multiple architectures and ARM is not yet a primary Fedora architecture.

The entire process is explained below. However, only the first and last steps are required. Feel free to skip some or all of the remaining steps - just make sure you leave a note on an "add to build" ticket noting which steps you have done. Daniel and Peter are more than happy to take on the packaging work on your behalf, and they can lump it into batches.

1. Produce source tarball, upload to relevant place.
2. Commit spec file to Fedora git, push and build for x86
   • Commit your change on both the f17 and master branch. Suggestion: commit on F17 branch, then use git merge to fast-forward master to the same commit.
   • Ensure you are on the f17 branch.
   • fedpkg push
   • fedpkg build
3. Submit an update for F17.
   • fedpkg update
4. When bodhi emails you saying that your F17 update can be pushed to stable, push it.
5. Put the relevant trac ticket in "add to build" state, noting which of the above steps you have completed.

ARM is intentionally left out of the picture here. Your package will be built automatically on ARM after a day or so. (Sometimes the build manager will build it manually in order to avoid the wait).

Packages are currently in frozen state, so it is important to communicate in trac the request to break the freeze and get a package included - it will not be pulled in automatically.

Non-Fedora package inclusion process

For packages that are maintained outside of Fedora, the inclusion process is:

1. Build, test and publish the RPM (including source RPM) inside the relevant RPM dropbox.
2. Put the relevant trac ticket in "add to build" state with a request for inclusion

Packages are currently in frozen state, so it is important to communicate in trac the request to break the freeze and get a package included - it will not be pulled in automatically.

Activity inclusion process

Now that we are in bug-fixing stages, activities have been frozen. However, we will take activity updates where they fix important bugs. The process is:

1. CC 'dsd' on a relevant ticket
   • This can be on SL or OLPC trac, and it can either be in a ticket where an activity bug was found and fixed, or it can be in a dedicated "Please update HelloWorld to v4" type ticket.
2. Add a comment on the ticket requesting inclusion in 12.1.0.

As for which fixes we want to include:

• We should focus on fixing clear, interesting and important bugs.
• The activity and the relevant functionality must already be tested by you on the most recent build
• The code change, and all other code changes between the current version and the new one must already be reviewed by you
• The release manager will repeat the testing and code review
• It's fine (at this stage) if the activity has changes unrelated to the interesting bug in question, but (in the case where you are the maintainer) its preferred (not required) to limit changes to only the bug in question.
• Please keep our workload down - focus on important bugs only, we're not looking to incorporate every single bug fix produced by the community at this stage. Every change requires review and testing and requires effort from multiple people, and (being honest programmers) our bugfixes introduce new bugs on a regular basis, further increasing the workload.

Bug reports

We are now looking for bug reports on all levels - system, Sugar, activities, ...

Sugar-specfic bugs and activity issues should be filed at http://bugs.sugarlabs.org. System-related bugs should be filed at http://dev.laptop.org. If in doubt, ask on the mailing list first, or file at OLPC and let us take care of it for you.

For OLPC tickets, leave the milestone field blank but mention clearly that you are testing 12.1.0, your bug report will then be triaged into the appropriate place.