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

[Charles Merriam]

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

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