(Imported from MoinMoin)
m (1 revision(s))
Latest revision as of 16:29, 24 May 2008
 OLPC project development streams
The OLPC platform development effort covers a very broader range of issues & technologies so no matter what your technical skillset there is certain to be an area where you can get involved in design/development of the project. At this time the work can probably be classified into a handful of sub-projects
- OS image tools - focuses on creation of tools for building the OS 'firmware' images from a Fedora OLPC yum repository.
- Software development kit - focuses on bundling of a set of tools to facilitate application development on the OLPC platform
- Simulator - although it could be considered a part of the SDK, it is more broadly applicable to both those creating & testing the base OS images.
- Optimization - considering ways in which the OS platform and basic applications can be optimized for the hardware constraints.
- Kernel - optimizing the kernel for the unique hardware constraints, such as limited RAM (no swap), development of MTD device drivers, ensuring flawless ACPI suspend/resume and much more
- OS Changes - Changes that need to be made to the base operating system utilities to host the OLPC operating system.
- Interaction - defining the mode/style of interaction for the desktop experiance.
- Localization/globalization - fonts, input maps, character sets, translations, graphics, and much more
 Getting involved
All the Fedora OLPC projects are maintained using the Mercurial source control tool. With a distributed SCM tool, such as Mercurial, anybody can get anonymous access to the master repository, download the complete repository history, work on their local repository copy & then periodically submit bundles of changes back upstream, preserving repository history at all times. For further information on getting the source read about the OLPC source repository setup .
If you have ideas for work to be done in any of these projects the best first step is to make a suggestion on the mailing lists , then work off a local copy of the repository. Those who get heavily involved in the development process can also be given direct repository access via SSH, although as noted above with a distributed SCM tool, those with anonymous access have near identical SCM capabilities to those with direct repository access. The only difference is the mechanism by which changes are pushed upstream - anonymous users export changelist bundles & submit via email for review, while authenticated users can push straight to the repository.