[IAEP] Long-term development strategy (Was: New XO-1.5 10.2.0 build 119)
pbrobinson at gmail.com
Tue Apr 13 02:59:49 EDT 2010
On Tue, Apr 13, 2010 at 2:31 AM, Bernie Innocenti <bernie at codewiz.org> wrote:
> 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
RH updates those sort of components regularly to ensure support.
> * Playing multimedia content downloaded from the Internet requires
> gstreamer with up-to-date codecs
That is not due to up to date codecs but rather patent free codecs.
Completely different issues. That is as valid with F-13 today as
> * activities such as Record tend to uncover obscure bugs in GStreamer
Nothing stopping these being fixed in RHEL/CentOS.
> * 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
RHEL updates this regularly as well and actively moves to the current
version. I believe RHEL-5 has firefox 3.5
> * ...not to mention NetworkManager...
Mention what about it? We don't use any of the latest NM features, its
stable and the maintainer actively assists and accepts patches.
> 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.
You are not alone, you should see my BZ queue.
>> 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
> 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.
In fact alot of the differences in packages were merged back in by me
in the F-10/F-11 timeframe. I'm well aware of those issues, I still
track them closely. I just wish it was the same with the kernel :-)
> 2) we switch to a real package system for activities with full support
> for dependency checking and a build cluster for multiple targets.
One word. PackageKit. Then its agnostic for all the distributions.
> 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.
You've obviously not dealt with them then on the RHEL side of things.
I work for a company that had over 1200 RHEL systems.
There are advantages to both approaches and I don't see that
supporting both is going to be an issue to do so at least in the short
term. I don't see that we need to rule out either option.
More information about the Devel