TuxPaint woes (John Gilmore)
gregsmitholpc at gmail.com
Wed Jul 30 07:20:11 EDT 2008
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:
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
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.
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.
More information about the Devel