[sugar] TuxPaint woes

[Michael Stone]

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?

> that we support the activities ourselves, 

As above. 

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

See 

   http://gsoc-sugarbot.blogspot.com/

for some active work in this direction.

>so far OLPC hasn't specified a minimal level of supplied
>services, or offered a way for activities to explicitly request
>services they know to be required.  

On the other hand, it would be rather trivial for activities which cared
to check their dependencies in a adhoc fashion (by running rpm
themselves if they wish) and by reporting errors if necessary
dependencies are unsatisfied.

> do you really think we can expect activity developers to maintain
> their code in "reaction mode", having to adapt to any change we make
> from release to release, only finding out about the breakage after the
> fact?  

I actually think that we [SugarLabs] should adopt an approach similar to
that taken by the Linux kernel (loosely paraphrased as):

   "we're going to make breaking changes but if you push your drivers
   [activities] upstream, we'll help carry them along..."

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.

>can't think of a faster way to make developers give up on our
>platform as a lost cause.

You need to be more imaginative. :)

Michael