[IAEP] Long-term development strategy (Was: New XO-1.5 10.2.0 build 119)

Bernie Innocenti bernie at codewiz.org
Mon Apr 12 21:31:25 EDT 2010

On Mon, 2010-04-12 at 23:54 +0100, Peter Robinson wrote:
> Bernie, I'm not sure the point of this point at this point in time. To
> copy and paste part of the response I did to the other thread on
> fedora-olpc for others benefit.
> I personally don't see the point discussing it because from where I
> sit I believe it will be supported well in both and continue to be so.
> That way people have the choice. It might well get to a stage where
> the newer versions of sugar won't run in RHEL/CentOS due to whatever
> deps at which point we get to a situation where that release becomes
> like 0.84 is currently and is a long term support release. I don't see
> why its hard to support both because its not. The package maintenance
> is simple and is done easily by a couple of people. There will be
> Fedora and it will continue to be supported in Fedora for the
> developers and the like that want the bleeding edge and then there
> will be the EL branch for those that don't like so much blood. Its
> called choice. There's no reason to limit it. There's not much point
> discussing it at the moment as RHEL-6 isn't out yet, yes its in beta
> but its not out.

I agree on this, but it misses the point :-)

I'm sure maintaining the Sugar 0.84 packages will be easy in RHEL6 as it
is in F11. I've even back-ported Sugar 0.88 to Fedora 11 with minimal

Most end-user support issues lay within base OS components rather than
the relatively small codebase of Sugar. Here are some real-world
examples from this development cycle:

 * GSM connectivity requires up-to-date versions of udev and
   modem-manager to support USB dongles commonly available in stores

 * Playing multimedia content downloaded from the Internet requires
   gstreamer with up-to-date codecs

 * activities such as Record tend to uncover obscure bugs in GStreamer 

 * Browse depends on xulrunner for security and compatiblity with web
   standards. Surfing the web today with a version of Firefox from
   3 years ago would be unthinkable

 * ...not to mention NetworkManager...

I would guesstimate that 80% of my time went into fixing platform bugs
and just 20% on Sugar itself. In part, this is because I could offload
the actual bugfixing to helpful people such as alsroot, silbe,
sayamindu, mtd and others.

> In short RHEL-6 isn't out yet, the associated CentOS6 release is quite
> a while away as a result. Also ARM isn't a supported platform there.
> Sugar is about options and I think having both options will be of
> benefit to different users. I believe the leading edge Fedora will
> continue to be a platform for development and then others in the know
> or deployments themselves can make the decision as to what's best for
> them.

In practice, choosing the distro independently of Sugar won't be
feasible on the XO until:

1) we merge (or kill) all the OLPC customizations. dsd and sdz have done
   a lot of work in this direction, but there are still a number of
   rogue packages in F11-XO1.

2) we switch to a real package system for activities with full support
   for dependency checking and a build cluster for multiple targets.

After this is done, it remains to be seen if someone who is using RHEL-6
on the XO would be able to file a bug in Red Hat's Bugzilla and actually
get it fixed for free. I have a feeling one would need to purchase an
enterprise support contract of some kind in order to attract the
necessary developer attention.

   // Bernie Innocenti - http://codewiz.org/
 \X/  Sugar Labs       - http://sugarlabs.org/

More information about the IAEP mailing list