Somewhat OT XFree86 question (maybe M. A. Harris will speak up)

[Mike A. Harris]

On Mon, 27 Oct 2003, Ryan G. wrote:

>slashdot threads) I find them to be quite useful and productivity
>enhancing.
>
>My questions are these;
>
>1-is/will true transparency implimented in gtk/xfree

That depends on wether or not someone implements that feature in
XFree86 or not.  You would have to ask the XFree86.org core team
wether or not they plan on implementing such a feature.  GTK
doesn't really enter into it per se.  Not until the X server has
the necessary support however.  This question is asked almost
daily by people on the XFree86 mailing lists, so you'll probably
be ignored if you ask there.  Solution: Read XFree86 mailing list
archives.  Search for the words "translucent" "translucency"  
"transparent" and "transparency"  (because the majority of human
beings don't know the difference between the words transparent
and translucent)


>2-will redhat support any competing window systems (or provide them as
>options)

To quote Donald Rumsfeld - "Sorry, but you're asking me to 
speculate on a hypothetical."  ;o)

The slightly more detailed answer is - if and when a _viable_
competing windowing system is created by the open source
community, which provides full software compatibility with what
we have now becomes available, it will be evaluated like any 
other software and technology as a potential candidate for future 
OS releases.  Without the existance of such a viable candidate 
however, it's not possible to provide a better response.


>3-does anyone know if keith packard and the suse crew are still working
>on xrender are there competing options out there

Keith hasn't worked at SuSE for about 2 years now.  ;o)

He works for Hewlett Packard, and he maintains Xrender, Xft,
fontconfig, Xcursor, Xrandr, kdrive (Keith's experimental X
server, often refered to as "TinyX" which is part of the XFree86
sources, but is officially maintained by Keith outside of
XFree86), and numerous other technologies.  Keith's work is
mostly hosted at freedesktop.org currently.  You may be 
interested in surfing through the freedesktop.org website, it 
contains a lot of stuff that might be interesting to you in this 
regard.

Keith just wrote 3 or 4 new experimental X extensions in the last 
week, which will lead to interesting technological advancements 
in X11 at some point in the future.  Before anyone asks "will 
this be in XFree86 4.4.0?" the answer is "no".  This work is in 
the very early stages of development and will probably be a long 
time until it is completely designed, implemented, and put into 
something highly useable by the masses of X11 using people out 
there.  Nonetheless, I wanted to mention it, so that you know 
Keith is busy as usual, making X11 not suck.  ;o)


>4-what's the general status of xfree and what's the policy for
>including upstream versions of x with fedora.

I'm not exactly sure what you're asking here, in order to be able 
to effectively answer the question, but I'll try.

XFree86 4.3.0 in Fedora Core, is highly stabilized compared to 
the official 4.3.0 release.  It includes a large number of bug 
fixes, some backported drivers, and various performance 
optimizations.  This will be released both in Fedora Core 1, and 
the majority of these enhancements released as erratum for Red 
Hat Linux 9 soon too.   Red Hat Linux 8.0 and earlier OS releases 
wont see anything but major security updates only for XFree86 
between now and their end of life.

Once Fedora Core 1 ships, I will be continuing to maintain 4.3.0 
updates via rawhide for a while, and those updates will continue 
to be recompileable and useable on Red Hat Linux 8.0, 9, Fedora 
Core 1, and Red Hat Enterprise Linux 3 more or less indefinitely.  
Once Fedora Core rawhide switches to XFree86 4.4.0 or whatever 
the next release becomes, 4.3.0 will be maintained still for
RHEL 3, plus RHL 9 updates into the future for a very long time, 
however over time that will shift to just security and critical 
fixes-only mode.

At some point not long from now, rawhide will switch from 4.3.0 
to XFree86 developmental CVS head snapshots, versioned as 
4.3.99.x as they're numbered upstream currently.  It will take a 
week or two for initial builds to be rawhide-ready, and they'll 
likely be extremely experimental and not intended for most people 
to use.

Once I've got the packaging stabilized for 4.3.99.x, I will be
dramatically ripping things apart in the bloodiest manner
possible, and splitting the fonts and documentation out of
XFree86's src.rpm to make them separately buildable noarch
packages to conserve disk space, built time, buildsystem usage,
to avoid people from having to redownload all the unchanged fonts
and docs every time an X update is available, and just for
general sanity.

The Xft, Xrender, and various other libraries and tidbits will be
split out of XFree86 src.rpm also, as a lot of them are actually
maintained upstream outside of XFree86, and just included in
XFree86 for convenience.  This will allow me to update these 
components more easily and provide erratum releases to people for 
those components more easily as well.

There are various other major packaging changes that will be 
occuring, and rawhide XFree86 and related stuff will likely be in 
a highly experimental state of break-your-system for a while, 
although of course I always try to limit breakage to be as 
minimal as possible, but you can't always guess all of the random 
things that could break when making changes, until someone 
reports them to you and you have the time to fix them and push 
new updates out to rawhide again.

Just rememeber - rawhide is highly experimental and guaranteed to 
break horrendously from time to time across all packages in the 
distribution.  


>what's the policy for including upstream versions of x with
>fedora.

Not sure what you mean, but if you mean upgrading XFree86 to a 
major new XFree86 release within a single Fedora Core release, it 
depends greatly on a number of factors.  I was able to release 
4.1.0 as an update for RHL 7.1 for example, which shipped with 
4.0.3, mainly because we had a lot of time to adequately test it, 
and there were no major changes that were potentially 
distribution risky in that release.  Kindof got lucky there.  
4.2.x however did not afford us the same luck.  4.3.0 in theory 
could be released as erratum for Red Hat Linux 8.0 I believe 
without causing a lot of headache, but I haven't gotten enough 
feedback in the wild to know for sure, and since 8.0 is near 
death now, it isn't worth the risk of possible regression, so 8.0 
will likely die with 4.2.1-something.

Fedora Core permits us a bit more freedom to update things, but
stability and reliability is still important, and I don't plan on
updating XFree86 releases for a current OS release just because a
new release is out.  I'll apply the same logic as I have in the 
past towards such updates - it's simple risk assessment.  The new 
release has to be released in a new OS release first, and then a 
month or two afterward, I can judge the stability and 
reliability, and other compatibility related issues based on the 
bug reports that are received in bugzilla, problems I see in 
mailing lists, personal email and IRC.

But in general, most OS releases will go end-of-line with the 
version of XFree86 they originally shipped with as a good hard 
rule.  Only time can tell for sure however, and RHL 7.1 shows 
that version updates are sometimes feasible too.

So, I'm not sure if I've answered your questions or not, but most 
likely this information is interesting or useful to you and 
others nonetheless.

Plus, I couldn't turn down the opportunity to show people that I 
can still write manuscript length email messages!  ;o)

Take care,
TTYL


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