Sugar on a Stick/Mango Lassi

Sugar on a Stick v4 Mango Lassi has been superseded by the Coconut release as of 09 October 2011. See the archive .iso files below for Mango Lassi downloads.

Sugar on a Stick - Mango Lassi

a Sugar environment you can carry in your pocket

Mango Lassi was the 4th version of Sugar on a Stick released on 02 November 2010. Mango Lassi is a popular drink.

Release announcement

We are proud to announce the availability of Sugar on a Stick v4, code-named Mango Lassi. More information about Sugar on a Stick, including download and installation details, is available at http://spins.fedoraproject.org/soas/.

archive .iso files: i686, x86_64

What's new in Mango Lassi

Sugar version 0.90. The most recent release of the Sugar Learning Platform features support for ad hoc Wi-Fi networks, which expands the "under a tree"-scenario to standard Wi-Fi enabled devices. There are also new capabilities in the learner's interface, including a spiral home view, enhanced color selector, and Journal sorting. A lot of under the hood improvements for stability have been included, as usual. More information about the 0.90 release of Sugar is available at 0.90/Notes.

Customize your own remix of Sugar on a Stick. Mango Lassi has a slightly larger Activity selection than its predecessor Mirabelle and has continued the trend of providing a few, better-tested Activities. We've realized that we'll never be able to create an Activity selection suitable for all deployments—instead, we've chosen to include and support a core set of basic, teacher-tested Activities in the default image, and invite deployments to use this as a base on which to build a customized Activity selection for their classrooms. Instructions on how to do this are available at http://download.sugarlabs.org/soas/docs/customization-guide/. A quick, but less pristine, method of build customization is available at Sugar on a Stick/Sugar Clone.

Sugar on a Stick is a Fedora Spin. Since our last version (Mirabelle), Sugar on a Stick has been recognized by the Fedora Project as an official Spin. This ties us more closely to Fedora's release cycle and gives us resources from their engineering and marketing teams, which extends the reach of Sugar on a Stick and makes the project itself more sustainable. In exchange, users of Fedora have access to an easily deployable implementation of the Sugar Platform; it's a great example of a mutually beneficial upstream–downstream relationship.

Contributing to Sugar on a Stick

With v4 of Sugar on a Stick, the team has continued to improve its release processes and engineering sustainability. New contributors are urged to get involved and help us move towards our long-term vision of bringing stability and deployability to Sugar's personalized learning environment.

If you'd like to contribute to the next version, due for release in early May of 2011, join our mailing list and visit Sugar on a Stick. All types of contributions are welcome, from the technical to the pedagogical, and we're happy to teach what we know and learn what you have to share.

Thank you to all the people involved for their awesome work!

Release history

Introduction

This section is a recap of the events during the v4 release cycle (Mango Lassi) of Sugar on a Stick. It was largely an evolution of the v3 release, with improved involvement with upstream Fedora and consolidation of the process. It is mostly documented on the mailing list, from personal memory and soas mailing list archives, since there was no attempt to document the release history during the course of the release cycle itself.

Pre-release

• 25th May 2010 - Fedora (and therefore Fedora Spin) release cycle for Fedora 14 begins; this is significant since Fedora is one of our major upstreams.

Re-approved as a Fedora Spin

"[Spins are alternate versions of Fedora, tailored for various types of users via hand-picked application sets and other customizations." --from http://spins.fedoraproject.org/about

Before SoaS was a spin, it was a Fedora Remix - which means that bit-wise, the product looked the same, but the technical work that needed to happen to generate it was all done manually and without external resources and support, so it happened spasmodically and slowly and with a great number of sleepless nights.

Becoming a Fedora Spin gave us access to Fedora's engineering, marketing, and QA resources, which dramatically improved the sustainability and scalability of our release engineering processes. For instance, .iso files stopped being produced by the "Sebastian manually builds them every time" process, and started being automatically generated for testing by Fedora build servers. We gained some instant automation of the infrastructure we need anyway, without any more work or maintenance on our part, so we could focus on things like... making Activities work, the stuff that's actually unique to Sugar.

