April Fool 2008 Build Process

New OLPC Process and Rules for Building Activities, Releases, and Firmware Builds

This article began the 2008 Debate of Build and Release on April 1, 2008.

I. Introduction

It's an exciting time at the OLPC Foundation! In the next few weeks we will be releasing Update 1 and holding our first Mini-Conference for developers at 1 Cambridge Center. Also, we are announcing our new processes for streamlining the development process.

Process and rules make it easier to create quality deployments to the children world wide that now depend on their XOs. We will be releasing high-quality, regularly scheduled deployments timed to coincide with the school year in most countries. These changes will help developers concentrate on high quality software and have their changes make it out to children more quickly.

The major changes outlined in this document include:

• Time-based Release Schedules
• Developer Changes: Better GIT web interface & standard project metrics
• Useful and predictable build targets

II. Time-based Release Schedule

OLPC is moving to time-based release schedule. A growing number of open source projects have standardized on this approach including the Ubuntu and Gnome projects. See https://wiki.ubuntu.com/TimeBasedReleases for one explanation of this system.

Major updates will be signed and released on May 15 and November 15 each year. This will allow ample time for review, teacher training, modified lesson plans, and deployment. The version numbers will be in the form "YY.season", so our next two releases will be "08.Spring" near May 15, 2008 and "08.Autumn" on November 15, 2008. This year, because of the transition, Update-1 may be released on a different date than May 15, 2008. It will still be officially called "the 08.Spring version".

Getting a stable build out to all corners of the globe can be hard. A branch grows in stability over time and stablity of the release and field testing the final release candidate takes time. We plan to finalize the exact schedule for 08.Autumn shortly, but expect the following:

           45 days until release     Feature Freeze
           30 days until release     User Interface Freeze, Sugar OS freeze, Imports Freeze
           15 days until release     Translation packages freeze, Final freeze and start final testing
           0 days                    Release on schedule.
           +30 days                  Announce schedule, priority, and tool chain changes for next release at developers conference.

III. Developer Changes

These changes should help developers by making it easier to get their changes into regular builds. Changes are minimal: most developers will only need to name a new GIT branch.

The biggest change for developers will be to provide named branches for the stable version and for each release version. The OLPC Foundation may create a named branch for inactive and completed projects that should be a release. Also, the OLPC Foundation may create an "as shipped" branch when we finish a release cycle. We recommend that projects try to develop new features be in separate branches and merge them back into a 'stable' branch as they are completed; just our advice. See the wiki for the latest branch names and explanations.

Another exciting change is a new look to the online GIT repository that we are rolling out on May 1, 2008. The interface looks nicer, with colored source code in the browser; searching across source files; links to pydoc, testing, and coverage reports by file; and links into the wiki pages for each activity. Anyone will be able to start project in dev.laptop.org's GIT without having to apply in advance: we encourage developers to use GIT from the beginning. With a growing number of new projects, we will be introducing a metric, named Solidity, to categorize projects.

Solidity is a new metric to seperate ideas and prototypes from shipping activites. This simple metric puts each project in one of three states: "steam", "water", or "ice". The new GIT web pages will show this state along with numbers for Components, Translations, and Coverage. The Components number derives from a project's wiki page, lesson plans, and artwork. Translation numbers derive from the Pootle measurements of translations into core deployment languages. Coverage numbers derive from code coverage numbers by various methods being discussed on the "testing@laptop.org" mailing list. At a minimum, we will include code coverage numbers from Python's "doc tests" and the "UnitTest" module. The solidity metric changes via a "phase change" initiated at OLPC Foundation discretion.

These changes will help developers get their changes into the appropriate builds for more testing and for attracting more developers.

IV. Build Targets

Another exciting change: we are pleased to announce build process improvements! We have a new build process we hope to unify across Sugar OS components, Activities, and bios (flash) images. The number of build targets will expand dramatically by dividing up versions, formats, and bundles.

There are three versions in the build process: product, pre-product, and joyride. Product releases are the two per year tested releases for deployment. Pre-product releases are the alpha, beta, and release candidate builds that replace the current 'stable' designation. Joyride is the nightly build with all the stability of driving fast on slippery mountain roads hoping not to crash the same place twice. Only "joyride" builds will pull the latest library versions from off-site servers.

There will also be multiple formats produced in the build process, which should make it more accessible to Activity developers. Each build will be available in Ubuntu (currently "Gutsy" version) packages, Ext3 files for Q/EMU, a virtual drive for VMWare servers, jffs2 (flash/Nand), .zip/.xo, and continued support for sugar-jhbuild users. We are still fleshing out the details for a testing harness version and for a Macintosh developer version. We hope that any programmer who wants to develop for the OLPC will be able to do so with under thirty minutes of set-up.

Finally, there will be multiple bundles for each build: Sugar/OS without Activities; Sugar/OS with Solidity=Ice Activities; Sugar/OS with Solidity=Ice Activities & Source Code; and Sugar/OS with All Activities & Source Code. The two bundles with source code may exceed the standard storage ability of XO-1 laptops. There will also be some special bundles. Live CD builds, based on the "Sugar/OS with Solidity=Ice Activities" bundle for the latest product release will be aimed at potential donors and press. We are still exploring making custom deployment bundles to provide configuration help such as selecting activities, the Jabber host, default languages, and security settings.

That's a lot of builds! At a minimum we are expecting (3 versions) x (4 formats) x (4 bundles) + Live and deployment builds. The extra complexity will be worth it to make available the torrent or download that best suits your needs.

V. Conclusions & Summary

The OLPC Build Process is getting cleaner, faster, and more reliable. The new time-based release cycle provides the regularlity needed by teachers and regional groups; the new developer interface and branch structure speeds up development; and the new build targets make it easier to acquire and test the latest builds. Any challenges with the transition will be rewarded with higher quality software.

Charles Merriam April 1st OLPC Build Administrator charles.merriam@gmail.com

Note for Non-United States Readers:

The United States has a tradition of pranks and jokes each April 1st. See Wikipedia for an explanation of this tradition. This is not a new policy of the OLPC Foundation, nor do I represent them. The OLPC Foundation remains committed to "retro style" build processes emphasizing the artistic experience of administration over product quality. Smile.