9.1.0 requirements: Difference between revisions

From OLPC
Jump to navigation Jump to search
No edit summary
 
(287 intermediate revisions by 29 users not shown)
Line 1: Line 1:
<b><font color=red><big>For information on current and future OLPC software releases, see [[Releases]]</big></font></b>
= Release 9.1.0 Overview =
This is a time based release per the process at: <br>
[[Release Process Home]]


[http://lists.laptop.org/pipermail/devel/2009-February/023079.html 9.1.0 was cancelled]. However, many of the planned features found their way into newer OLPC OS [[releases]].
The process is not final. It is a set of rough guidelines still being worked out and subject to change.


{{Deprecated}}
The goal (not confirmed) is to make this release public sometime between December, 2008 and June, 2009.
{{RightTOC}}


This page defined the requirements, schedule and overall planning for a release 9.1.0.
== Technical Strategy ==
Faster, more robust, better integration of activities, more collaboration...


[[Feature requests]] tracked features, requirements, and requests, and plans by customer;
See requirement definition at [[Requirements]]
[[Feature roadmap]] tracked all software features by technical strategy.


See also notes from [[XOcamp 2]] technical conference.
== Sales - Deployment Strategy ==
See customers below.


= Overview =
== Pedagogical Strategy ==
This release is the first major new feature release after [[8.2.0]] Its is the first of two major feature releases we want to deliver in 2009. The target date for this release is March 7, 2009 (Note: date and feature set not final and subject to change).
....


This release must run on all existing XO hardware.
= Target Deployments =
See: [[User talk:Gregorio#Shipment Quantities and Languages]]


= Technical strategy =
== Uruguay ==
This section outlines the main areas of technology that we will focus on improving. All of the specific features should address one of these primary concerns. The choice of these comes from listening to users and deployment leads and hearing what their concerns are.
Spanish
100K x XOs?


The strategic priorities are to make the XO work the way users expect and help get the XO deployed more quickly in more countries.
== Peru ==
Spanish
100K x XOs?


== Easier to deploy and maintain ==
== Mexico ==
'''Easier to deploy''' focuses on facilitating the imaging of XOs, their activation, the installation and extension of custom leases and anything else needed to get the XOs from the factory in to the schools.
Spanish <br>
Some examples include: <br>
50K x XOs
# Creating customization images (to include language packs and rpms)
# Installing images in the warehouse
# Activation and Leases


'''Easier to maintain''' focuses on upgrading, keeping the XOs working, monitoring them and allowing recovery of data from errors.
== Mongolia ==
Some examples include: <br>
Mongolian? <br>
# Upgrade in the schools
20K x XOs
# Updating activities
# Reducing power consumption


== Greater reliability and performance ==
== Rwanda ==
* No loss of data. Fewer crashes and fewer open bugs than 8.2 and previous releases. See also: http://wiki.laptop.org/go/User:Gregorio/8.2.0_release_criteria
French 10K x XOs
* At the time of the release, works the way the manual says it works. That is, all of the things explained and listed in these manuals must work as described. <br>
http://www.laptop.org/manual/ <br>
* Better performance includes faster GUI interactions. Includes launching activities, switching from one activity to another, using the journal and using the frame. GUI, activities, back ups.


== Haiti ==
== Primary release drivers ==
Date: March 7, 009
Kreyol <br>
13K x XOs


Customers: [[Rwanda]], [[Peru]], [[Ethiopia]], [[Uruguay]], [[Haiti]], [[OLPC Birmingham]], [[Mongolia]], [[Ghana]], [[Dubai]], [[Lebanon]]
== Ethiopia ==
Amharic <br>
5k x XOs


== Cambodia ==
== Features ==
Khmer <br>
1000 XOs


== Afghanistan ==
=== Top Priority ===
The following are critical must-deliver features for this release. The categories are listed in priority order. <br>
Dari <br>
3000 x XOs


'''See all top priority features with details on one page [[Feature_roadmap/Page_of_all_features_that_target_9.1.0|here]]'''
== Thailand ==
Thai <br>
500 x XOs


Feature categorized in to the four main areas are list below: <br>
== India ==
Devanagari <br>
500


1 - Rebasing on F10 and allowing "regular" Fedora window managers and applications to run. <br>
== Brazil ==
[[Feature roadmap/Rebase on Fedora 10|Rebase on Fedora 10]] <br>
Portuguese <br>
[[Feature_roadmap/Run_Fedora_applications_on_XO|Run_Fedora_applications_on_XO]] <br>
200 x XOs


2 - Activation/lease/signing/image customization. A subset of the features in [[:Category:Security, activation and deployability]] <br>
== Arabic ==
[[Feature_roadmap/Activation_lease_security|Activation_lease_security]] <br>
Sabra and Shatila (Lebanon) <br>
[[Feature_roadmap/Image_customization|Image_customization]] <br>
500 x XOs
[[Feature_roadmap/Image_signing_key_delegation|Image_signing_key_delegation]] <br>
[[Feature_roadmap/Faster_imaging|Faster_imaging]] <br>
[[Feature_roadmap/Activation_via_wireless|Activation_via_wireless]] <br>


3 - Power management. Some key features in [[:Category:Power management]] <br>
== Oceania ==
[[Feature_roadmap/Improved_battery_life|Improved_battery_life]] <br>
Enlish? <br>
[[Feature_roadmap/No_power_regressions|No_power_regressions]] <br>
500 x XOs
[[Feature_roadmap/Shutdown_menu|Shutdown_menu]] <br>


4 - Localization/translation. <br>
== Italy ==
[[Feature_roadmap/SCIM]] <br>
Italian <br>
[[Feature roadmap/Better Arabic Support]] <br>
600 x XOs
[[Feature roadmap/RTL support]] <br>


== Turkey ==
=== Second Priority ===
These are very important features which benefit priority deployments. Any available engineer is encouraged to help with these, provided it does not take time away from working on the top priority features.
Turkish? <br>
15k x XOs


# Performance http://wiki.laptop.org/go/Feature_roadmap/General_UI_sluggishness
== Senegal ==
# Synchronous collaboration (reliability) http://wiki.laptop.org/go/Feature_roadmap/Synchronous_collaboration
French <br>
# Asynchronous collaboration http://wiki.laptop.org/go/Feature_roadmap/Asynchronous_collaboration
1000 x XOs
# Flash


== Argentina ==
= Activities =
Sign in to the wiki and leave your suggestion for any activities you think we should install by default here.


Each activity will need a maintainer, latest version, and a [[Test_cases|test case]] to be considered for the release.
== Equitorial Guinea ==


The maintainer is the [[Property:Contact person]] on the activity's wiki page (click [Edit with form] and modify "Maintainer's user page" to update). The .xo URL and version for 9.1.0 should be in the activity's Activities/''My activity''_(latest) fragment, e.g. [[Activities/Chat_(latest)]]. ''(If this latest version is incompatible with [[8.2.0]], make sure that [[Activities/G1G1/8.2]] does not reference it.)''
== Panama ==
Spanish


{|class="wikitable"
== Birmingham ==
|+ '''Default Activities for 9.1.0'''
English
|-
!Name
!"(latest)" fragment
!Documentation
!URL to Test Case
!License status
!Status
! Comments
|-


|-
== South Carolina ==
|[[Chat]]
English
|[[Activities/Chat (latest)]]
|[[Chat]]
|
|GPLv2+
|Accepted pending final tests.
|


|}
== New York City ==
English


''' Please help add all potential activities to this table. Add as much info as you have and leave the rest blank.'''
= Priorities from Deployments =
Should list what, who and why on each item. Should link to detailed requirements and use cases eventually.


=== Nominations ===
See [[User talk:Gregorio#Priorities from Carla]]
''(sign your nominations with <tt><nowiki>--&nbsp;~~~~</nowiki></tt>)''
* I nominate [[Develop]]. Version and test case upcoming. [[User:Homunq|Homunq]] 15:04, 10 December 2008 (UTC)


* I nominate [[StarChart]] (http://www.wa1gsf.net/downloads/XO/StarChart-5.xo) version 5 maintained by [[User:davewa|David Wallace]], licensed under GPLv2+. Note that Version 6 is in development and will have 2 more features and should be i18n-ed. Release of v.6 was planned for 1/1/09 but is slipping (because I don't understand how to get the mouse click event). -- [[User:Davewa|Davewa]] 19:39, 10 December 2008 (UTC); edited Jan 6, 2009
== Activity Related Work ==
* I nominate SimCity http://wiki.laptop.org/go/Simcity and/or Micropolis, preferably Micropolis if we can get good response from a maintainer. [[User:Gregorio|Gregorio]] 15:21, 11 December 2008 (UTC)
Requests from Birmingham. <br>
New activities: <br>
Firefox, Flash, mplayer <br>
A spreadsheet (I'm going to use gnumeric until Socialcalc is ready for production) <br>
A more full featured pdf reader (yes, I know there's the Read activity, but I'm planning on installing the full evince and making sure Firefox can open pdfs with it) <br>
A document editor the user can insert images into (the full Abiword would be great for this, but the current workaround [after editing a file] is to open write, then hit ctrl+n) <br>


* I nominate [[Image_Viewer]] and [[Jukebox]]. [[User:Sayamindu|Sayamindu]] 20:30, 17 December 2008 (UTC)
General requests: <br>
I have got to be able to sugarize third party applications.


=== Lists of possible candidate activities ===
== Longer Battery Life ==
* [[Activities/G1G1/8.2]] is the list of activities that the [[Software updater]] installs and upgrades on [[G1G1]] machines running [[Release notes/8.2.0|Release 8.2.0]].
=== Requirement Definition ===
* The following activities have [[Property:Activity group|Activity group]] Activities/G1G1 checked on their wiki page, as of 2008-12-10 the names exactly match [[Activities/G1G1/8.2]] (good!):
[[Requirements#Power Management Requirements]]
: {{#ask: [[Activity group::Activities/G1G1]] | format = list}}
* [[Activity queries]] has a sortable list of every wiki page in [[:Category:Activities]], and other counts and queries of activities.
* As of December 3rd 2008, the following activities have test pages but aren't in the Activities/G1G1 list above.
: [[Clock]], [[Colors!]] (was Color?) [[Comic]] (not sure what this is), [[GCompris]]-Chess, [[GCompris]]-Sudoku, [[License]], [[x2o]]
:: (The full list of activities with test pages is<br>Analyze, Browse, Calculate, Clock, Color, Comic, Distance (now Acoustic Tape Measure), Etoys, Gcompris-Chess, Gcompris-Sudoku, Help, Implode, Log, Maze, Measure, Memorize, Moon, Paint, Pippy, Read, Record, TurtleArt, x2o )
* During [[8.1.0]] ("Update.1") planning around March 2008, [[Elements]], [[License]], and [[Xo-get]] were to be considered for a future [[G1G1 activity pack]]
* The following activities are (misplaced) in [[:Category:Activity bundle]] but don't use the the semantic form; so they have a .xo file yet are not in many queries
:: [[Comic Maker]], [[Firefox]], [[Games/Productive]], [[HablarConSara]], [[HelloMesh]], [[Image Viewer]], [[Lambda]], [[Pacman]], [[Physics]], [[PlayGo]], [[Rollcats]], [[Turtle Art/lang-es]], [[XO-GCC]], [[Xo-get/Xo-get-gtk]], [[XoIRC]]
* [[Activities]] claims to be the full set of OLPC hosted activities.
* [[Activities/All]] is inaccurately titled, it's a manually-updated list of activities.
* a previous listing of activities and status on Google Docs (on the "Matrix deprecated" tab) is at http://spreadsheets.google.com/ccc?key=p_Xhb6KcXLyEViA50CnCaDg&hl=en


= Schedule =
=== Who requested ===
* December 5 - Agree and document on Trac usage. Tag critical features for 9.1.0 on roadmap page and linked on 9.1.0 page.
Kim
* December 12 - Trac scrub underway bugs targeted for inclusion in 9.1.0 flagged. First pass at requirements definition done for all main features.
* December 19 - Scrub of all past Trac bugs completed. Last round of comments on requirements. First pass at specification write ups. Rough scoping recorded and engineers assigned.
* December 24 - Branch strategy defined and check in branch chosen (Joyride?). Weekly bug triage begun.
* January 7 - Presentations for XO Camp shared. All specifications posted and reviews scheduled. Code reviews scheduled as needed. Designs of major features shared with key customers for confirmation and comment.
* January 12 to 15 - XO Camp held. http://wiki.laptop.org/go/XOcamp_2.
* January 16 - Sugar 0.83 string/API/feature freeze. See: http://sugarlabs.org/go/DevelopmentTeam/Release/Roadmap
* January 23 - Code for all major features in branch. Alpha test begun. Daily bug triage begun. Something similar to [[Release_Process_Home#Steam_Milestone|Steam]] milestone announced.
* January 30 - Beta test begun. Must fix bugs listed in Trac. Release notes started.
* February 9 - First Release Candidate built. Regression test defined. List of target activities to include in default image chosen. Something similar [[Release_Process_Home#Water_Milestone|Water]] milestone announced.
* February 16 - Second release candidate chosen. Default activities tested. Something similar to [[Release_Process_Home#Ice_Milestone|Ice]] announced. Penultimate regression test set. Release notes new feature section, final edit. Open bugs section started.
* February 28 - Final release candidate chosen. Image sent to Quanta for factory verification. Final regression test done. Upgrade tests done for release notes.
* March 7 - Quanta ships first XO with new image. Final release notes written and reviewed. On time release!
* March 8 - Release announcement sent out.


== Touchpad ==
=== Requirement Defintion ===


Possible QA milestones: <br>
=== Who requested ===
- Start creating test cases for each feature. <br>
Improved in 8.2.0 <br>
- Finish creating test cases. <br>
Priority request from Carla <br>
- Execute all test cases once. <br>


First stab at schedule done by [[User:Gregorio|Gregorio]] 18:50, 2 December 2008 (UTC)
== Collaboration ==
=== Requirement Definition ===
Allow for intuitive mesh connection and activity-sharing. <br>
Must support first two use cases defined at: [[Use Cases#Collaboration Examples]]


= Standard information =
[[Requirements#Mesh / Connectivity_Requirements]]
<small>(These are all semantic annotations that other pages such as [[Releases]] can query.)</small>


Primary objectives:
[[Requirements#AbiWord Sharing Requirements]]
* was to have been a time-based release in 2009 per the process at: [[Release Process Home]].

* Deployability
=== Who requested ===
Priority request from Carla and David. <br>
Also several thread on OLPC-Sur. <br>
Peru technical leaders <br>

=== Inter-school communication ===
What I see as most missing and most necessary is a safe space for collaboration between students at different schools, even in different
countries. <br>
http://lists.laptop.org/pipermail/localization/2008-July/001249.html

== Performance and Reliability ==
Faster activity launching <br>
6472

- File/activity open

- File save

- Task switching

- Activity or main GUI responsivesness to cursor

- Hardware

=== Suggestions from Marco ===
1 General UI sluggishness.

Without going too deep into the stack, I think there is a lot of space or improvement even in the python code. Michael mentioned icon cache
and mesh view layout, both areas of the code that didn't get any love for a while and where I'm convinced we can make big/quick progresses.
I'm planning to spend a lot of my time on this in the next release cycle.

2 Datastore performance.

I'd expect improving jffs2 performance would be a big win there. The UI can probably be smarter in the way it uses the datastore too Finally we
can try to improve at the datastore level, but there we clash with the rewrite plans. I think we should find an agreement on the datastore design and just try and get it done for 9.1.0, there are two many things blocking on it.

We need to allocate time and focus to do some good profiling and then attack the problems we find. That's why I'm advocating for the next
Sugar release cycle to be largely about perfomance improvements, bug fixes and code refactoring, with the possible exception of the datastore
rewrite.

== File Management ==


== Security Activation and Deployability ==
=== School server push of XO images ===

Requirement: The XO should be able to get the latest build from the school
server

* The administrator makes the desired build available in the designated
directory. When ready, the administrator requests to 'push' the build to all
laptops as they come on line. Both of these activities should be an
easy-to-use UI at the school server.

* A test requirement is the ability to create a white list of serial numbers
that should be upgraded with the push.

Source: Peru

=== Activation lease security feature ===
Requirement - if the laptop is stolen, and doesn't contact its local school
server within some period time (activation lease time); then it will tell
the user that it will not activate on next boot and provide date and time.

Requirement - it is not possible to set the date on the laptop to keep it
within the lease period or to force it to outside the lease management. This
might mean you cannot change the date or there is no root access, or it
might mean an alternate time source is used... (not trying to solve the
problem, just want to note this requirement).

Source: Peru

=== XO Monitoring ===

Requirement: Provide XS database and an API so that countries can create reports and monitoring for various aspects of XOs:

* Version of code
* Which laptops are being seen each day
* Total number of laptops being seen per day
* Number of laptops accessing the internet
* List of URLs being accessed
* List of URLs per laptop
* Which activities are being used per laptop
* Number of minutes in each activity per laptop; can we determine (and subtract) idle time?
* Number of minutes in each activity within and outside of school hours (perhaps this means we capture the 'start' time of each activity and allow the reporting to decide if this is during or outside of school hours).

Background and implementation ideas: <br>
I think there might be some work in the XO to make the information available; and a database and API spec from the school server. This is not as high priority for their deployment as the passive lease management, but I believe this feature will be important for any deployment. We should try to get feedback from other deployments as to the information we want to collect.

Source: Peru

=== Customized Startup Images ===
Must allow changing startup picture by copying an image to the XO. This should not require any OLPC developer intervention and should not need a new or special build.

http://lists.laptop.org/pipermail/devel/2008-July/017299.html

Source: Colombia and Mexico before.

May be fixed in 8.2.0. See: http://wiki.laptop.org/go/Tweaking_the_boot_animation

== Network Manager Connections ==
G1G1 encryption.

802.11i (AKA 802.1x) Uruguay


== Unadorned and unedited user feedback ==
6th grade kids feedback on build 656: <br>
http://sextosdela37.blogspot.com/2008/04/analizando-el-uso-de-las-laptop-en-el.html

Priorities from Carla: [[User talk:Gregorio#Priorities from Carla]]

Comments from technical user in Ecuador: <br>
http://lists.laptop.org/pipermail/olpc-sur/2008-July/000408.html

== GUI and Usability ==
Request from Uruguay for HW alerts: <br>
http://lists.laptop.org/pipermail/sugar/2008-July/007086.html

Designs ideas from Scott and Eben in thread.
e.g. I hope our alert system will use the freedesktop.org standard:
http://www.galago-project.org/specs/notification/index.php

= Priorities from Engineering =
*{{ticket|4662}} needed for better activity capabilities.
*{{ticket|2447}} caps lock
*{{ticket|1997}} flashing in write
*NAND full crashes system
*I think analyzing performance of non-JFFS2 file systems and picking a replacement should be a high-priority item for 9.1 update.
*from: http://lists.laptop.org/pipermail/devel/2008-July/016994.html
*{{ticket|2188}} sharing files and resources between activities

Fedora 10 rebase?

== Faster Upgrade ==
Make it easier to upgrade many laptops in the field. Several cases: <br>

Updates:<br>
# XOs in warehouse need update before being shipped.
# XOs in school with no WAN
# XOs in school with thin WAN pipe (BW <= 1Mb/s)
# XOs in in school with good WAN (BW >= 1Mb/s)

Possibly sub-variants of in school case for Mesh, Wireless AP, XS.

== Localization ==

Spell checking in as part of l10n. (Sayamindu)

Allow adding a language after the build is created and without OLPC intervention

== e-mail from Ben S ==
http://lists.laptop.org/pipermail/sugar/2008-July/007390.html

1. The datastore <br>
Sugar's design calls for a centralized rich data storage system, the
datastore. The datastore provides secure, limited file access to
Activities, manages file metadata, maintains a differentially compressed
history of all work, ensures reliable backups to a trusted server, and
mediates the connection to removable media. Every one of these features
is crucial to Sugar's functioning, and almost none are really working at
this time. We cannot afford another release based on the present
datastore, as it fails to implement the features we require, and is
unreliable even in the features it supposedly implements.

Solution: <br>
There have, at this point, been at least five distinct proposals for a
next-generation datastore design, all differing in underlying
implementation and user-facing functionality. We need to have a Once And
For All datastore summit, draw up a compromise datastore design, and
implement it. We can do this by 9.1.0, if we are willing to make it a
priority.

Additional Links:
* [[Sugar.datastore.datastore|The current datastore]]
* [[Olpcfs]]
* [http://lists.laptop.org/pipermail/community-news/2008-January/000095.html Sugar Datastore Summit in January] (item 10).
* [http://dev.laptop.org/git?p=users/mstone/sds;a=blob;f=README;hb=HEAD SDS] (stands for Simple Data Store or possibly something else)
* [http://lists.laptop.org/pipermail/devel/2008-March/012047.html Git-based] datastore design

2. OS Updates <br>
We now have hundreds of thousands of laptops deployed in the field,
running a variety of OS versions. OLPC cannot afford to support a
multitude of decrepit versions, and children cannot afford to suffer
defects that have long since been fixed. We need a reliable, fast,
update system that does not rely on the network, so that children
everywhere can move to the
latest version of Sugar without losing their data. The update system must
support tremendously invasive upgrades, like repartitioning the NAND and
replacing JFFS2, because we expect to do this in short order.

Solution: <br>
A secure usb autoreinstallation stick is required. It is not technically
challenging to implement, but it must be made a priority, and then be made
widely available and idiot-proof.

3. File Sharing <br>
Students and teachers have no good way to distribute files directly from
one person's Journal to another. If all Activities that open a file do
not implement Collaboration, then there is simply no way to transfer that
file over the network. This is the most basic possible network
functionality --- FTP was standardized in 1971 --- but it is completely
missing from our system.

Solution: <br>
A number of technical proof-of-concept programs have been written for
distributing files, using methods like HTTP over stream tubes and
Cerebro's Teleport. There is an excellent set of [[Specifications/Object_Transfers|UI mockups for this]
functionality. All that is left is to Get It Done.

Additional Links:
* [[Read]]
* [http://lists.laptop.org/pipermail/sugar/2008-March/004499.html Distribute]
* [[Summer_of_Code/Ideas#Publication_and_Journal_sharing|A Summer of Code application]]

4. Activity Modification <br>
A keystone of the Sugar design has always been the user's ability to edit
any Activity, and to cement this a "View Source" key was designed right
into the hardware. This functionality is simply missing, and that
prevents us from making our principal claim regarding an emphasis on user
modification.

Solution: <br>
"Develop" must be polished, finished, and included by default. This will
require modifications to the core system, in order to support an endless
variety of slightly modified Activities. It will also require work on the
Develop program itself. If volunteer efforts are not moving fast enough, OLPC
must ensure that someone is working on the problem as a professional.

Additional links:
* [[Develop]]
* [[Old_Develop_activity|Previous, stalled attempt at Develop]]
* [[View_Source|Current status of "view source"]]
* [[OLPC_Human_Interface_Guidelines/The_Laptop_Experience/View_Source]]
* [[EAG_The_Laptop_Experience:_View_Source]]

5. Bitfrost <br>
Sugar, as it currently stands, is among the least secure operating systems
ever, far less secure than any modern Linux or Windows OS. I can easily
write an Activity that, when run by the user, escalates to root privileges
and does anything I like with the system. Given Sugar's competitive
status against Windows XO, this failing threatens the very existence of
the project. The Sugar designs have long stated that safely running
untrusted code from a classmate is a key goal for learning, but the
current software accomplishes precisely the opposite.

Solution:<br>
NO ONE IS WORKING ON BITFROST. That's right. Everyone who was working on
Sugar security (after activation) has either left OLPC or moved into
another role. Someone must be assigned to continue the security work, or
it will certainly never make progress. Anyone who _does_ take on this
challenge will start from a much better position than previously,
because many of the Vserver features have moved into the mainline kernel
over the last few versions. The kernel now contains a number of new,
powerful isolation and control primitives.

6. Power management <br>
Power management is the raison d'etre of the XO hardware. It is the
reason that the hardware took four times as long to develop as a standard
laptop, the reason that we suffer from the closed Marvell operating
system, the reason that OLPC's best engineers flew around the globe
fighting with details of voltage and capacitance. In an increasingly
crowded low cost laptop market, it is one of OLPC's few remaining
distinctions. As of 8.2.0, aggressive suspend is available, but its
functionality is still far from the target.

Solution: <br>
Enabling aggressive power management is a major challenge, perhaps more
difficult than anything else on this list. We know what is required for a
first step: ensure that we can reliably wake up from a hardware timer.

This single feature would be enough to enable a basic sleepy approach
that is truly transparent to software. Other work includes removing USB
from the critical path on resume. Aggressive suspend may not be ready for
9.1.0, but if no one is working on it it will never be ready.

= Key Modules and Relevant Module Roadmaps =


Lead customers: Peru, Ethiopia, Uruguay, Haiti, Mongolia, Nepal and Rwanda
[[Category:Releases]]
[[Category:Releases]]

Latest revision as of 15:56, 10 February 2011

For information on current and future OLPC software releases, see Releases

9.1.0 was cancelled. However, many of the planned features found their way into newer OLPC OS releases.

Stop hand.png WARNING:
The content of this section is considered
DEPRECATED and OBSOLETE
It is preserved for historical or documenting reasons.


This page defined the requirements, schedule and overall planning for a release 9.1.0.

Feature requests tracked features, requirements, and requests, and plans by customer; Feature roadmap tracked all software features by technical strategy.

See also notes from XOcamp 2 technical conference.

Overview

This release is the first major new feature release after 8.2.0 Its is the first of two major feature releases we want to deliver in 2009. The target date for this release is March 7, 2009 (Note: date and feature set not final and subject to change).

This release must run on all existing XO hardware.

Technical strategy

This section outlines the main areas of technology that we will focus on improving. All of the specific features should address one of these primary concerns. The choice of these comes from listening to users and deployment leads and hearing what their concerns are.

The strategic priorities are to make the XO work the way users expect and help get the XO deployed more quickly in more countries.

Easier to deploy and maintain

Easier to deploy focuses on facilitating the imaging of XOs, their activation, the installation and extension of custom leases and anything else needed to get the XOs from the factory in to the schools. Some examples include:

  1. Creating customization images (to include language packs and rpms)
  2. Installing images in the warehouse
  3. Activation and Leases

Easier to maintain focuses on upgrading, keeping the XOs working, monitoring them and allowing recovery of data from errors. Some examples include:

  1. Upgrade in the schools
  2. Updating activities
  3. Reducing power consumption

Greater reliability and performance

  • No loss of data. Fewer crashes and fewer open bugs than 8.2 and previous releases. See also: http://wiki.laptop.org/go/User:Gregorio/8.2.0_release_criteria
  • At the time of the release, works the way the manual says it works. That is, all of the things explained and listed in these manuals must work as described.

http://www.laptop.org/manual/

  • Better performance includes faster GUI interactions. Includes launching activities, switching from one activity to another, using the journal and using the frame. GUI, activities, back ups.

Primary release drivers

Date: March 7, 009

Customers: Rwanda, Peru, Ethiopia, Uruguay, Haiti, OLPC Birmingham, Mongolia, Ghana, Dubai, Lebanon

Features

Top Priority

The following are critical must-deliver features for this release. The categories are listed in priority order.

See all top priority features with details on one page here

Feature categorized in to the four main areas are list below:

1 - Rebasing on F10 and allowing "regular" Fedora window managers and applications to run.
Rebase on Fedora 10
Run_Fedora_applications_on_XO

2 - Activation/lease/signing/image customization. A subset of the features in Category:Security, activation and deployability
Activation_lease_security
Image_customization
Image_signing_key_delegation
Faster_imaging
Activation_via_wireless

3 - Power management. Some key features in Category:Power management
Improved_battery_life
No_power_regressions
Shutdown_menu

4 - Localization/translation.
Feature_roadmap/SCIM
Feature roadmap/Better Arabic Support
Feature roadmap/RTL support

Second Priority

These are very important features which benefit priority deployments. Any available engineer is encouraged to help with these, provided it does not take time away from working on the top priority features.

  1. Performance http://wiki.laptop.org/go/Feature_roadmap/General_UI_sluggishness
  2. Synchronous collaboration (reliability) http://wiki.laptop.org/go/Feature_roadmap/Synchronous_collaboration
  3. Asynchronous collaboration http://wiki.laptop.org/go/Feature_roadmap/Asynchronous_collaboration
  4. Flash

Activities

Sign in to the wiki and leave your suggestion for any activities you think we should install by default here.

Each activity will need a maintainer, latest version, and a test case to be considered for the release.

The maintainer is the Property:Contact person on the activity's wiki page (click [Edit with form] and modify "Maintainer's user page" to update). The .xo URL and version for 9.1.0 should be in the activity's Activities/My activity_(latest) fragment, e.g. Activities/Chat_(latest). (If this latest version is incompatible with 8.2.0, make sure that Activities/G1G1/8.2 does not reference it.)

Default Activities for 9.1.0
Name "(latest)" fragment Documentation URL to Test Case License status Status Comments
Chat Activities/Chat (latest) Chat GPLv2+ Accepted pending final tests.

Please help add all potential activities to this table. Add as much info as you have and leave the rest blank.

Nominations

(sign your nominations with -- ~~~~)

  • I nominate Develop. Version and test case upcoming. Homunq 15:04, 10 December 2008 (UTC)

Lists of possible candidate activities

{{#ask: Activity group::Activities/G1G1 | format = list}}
  • Activity queries has a sortable list of every wiki page in Category:Activities, and other counts and queries of activities.
  • As of December 3rd 2008, the following activities have test pages but aren't in the Activities/G1G1 list above.
Clock, Colors! (was Color?) Comic (not sure what this is), GCompris-Chess, GCompris-Sudoku, License, x2o
(The full list of activities with test pages is
Analyze, Browse, Calculate, Clock, Color, Comic, Distance (now Acoustic Tape Measure), Etoys, Gcompris-Chess, Gcompris-Sudoku, Help, Implode, Log, Maze, Measure, Memorize, Moon, Paint, Pippy, Read, Record, TurtleArt, x2o )
Comic Maker, Firefox, Games/Productive, HablarConSara, HelloMesh, Image Viewer, Lambda, Pacman, Physics, PlayGo, Rollcats, Turtle Art/lang-es, XO-GCC, Xo-get/Xo-get-gtk, XoIRC

Schedule

  • December 5 - Agree and document on Trac usage. Tag critical features for 9.1.0 on roadmap page and linked on 9.1.0 page.
  • December 12 - Trac scrub underway bugs targeted for inclusion in 9.1.0 flagged. First pass at requirements definition done for all main features.
  • December 19 - Scrub of all past Trac bugs completed. Last round of comments on requirements. First pass at specification write ups. Rough scoping recorded and engineers assigned.
  • December 24 - Branch strategy defined and check in branch chosen (Joyride?). Weekly bug triage begun.
  • January 7 - Presentations for XO Camp shared. All specifications posted and reviews scheduled. Code reviews scheduled as needed. Designs of major features shared with key customers for confirmation and comment.
  • January 12 to 15 - XO Camp held. http://wiki.laptop.org/go/XOcamp_2.
  • January 16 - Sugar 0.83 string/API/feature freeze. See: http://sugarlabs.org/go/DevelopmentTeam/Release/Roadmap
  • January 23 - Code for all major features in branch. Alpha test begun. Daily bug triage begun. Something similar to Steam milestone announced.
  • January 30 - Beta test begun. Must fix bugs listed in Trac. Release notes started.
  • February 9 - First Release Candidate built. Regression test defined. List of target activities to include in default image chosen. Something similar Water milestone announced.
  • February 16 - Second release candidate chosen. Default activities tested. Something similar to Ice announced. Penultimate regression test set. Release notes new feature section, final edit. Open bugs section started.
  • February 28 - Final release candidate chosen. Image sent to Quanta for factory verification. Final regression test done. Upgrade tests done for release notes.
  • March 7 - Quanta ships first XO with new image. Final release notes written and reviewed. On time release!
  • March 8 - Release announcement sent out.


Possible QA milestones:
- Start creating test cases for each feature.
- Finish creating test cases.
- Execute all test cases once.

First stab at schedule done by Gregorio 18:50, 2 December 2008 (UTC)

Standard information

(These are all semantic annotations that other pages such as Releases can query.)

Primary objectives:

  • was to have been a time-based release in 2009 per the process at: Release Process Home.
  • Deployability

Lead customers: Peru, Ethiopia, Uruguay, Haiti, Mongolia, Nepal and Rwanda