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 <[EMAIL PROTECTED]> > Subject: Re: TuxPaint woes > To: devel@lists.laptop.org, [EMAIL PROTECTED] > Message-ID: <[EMAIL PROTECTED]> > > > >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 > _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel