TuxPaint woes

[Erik Garrison]

On Tue, Jul 29, 2008 at 08:04:10AM -0400, pgf at laptop.org wrote:
> michael wrote:
>  > On Mon, Jul 28, 2008 at 11:26:28PM -0400, pgf at laptop.org wrote:
>  > >the obvious answers are that we need to commit to some level of
>  > >continuing support for activities, 
>  > 
>  > What notion of "support" would you suggest?
> 
> not breaking supplied interfaces without providing feedback to
> the activities that they're broken.  commiting to a level of
> minimal interfaces.  that sort of thing.
> 

The software interfaces on the XO are in large part provided by system
libraries.  In the case of TuxPaint, the interface breakage includes the
removal of software systems from our builds which TuxPaint requires to
run.

We can lock down the Sugar API and provide feedback when that API
changes, but attempting to provide feedback about breakage in all the
other software interfaces on the XO is not something which I believe is
possible without cataloging and managing a list of interface
(software) dependencies which each activity requires.

At very least, developers should have access to such a catalog.  Unless
we are going to produce our own solution to this problem, I suggest that
such a cataloging system already exists in the form of existing package
managers, and we should consider how we can intergrate with these
systems before claiming alternative methods are equivalent.
  
>  > > or that we need to provide an extensible system so that
>  > >activities can specify their dependencies (which will either lead
>  > >to their fulfillment, or to the explicit disabling of the activity if
>  > >they can't be fullfilled).
>  > 
>  > Constraint satisfaction (i.e. dependency checking) is certainly one
>  > approach; however, it is not universal; i.e. similar results can be
>  > achieved with usage-outcome reporting technology driven by both manual
>  > and automated regression testing.
> 
> this isn't a good argument against dependency checking.  and i'm
> not sure why we'd go out of our way to invent yet another new
> technology to support our system.

I do not understand how usage-outcome reporting technology will be more
readily deployed than activity-author directed dependency description.
In my opinion, proactive author-driven dependency description is a more
easily delegated task than regression testing.

The procedure for a given activity author to verify a set of
dependencies for their application would be as follows:

 - Set up debootstrap-like environment on which to test their activity.
 - Use a package manager to download all the packages required to run
   the activity.
 - Produce a list of the list difference between the base packages in
   the system and those required for the activity.

Then, on the image-builder side of the software distribution cycle:

 - Set up a debootstrap-like environment to build a system image.
 - Use a package manager to download all the activities to be used on
   the system.
 - Produce an image which can be used to boot an XO.



>  > According to this suggestion, OLPC would contribute to the maintenance
>  > of activities which are important to it as would any other employer of
>  > SugarLabs coders. Overall responsibility for maintaining SL-designated
>  > activities would rest with the SugarLabs community itself.
> 
> i don't believe this model would work.  open source works because
> by and large the traditional unix application environnment has
> been _incredibly_ stable -- the system call interface hasn't changed
> via deletion of a call in a very long time.  when new interfaces
> or api's are introduced, a lot of effort is put into creating new
> stability:  system calls are deprecated for years before being
> deleted, likewise for gtk api calls.  system modules aren't
> simply removed -- they become separate packages that can be
> separately requested.  open source developers (and i count myself
> among them) aren't the least bit interested in chasing a moving
> target -- they want a stable base on which to work.

It is exactly this thread of tradition which we have broken with.
Primarily because of security concerns, we don't provide application
developers access to a set of interfaces which largely haven't changed
since a decade before I was born.  This is not helping the integration
of existing open source efforts into ours.


erik