On Fri, May 21, 2010 at 4:46 AM, Tomeu Vizoso <[email protected]> wrote: > On Fri, May 21, 2010 at 02:04, David Farning <[email protected]> wrote: >> On Thu, May 20, 2010 at 6:55 PM, Paul Fox <[email protected]> wrote: >>> david wrote: >>> > As Bernie announced, we working on supporting Sugar .88 on the XO-1. >>> >>> hi david -- >>> >>> for those of us joining this thread late, can you expand on what/who >>> you mean by "we"? (or tell me to read the archives, if that's >>> more appropriate.) >> >> Sorry, By we, I mean Activity Central and compnay that Bernie, >> Caroline, and I have started to support OLPC and Sugar deployments. >> >> It is going to take me awhile to figure out how to communicate with >> the community. I would like to keep the larger Sugar and OLPC >> projects aware of what our company is doing. But, I don't what it to >> sound like a press release of pitch for the company:) > > Any blog we could syndicate in the planet(s)?
Excellent point, I'll start a blog and request that it be syndicated on the Sugar Labs and OLPC planets. > Regards, > > Tomeu > >> david >>> paul >>> >>> >>> > This projects is customer driven by the deployment in Paraguay. They, >>> > along with bernie, made a decision that it would be more useful, >>> > usable, and cost effective to settle on .88 rather than .82. This >>> > strictly a decision made by a single deployment, which I support. >>> > >>> > As an ecosystem we can make lists of Pros on Cons why this is a good >>> > or bad decision and why I am an idiot. At the end of the day this was >>> > a decision made by a deployment. The primary reason for this decision >>> > is that the deployment does not yet has an established base of .82 >>> > machines. Something we need to be aware of as developers is that >>> > deployments think on a much longer scale. As developers, if we have a >>> > bug we can commit a fix and rebuild within a few days. Deployments >>> > can take weeks if not months to push a minor update. >>> > >>> > Major version upgrades are something developers can do every six >>> > months. From my experience a couple couple of weeks of 'hmmm, better >>> > file a bug on that' and I have well running machines after an upgrade. >>> > For a enterprise, such as a deployment, the decision to update >>> > becomes much harder and takes much longer to implement. As Martin >>> > pointed out, a significant amount of Quality Assurance goes into a >>> > deployment upgrade. Not only do the hardware, OS, and learning >>> > platform need to work together, all infrastructure, activities and >>> > third party applications must also work after the update. The problem >>> > just got significantly harder:) If I hit a bug while while sitting in >>> > my office that is one thing. If a teacher hits a bug where the >>> > computers no longer connect to the server that is another thing >>> > entirely. >>> > >>> > On the other hand, there have been several significant improvements in >>> > both Sugar and Fedora over the last couple of releases. It would be >>> > valuable to make those improvement available to end users. >>> > >>> > My research has indicated that education institutions find that 3 >>> > years is the right balance between stability and improved >>> > functionality of new software. Because to the newness of the Sugar 2 >>> > years is a reasonable first round of updates due to the higher than >>> > normal increases in usefulness and usability. >>> > >>> > Blame and credit are important motivators in this game:( As such, if >>> > we fail, it is the fault of Bernie, paraguayeduca, and I for: 1) >>> > starting with a bad premise, 2) making bad technical decision, or 3) >>> > making bad operational decisions. If we fail it will be due to the >>> > cooperative efforts of deployments, Sugar Labs, OLPC, and other >>> > interested third parties. >>> > >>> > david >>> > _______________________________________________ >>> > Sugar-devel mailing list >>> > [email protected] >>> > http://lists.sugarlabs.org/listinfo/sugar-devel >>> >>> =--------------------- >>> paul fox, [email protected] >>> >> _______________________________________________ >> IAEP -- It's An Education Project (not a laptop project!) >> [email protected] >> http://lists.sugarlabs.org/listinfo/iaep > _______________________________________________ IAEP -- It's An Education Project (not a laptop project!) [email protected] http://lists.sugarlabs.org/listinfo/iaep
