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

Wed Apr 2 13:29:48 EDT 2008

I'm a bit confused at this point as to whether Charles's message was an
April Fool's prank or the real deal. Charles -- you got all of us here,
now can you shed some light? :-)

Grig

--- "C. Scott Ananian" <cscott at laptop.org> wrote:

> 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/ )
> _______________________________________________
> Testing mailing list
> Testing at lists.laptop.org
> http://lists.laptop.org/listinfo/testing
> 