TuxPaint woes (John Gilmore)

[Greg Smith]

Hi John and Michael,

Thanks to John for raising these concerns and sticking with us after a 
frustrating first two experiences. SimCity has good traction in the user 
  base and its a very high priority activity for us.

On when the code is stable and frozen enough to do final regression 
testing of activities:

Michael,

Can we track that as a milestone? Is that "code freeze (a.k.a.
package-level change control)" which is targeted (pending confirmation 
e-mail) for Wed. August 6?


On the question of future API re-architecture, it is under consideration 
for 9.1.0 and being tracked here: http://wiki.laptop.org/go/9.1.0
especially at
http://wiki.laptop.org/go/9.1.0#e-mail_from_Ben_S

I will try to warn well in advance of any future API changes and I will 
try to hold changes to a minimum (target none!) between 8.2.0 and 9.1.0. 
  We need to hear confirmation from the engineers and we may need to 
revisit this after we put a stake in the ground on freezing 8.2.0 APIs.

Thanks,

Greg S

Date: Tue, 29 Jul 2008 17:54:42 -0700
> From: John Gilmore <gnu at toad.com>
> Subject: Re: TuxPaint woes 
> To: devel at lists.laptop.org, gnu at toad.com
> Message-ID: <200807300054.m6U0sgle031956 at new.toad.com>
> 
>  > >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
>