joyride 2128 smoketest

[Erik Garrison]

On Wed, Jul 09, 2008 at 02:29:17PM -0400, Kim Quirk wrote:
> With almost 400,000 deployed in the world, we need to have some good
> discussions on the backward compatibilty and upgradability of Activities.
> 
> Some of the bugs Charlie is writing up from the QA first look at joyride may
> be answered by upgrading an activity to a newer one.
> 
> So here are the questions we need to discuss:
> 
> 1 - Is there anyway to ensure backward compatibility of activities (the
> 8.1.1 activities will work with 8.2)?  -- seems like a long shot to me.
> 
> 2 - For support purposes, do we need or want to say that activities will be
> backward compatible only across the year designator (8.1 activities will
> work with 8.2; but from 8.x to 9.x, the activities will need to be updated
> and probably retested and checked for new translations).
> 


> 3 - Since I think it is going to be really hard to do either 1 or 2 above,
> then we have to have a strategy for easy activity upgrades. We've talked
> about this for a long time... do we have a proposal that we can really
> implement as part of the 8.2 release?

Problem:
  We release a new activity that works on our development stream, but
how does a user know if it is supported on their system?  How do they
know to download it?  What if it has system dependencies which are unmet
on the user's existing system?

Commonly utilized solution (at least in the Linux world):
  Use a package manager to manage such details for the user.  For each
packaged version of an activity, record which versions of other system
libraries and applications it requires and where to download it.  When
the user attempts to install a package, check that its dependencies are
met in the existing system.  If they are not, ask the user if they wish
to make the required upgrades and inform them of the consequences (in
terms of memory usage and other software breakage).


Such a system could also be used to deliver security updates and manage
incremental system upgrades.  (For all discussion of security I've seen
on the devel list, the distribution of security-related software updates
is not something I have noticed.  How are we planning on doing this
outside of olpc-update?)

The problem of software deployment which you note in #3 is _exactly_ the
kind of problem that package management system could be used to solve.
We already ship one on the laptop (yum)!  Perhaps we could be using it
to handle our activity updates?  If the problem is that yum is slow and
awful, then maybe we need to start thinking about using apt.

In the long run I have trouble imagining how this problem will be solved
without roughly approximating the behavior of apt or rpm package
management systems.  I suggest we start exploring methods to install and
upgrade activities using such systems.  I do not know if this is
something we can manage for the 8.2 release, but I would be more than
willing to start working on it as soon as necessary.

Erik