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

[Bernie Innocenti]

On Mon, 2010-03-15 at 10:46 -0500, Martin Langhoff wrote:
> On Sun, Mar 14, 2010 at 1:17 AM, Bernie Innocenti <bernie at codewiz.org> wrote:
> > 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
> 
> So no XS in place?

The repair lab is not nearby any of the schools.


> Downstreams that go to deployment (OLPC!) want to wait until a release
> is reasonably well tested and stabilised.

We have a chicken-and-egg problem: deployments have to participate in
testing (and development), otherwise no bugs will ever be fixed.


> > Stability is a classic justification for longer release cycles
> 
> The thing is: stabilisation takes time. These users are not
> programmers, nor geeks. They are not the Fedora hard-core "gimme the
> latest even if broken". They are teachers and children in a school.
> 
> I don't mess with my editor or my version control system often. emacs
> updates have messed up my life, so I don't do them in the middle of a
> project. Similarly, teachers won't want frequent updates, or updates
> that are broken (in Sugar core, or in activity compatibility!).

Letting volunteer children and teachers test the software has been
incredibly productive. I wish I could have started one month earlier, so
there would have been enough time to fix most problems before schools
reopened in LatAm.

A few trainers who were asked to test new builds much explanation
complained for the annoyances without providing enough information for a
bug report. Considering that most of them were exposed to computers for
the first time in their lives just a couple of months ago, it's no
wonder they were unable to distinguish between hardware and software
problems.

I filed a few real bugs last week, and this week I'll spend a few full
days side by side with the trainers to see what issues are still
bothering them.


> That is only true if the dev team only cares about the hardcore geeks
> that want the latest and greatest.
> 
> If the dev team cares about end users, then it's not abandonware.

Which dev team? There are many: Sugar Labs, OLPC, Fedora, and all the
other upstream projects we depend upon.

Now I have a problem with udev which is unlikely to be fixed by
upstream. The maintainer *does* care about end users, but he'd rather
spend his time supporting the current user base than the legacy Fedora
11 which is soon going end-of-life.

Same goes for the activities developers: maintaining compatibility with
3-4 releases of Sugar is prohibitive. Backporting bugfixes is also very
expensive in terms of time and not something that volunteers are likely
to do spontaneously.

OLPC allocated developers to maintain the Sugar 0.84 and related
activities, but it would save time if we could stay closer the latest
Fedora and the latest Sugar, at least at release time.


> > 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.
> 
> Agreed. One path is to release less often. Or to mark certain releases "LTS".

I've been suffering with RHEL for a while and I'm sure Ubuntu LTS has
the same problem: no support for new hardware, ancient versions of
software which don't interact well with the rest of the world...

I think it would work well if one could freeze the whole universe at the
time of the LTS release.


> Yep. You could make it a "major / minor" pair. So you only have one
> LTS per year.
> 
> "Developer" releases can happen more often.

One year of slack between development and user release would be ideal.
By LTS, I thought you meant 5 years :-)

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