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

[Peter Robinson]

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 :-)

Not exactly.

> 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
> tweaks.
>
> 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:

Agreed.

>  * 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
RHEL-5

>  * 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
>> 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.

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.

Peter