Sugar on a Stick/Mango Lassi: Difference between revisions
Pbrobinson (talk | contribs) |
Pbrobinson (talk | contribs) |
||
| Line 60: | Line 60: | ||
=== Introduction === | === Introduction === | ||
This section is a recap of the events that happened during the | 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 === | ||
* ''' | * '''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. | ||
=== | === 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 | ||
| Line 74: | Line 72: | ||
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 | 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 | |||
=== Feature process === | === Feature process === | ||
| Line 88: | Line 80: | ||
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. | ||
* ''' | * '''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. | ||
| Line 96: | Line 88: | ||
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 | 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 === | ||