Activity Backward Compatibility (was re: Re: joyride 2128 smoketest)

[Brian Jordan]

On Mon, Jul 14, 2008 at 10:24 AM, Eben Eliason <eben.eliason at gmail.com> wrote:
> 2008/7/14 Kim Quirk <kim at laptop.org>:
>> I've been thinking about this problem for the last year -- when it first
>> became obvious (to me) that:
>>
>> 1 - we were definitely NOT going to be able to lock down APIs for at least a
>> year or two
>> 2 - we have no control over the activity developers and the maintainability
>> of any given activity (unless we decide to 'own' it)
>> 3 - all standard 'best practices' for ensure that 'customers' can keep
>> working seamlessly through upgrades have to be dropped for the OLPC project
>
> Agreed on all of the above.
>
>> And the only 'real' solutions I have come up with are:
>>
>> 1 - completely separate the activities from the OS in order to help people
>> understand that most activities are NOT supported or maintained by OLPC;
>> they need to be able to upgrade activities as needed and not wait for new
>> releases from OLPC
>
> This is one of those steps that makes sense politically, but doesn't
> really pan out so well in practice.  We really *do* need to have
> maintainability of a subset of activities.  It's unfortunately that
> defining the set we want to 'own' gets people so flustered, but I
> still think we may find we need to make some form of commitment in
> this regard.
>
>> 2 - push for 'school year' releases (fall and spring); where a school will
>> pick a release and use it for the entire school year so we don't have to
>> worry about upgrades in between that time
>
> Yup.
>
>> and, most recently you will hear me pushing for:
>>
>> 3 - Encourage schools to completely reflash (cleaninstall) their laptops
>> each year. At the end of the school year, you save away kids data (hopefully
>> that is done automatically) and you do a cleaninstall of the next year's
>> image; retest all the latest versions of Activities that you want to use;
>> and provide 'clean' laptops to the kids at the start of the next school
>> year.
>
> I think this would be a real shame, honestly. It completely tosses out
> the benefits of the Journal as a structure for ones interactions and
> created objects.  It means I can't incorporate photos that I took over
> the summer, or last year, into a story I wrote (for instance, even a
> "what I did this summer" essay that we've all written at least once).
> It means I can't go back and look at some math homework I did to
> refresh myself on how a particular algorithm works.  It means I can't
> create a new etoys project from an experiment I made last year but
> didn't have time to continue.  It means that I lose references to all
> the friends/groups I've made.  It means that my computer is reset to
> factory state and I have to change my personal preferences all over
> again.
>
> I think we need to find a way to make solid, secure updates without
> wiping the machines clean each year; otherwise we're contradicting our
> goals for learning, as I see it.

At the very least, end of year sounds like a good time to backup and
organize all student data from the year somewhere (XS?).

>
> - Eben
> _______________________________________________
> Devel mailing list
> Devel at lists.laptop.org
> http://lists.laptop.org/listinfo/devel
>