Sugar on a Stick/Mango Lassi

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

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!

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.