On Thu, May 20, 2010 at 06:48:31PM -0500, David Farning wrote: > 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.
Great news. Please CC me to bugs/patches involved to this deployment. For now, I'm more working on 0sugar/polyol/libjournal and don't track core related stuff often, but I'll do my best. Besides, I'm planing (next week) start changing ASLO code base (will post to sugar-devel@ about it) to make ASLO more corresponding to particular deployment needs (per deployment QA and activities list at least). > 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!) > i...@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/iaep > -- Aleksey _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel