[Testing] New OLPC Process and Rules for Builing Activities, Releases, and Firmware Builds
Charles Merriam
charles.merriam at gmail.com
Fri Apr 4 01:39:00 EDT 2008
April Fool's was a good way to present what does eventually need to be
done, and what is done in some other open source projects.
It's a good way of doing it, and would require some work. I would set
up a set of stages with the highest and easiest pay-offs first, e.g.
building versions with and without activities and with and without
source would be easy. I don't know how to implement some of the
features, especially code coverage metrics.
That said, it is likely to remain an April Fool's prank unless OLPC
Foundation folk are willing to head towards tested and timely releases
where experimentation takes place on branches. This change in
mentality is work for some developers and impossible for others.
There are some fix-ups on the proposal; the stages of water metaphor
needs better explanation and the spring and summer metaphors need
renaming (thanks Andrew).
Does anyone believe OLPC Foundation is up to this style of change?
Charles
On Wed, Apr 2, 2008 at 10:29 AM, Grig Gheorghiu <grig at gheorghiu.net> wrote:
> 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
> >
>
>
More information about the Devel
mailing list