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!)
IAEP@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/iaep
--
Aleksey
___
IAEP -- It's An Education Project (not a laptop project!)
IAEP@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/iaep
