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/ ) _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel