[Sugar-devel] [ANNOUNCE] Schedule after Sugar 0.90.0 is released --- or "After the game is before the game"

[Simon Schampijer]

Dear Sugar community,

after successfully releasing 0.90 there should be a


to celebrate what has been achieved and then we can start thinking what 
to do next. Some items are rather near term goals but there is as well 
the long road that leads to a new release --- 0.92 (1.0).


=== Branching ===
After the final release of a module, a branch should be created to host 
further stable development. If you do not have an 'unstable' commit yet 
you can leave your branch as is, as this ease the work for translators 
by not having to translate for two branches. The details about branching 
are described at [1].


=== Bug fix release ===
To make sure we have the latest packages in F14 before the Final Change 
deadline happens the 18th of October [2], I added another bug fix 
release [3]. As Fedora is the bleeding edge at the moment we just 
backpack on this date.

* 0.90.1 will be the 15th of October
* 0.90.2 will be the 27th of October


=== Testing 0.90 ===
So far we have not seen much testing of 0.90 yet, that is why the bug 
fix releases noted above are so important to us. We need as well your 
help to actually discover the bugs! There are basically three ways how 
you can test as of today (besides using sugar-jhbuild):

* Install Fedora 14 on a machine and install the Sugar desktop

* Test using Sugar on a stick: Get one of the nightly snapshots [4] and 
put it on a usb key. You can find instructions about it at [5]. It is 
good to subscribe to the Soas mailing list (low traffic) [6] for 
announcement and discussions in that case.

* If you have an XO (XO-1 or XO-1.5) you can use an image from [7].

If you are aware of any other distribution where Sugar 0.90 can be 
tested easily please comment.


=== 0.92 ===
Based on the GNOME schedule I made a first draft of the 0.92 roadmap. I 
reintroduced the "Feature Acceptance" milestone. The idea is that the 
discussion about a feature does not start one day before the feature 
freeze. As stated in the Feature policy [9] the acceptance is a sanity 
check, presumed in most cases to be a formality, to ensure that new 
features compliment Sugar guidelines and is manageable, prior to 
publicizing as officially targeted for the next release. The actual code 
must be ready by the Feature Freeze and is reviewed by the module 
maintainer.


On behalf of the Sugar community,
     Your Release Team


[1] http://wiki.sugarlabs.org/go/Development_Team/Release#Branching
[2] https://fedoraproject.org/wiki/Releases/14/Schedule
[3] http://wiki.sugarlabs.org/go/0.90/Roadmap#Schedule
[4] http://alt.fedoraproject.org/pub/alt/nightly-composes/soas
[5] http://wiki.sugarlabs.org/go/Sugar_on_a_Stick/Installation
[6] http://lists.sugarlabs.org/listinfo/soas
[7] http://dev.laptop.org/~erikos/F14_builds/
[8] http://wiki.sugarlabs.org/go/0.92/Roadmap#Schedule
[9] http://wiki.sugarlabs.org/go/Features/Policy#Acceptance_of_a_feature