With yet another (Fedora and SoaS) release cycle coming up, recapping the main decisions/events and rationale of the past 6 months.

Sugar Labs folks interested in a peek behind the scenes may find it fascinating reading, but we think Fedora folks curious about what the spins process looks like from the "other side" and Teaching Open Source folks looking for examples of reflective learning may also benefit from a quick skim. We had many triumphs and learned many lessons (often the hard way) - some excerpts are below.

On becoming a Fedora Spin

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 scaleability 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.


The January 8, 2010 SoaS planning meeting led to the decision to apply for spin status. Looking at the January mailing list archives, we didn't explain the significance of the spin decision very well then, which may have led to communication disconnects down the line that made Activity development and Marketing more difficult. In particular, we did not make it clear enough that we were now tied to the Fedora release cycle, and what that meant.

On accidentally making life difficult for Activity developers

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.

Major accomplishments this release cycle

  • We have a team!
  • We have a release schedule!
  • We started using the Fedora Spins process and engineering resources, which made release engineering much smoother.
  • We started driving communications to public channels - notably the SoaS mailing list - so things are more transparent.
  • Multiple people have commit access to each repository that needs to be handled, so there are no single-person bottlenecks remaining.
  • We shifted to a time-based release cycle, meaning we had a target release date set early in the process rather than our prior "it seems ready... now-ish?" method.

There's more available at the full recap - we're still a pretty fledgling project and new to introducing many of these processes (and still building our scaffolding!) so if you have thoughts/comments/suggestions/advice on how we could improve, please let us know via comments here, the soas mailing list, or pinging pbrobinson (Peter), sdziallas (Sebastian), or mchua (Mel) on IRC (we're often in #sugar on irc.freenode.net).

Planning for the 4th release (the codename for this release is yet to
be chosen - suggestions for this welcome, too!) begins on Monday, June
7, at our weekly IRC meeting. And of course, if you're interested in helping with the next release, please join us!