Difference between revisions of "Development Team/Manual"

From Sugar Labs
Jump to navigation Jump to search
(No difference)

Revision as of 16:12, 12 January 2008

english | Copy "{{subst:requesttranslation}}" to 한국어 HowTo [ID# 5337]  +/-  


This is a quick intro to working on activities for the XO, and other code for OLPC. Feel free to add to and update the manual; it is a work in progress.

This manual tries to provide you with the answers you need to get started either by contributing to existing projects or starting your own. Although it focuses on the software development side of the process, we are also very interested in encouraging other contribtions.

Overview

  • Developers/Setup
    • Describes how to set up a Sugar development environment, with a discussion of which approach is likely to be the most appropriate for you
  • Developers/Stack
    • Describes the "operating stack" of the OLPC Sugar environment, the combination of hardware, operating system, services, libraries and activities that combine to form the environment in which you will be programming
  • Developers/Issues
    • Describes the special considerations required for working on the OLPC project, particularly those driven by our target hardware and deployment environments
  • Developers/Projects
    • Suggests ways to choose a particular project, whether one that already exists, or one of your own, and how to start working on the project once you have chosen it
  • Developers/Communication
    • Describes the various support and communications channels used by the project, including how to get help with problems, and how to set up your own per-project communications channels
  • Developers/Documentation
    • Collects pointers to the various sources of documentation available for the project. Helping us better document our code is always a welcome contribution.
  • Developers/FAQ
    • Collects and attempts to answer common questions that developers have when working on the Sugar platform

Release Schedule

We expect to be doing updates monthly through the first quarter of 2008. After that, we will likely adopt a three-month update cycle. Eventually we will adopt a six-month update cycle. It should also be noted that we will be—when time permits—moving to a build environment that enables individual activity developers to maintain their own build cycles. Russian forever!!! :)))

Related docs and manuals