Sugar on a Stick release process

Feature process

The feature process for Sugar on a Stick aims at providing a structured way of implementing and keeping track of upcoming features for the next release of Sugar on a Stick. This document outlines the guidelines for submitting feature proposals. An important thing to realize is the release schedule for each release.

• What is a feature? A feature is defined as a significant change or enhancement to the version of Sugar on a Stick currently under development that may or may not include new packages and also relate to features of both Fedora and Sugar
• What are the deadlines? The deadlines for the release currently under development are outlined in the release schedule.
• What do I get with a feature? Having your feature approved not only helps everybody involved in the development and engineering process to keep track of its state, but also allows other teams - like the marketing team - to leverage your work and promote it.
• What are my responsibilities? By signing up for a feature, you sign up for taking care of it. That means you'll be the one responsible for providing updates and interacting with the different teams concerned by your feature, like the release engineering for Sugar on a Stick. It does, however, not mean that you've to realize your feature all alone - go out and tell the lists and the planet about your work. Get people excited to help you!
• How does evaluation happen? Your proposal needs a majority of YAY votes from the release team (determined for a given release by the release manager - the v4 release manager is Sebastian Dziallas, and the current relase team is formed by Peter Robinson, Mel Chua and Sebastian Dziallas) to get approval. Discussion will happen at a weekly meeting, while the decisions will be announced to the SoaS mailing list.
• What if my feature got rejected? No worries! Features that are originally rejected can be revised and resubmitted.

How to submit a feature for consideration

1. Fill out the template and stick it on a page in the wiki. (TODO: create Category:SoaS_v4_Feature so people can make their pages belong to the appropriate category so that we know which version you're targeting ).
2. Place a link to your proposal in the #Current feature ideas section of this page while you're working on the document.
3. Send an email to the SoaS list and incorporate any feedback you might receive.
4. When you think your feature proposal is ready, move it to the #Features submitted for review section of this page. It will be brought up at the next Sugar on a Stick meeting, where it'll be evaluated and voted on. We might ask you to make further adjustments and revisit it at a later point or approve the feature directly. We're looking forward to hearing about your ideas!

Approved features for the current release

Features must be added to this list by a member of the release team. Place complete feature proposals in the #Features submitted for review section for consideration at the next meeting.

Features submitted for review

When your feature proposal is complete and ready to review, add it to the list below. These will be considered at the next Sugar on a Stick meeting.

• Add feature here

Current feature ideas

These feature ideas are in various stages of development.

• School server
• Kickstart generator
• Sugar Creation Kit DVD [1]
• ASLOxo (Also included on SCK DVD: over 140 ASLO.xo files to put on a second USB stick for installing activities by drag-drop into the sugar Journal of a running Soas Stick.) [2]
• Revised Browse default bookmarks_html [3]
• btrfs and snapshots
• systemd
• More robust iso
• Features/Revised_Browse_default-bookmarks.html
• ASLOxo (Also included on SCK DVD: over 140 ASLO.xo files to put on a second USB stick for installing activities by drag-drop into the sugar Journal of a running Soas Stick.) [4]

Testing process

Changing in a few minutes - it's a draft, I'm still writing this. Mchua 16:00, 21 June 2010 (EDT)

Our build/test/release process can be summarized as follows:

1) An agreed-upon image each week for testers to attack (the daily build on $datetime of each week, for instance)

2) An agreed-upon set of test cases for them to execute (iow, the "test plan" thing we haven't had before)

3) An agreed-upon place and format for the results from running those test cases to be reported to

4) An agreed-upon $datetime each week by which all test results for that week will be submitted - so that the development team has a chance to look at those results and revise the build before the next test image goes out.

nightly builds: http://alt.fedoraproject.org/pub/alt/nightly-composes/soas/