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

[Peter Robinson]

On Fri, Apr 16, 2010 at 9:20 PM, Bernie Innocenti <bernie at codewiz.org> wrote:
> 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".

Yes, but usb_modeswitch works quite well. There's been a lot change
since RHEL 5 was released about 3 years ago. I think RHEL-6 will be
somewhat more easy in that regard because a lot of the building blocks
that weren't in place 3 years ago are now.

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

Hmm. Skype isn't what I would call an enterprise product. If you want
enterprise VoIP you'd use enterprise. Adobe still support acroread etc
on RHEL-4!

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

Yes, but being supported on the enterprise product means its more
likely to be fixed in their stream. It also gives you a more stable
environment rather that something that is like running across jelly.

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

Yes, but we would have packages in the later versions of fedora that
would support the later ABI of the newer versions of firefox that we
would be able to compile against it so that isn't a major problem. One
of the advantages of following both release trains.

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

See point above.

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

umm.... we're talking RHEL or a RHEL derived distro. That side will be
stable..... and the core components of NM are stable. The thread that
you reference from the quick read I had was due to instability in the
driver that was worked around in NetworkManager so that can only talk
up not down NM support!

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

Really? I bet it was more the underlying driver issues that were more
the case..... Almost all of the issues I have wit NM ultimately are
the drivers not NM at all.

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

People are slowly coming around, and I'm slowly bribing people :-D

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

We pay for support (RHEL you need subscriptions, and that is support)
but the support I refer to above is from me logging bugzilla tickets
under my standard BZ account (my gmail address) so is not any
different to anyone else because quite simply I've never needed to
pull out the "I have paid support fix this now" ticket because it gets
fixed so quickly by just logging it in BZ (recently got a bug acked
and a patch posted for RHEL-4 24 hours after I posted the bug!)

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

Agreed. And in fact I said that exactly and hence my reference to the
18 month to 2.5 year point but the fact is by then you'll almost be to
RHEL N+1 release so you role it over.

The EL packaging makes it easy enough that its "if it compile and
there is demand for it then you can do so because to push it out isn't
had" if it stops compiling you send it out to the lists and either
people care enough to fix the problem or else it stays on what ever
the currently compiling version is. Sort of like the extended
maintenance of the 0.84.x releases.

Your making the problem like a Cross Road in a road. Its really not
that. We are going to be following the upstream Fedora releases but I
really don't think it will be hard to follow a RHEL release train
either. In the F-7 to F-10 time frame the changes were massive. I know
I had to assist in merging them upstream. But since then there's not
been massive underlying changes that aren't manageable. The biggest I
think are probably Tomeu's plans for the telepathy stuff and that is
just to bring us back in line with the main line.

I think the next big disruptive change will be python3 and associated
pygtk changes, and while I don't have a crystal ball I think we can
either stick with the current and it will be supported or there will
be ways to support the new stuff.

Cheers,
Peter