9.1.0 requirements: Difference between revisions

From OLPC
Jump to navigation Jump to search
No edit summary
 
(110 intermediate revisions by 13 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>

[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]].

{{Deprecated}}
{{RightTOC}}
{{RightTOC}}


This page defined the requirements, schedule and overall planning for a release 9.1.0.
This page defines the requirements for release 9.1.0. It is modeled after a Product Requirements Defintion document which intends to define who the users are, what they need and what technology needs to built in order to achieve the product and user goals.

[[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 =
= Overview =
This release is the first major new feature release after 8.2. Its is the first of two major feature releases we want to deliver in 2009. The target date for this release is March 15, 2009 (Note: date and feature set not final and subject to change).
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 C1, C2, C3 and the new C4 motherboards. (check exact list and add URL)
This release must run on all existing XO hardware.


= Technical Strategy =
= 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.
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.
The first two strategic priorities are focused on making the XO work the way users expect it to and helping get the XO deployed more quickly in more countries. The third is also an area where we have unmet expectations. However, there have been many different understandings of what collaboration means. This release should clarify a few specific examples of collaboration and ensure that those are supported and reliable. We have a window of opportunity to build something completely new and original in this space. If we come up with a new work flow here, it must be reliable and usable within the constraints of the existing technology.


== Greater Reliability and Performance ==
== 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.
* 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
Some examples include: <br>
* 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://en.flossmanuals.net/Sugar/ <br>
http://en.flossmanuals.net/XO <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.

== Easier to Deploy and Maintain ==
Quick, clean way to upgrade XOs in the field. Covers several cases including
# Creating customization images (to include language packs and rpms)
# Creating customization images (to include language packs and rpms)
# Installing images in the warehouse
# 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.
Some examples include: <br>
# Upgrade in the schools
# Upgrade in the schools
# Updating activities
# Updating activities
# Reducing power consumption
# Activation and Leases


== Greater reliability and performance ==
Each should be optimized for case where XS is available, Internet only available and no Internet (AKA USB). Must make it easier to load new image, latest translations, activities and content bundles.
* 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. <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.


== Collaboration ==
== Primary release drivers ==
Date: March 7, 009
# More fully defined activity sharing paradigms, especially with write.
# At least one data collection and analysis application supported with an architecture defined for others to follow.
# Easier file sharing between XOs and easier to generate and upload user generated content to the internet.
# Workflow defined and tools developed for students to collaborate on projects. Must also maintain a history of projects and people who worked on them
# Greater scale for number of XOs that can collaborate.
# Segregate users so that all the available channels and spectrum are used.


Customers: [[Rwanda]], [[Peru]], [[Ethiopia]], [[Uruguay]], [[Haiti]], [[OLPC Birmingham]], [[Mongolia]], [[Ghana]], [[Dubai]], [[Lebanon]]
= Pedagogical Strategy =
....


== Features ==
= Primary Release Drivers =
Date:<br>
The goal (not confirmed) is to release at the end of Q1 (March 2009).


=== Top Priority ===
Customers<br>
The following are critical must-deliver features for this release. The categories are listed in priority order. <br>
Schools that will be deploying in Aug-Sept of 2009.


'''See all top priority features with details on one page [[Feature_roadmap/Page_of_all_features_that_target_9.1.0|here]]'''
Features<br>


Feature categorized in to the four main areas are list below: <br>
= Target Deployments =
See: [[User talk:Gregorio#Shipment Quantities and Languages]]


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


2 - Activation/lease/signing/image customization. A subset of the features in [[:Category:Security, activation and deployability]] <br>
http://wiki.laptop.org/go/OLPC_Uruguay
[[Feature_roadmap/Activation_lease_security|Activation_lease_security]] <br>
[[Feature_roadmap/Image_customization|Image_customization]] <br>
[[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>
From Emiliano and Erik in e-mail:<br>
[[Feature_roadmap/Improved_battery_life|Improved_battery_life]] <br>
Allow Uruguay to sign their own builds so that they can take an image from us, add their customizations then sign it and deploy on the XOs with the existing OLPC provided upgrade tools (e.g. olpc-update and USB keys). <br>
[[Feature_roadmap/No_power_regressions|No_power_regressions]] <br>
[[Feature_roadmap/Shutdown_menu|Shutdown_menu]] <br>


4 - Localization/translation. <br>
An efficient system upgrade method (ideally this preserves user ata, ideally it can be done in schools with minimal manual effort). <br>
[[Feature_roadmap/SCIM]] <br>
[[Feature roadmap/Better Arabic Support]] <br>
[[Feature roadmap/RTL support]] <br>


=== Second Priority ===
: ''"Efficient" needs to be more carefully defined for this to be actionable. What resource is most precious?'' --[[User:Mstone|Michael Stone]] 00:00, 24 September 2008 (UTC)
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.


# Performance http://wiki.laptop.org/go/Feature_roadmap/General_UI_sluggishness
List of changes in the new build (to be used to decide the best time to upgrade their deployed systems). <br>
# Synchronous collaboration (reliability) http://wiki.laptop.org/go/Feature_roadmap/Synchronous_collaboration
# Asynchronous collaboration http://wiki.laptop.org/go/Feature_roadmap/Asynchronous_collaboration
# Flash


= Activities =
: ''How are the present release notes inadequate?'' --[[User:Mstone|Michael Stone]] 00:00, 24 September 2008 (UTC)
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.
Request from Uruguay for HW alerts: <br>
http://lists.laptop.org/pipermail/sugar/2008-July/007086.html <br>


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.)''
In e-mail to Greg S: <br>
Better performance of Sugar. Faster launch and close of activities, faster switching between activities, better network usage, more responsive Sugar including Journal.


{|class="wikitable"
Better Flash support. Minimum on par with FF 3 on XP.
|+ '''Default Activities for 9.1.0'''
|-
!Name
!"(latest)" fragment
!Documentation
!URL to Test Case
!License status
!Status
! Comments
|-


|-
From ErikG trip: <br>
|[[Chat]]
# Upgrade improvements including self signing
|[[Activities/Chat (latest)]]
# Faster (better performance) including flash
|[[Chat]]
# HW clock
|
# Journal to USB simplification (direct file system access) - teacher
|GPLv2+
|Accepted pending final tests.
|


|}
Notes from the peanut gallery:


''' Please help add all potential activities to this table. Add as much info as you have and leave the rest blank.'''
: ''an important question which I do not see being approached in these notes is "how are the Uruguay-based folks going to help get these patches written, tested, merged, and released?"'' --[[User:Mstone|Michael Stone]] 00:07, 24 September 2008 (UTC)


== Peru ==
=== Nominations ===
''(sign your nominations with <tt><nowiki>--&nbsp;~~~~</nowiki></tt>)''
Spanish <br>
* I nominate [[Develop]]. Version and test case upcoming. [[User:Homunq|Homunq]] 15:04, 10 December 2008 (UTC)
100K x XOs


* 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
http://wiki.laptop.org/go/OLPC_Peru <br>
* 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)


* I nominate [[Image_Viewer]] and [[Jukebox]]. [[User:Sayamindu|Sayamindu]] 20:30, 17 December 2008 (UTC)
http://wiki.laptop.org/go/Peru_activity_pack <br>


=== Lists of possible candidate activities ===
40K XOs with 656
* [[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]].
* 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!):
: {{#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 =
100K XOs with build 703
* 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 [[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.


Expected to update them each year at the beginning of the school year (Feb).


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


First stab at schedule done by [[User:Gregorio|Gregorio]] 18:50, 2 December 2008 (UTC)
'''Unedited Requests below this line <br>


= Standard information =
----

From Wad trip on April 2008 in priority order: <br>
# '''Speeding up the user interface'''
# '''Power management of the laptop to extend the life of a single battery charge.'''
# '''Improvements to the group model''' (specifically, they are looking at support of multiple groups, possibly defined and shared between users --- e.g. the teacher makes a group that is "first grade", so it is easy to invite only the first graders to join an activity.
# '''Easy backup of the laptops'''

From Kim Trip July 2008, not in priority order: <br>
'''Activation lease security feature''' <br>
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. When it gets in the vicinity of the school server again, it will be
re-activated automatically.

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.

'''School Server monitoring of XOs''' <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.

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

'''Run XS code on an XO''' <br>
Can require additional HW (e.g. SD card or USB drive) on XO. Not completely clear how important this one is to Peru.

''' Make it easier for Peru to add activities and content to a build''' <br>
This should allow them to add their own content and set of activities to a build after it is finalized and released by OLPC. The goal is for minimal or no OLPC involvement needed.

'''Requirements for groups (in priority order for Peru)'''
# Project Groups, which can be set up on the XO. These groups might stay together for days, weeks, or months - for example to discuss growing different vegetables or flowers. Generally smaller than a classroom. These groups can be created by students.
# Groups per classroom, to be set up on a School Server by someone with special access (needs a UI that can be use by a teacher with password, for instance). Use case is to be able to hand out books, vocabulary lists, etc. these would be best to do within a class.
# Groups at the grade level because each grade will have some common curriculum. This would be set up at the school server and require special access.

Other Requirements from Peru <br>
'''Allow upgrading with Kingston USB keys''' <br>
'''Make it easy to backup files before re-imaging them ''' <br>
''' Tool integrated with the XO to collect teacher feedback on trainings ''' <br>
''' Build training tools and enhance the training experience ''' <br>

== Haiti ==
Kreyol <br>
13K x XOs

== Rwanda ==
10K x XOs with English keyboards.

== Ethiopia ==
Amharic <br>

5k x XOs

They need some fixes to Amharic implementation which require a piece of software called SCIM. See http://wiki.laptop.org/go/9.1.0#Localization for more details.

== Arabic ==
Lebanon? <br>
500 x XOs

== Birmingham ==
English

== Afghanistan ==
Dari <br>
3000 x XOs

== G1G1 ==
English, other?

== Mexico ==
Spanish <br>
50K x XOs

== Mongolia ==
Mongolian? <br>
Journal entries saved it Cyrillic can be opened.
Ability to easily upgrade. So Students do not have to go to terminal and type olpc-update --usb. Build this into an "Upgrade Stick" similar to Customization Key.

20K x XOs

== Cambodia ==
Khmer <br>
1000 XOs

== Thailand ==
Thai <br>
500 x XOs

== India ==
Devanagari <br>
500

== Brazil ==
Portuguese <br>
200 x XOs

== Oceania ==
Enlish? <br>
500 x XOs

== Italy ==
Italian <br>
600 x XOs

== Turkey ==
Turkish? <br>
15k x XOs

== Senegal ==
French <br>
1000 x XOs

== Argentina ==

== Equitorial Guinea ==

== Panama ==
Spanish

== South Carolina ==
English

== New York City ==
English

== China ==
?

== Pakistan ==
?

= Priorities from Deployments =

There is more work readily at hand than we can do in time for this release. This section mentions areas to consider.

== Activity Related Work ==
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>

General requests: <br>
Make it easy to sugarize third party applications.

Support Java in Browse. Needed to see Scratch web site <br>

A better color picker in Paint & Write. Current one is "It is made for professionals to get the HTML code of the color, but it also leads to error since people need to select the color in the circle and then in the triangle. It is giving bad time to people around here [Rwanda]". <br>
From Juliano in e-mail 9/1.

Better Flash support. Minimum on par with FF on XP. From test report by Emiliano and thread on sur list.

=== Most Commonly Used Activities ===

== Longer Battery Life ==
=== Requirement Definition ===
A list of UI actions which may affect power usage: [[Requirements#Power Management Requirements]]

Background on power draw including a break down watts used in different modes: http://wiki.laptop.org/go/XO_Power_Draw#The_Numbers

Our job is to increase battery life in as many modes as possible.

Suggestions from John/Gnu for increasing battery life follow.

Significant technical actions that could reduce the laptop's power draw:

* Allow users to disable the mesh: reduces power consumption of the WiFi chip, allows the WiFi chip to enter power-save mode, and most importantly, allows lid-closed suspend to totally power off the WiFi chip. #6955

* When the lid is closed, and the mesh is off (Wifi could be off or on), the laptop should totally power off the WiFi chip. This would lengthen the duration of lid-closed suspend (before totally draining the battery) from about 8 hours to several days. WiFi with an access point rather than mesh is now the default configuration in most schools, so this would have a dramatic impact on most deployments, particularly those with off-grid power. #7879

* Put the EC into deep sleep when in a lid-closed suspend. This will cut its power from about 60ma to about 20ma (check with rsmith), which would further increase the duration of a lid-closed suspend before the battery drains.

* Speed up Resume, which currently takes more than 1000 ms. A cheap shot at this is to unload the USB bus modules. The Extreme power management setting was supposed to do this ("USB-disabling") but it doesn't yet. This would make auto-suspends much less visible to the interactive performance of the laptop, probably cutting the resume time to 500ms, which would let us enable auto-suspend in more circumstances. Beyond this cheap hack, we should actually fix the USB drivers so that you CAN be using the USB -- the wifi/mesh in particular -- and still not hang for half a second uselessly on every resume.

* Fix serious bugs in resume and networking. These have so far prevented us from turning on autosuspend by default for three major releases (650, update.1, and 8.2.0), and in each release, we decide at the last minute that we can't fix these bugs because it's too late in the release cycle and we didn't fix them earlier. Multicast, ARP, mDNS, the Presence Service, and collaboration must all work in the presence of autosuspend. Much work has gone into fixing these, but neither the final nits, nor polish, nor system-level testing in a network testbed, has occurred.

* Reduce packet traffic during sharing -- particularly multicast traffic, which loads many machines (and wakes them up from autosuspend). This will require diagnosis and improvement of the presence and collaboration protocols. Some work was done on this, after the high packet traffic melted the WiFi bandwidth in early deployments (e.g. turn on 30 laptops in the mesh, none of them can usefully get anything done), but our main response was to tell later deployments "Don't use the mesh, use access points" -- a significant reversal that we should keep working to fix.

* Improve cpu idle detection. Currently we can't auto-suspend very often (only after >1 minute of no user interaction) because it's so heavy-handed. The cpuidle infrastructure in the kernel should be able to tell us when it's safe to suspend because no process wants access to the CPU for the next few seconds. Most of the pieces are there.

* Reduce useless polling by kernel, daemons, and activities. There's still a major Python bug that causes multi-threaded pyGTK2 programs to poll uselessly once a second (#4680, #4677). Much work was done to close it, but there is still a small sprint required to get it done. This not only reduces power use directly, but also allows the system to suspend because it doesn't appear that activities need to do some work soon.

=== Who requested ===
Kim, Carla, John/Gnu

=== Related Links ===
http://wiki.laptop.org/go/Per-Activity_Power_Usage

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

=== Who requested ===
Improved in 8.2.0 <br>
Priority request from Carla <br>

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

== Collaboration ==
This area has been flagged as critical to our success by many people, especially,
Carla and David. <br>
Teachers on OLPC-Sur. <br>
Peru technical leaders <br>

=== [[9.1.0 Collaboration Requirements]] Phase 1 ===
Allow for intuitive mesh connection and activity-sharing. <br>
Must support first two use cases defined at: [[Use Cases#Collaboration Examples]]

[[Requirements#Mesh / Connectivity_Requirements]]

[[Requirements#AbiWord Sharing Requirements]]

http://lists.laptop.org/pipermail/sugar/2008-July/007407.html

May need to include that link in developer section below, tbd

=== [[Collaboration Requirement Phase 2]] ===
Interschool, other use cases.

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

=== Groups ===
4043

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

- File/activity open

- File save

- Task switching

- Activity or main GUI responsivesness to cursor

- Hardware

- Prevent or warn when user starts opening too many activities. Reduce OOM problems and handle OOM better. Ensure that activities don't harm the system. Find and reduce memory leaks. Make the system more stable.

=== Suggestions from Marco ===
From: http://lists.laptop.org/pipermail/sugar/2008-July/007471.html

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 ==
'''Candybag'''
Idea for a new activity: Candy Bag. You open a bag (i.e. you launch the
CandyBag activity), then you put journal entries in it, then sharing
this activity means that your friends can grab a candy in your bag. <br>
From: http://lists.laptop.org/pipermail/devel/2008-July/017459.html

I'd be curious to see if there is a benefit to having a task like this manifested as an activity. It might work well. There's also a design for a more embedded [[Specifications/Object_Transfers|XO to XO object transfer system]]. [[User:Eben|Eben]] 19:40, 19 September 2008 (UTC)

See also point #3 at<br>
http://wiki.laptop.org/go/9.1.0#e-mail_from_Ben_S

copy all files from the journal to a USB device with one keystroke <br>
From Bastien

Allow listing, copying and finding files with standard Unix commands in the terminal view. <br>
See also point #1 at: http://wiki.laptop.org/go/9.1.0#e-mail_from_Ben_S

== Localization ==
Spell checking as part of l10n. (Sayamindu and Sur list)

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

Chinese support (Kim)

Better RTL support

SCIM (Sayamindu)

[http://lists.laptop.org/pipermail/devel/2008-June/015838.html Translation Technology], (see an earlier post, [http://lists.laptop.org/pipermail/devel/2006-March/000000.html Scaling and localization in package management], for background)

== Security, Activation and Deployability ==

Easy GUI update of OS over net or from USB <br>
Mostly for G1G1 but useful for all.

=== Easier Upgrades and Initial Install ===
Many deployments have noted how hard it is to install or upgrade, especially on thousands of XOs. One issue is that inevitably, the Xos ship from the factory with an older build and countries need to upgrade them before deploying. I call that "upgrade in a warehouse". In other cases the XOs get deployed but there is little or no WAN available to upgrade.

==== Initial Install Requirement ====
When imaging a new laptop or upgrading a laptop we must support the following.

Via USB stick:
* When imaging in a warehouse must activate the laptop
* Must not require any user interaction with the keyboard. Can require holding down a game key on startup but prefer not to make the user do that on initial image install only.
* Must allow setting the language
* Must allow installing a language pack
* Must allow configuring the keyboard for a language
* Must allow inclusion of activities and other content,
* Must allow installing an RPM (Ethiopia)

Via network (can require a school server):
* The solution needs to take 1/2 the time or less than doing the upgrade from USB when 1000 or more XOs are being imaged in a warehouse before deployment.
* When imaging in a warehouse must activate the XO.
* Must not require any user interaction with the keyboard. Can require holding down a game key on startup but prefer not to make the user do that on initial image install only.
* Must allow setting the language
* Must allow installing a language pack
* Must allow configuring the keyboard for a language
* Must allow inclusion of activities and other content
* Must allow installing an RPM (e.g. in Ethiopia)
* Must not pull any files over the WAN more than once.

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

Source: Reuben, Rwanda, Birmingham, Haiti and other XO deployments where it takes too long to re-image XOs that just came from the factory.

==== Upgrade Requirement ====
Needs definition.

=== 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).

Requirement - Must allow setting of the lease time by the deployment lead (User interface required). That is, they can set it for 90 days (or whatever they want) on the first lease expiration and can set it to 30 days on the second. The granularity should be at 24 hours and be from 1 day to never expire.

Source: Peru via Kim except last point added by GS

Related requirement for Ethiopia and other countries: <br>
* Support the same as described above for Peru but allow the server which determines the activation to be across the Internet (AKA over a WAN and ibn a data center run by the deployment).

* Support the same requirement as described above but allow the reset of the activation to be done via USB key. That is, when an XO's lease expires, it must be booted with the USB key containing a special code. This can be done before it expires to extend the lease.

Related documentation: <br>
http://wiki.laptop.org/go/Firmware_Key_and_Signature_Formats#Version_2 <br>
http://dev.laptop.org/~cscott/joyride-api/bitfrost.leases.crypto-module.html <br>
http://lists.laptop.org/pipermail/security/2008-June/000441.html <br>

6689 and 7878 Expand customization key capabilities.

Allow school server to activiate XOs. <br>
Source: thread on techteam <br>

Actual security requirements: [[User:Mstone/Commentaries/Security_1]]

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

Already present in 8.1.0. See: http://wiki.laptop.org/go/Tweaking_the_boot_animation

Should allow setting the language at the factory or when upgrading/re-imaging. The idea is to not require the kids to click the control panel to get to their language. One idea is to include it in the choice you make on first boot (e.g. name and color) better would be to set the language at install. <br>
Source: Bastien for Haiti.

Allow setting of Sugar Control Panel features in customization key. From Peru via Erik <br>
http://dev.laptoptop.org/ticket/6432
http://lists.laptop.org/pipermail/devel/2008-March/011553.html
http://lists.laptop.org/pipermail/devel/2008-July/016417.html

=== Allow Key Customers to Sign Their Own Builds ===
Uruguay request

== Network Manager Connections ==
G1G1 encryption.

802.11i (AKA 802.1x) Uruguay

GUI for managing network connections.

Better default network connection choice algorithm (e.g. if USB - Ethernet is connected, use it first source: A Callahan).
: This already happens, but perhaps there are bugs. -[[User:DanielDrake|DanielDrake]] 16:37, 3 October 2008 (UTC)
This algorithm should be "smart" in its firsdt choice but should also be adjustable in the GUI.

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

More prominent help information - Brianne, G1G1 <br>
One idea from Eben. From: http://lists.laptop.org/pipermail/sugar/2008-August/007547.html <br>
All of our initial discussions on help focused around a contextual help system, and I still hope that this is where we'll be taking this in the future. By embedding (?) icons within the secondary palette menus for various devices, objects, activities, and even individual buttons and controls, we can provide a way to launch into the help activity and dive directly to the relevant info for the activity, control, etc. selected. In addition, I'd like to support a community driven help system by which, in addition to the activity/olpc provided help, it's possible for kids to add tips, tricks, images, tutorials, and other info to these sections for later consumption by peers.

This is a noble, but ambitious goal, which is why a simple and static help activity is the present solution, and why it's only integrated into the system at a single point - the activity itself.

Show size of files in journal and in general make it easier.

Trash can for recovering files. Requested by Bastien, Haiti. <br>
http://lists.laptop.org/pipermail/sugar/2008-August/007889.html

XO needs a clock <br>

= 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
*{{ticket|1496}} Switch to real public keys - Scott
*{{ticket|8170}}
*{{ticket|8171}}
*{{ticket|8177}}

Upgrade journal per: http://wiki.laptop.org/go/OLPC_Human_Interface_Guidelines/The_Laptop_Experience/The_Journal

Less flickering in starting activities and other screen changes - Michael

Show memory usage to user: <br>
We provide no end user feedback on memory usage, either. We should investigate whether revisiting our previous attempt to give such feedback, now that Linux can provide much better information than it could when we abandoned our previous donut attempt. The users could really help, if only we let them know a bit about what was going on...
From Jim e-mail to devel: http://lists.laptop.org/pipermail/devel/2008-September/018944.html

Fedora 10 rebase?

Fix all GPL issues and get sign off from FSF that we are fully compliant.

Ensure the blinking of the lights is meaningful. <br>
http://lists.laptop.org/pipermail/sugar/2008-September/008237.html

Debug tool that easily allows plug of diagnostic USB stick which analyzes and reports back detailed status. <br>
ErikG idea from Uruguay

Backup to Internet idea from Walter: <br>
http://lists.laptop.org/pipermail/sugar/2008-September/008340.html

Stability suggestion from Albert C (and his children) re. protecting against out of RAM conditions: <br>
http://lists.laptop.org/pipermail/devel/2008-September/019575.html

== Sugar Roadmap ==
http://sugarlabs.org/go/ReleaseTeam/Roadmap/0.84

== Easier Access to and Help Using Source Code ==
Put a link in the library on the XO which links to GIT or other relevant source. (source: John/Gnu)

== Improved Clipboard ==

Here is a rough [[Specifications/Clipboard|specification]] of the intended design for a usable multi-item clipboard. I'll add a list of related tickets shortly.

== Sugar Architecture Ideas ==
From thread started by Michael S <br>
http://lists.laptop.org/pipermail/sugar/2008-July/007304.html

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

- Expose the file system on save, open and in the journal. Source: Marvin Minsky

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.

== Easy Update for G1G1 ==
I think this is the biggest missing feature for G1G1 users, honestly. The software update control panel for activities is a great step in the right direction, but to really get people into Sugar moving forward, we have to make one-click updates a reality. They have no school server or other centralized source doing it for them, and we can't expect many to go through the manual update process. Once we have a super-simple control-panel-integrated dev key request process, we should also adjust the update UI to offer cutting-edge updates to those with keys.

From Eben and Joe

== Suggestions from [[User:CScott]] ==
* Better "legacy app" compatibility; this should allow us to run existing apps like firefox, pidgin, and gimp in a reasonable manner:
** Replace matchbox window manager with [[XMonad]], [http://en.wikipedia.org/wiki/Metacity Metacity], [http://awesome.naquadah.org/ awesome], etc. Should provide both 'full screen' mode and traditional 'tiled' mode.
** Switch to standard freedesktop.org [http://www.freedesktop.org/wiki/Specifications/startup-notification-spec startup notification] mechanism: <trac>5271</trac>
** Implement freedesktop.org [http://www.galago-project.org/specs/notification/index.php notifications mechanism] for alerts (low battery, low disk space, available software update)
** Refactor home/friends/mesh view as operations on root window, so they make sense in a multiwindow setup. (It's been suggested that looking at the xpenguins code is instructive for understanding how nautilus,etc arrange their root window.)
* Improved antitheft mechanisms:
** ECO fix and EC improvements
** Security control panel, with "am I stolen" and lease renewal buttons: <trac>1502</trac>, <trac>6428</trac>
** olpcrd work: <trac>7397</trac>
** Revoke root capabilities when booted with security enabled: <trac>7562</trac>
* Improved update mechanisms
** Real COW for pristine versions, allowing... <trac>3581</trac>
** ...binary-diff updates over http (avoiding rsync in many cases) <trac>4259</trac>, etc
** Integration of core OS updates with software update control panel: <trac>7618</trac>
** Integration of software updates with notification system
** Incremental updates of activity bundles (only changed files)
** Send back statistical data when checking for updates (batmon, etc) <trac>4594</trac>, <trac>6447</trac>
* Security/isolation work
** Implementation of P_SF_CORE, P_SF_RUN
** Mechanism to validate updates to loopholed activities & allow user to manage exceptions
** Persistent activity storage
** NSS modules for rainbow users and for olpc/root users
** Rainbow
* Journal improvements
** Proper display of 'new versions' of activities
** Tagging system to allow folder-like management for advanced users
** Datastore rework
** Direct execution of activities from datastore (avoid installation step) <trac>7713</trac>
** Ability to have multiple versions of an activity installed concurrently. (API work necessary: <trac>7713</trac>)
* Translation improvements
** "multiple languages, multiple places": translation system should look in local, then activity, then system translation tables, then repeat for each in a set of fallback languages (eg, quechua, spanish, english)
** separable translation packs
** "click-to-translate": wiki-like editing of translatable labels in the UI
* "Asynchronous internet"
** Integration of wwwoffle with small local cache
** Content bundles to seed that cache
** Mechanism to request downloads later
* Library improvements
** The current API is a mess, doesn't match the documentation on the wiki, is inconsistent with the activity.info format, etc.
** Merging content and activities -- a bundle ought to be able to have *both* a library.info *and* an activity.info
** Using a content format which is consistent with "offline internet" content -- more or less consider installing content files as pushing stuff into an offline cache
** Dynamic generation of the top-level "home" page so we don't need to run the indexer after installing content bundles.
* Fedora integration
** tools to manage forked packages better. To start with: a notification tool to let us know if a new upstream release has occurred for a package we have forked.


== TODO list of [[User:Sayamindu]] ==

* Language Packs version 3
** Packs should be as RPMs
** Utilize patches from Ubuntu for Python and Glibc to define a separate install location/search path for PO files installed via the packs
** Also see CScott's wishlist above.

* SCIM support
** Conversion of all existing layouts to [http://www.m17n.org/common/m17n-docs-en/m17nDBFormat.html m17n db format ], along with refinements and better support for modifiers whenever possible (<trac>6280</trac>
** Modification of relevant startup and configuration scripts for SCIM support
** User experience for keyboard layout switching should not change
** Proper handling of Amharic characters (<trac>8494</trac>)
** Implementation of [[OLPC_Nepal_Keyboard]]

* Enhanced i18n
** Better support for translation of content
** Investigation of the possibility of using native digits for translations <trac>7857</trac>

* Read improvements
** Better Ebook mode support (still vague on this.. expect more details soon)

* Terminal improvements
** Copy paste and drag and drop support enhancements
** Pippyfication (<trac>5543</trac>)
** Better handling of "Run as root in the UI"

* Support for standard desktop applications in Sugar
** Replace matchbox with something more friendlier to standard desktop applications
** Support for .desktop files in the launcher list
** Support startup-notification
** Support standard application icons on the frame


== Thoughts from [[User:cjb]] ==
* Power turned on by default.
* Translation of Sugar inside Sugar?

== Thoughts from [[User:Mstone]] ==

* [[Security]] already contains my immediate security roadmap.
* My [[User:Mstone|user page]] links to several of my other ideas, many of which are procedural improvements with software components.
* My largest ongoing concern is that we have not yet smoothly carried a deployment through an update to a new major stable release. (Peru may become our first exception to this rule, but this remains to be seen.)

== Notes from [[user:sj|sj]] ==
This page shouldn't be broken down by contributor; it needs serious refactoring and organization by topic and scope.

Library and bundle updates:
* API and .info unification across content and activity bundles. Making both and a general [[generic bundle]] clearly described within an overarching bundle format.
** '''thought experiment''' : how does one present an activity (has its own isolation-friendly code) that includes a library bundle (its own browser-browsable static content, help and supplemental materials) and a generic resource bundle (a repository of sounds and images) look like? How do other parts of the system (the Journal, Browse, other activities) see and interact with these three collections of material (to browse and copy the code, to view the static content, to aggregate the resource collections with other collections)?
* a [[Dynamic library]] implementation
* coordination of a unified help interface building on top of the library bundles defined for each activity on the system.
** integration of some way to update and share this. related to how to leave a comment on/about an activity or file/resource
* coordination of local library bundles, and regional caches of viewed material, school server caches of bundles, and web caches.
* cleaner display of available bundles via a bundle updater; relatd to but not the same as the current software upgrade function, which has a strong emphasis on olpc-stamped/signed materials

Sharing updates:
* provide a way to send a file to someone else. related to [[bundle (activity)]].
* provide a way to publish material to the world. related slightly to how edublog works now? see also robson's and juliano's interests here
* add support for asynchronous sharing over time : the sharing of an effort should not require everyone to be online at once.

Adding basic interface pieces that we want to support in the long term, and making them do something familiar, reliably, every time they are at hand. "escape", "stop/start", "share", "view source", "keep", "cut" and "paste" should all do fairly reliable things across activities. Make them do something recognizable even when the activity developer hasn't provided an app-specific hook for same.

== Replacement File System ==

The current file system used on the XO ([[http://en.wikipedia.org/wiki/JFFS2 JFFS2]]) was developed in the days of 32/64MiB NOR flash devices and does not scale well to the 1GiB NAND devices we are using today and certainly will not deal well with larger devices in gen 1.5 and gen 2 systems. The main issues are that JFFS2 needs to scan all blocks at mount time and that the garbage collection algorithm increasingly consumes CPU cycles as the system fills up. The first issue manifests itself as large delays at boot up to mount the file system as it is full (need to quantify this), and the second issue simply means less CPU cycles can be dedicated to user task processing. In the last few years, there has been much activity in the embedded Linux world on alternatives to JFFS2 and we need to investigate these to determine which one best fits our needs:

* [http://www.yaffs.net/ YAFFS2] : Has been around for several years and in active use in the embedded space. It does not provide compression out of the box as the devices that use it often carry already compressed data such as MP3 and MPG files.

* [http://www.linux-mtd.infradead.org/doc/ubifs.html UBIFS]: A new file system recently merged into the kernel designed for use on large flash devices. Supports compression out of the box and supports disabling compression on a per-inode basis, which is something we desire.

* [http://logfs.org/logfs/ LogFS] : Another JFFS2 replacement designed for fast operation and scalability. Still fairly new and not in very active use AFAIK.

* [http://btrfs.wiki.kernel.org/index.php/Main_Page Btrfs] : A very new file system that is primarily targeted for large storage systems with features such as snapshotting, RAID support, and online fsck. David Woodhouse has expressed that he will look into getting this to work on NAND, but it is too new of a code base to consider for 9.1

* Managed NAND : (Not an option for existing XO machines, but might be a direction for future hardware) The industry seems to be moving away from raw NAND in favor of a NAND-chip plus microcontroller solution. The microcontroller implements a Flash Translation Layer that hides the low level NAND details, presenting a higher level interface that looks like an ordinary hard disk, so an ordinary filesystem layout like ext3 could be used. The driving force behind managed NAND is rapid hardware evolution toward multi-level-cell NAND chips and smaller process geometries, which change important NAND parameters like page sizes and ECC. The situation is similar to what happened with hard disks in the 80's, where raw-disk interfaces gave way to SCSI and IDE, which hide the ugly low-level details that changed every technology generation. Managed NAND options include LBA-NAND from Toshiba (pin-compatible with NAND chips), eMMC from multiple vendors (with an SD/MMC-compatible hardware interface), and various "disk on chip" products (IDE-compatible interface).

=== Development Process ===

* Analyze and quantify the use patterns that trigger issues with JFFS2.
* Gather requirements for a new file system that go beyond solving above issues.
* Develop/integrate a set of tests for FS performance and reliability that take into account our use patterns, the above issues, and any other features we wish to validate.
* Study the three main alternatives (YAFFS, UbiFS, LogFS) to determine what requirements they meet
* Run our FS test suite on above alternatives
* Analyze test results and requirements study and make a decision on which alternative to use.

=== Deployment Process ===

Once a file system is chosen from the above process, we will have to:

* Integrate the file system into our kernel if it is not upstream (YAFFS2 or Logfs)
* Integrate the file system support packages into our build system and file system images
* Update our build scripts to generate the proper image type for

=== Activity Impact ===

This change should not have any impact on activity developers as it is at a very low level of the stack.

=== End User Impact ===

End users will see faster boot up time and will not see (as much) performance degradation as the file system fills up.

= Key Modules and Relevant Module Roadmaps =



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


Primary objectives:
Release notes: [[Release notes/{{PAGENAME}}]]
* was to have been a time-based release in 2009 per the process at: [[Release Process Home]].
[[Category:Releases]]
* Deployability
<!-- above lines maybe should be a template -->

Status: [[status::gathering requirements]] and setting priorities

Primary maintainer: not chosen yet

ECO: not yet

Primary objective:
* [[Has objective::This is a time-based release per the process at: [[Release Process Home]].]]
* [[Has objective::Not chosen yet.]]
The process is not final. It is a set of rough guidelines still being worked out and subject to change.

Lead customer: ?

Build number and URL: [[Build number::999]]


Lead customers: Peru, Ethiopia, Uruguay, Haiti, Mongolia, Nepal and Rwanda
Schedule: tbd, should be first half CY 09 and possibly as early as December 2008.
[[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

Retrieved from "http://wiki.laptop.org/mediawiki/index.php?title=9.1.0_requirements&oldid=252743"