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

[Bernie Innocenti]

On Tue, 2010-04-13 at 07:59 +0100, Peter Robinson wrote:
> > I agree on this, but it misses the point :-)
> 
> Not exactly.

That was just supposed to continue your point-point-point pun :)


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

This isn't a trivial bugfix or a matter of a missing product ID. It's an
entire missing subsystem. I asked Harald Hoyer, the maintainer of udev,
if there was a way to back-port the mode switch functionality from F12
to F11 and he told me "good luck with it".


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

RPM Fusion does indeed support RHEL5, but that's quite surprising.

Enterprise distros have a tiny user base relative to the mainstream ones
and tend to be badly supported even by proprietary software vendors such
as Skype and Adobe.


> >  * activities such as Record tend to uncover obscure bugs in GStreamer
> 
> Nothing stopping these being fixed in RHEL/CentOS.

Nothing stops bugs from being fixed on Red Hat 7.2 either, as long as
you're willing to invest your own time to do it.


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

Ha! Upgrading Firefox to version 3.5 would break the xulrunner ABI, on
which we depend for hulahop (and hence Browse).

If adding features incrementally without ever breaking the ABI was
feasible, the mainstream distros would do it as well.


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

Stable?!? See this thread (it's broken up across 3 months in the
pipermail archives):

 http://lists.laptop.org/pipermail/devel/2010-February/thread.html#27505


Besides this one, there were also other problems. I'd say NM was a major
headache for this development cycle.


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

Sorry, I totally forgot about the awesome work you had done for
upstreaming OLPC changes into Fedora.


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

+1 from me, but many Sugar developers wish to maintain the status quo.

It's been discussed many times in the past. Unless the distributors take
the initiative to do the work, it looks like native packaging formats
aren't going to be supported by Sugar anytime soon. 


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

Are we talking about paid support or free support? I'm sure you can get
RH to fix any bug if you purchase 1200 RHEL licenses from them.


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

I'm not against packaging Sugar for RHEL. I just think it would cost
more to support after the first year or two.

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