As Bernie announced, we working on supporting Sugar .88 on the XO-1. 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 _______________________________________________ IAEP -- It's An Education Project (not a laptop project!) [email protected] http://lists.sugarlabs.org/listinfo/iaep
