[sugar] [Testing] New OLPC Process and Rules for Builing Activities, Releases, and Firmware Builds
C. Scott Ananian
cscott at laptop.org
Wed Apr 2 13:14:41 EDT 2008
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/ )
More information about the Sugar
mailing list