simon at schampijer.de
Mon May 3 05:02:56 EDT 2010
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
== 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) . 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 .
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 . 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.
More information about the IAEP