RFC: What to do with the stale/buggy Xft/Xrender in the tree.

[Mike A. Harris]

On Mon, 1 Mar 2004, Kaleb S. KEITHLEY wrote:

>> 2) Replace stale Xft/Xrender with new upstream version.
>>=20
>> Problems:
>> - We can't do this correctly as imake can't create .so files=20
>>   with the right versioned extension.
>
>It shouldn't be hard to fix imake, or more accurately, lnxLib.rules, to=20
>deal with teeny library revs. That's probably useful in the general=20
>sense. Although it'll break when some genius decides he needs four=20
>levels of versions on a library.

I don't think anyone is worried about 4 level versions, as I=20
don't think they exist, but if you think it's easy to fix imake=20
to permit 3 levels easily without breaking portability at all,=20
that sounds like a possibly superior solution.


>> - While there are a few ugly hack methods that might work, they=20
>>   would be very ugly and prone to be problematic, and highly=20
>>   likely to be non-portable.
>
>What part is non-portable?

The hacks which I envisioned but did not elaborate on "work on=20
Linux", but wether they would work on any other OS I haven't the=20
faintest clue, and so I assume they are not portable by default,=20
because they specifically will name the files with 3 level=20
version period.  Any OS that doesn't support that will break.

Thus, the "hack" solution is not viable IMHO in the xorg tree as=20
it is just that - an ugly OS specific hack.


>> After our discussion in IRC, we currently believe that option #6
>> above is the least disruptive of them all, and provides the most
>> amount of compatibility, while making the defaults sane for each
>> OS platform.  I would like to get some technical feedback from
>> Egbert and others about the above solutions, and try to come to a=20
>> concensus soon, so that the work to clean this up can get in tree=20
>> ASAP.
>
>but I'd rather see lnxLib.rules fixed to deal with three-level
>versions and install current bits.

If it is that easily fixable, then this is probably a better all
around solution.  Who is the most familiar with Imake that could
make this happen ASAP, so we can get the new Xft/Xrender/Xcursor
into the tree?

Even with them in tree however, we still need to implement=20
HasXrender/HasXft/HasXcursor so that out of tree libs can be=20
used.  That part is easier though.


>I missed that discussion (because I can't be on IRC 24=D77)

Nobody can be present in IRC and also awake and at their keyboard
24/7 ready for a conversation that might creep up.  ;o)

Nonetheless, IRC is a very useful realtime communication and
collaboration tool which we currently use to discuss whatever
topics happen to come up.  Those present at the time when a
discussion arises, or who join in while a discussion is underway,
obviously have the opportunity to participate in the discussion
if they desire.

Nobody is expected to use IRC to communicate, or to even use it=20
at all ever if they do not wish to.  Those who do use it however,=20
find great benefit in doing so, and are unlikely to stop using=20
it.

Since this particular topic did arise in IRC however, I decided=20
to use IRC as a tool to brainstorm possible solutions with Keith,=20
Jim and others present, so that we could then put together an=20
email message presenting the problem and our currently=20
brainstormed solutions to the wider group of people.

To have discussed that purely via email would have taken several=20
days at a minimum due to the asynchronous nature of email, and=20
how closely people read their email and respond.

Likewise, we have several weekly teleconference calls, and some
people can make it to them, others can not, either due to the
expense of a long distance call, due to timing conflicts, or due
to other reasons.  Nonetheless realtime confcalls are a very
useful part of the collaboration process, and we need them to
continue, even if some people can't participate in them, or
choose not to for whatever reason.  The same thing can be said
about IRC.

The important thing, is that there are /multiple/ communication
mechanisms available to open source projects, which increases the
amount of collaboration going on.  Nobody is pressured to use IRC
any more than anyone is pressured to call into a confcall, or
join a mailing list.  People will use the tools that work for
them best, and others do the same.

Several people who can't make confcalls have asked for meetings=20
to be arranged using VoIP software also.  Some people are=20
comfortable with this, others are not.  Others like myself are=20
behind IP firewalls that make that type of software break=20
horribly.  I'm sure nonetheless though that someone will start=20
setting up VoIP meetings as an additional communication=20
mechanism for those so interested to use.

I guess the main point I'm trying to make, is to use whatever=20
communication mechanisms you find most effective for you=20
personally, however others will do the same, and while there is=20
likely to be some overlap, there is also likely to be personal=20
preference that does not overlap.

Take care,
TTYL

--=20
Mike A. Harris     ftp://people.redhat.com/mharris
OS Systems Engineer - XFree86 maintainer - Red Hat