[IAEP] maintenance

[Simon Schampijer]

Hi,

thanks Tomeu for bringing this on the table and for providing a plan how 
we can improve the situation and thanks everyone for the interesting 
comments.

== Release ==

I first want to highlight the situation from the release process point 
of view. SL had a release process in place for three releases now. It is 
a six month development cycle that is time wise close to the Fedora 
release process (to make sure the new Sugar release is available in the 
new Fedora one) [1]. We established the process with the knowledge we 
had from the processes at OLPC and the Fedora process.

When we started the process our resources were different, more people 
were still directly paid to work on Sugar. Over time we scaled back on 
our goals per release, as we found out that the processes have to be 
different with a volunteer based community. For example a Feature that 
involves changes in UI and workflow is something that takes a lot of 
time (if you want to do it right) when working with the resources we 
have today. This is just something we had to understand. So we scaled 
back on the number of features and tried to make sure we set higher 
priorities on features that were needed in the field. This is reflected 
in the Feature process [2].

Christoph and others have pointed out that downstreams are probably 
happy what they have today and that they want to just stabilize that 
state. That would explain to me a lot the reservation during the release 
process when it comes to new features and heavier polishing. There was a 
direct interest by downstream in the 3G-Feature and that went trough all 
the steps needed to make it into a release (congrats and thanks for 
following the process btw).

== Maintainers, Coordinators ==

Even with a down scaled process someone has to run it, that those that 
are interested in including a Feature find the possibilities to do that. 
Someone has to do the release management, take care of the feature 
process, do review the code, maintain the modules, does bug triage, does 
testing... Some people might say: "Oh that sounds time consuming, or I 
have no experience in that." What made me really sad this cycle were the 
missing small pieces like people doing testing or coordinating testing. 
Those are really low entry points into getting involved and would have 
showed an interest in what we are doing.

== What to do now ==

And I think those are the missing pieces Tomeu is referring to. First we 
need to define our goals, and that has to happen on our given resources, 
I presume. We overestimated for too long on what we can do, because some 
people took too many roles and tried to fill the gaps.

We need maintainers/peers for the code. As Sascha suggested, those can 
be several people, our maintainer structure suggests peers per module to 
not block on a single person and to minimize the load.

Furthermore we need coordinators. A coordinator for the deployments - 
the deployment team must be in place. This is the entry point for the 
deployments, ideally each deployment is represented there. We have a 
process for giving feedback what is needed in the field [2]. Of course 
this can be enhanced but we have a starting point.

Furthermore if we want to keep on doing software releases we need a 
testing/QA team and a bugsquad that keeps our bug database up to date. 
Of course this can grow and shrink depending on our expectations too. If 
we just do stabilizing work this is a small effort, if we want to do 
features this effort should grow.

Regards,
    Simon

[1] http://wiki.sugarlabs.org/go/0.88/Roadmap
[2] http://wiki.sugarlabs.org/go/Features/Policy