[Sugar-devel] [IAEP] Children want Sugar 0.84, for the wrong reason

[Bernie Innocenti]

On Sat, 2010-03-13 at 20:50 +0000, Gary C Martin wrote:
> Agreed, though this argument only really works if the changes
> each time are easy to install from the user perspective with
> no loss of data. I wish we were doing much better here.

Me too, but it's not as bad as it seems: the techies use a simple shell
script to backup and restore the journal (and scratch data) across
updates. The script doesn't backup any Sugar settings, so users get to
the initial setup screen when they're handed back their laptops. Nobody
ever complains about this, but it would be easy to do.

To save time, only teachers' journals are being preserved across
updates. Kids don't seem to care at all, they voluntarily come and beg
the technicians to upgrade their laptops so they could use "Piecito".


> It feels uncomfortable that Sugar 0.84 is already a year old effort
> as of this week, from its official release, too far ahead of
> deployments?

It seems we should try to shorten our "time to market". Both Fedora and
SoaS have been trailing Sugar releases quite well. Instead, OLPC appears
to have frozen on Fedora 11 much too early.

Both Sugar and Fedora are aligned on a predictable, 6-months release
cycle, so it's safe for downstream projects to pick a version which is
expected a few months before the target release date.

Stability is a classic justification for longer release cycles, starting
with a selection of well seasoned packages. The problem with this
approach is that, by the time it reaches the first user, all software is
already abandonware. Upstream developers are working 3 versions ahead of
you and tend to ignore all your bug reports. So you end up backporting
all the fixes you need on your own, which tends to be hard and risky
because meanwhile the codebase has changed so much.

One would think that a relatively fixed platform like the XO-1 could lag
behind on hardware support without consequences, but users have the bad
habit of demanding that a 3G modem purchased last week would work on a
version of Fedora released one year ago. So you end up back-porting
large pieces of Fedora 12--breaking who knows what else--while the udev
maintainer asks you to keep him informed on your progress. So much for
the good intentions of stability.

Not to mention dependencies: many of the bugs found in Sugar activities
by your testers seem to have been fixed in new upstream releases...
which require Sugar 0.86 minimum. Bummer!

Given enough time and money, one could even stabilize Windows Vista.
However, the most efficient use of our scarce resources would be to
reduce version diversity across downstream distributors in order to
share the burden of maintaining all them.

The educational nature of Sugar puts one additional constraint on us:
software updates are best done at the beginning of every school year,
which varies wildly from one nation to the other. Given our 6-months
cycles, at any time we'd have todeal with a minimum of 2 Sugar releases
in parallel.

Not ideal, but still better than the current situation in which we start
a school year with a version of Sugar released over one year ago.

-- 
   // Bernie Innocenti - http://codewiz.org/
 \X/  Sugar Labs       - http://sugarlabs.org/