XS Roadmap: Difference between revisions
RafaelOrtiz (talk | contribs) mNo edit summary |
(→v0.5: it's nearly out, so cleanup) |
||
(28 intermediate revisions by 7 users not shown) | |||
Line 1: | Line 1: | ||
{{OLPC}} |
{{OLPC}} |
||
= |
== Release goals == |
||
The release goals and mgmt are in Trac - see the links to track next to each release... |
|||
=== v1.0 === |
|||
* Features from 0.9 |
|||
* Bugfixes |
|||
* Upgrade path from any earlier 0.x release |
|||
=== v0.9 aka ''Wishlist''=== |
|||
Below is the shortlist of features for the 0.x series. See the [https://dev.laptop.org/query?status=assigned&status=new&status=reopened&group=milestone&component=school+server&order=priority&col=id&col=summary&col=status&col=priority&type=enhancement full list of enhancement requests here] - check there to see if the enhancement and features you want to suggest are already recorded. If they are not, you can record a new one in [https://dev.laptop.org/newticket our task tracker], make sure you pick the ''schoolserver'' component, and set it to type=''enhancement''. |
|||
* '''[[XS_Manageability]]''' - solid, secure and flexible remote management for XS, inspired in ISConf and PlanetLab |
|||
* '''[[XS_HTTP_Proxy]]''' a strong double-proxy setup inspired on CoDeeN |
|||
* '''[[XS_Backup]]''' solid, flexible scheme to backup and restore the XS itself |
|||
* '''[[XS_AdminUI]]''' simple admin UI to support some key usage scenarios |
|||
* Port to Fedora 9 |
|||
* Webapps |
|||
** '''[[XS_Mediawiki]]''' - with customised UI, options to load/update prepackaged Wikipedia content, local content, SSO |
|||
* '''[[XS_Library]]''' - Content repository infrastructure -- possibly based on Moodle |
|||
* XO Upgrade server - See https://dev.laptop.org/ticket/6371 |
|||
** NOC team makes the desired build available on XS installs via the XS management tools. |
|||
** Desired: white list of machine SNs OKd for the upgrade. |
|||
* [[XS Blueprints:Data Collection and Reports|XS Reports]] - collect information so that the NOC can produce reports. |
|||
=== v0.6 === |
|||
[https://dev.laptop.org/query?group=status&milestone=xs-0.6 Trac page for XS-0.6 ] - |
|||
=== v0.5 === |
|||
[https://dev.laptop.org/query?group=status&milestone=xs-0.5 Trac page for XS-0.5 ] - This release will be based on [[Fedora]]. |
|||
As of November 2008 XS 0.5 is in release candidate stage. |
|||
* Root password management as per [[XS Blueprints:OTP root_passwords]] |
|||
=== v0.4 === |
|||
[https://dev.laptop.org/query?group=status&milestone=xs-0.4 Trac page for XS-0.4 ] - '''Done''' - The focus of this release is in packaging the '''upgrade server''' and providing a '''cleaned up configuration management'''. |
|||
* DS-Backup as per [[XS_Blueprints:Datastore_Simple_Backup_and_Restore]] |
|||
Release notes at: [[XS Release Notes]] |
|||
=== v0.3 === |
|||
Matches XO's "8.1.x" releases. This ended up being a bugfix release on earlier code. Notes below are of work that has landed in later releases... |
|||
Intended to be deployed in Peru - our first large-scale install of XSs, many of them with nil or spotty connectivity, so strong focus on manageability. |
|||
* Manageability |
|||
== Release schedule == |
|||
The XS should see a new ''feature'' release every ~4 weeks until we hit v1.0. At that point we will encourage installations to switch to v1.0 and ensure the upgrades from earlier releases to 1.0 work smoothly. From 1.0 onwards the release cycle will be slower - probably about 4 months. |
|||
In calendar terms, we are very loosely talking about |
|||
== Versioning Scheme == |
|||
Releases will follow a '''<major>.<feature>.<minor>''' versioning scheme, as follows: |
Releases will follow a '''<major>.<feature>.<minor>''' versioning scheme, as follows: |
||
Line 8: | Line 67: | ||
* 1.0 is our mid-term "we are proud of it - features and stability" release |
* 1.0 is our mid-term "we are proud of it - features and stability" release |
||
* 0.3 will be the first release managed by Martin Langhoff, to sync with Peru's April 2008 deployment |
* 0.3 will be the first release managed by Martin Langhoff, to sync with Peru's April 2008 deployment |
||
* 0.2 is Build |
* 0.2 is Build 163/164 by Wad. |
||
If for example 0.2 needs bugfixes, we'll see a 0.2.1 release. The 0.9 to 1.0 transition will be about stability and polish. |
If for example 0.2 needs bugfixes, we'll see a 0.2.1 release. The 0.9 to 1.0 transition will be about stability and polish. |
||
Line 16: | Line 75: | ||
'''Note''': On dev.laptop.org our release names are prefixed with "xs-" so 1.0 is xs-1.0. |
'''Note''': On dev.laptop.org our release names are prefixed with "xs-" so 1.0 is xs-1.0. |
||
=== Upgradeability Considerations === |
|||
= Release schedule = |
|||
The XS should see a new ''feature'' release every 3~4 weeks until we hit v1.0. At that point we will encourage installations to switch to v1.0 and ensure the upgrades from earlier releases to 1.0 work smoothly. From 1.0 onwards the release cycle will be slower - probably about 4 months. |
|||
In calendar terms, we are very loosely talking about |
|||
* 0.2 18th April 2008 |
|||
* 0.3 9th May 2008 |
|||
* 1.0 mid-November 2008 |
|||
* 1.1 March 2009 |
|||
== Upgradeability Considerations == |
|||
A key consideration is that once XS is widely installed, countries/regions will want to limit the number of upgrades they apply to the XS. During the 1.x cycle, we must support environments where the XS has a yearly upgrade. That means that with a 4-month cycle 1.0 must be able to upgrade to 1.4 smoothly. |
A key consideration is that once XS is widely installed, countries/regions will want to limit the number of upgrades they apply to the XS. During the 1.x cycle, we must support environments where the XS has a yearly upgrade. That means that with a 4-month cycle 1.0 must be able to upgrade to 1.4 smoothly. |
||
Line 44: | Line 92: | ||
* A common scenario will be an unattended, unmanaged XS that only gets powered up and forgotten. Might have Internet/WAN access, but probably not. Are we improving/regressing the XS performance for that scenario? |
* A common scenario will be an unattended, unmanaged XS that only gets powered up and forgotten. Might have Internet/WAN access, but probably not. Are we improving/regressing the XS performance for that scenario? |
||
* How about the minimal configuration scenarios? |
* How about the minimal configuration scenarios? |
||
= Release goals = |
|||
== 1.0 == |
|||
* features from 0.9 |
|||
* bufixes |
|||
* upgrade path from any earlier 0.x release |
|||
== 0.? == |
|||
Wishlist for the 0.x series. |
|||
* '''[[XS_Manageability]]''' - solid, secure and flexible remote management for XS, inspired in ISConf and PlanetLab |
|||
* '''[[XS_HTTP_Proxy]]''' a strong double-proxy setup inspired on CoDeeN |
|||
* '''[[XS_BackupRestoreService]]''' Integration with XO's Journal to provide a backend that facilitates content "restore" services in a "time machine" style |
|||
* '''[[XS_BackupRestoreDRStrategy]]''' solid, flexible scheme to backup and restore the XS itself |
|||
* '''[[XS_AdminUI]]''' simple admin UI to support some key usage scenarios |
|||
* Webapps |
|||
** '''[[XS_Moodle]]''' - with customised UI, options to load prepackaged course content, SSO |
|||
** '''[[XS_Mediawiki]]''' - with customised UI, options to load/update prepackaged Wikipedia content, local content, SSO |
|||
* '''[[XS_Library]]''' - Content repository infrastructure |
|||
== 0.3 == |
|||
Matches XO's "Update.1" release. Will be deployed in Peru - our first large-scale install of XSs, many of them with nil or spotty connectivity, so strong focus on install tools and manageability. |
|||
* Backups |
|||
* Install config |
|||
* Security scheme |
|||
* Manageability |
|||
''Note:'' Old releases go to the [[XS_Changelog]] |
''Note:'' Old releases go to the [[XS_Changelog]] |
Latest revision as of 04:44, 18 November 2008
Release goals
The release goals and mgmt are in Trac - see the links to track next to each release...
v1.0
- Features from 0.9
- Bugfixes
- Upgrade path from any earlier 0.x release
v0.9 aka Wishlist
Below is the shortlist of features for the 0.x series. See the full list of enhancement requests here - check there to see if the enhancement and features you want to suggest are already recorded. If they are not, you can record a new one in our task tracker, make sure you pick the schoolserver component, and set it to type=enhancement.
- XS_Manageability - solid, secure and flexible remote management for XS, inspired in ISConf and PlanetLab
- XS_HTTP_Proxy a strong double-proxy setup inspired on CoDeeN
- XS_Backup solid, flexible scheme to backup and restore the XS itself
- XS_AdminUI simple admin UI to support some key usage scenarios
- Port to Fedora 9
- Webapps
- XS_Mediawiki - with customised UI, options to load/update prepackaged Wikipedia content, local content, SSO
- XS_Library - Content repository infrastructure -- possibly based on Moodle
- XO Upgrade server - See https://dev.laptop.org/ticket/6371
- NOC team makes the desired build available on XS installs via the XS management tools.
- Desired: white list of machine SNs OKd for the upgrade.
- XS Reports - collect information so that the NOC can produce reports.
v0.6
v0.5
Trac page for XS-0.5 - This release will be based on Fedora. As of November 2008 XS 0.5 is in release candidate stage.
- Root password management as per XS Blueprints:OTP root_passwords
v0.4
Trac page for XS-0.4 - Done - The focus of this release is in packaging the upgrade server and providing a cleaned up configuration management.
- DS-Backup as per XS_Blueprints:Datastore_Simple_Backup_and_Restore
Release notes at: XS Release Notes
v0.3
Matches XO's "8.1.x" releases. This ended up being a bugfix release on earlier code. Notes below are of work that has landed in later releases...
Intended to be deployed in Peru - our first large-scale install of XSs, many of them with nil or spotty connectivity, so strong focus on manageability.
- Manageability
Release schedule
The XS should see a new feature release every ~4 weeks until we hit v1.0. At that point we will encourage installations to switch to v1.0 and ensure the upgrades from earlier releases to 1.0 work smoothly. From 1.0 onwards the release cycle will be slower - probably about 4 months.
In calendar terms, we are very loosely talking about
Versioning Scheme
Releases will follow a <major>.<feature>.<minor> versioning scheme, as follows:
- 2.0 is our long-term "Next Gen" release somewhere in the distance
- 1.0 is our mid-term "we are proud of it - features and stability" release
- 0.3 will be the first release managed by Martin Langhoff, to sync with Peru's April 2008 deployment
- 0.2 is Build 163/164 by Wad.
If for example 0.2 needs bugfixes, we'll see a 0.2.1 release. The 0.9 to 1.0 transition will be about stability and polish.
Exactly what happens between 0.2 and 1.0 will be defined via release goals and blueprints (similar to Ubuntu's approach) which will be managed in dev.laptop.org .
Note: On dev.laptop.org our release names are prefixed with "xs-" so 1.0 is xs-1.0.
Upgradeability Considerations
A key consideration is that once XS is widely installed, countries/regions will want to limit the number of upgrades they apply to the XS. During the 1.x cycle, we must support environments where the XS has a yearly upgrade. That means that with a 4-month cycle 1.0 must be able to upgrade to 1.4 smoothly.
Deployment managers need to be aware that XS with versions earlier than 1.0 can be managed in two ways:
- Once 1.0 is ready, there will be a special upgrade procedure to get from 0.x to 1.0 with minimal steps.
- Upgrading through each version.
Installations using 1.x will be expected to upgrade at least yearly.
Key metrics
When judging release goals, there are some key metrics we must consider (and are not always obvious):
- A common scenario will be an unattended, unmanaged XS that only gets powered up and forgotten. Might have Internet/WAN access, but probably not. Are we improving/regressing the XS performance for that scenario?
- How about the minimal configuration scenarios?
Note: Old releases go to the XS_Changelog