Feature Freeze (in the Fedora 14 cycle, 27 July 2010) was a hard deadline for Spin approval, so it was significant that we got in before that (Fedora-imposed) deadline. If we'd missed that, we would not have been able to take advantage of Fedora's engineering, etc. resources at all for Mango Lassi.

Feature process

The main point made here is that unlike two of our major upstreams (Sugar and Fedora) we didn't have a feature freeze for SoaS, but should have, at around this time.

• July 27, 2010 - Fedora Feature Freeze

The way features happen in Fedora is that early in the release process, developers propose features, and they are approved by a feature freeze date (which is before the alpha release). They have to meet certain criteria by certain deadlines - if they don't, they're dropped and not eligible for mention as features. Major features must be in and testable by Alpha; minor changes need to be in and testable by Beta, after Beta only bugfixes are allowed.

This feature process is not unique to Fedora. Feature processes are things that happen in basically every major FOSS project, and really in every major engineering project (even non-software) - it's how we systematically make sure we build something that's good and working.

The feature process also aids with marketing. The Marketing team in Fedora makes their plans according to the feature list that's set by Alpha - this lets us plan how to target those features early in the process.

Since SoaS relies on both Sugar and Fedora as upstreams, we rely on their feature processes - most SoaS features come from either Fedora features or Sugar features. (For reference, our main upstreams are Fedora, Sugar Labs (sugar-core), ASLO (Activities), GNOME, and Python.) For v4, we built the release using a lightweight feature process for SoaS that inherits from those two upstreams.

Activity development confusion

Activity developers weren't informed of changes in the libraries their Activities depended on, when those libraries changed in Fedora (and thus got included in SoaS). This led to confusion and instability late in the cycle when Activity folks belatedly realized this had happened.

Two of our upstreams (Fedora and ASLO) basically collided when they combined, and didn't realize that collision was coming, because we didn't track dependencies between them... part of the problem was that we didn't know who was responsible for keeping track of that aspect of communication, so everyone assumed it was someone else and nobody did it.

The Activities confusion manifests itself in the small number of "supported" activities in the v3 release. Marketing was then confronted with the sudden removal/noninclusion of activities from the release - again, this is something that could have been prevented with a working feature process.

QA

Thomas did field-testing (building real SoaS sticks from .iso files and testing on those) - it's the closest thing to systematic testing we've had yet, though we still have a ways to go. Thank you also to James Cameron in Australia for his testing help!

Mango Lassi didn't have a test plan and it made things confusing for both testers and release engineering; it wasn't always clear what needed to be tested, or what had been tested and how, or where results were or what they meant, and how test results should impact development and vice versa.

Documentation

We now have a Customization Guide and Creation Kit as official documentation on how to custom-build an image and burn a SoaS stick, respectively. A new release of the documentation should come out with each new release of SoaS (although resources have prevented this). This may not be an improvement over our ad hoc wiki documentation methods, as the tools needed to participate are more complicated, and the Spin page documentation is not open to editing. The Fedora Sugar on a Stick pages have not been edited since Mirabelle was released in May 2010. The attempt to better support a small number of known-working "how to set up SoaS" instructions has not been fulfilled.

Release and Marketing

Mango Lassi was released on 02 November 2010. It's shiny! It's orange! It had over 50 downloads within the 12 hours of release.

We have a shiny user-facing page as well as a Contributors Portal, to serve (and hopefully link) the two different audiences. We hope most people will want to wear both hats, in part.

Major accomplishments this release cycle

• We followed the Fedora release schedule relatively well with more people understanding the process.
• We expanded the use of the Fedora Spins process and engineering resources, which made release engineering much smoother.
• Continued use of public communications channels - notably the SoaS mailing list - so things are more transparent.
• Expanded discussion with upstream Fedora especially Fedora QA team and the new AutoQA processes. Initial integration in the Fedora Desktop QA testing process with initial guidelines and test process created. This will be expanded in Fedora 15 for the SoaS v5 release.

Press coverage

Feel free to add links to press coverage you find about Mango Lassi to this section.