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" <[EMAIL PROTECTED]> wrote: > On Tue, Apr 1, 2008 at 6:55 PM, Charles Merriam > <[EMAIL PROTECTED]> 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 "[EMAIL PROTECTED]" 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 > [email protected] > http://lists.laptop.org/listinfo/testing > _______________________________________________ Testing mailing list [email protected] http://lists.laptop.org/listinfo/testing
