[sugar] Making updating easier and Planning for Support

[David Farning]

On Sun, 2008-06-22 at 15:02 -0400, Kim Quirk wrote:
> Deepak (and others interested in support),
> 
> This is a good question and we've talked about it from time to time.
> 
> The OLPC Support planning is really just now underway. We've made some
> good progress on the Hardware side of support (spare parts, repair
> centers, warranty, etc); and now we need some focus on the Software
> side of Support.
> 
> Here is my proposal:
> First I'd like to begin separating 'Sustaining Engineering' functions
> from 'Development Engineering'. Sustaining is focused on the problems
> and bug fixes needed for countries (and G1G1). There has to be a close
> tie in between the groups and training from development to sustaining,
> but it should allow the Development team to be more forward looking.

This is going to be were an interesting intersection between community
and corporate occurs.  Kernel.org releases every couple of months and
Distributors like RedHat end up supporting a given release for several
years. 

> Secondly, I am proposing that our Support team can only support one
> major release along with the current one. With school systems being
> run on yearly basis, this would suggest that we plan for 2 major
> releases per year. That would give schools a chance to use either the
> fall or spring release as their base; and then plan to upgrade between
> school years to the next release.

Two releases per year make sense.  Particularly when add in the fact that
we have two hemispheres with opposing springs and falls. 

> Here is an example:
> We provide release 8.2.0 in Aug/Sept;  school systems that start in
> Feb or March would be encouraged to use this release, add their
> content and activities, test, and get the release out to the XOs
> before the start of the school year. We might need to provide 8.2.1 or
> 8.2.2 as they do their testing as major issues are found.

At least for now 6 moths releases with 12 month support seem pretty
sane.  One more thing to think about is making Sugar releases one month
and distributions releasing one month later.  Releasing like this should
allow distributions, currently OLPC, to plan on constant Sugar releases
dates. At the same time, the cost and effort of developing Sugar is
spread across a broader audience.      

> We had been talking about as many as 3 or 4 major releases per year...
> so this is a good point of discussion and something I'd like to
> finalize in the next few weeks.  Perhaps the minor/patch releases can
> allow small features so developers don't feel like they have only two
> times/year to get in a new feature. We have to think about what that
> means for testing and support. We also have to keep in mind that our
> audience is schools, teachers and students, not developers.

One way of handling the 'stale' issue is to detach activity releases
from OS releases.  I currently am working on modifying
addons.mozilla.org to serve activities for
activities.sugarlabs.org.     

> If we start with a set of goals for the Support of our SW, then we can
> have a good discussion on this. Here are the three goals I have so
> far:
> 1 - Ensure that security issues and major bugs are addressed in a timely fashion
> 2 - Ensure that there are resources available to review, recreate, and
> help fix and test serious and critical problems from the field.
> 3 - Manage the process of development, test, and release for
> minor/patch releases.

Here, we need to make a very conscious effort of creating support to be
collaborative.  It is very frustrating to every single distribution
trying to maintain individual patch sets for their support releases.

>From a marketing point of view, product differentiation can be useful
but from a software development point of view collaboration is critical.

Dfarning