status of forks

Bert Freudenberg bert at freudenbergs.de
Wed Jan 14 08:23:16 EST 2009


On 14.01.2009, at 13:15, Morgan Collett wrote:

> On Sat, Jan 10, 2009 at 11:47, Peter Robinson <pbrobinson at gmail.com>  
> wrote:
>>> I see two classes of forks
>>>
>>> 1. forks to use different compile/packaging options to eliminate
>>> dependancies
>>>
>>> 2. forks to change the code (adding functionality in particular)
>>>
>>> I'm not _that_ interested in #1, but am very interested in #2,  
>>> especially
>>> anything done to make things work with the XO hardware.
>>
>> I don't think there are any other than the kernel that are forked for
>> hardware issues, and the stock Fedora i386 kernel will work with the
>> XO but the likes of numerous ethernet/storage drivers, ISA, MCA,  
>> Token
>> Ring and the like are of little use for the device :-) . There use to
>> be a HW issue in the shipped gstreamer that caused it be be forked  
>> but
>> I'm not aware of any other hardware issues in mainline kernel issues.
>
> Another reason for forks is Rainbow.
>
> telepathy-gabble and telepathy-salut both had OLPC-3 branches for
> 8.2.x and have OLPC-4 branches for 9.1.0 because Rainbow runs
> activities under different UIDs and they all need to connect to gabble
> and salut - so there are two patches for each of these to weaken the
> usual UID restrictions. This weakens dbus and socket permissions on a
> multiuser system, so the patches are only suitable for running under
> Rainbow and upstream Telepathy won't merge them into releases.
>
> Since these are build-time patches, I'm not sure how you would remove
> this fork - since regular F-10 and F-11 shouldn't have the patches,
> but Rainbow requires them.


Well, the typical way would be to add a runtime option. Like per  
config file, or an environment variable, passed into the  
initialization routine, etc. Why shouldn't that option be able to go  
upstream?

- Bert -





More information about the Devel mailing list