TuxPaint woes

[pgf at laptop.org]

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.

 > 
 > > that we support the activities ourselves, 
 > 
 > As above. 

we clearly can't support all activities.  i'm sure you realized it
was a rhetorical suggestion.

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

 > 
 > See 
 > 
 >    http://gsoc-sugarbot.blogspot.com/
 > 
 > for some active work in this direction.

this looks like a testing framework.  how does this help activity
developers?  (sorry -- i'm rushing, and don't have time to give
it a full read.)

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

as someone else replied, this is far from trivial.

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

i'd point out that the continually breaking kernel interface is
a serious problem for lots and lots of clients of the linux kernel,
no matter how much the lkml believes otherwise.

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

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

i'm not sure about that.  :-)

paul
=---------------------
 paul fox, pgf at laptop.org