TuxPaint woes

[John Gilmore]

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

As someone whose year-long OLPC-specific project (SimCity) was broken
by Sugar interface changes right before the 650 release, I can report
that it was pretty disheartening.  Both the sound and the running icon
for SimCity were broken (and remain unfixed today).  The breakage was
created *after* Electronic Arts' QA testers signed off on the fully
functional SimCity release.

The next release was the 656 bug-patch, not involving SimCity; the one
after that was the update.1 "non-release" that was frozen for four
months without visible progress, and then some random numbered
snapshot "became" the release, except without any activities.  There
hasn't been one since.

When, exactly, should we be testing SimCity against a release
candidate?  What level of interface freeze is OLPC and SugarLabs
willing to give us?  When we revise it until it works, and submit it
to EA for another round of QA, we want to be sure that Sugar won't
break it again with last-minute changes.

There are many reasons to change Sugar interfaces.  The datastore
interface is totally terrible and can't survive, for example.  But how
about providing a second, improved, interface in parallel; then
migrating most activities over to it; then deprecating the original
interface, and gradually removing support for it over several
releases?  Rather than changing the syntax or semantics of the
existing interface.  And how about doing interface conversion work at
the *beginning* of a 6-month development cycle, not at the very end?
This isn't rocket science; many software projects have learned these
lessons.  Sugar can learn 'em too.

	John