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

[C. Scott Ananian]

On Tue, Apr 1, 2008 at 6:55 PM, Charles Merriam
<charles.merriam at gmail.com> wrote:
> 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.

Can we present this as a formal proposal at the mini-conference?
 --scott

-- 
 ( http://cscott.net/ )