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