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

Mon Jul 14 10:09:06 EDT 2008

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

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
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

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.

If schools agree that this a good idea (it also wipes all the data and
provides students with a lot more room); then what I would push for is that
saved data can continue to work on upgraded activities -- this is something
that the activity developers have to worry about, but it decreases the test
effort quite a bit and recommends that schools retest activities between
school years.

Kim

On Mon, Jul 14, 2008 at 9:14 AM, Greg Smith <gregsmitholpc at gmail.com> wrote:

> Hi All,
>
> Responding to all in one pass.
>
>  From Scott -
> > The general solution to this problem is trac #4951, the activity
> > updater, which I've landed recently.  Trac #7495 says that the first
> > boot after an upgrade should open the activity updater, so that a
> > version of the activity compatible with the new OS can be installed if
> > necessary.  The activity update protocol understands simple base OS
> > dependencies, so that you can specify a different version for 8.1 and
> > 8.2 (for example).  The [[Activity_bundles]] wiki page documents the
> > update_url tag.
>
> GS - Sounds good but it still requires all activity developers to update
> their activities which I think is the central problem. Also, we still
> need to warn users in advance, especially if they upgrade via USB.
> Definitely will help so let's do it if its not too much work.
>
>  From Michael -
> 2 -
> > Off the top of my head:
> >
> >   Activity toolbars
> >   Bitfrost protections
> >   Power-management work
> >   Datastore APIs
> >   Collaboration APIs
> >   APIs which hamstring our software on other distributions
>
> GS - How certain are these and is there any documentation of them or
> what activity changes they will require? We should agree that they are
> must have items worth requiring activity upgrade before doing them and we
> should document what it will cost activity developers if we do.
>
> > As above - it is our responsibility, when making breaking changes, to
> > help carry our downstream partners along with us.
> and related comments
>
> GS - Does anyone have the contact info for the developers of all the
> currently available activities? Can we document the changes they need to
> make in 8.2.0 and contact them? Let's also ask them what they think
> about us requiring they rewrite in each release.
>
> >> If we can define "well behaved" and not test activities that meet that
> >> criteria it will save us a lot of test time.
> >
> > As hinted above, I do not believe that we can spare activities from API
> > breakage. At best we can somewhat increase the amount of time in which
> > it is possible run software based on deprecated assumptions.
>
> GS - I'm asking if we can tell developers "here are the things you can
> do which will be safe". That is, make some kind of promise of backward
> compatibility for some subset of all functionality.
>
> >  http://ivory.idyll.org/blog/mar-08/software-quality-death-spiral.html
> >   http://ivory.idyll.org/blog/mar-08/pycon-08-thoughts.html
> >   http://ivory.idyll.org/blog/mar-08/peekaboo-and-screencasts.html
>
> GS - Will read Monday, thanks.
>
> >> e.g. can we say that all activities not listed on this page:
> >> http://wiki.sugarlabs.org/go/ReleaseTeam/Releases/Sucrose/0.81.4 will
> >> work the same in 8.2.0 as they did in previous releases?
> >
> > Your statement is too ambiguous to safely promise. Can you be more
> > precise about what you actually want to promise?
>
> GS - I thought it was precise :-) and I meant "not". I want to know if
> we can promise that *any* activities will continue to work. I hoped that
> these Sugar activities are the only ones using some APIs (e.g.
> collaboration) and therefore the only ones susceptible to breakage.
>
>
> >> In the future if some piece of core code will cause previously
> supported
> >> activities to no longer work, I hope we can discuss and accept or
> reject
> >> that in advance (sorry if I missed that debate on this round).
> >
> > Again, please say more about what you're thinking of.
>
> GS - I'm saying let's make sure to discuss and agree before making any
> API changes that might break activities.
>
> > Tuesday call?
> >
>
> GS - Sorry I meant Tuesday software IRC/Gabble meeting. We are on for
> Tuesday and Wed. again this week at the same times, right?
>
> RE: Marco's comments.
>
> GS - Thanks! Can you start adding the names of all activities that we
> know should/will work to the Release notes too?
>
> How does someone know what version they have of an activity in Fructose
> or Glucose?
>
> Its helpful to claim "backward compatible" from Update.1. However, I
> believe many people will be upgrading from 656 too. Maybe we have to
> say: "upgrade all your activities" in that case?
>
> **********
> A few more questions on this:
> - Leaving aside how its done technically, I believe that Linux
> distributions are fully backward compatible. That is, you can go to the
> latest supported Distribution and leave your Firefox (or any
> application) on its older release and it will still work fine. Let me
> know if that is not correct. I think that is what we need to strive for,
> eventually.
>
> - Black box testing of all activities is not feasible unless the
> authors do it themselves. Can we grep all the activity source code for
> the functions (or objects or whatever) that have changed and determine
> which activities might break? I haven't learned much about activity
> creation and bundling yet so pardon my ignorance if this is a naive
> question.
>
> Until we get a better grip on "downstream" relationships with activity
> authors I think the only short term answer is better documentation.
>
> Can someone put up a wiki page that explains what has changed and tells
> activity authors what they need to check in their code to determine if
> they are still compatible?
>
> Bobby,
>
> Are you ready to upgrade your activity every 6 months? Do you promise?
> :-) Do you know what to do in this release?
>
> **********
> Sorry for the long thread but I'm worried. If any significant activities
> fail on upgrade, users will hit the roof. Users don't know the
> difference between the OS and the activities (not sure I do either :-).
> They just know something used to work and after we told them to upgrade
> it doesn't.
>
> Imagine someone walking 20 hours through the jungles of Peru with a
> USB stick. Upgrading a remote school then finding out they can't save in
> Write or TamTam. They can downgrade (kudos to whoever built that!) but
> he has to walk 40 more hours now to fix it. If he read the release notes
> and there was no mention of this, that will be one angry technician!
>
> Hopefully I'm being too conservative and 8.2.0 will go easy so we have
> more time to come up with a plan...
>
> Thanks,
>
> Greg S
>
> _______________________________________________
> Devel mailing list
> Devel at lists.laptop.org
> http://lists.laptop.org/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laptop.org/pipermail/devel/attachments/20080714/d25342e1/attachment.html>