[IAEP] Supporting Sugar .88 on the XO1
alsroot at member.fsf.org
Thu Jun 10 11:33:26 EDT 2010
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
> 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.
> IAEP -- It's An Education Project (not a laptop project!)
> IAEP at lists.sugarlabs.org
More information about the IAEP