[Sugar-devel] Sugar Release Management --- handing over

[Simon Schampijer]

A few words on the last Sugar release, a reflection from the release 
manager's point of view.

== Involvement from Downstream ==

We saw the first bigger contribution from downstream. Developers and 
educators from Plan Ceibal and Paraguay Educa worked together to add the 
GSM feature [1] to Sugar. Many thanks to Tomeu Vizoso for introducing 
the new upstream contributors to the development process. We need more 
of these contributions!

Here we can see two important points: Shared interest in a Feature made 
it possible to enhance the platform in no time. Those parties need a 
channel to communicate with each other, Sugar Labs. Hence the recently 
repeated request to get the Deployment team up again to make this 
communication channel more visible and ease the communication. And of 
course the people working on the Feature need a process they can follow 
to include their work upstream, the Sugar Feature Process [2]. And of 
course at the beginning you need to introduce the newcomers to the 
processes the guidelines etc, this takes a bit of time, not something 
that just happen right away.

[1] 
http://wiki.sugarlabs.org/go/0.88/Notes#Connect_to_the_Internet_using_a_GSM_modem
[2] http://wiki.sugarlabs.org/go/Features/Policy

== Design ==

Sugar from a technical point of view is not much of a revolution. What 
makes it unique is the design and a few key ideas like the Journal and 
collaboration. Having a prominent presence of Designers during the 
release cycle is needed when it comes to new Features and changing 
current work flow or adding new one. As we have many users out there by 
now, one must be careful to not introduce regressions for current users. 
Sometimes enhancements does not turn out to be that great in the end, as 
we had to discover during the 0.88 cycle. As the change in UI is not 
always easily qualified, this needs certain iterations in the process, 
conducted tests with user groups [3] and so on.

During the last cycle I established the design team meetings again, to 
give attention to these needs. In my opinion, having a design team that 
is present during the development cycle and defined processes on which 
bases the teams can work together is the ground on which the platform 
can be enhanced. Of course, if we only want to do stabilization, this is 
not as much of a need.

[3] http://lists.sugarlabs.org/archive/sugar-devel/2010-March/022872.html

== Testing / QA ==

As already seen in previous releases we lack testing during the 
development cycle (btw, the Soas team has the same issue of lack of 
testing). Bugs get harder and harder to fix the later it gets in the 
cycle. Once Sugar is already shipped in a distribution it is even worse. 
Testing and QA is a low entry point. It is not very time consuming, one 
can do it asynchronously it just needs a bit of thinking how to gather 
the results and that it happens at all. I tried to give attention to 
this issue during the cycle, asked possible testers how it would work 
best for them, organized testing days [4] etc. I think what it needs is 
a coordinator that coordinates the different groups that already do 
testing (olpc has several ones) and works together with the release team 
to know what maybe needs special attention.

[4] http://lists.sugarlabs.org/archive/sugar-devel/2010-February/022413.html

== Bug Squad ==

Once we get more testing a bug squad [5] is a very good thing to have to 
take load from the developers. Mainly they filter incoming bugs, do ask 
for clarification when needed etc. Here as well, a coordinator would be 
needed to group a team around him.

[5] http://wiki.sugarlabs.org/go/BugSquad

== Summary ==

As discussed in many other threads, Sugar Labs has an issue of 
resources. One way out is to get more people on board, this is a 
mid-term strategy, but something we have to start now (deployment team). 
For the short term we have to live with the resources, and people have 
to take clear roles. And those coordinators must communicate a lot with 
each other. If you have small resources, clear roles and good 
communication is the key. And of course, it might help to scale down 
expectations and efforts if your resources do not allow you to do what 
you like to.


Regards,
    Simon


PS: Thanks Mel for reminding me of reflecting about the last release :)