Changes

=== Introduction ===

=== Introduction ===

This section is a recap of the events that happened during the v3 release cycle (Mango Lassi) of Sugar on a Stick. It was largely constructed during the v3 release review meeting on 5/31/2010 [http://meeting.olpcorps.net/sugar-meeting/sugar-meeting.minutes.20100531_1507.html (minutes)] [http://meeting.olpcorps.net/sugar-meeting/sugar-meeting.log.20100531_1507.html (log)] from personal memory and [http://lists.sugarlabs.org/archive/soas/ soas mailing list archives], since there was no attempt to document the release history during the course of the release cycle itself.  

This section is a recap of the events that happened 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. Its mostly documented on the mailing list, from personal memory and [http://lists.sugarlabs.org/archive/soas/ soas mailing list archives], since there was no attempt to document the release history during the course of the release cycle itself.  

=== Pre-release ===

=== Pre-release ===

* '''November 11, 2009''' - [http://fedoraproject.org Fedora] (and therefore [http://spins.fedoraproject.org Fedora Spin]) release cycle for Fedora 13 begins; this is significant since Fedora is one of our major upstreams.

* '''25th May 2010''' - [http://fedoraproject.org Fedora] (and therefore [http://spins.fedoraproject.org Fedora Spin]) release cycle for Fedora 14 begins; this is significant since Fedora is one of our major upstreams.

* '''December 2009''' - We're still actually on the Blueberry release and haven't started making Mango Lassi yet. Blueberry is getting a lot of good PR from SeanDaly and the Marketing crew.

=== Approval as a Fedora Spin ===

=== 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

"[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.

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.

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, July 27, 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 Freeze (in the Fedora 13 cycle, Feb 9, 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.

 

Looking at the [http://lists.sugarlabs.org/archive/soas/2010-January/thread.html 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.

=== Feature process ===

=== 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 around this time.

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 around this time.

* '''February 9, 2010''' - [https://fedoraproject.org/wiki/Features/Policy Fedora Feature Freeze]  

* '''July 27, 2010''' - [https://fedoraproject.org/wiki/Features/Policy 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 it's only bugfixes allowed.

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 it's only bugfixes allowed.

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 what features early in the process.  

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 what 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 will be building and using a lightweight feature process for SoaS that inherits from those two upstreams.

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 development confusion ===