ops, i meant xfree 4.2.1 :-)

This is not a bug report, closing NOTABUG.

I've been asked by a few people about this already now, so I'll say
it here for the benefit of everyone all at once, and so future
bug reports that are identical to this one can be closed as dupes
and redirected here.

XFree86 4.2.1 exists only as a cosmetic release as far as is concerned
with Red Hat Linux.  XFree86 4.2.0 comes from the CVS tag xf-4_2_0 in
XFree86 CVS.  There is a branch off that called xf_4_2-branch.  All
bug fixes, patches, security fixes that have been released since
XFree86 4.2.0 came out, which have been applied to the 4.2.0 stable
branch, are in the xf-4_2-branch of CVS.

Red Hat XFree86, is built from 4.2.0 plus a patch which is immediately
applied on top of that which brings it up to date with xf-4_2-branch.
The current 4.2.0-72 package in rawhide adds to that a security patch
to fix a hole that was discovered in Xlib.  The same patch which got
applied to xf-4_2-branch.  XFree86.org decided since it was a security
patch, that they would make a new "point" release, however there was
no prior plan on making an official 4.2.1 release.  So the 4.2.1 release
exists only to "commemorate" the security patch if you follow.

The only part of 4.2.1 that is not in Red Hat XFree86 4.2.0-72, is the
parts that change the version number from 4.2.0 to 4.2.1.  As such,
4.2.1 is cosmetic only, and unnecessary.  There is absolutely no gain
or benefit to Red Hat Linux users of using 4.2.1 instead of 4.2.0-72.

Here it is graphically - XFree86 CVS layout:

xf-4_1_0 -------- xf-4_2_0 ----------- CVS-HEAD (current development)
    |                 |
    xf-4_1-branch     xf-4_2-branch ---- xf-4_2_1 ----- (xf-4_2-branch head)
                                       |
                                      RHL-XFree86-4.2.0-72

As you can see, Red Hat Linux XFree86 4.2.0 tracks the xf-4_2-branch
as always, and will continue doing so.  All Red Hat developmental
XFree86 releases will always be up to date with the current XFree86
stable branch at all times during development.  XFree86 will be updated
for previous Red Hat Linux distribution releases when:

1) A security problem is discovered, and patches exist to fix it, and
   the issue is important enough to warrant erratum.

2) A fair amount of new bugfixes have accumulated since the initial
   release, or last update, and if we have the manpower and time to
   ro an enhancement erratum, and the changes are large enough to
   make it worthwhile we may do so.

3) In order for any new XFree86 version to be released for an existing
   Red Hat Linux release as a major update (for example the
   4.0.3 -> 4.1.0 update in RHL 7.1), many criterion must be met, and
   established policies and procedures followed to ensure maximal
   quality and compatibility is retained.  Updated release versions
   generally do not and will not happen.  Once in a while, if time
   permits, and all conditions are met for updating, we may do an
   update, such as the 7.1 4.0.3->4.1.0 update, but it isn't just a
   decision done on a whim, that takes 2 hours to update, prepare,
   build, and throw in the buildsystem and copy to the ftp servers.

Updating XFree86 requires a very significant amount of engineering
resources, followed by months of debugging/troubleshooting, bug
fixing, package honing, etc.  Internal Red Hat testing, public beta
testing, Red Hat QA testing, etc.

As such, users _never_ _ever_ need to ask Red Hat to release a new
version of XFree86, or update it.  XFree86 will be updated as often
as it can be, and no sooner.  No amount of users asking for updates
or new versions will make the process any faster.  In fact, it
slows the process down as we then have to stop what we're doing
and respond to people to tell them why they'll have to wait.  Quite
often we need to then debate it with them.  That doesn't help us
to get work done.

So please everyone - do not bug me about XFree86 4.2.1, 4.3.0 or
any future releases of XFree86, and don't bug me or anyone else
at Red Hat about updated XFree86 releases for previous Red Hat
Linux distributions.  We may or may not update it, and we can't tell
you in advance if we will because we simply do not make those
decisions up front.  They occur on an as-time-permits basis only,
and time usually doesn't permit.

Sorry if I've written a book here, but I prefer to write it out once,
and point the other 400 people here to read what I wrote once, rather
than writing it out 400 times.  The time it takes to respond to 400
people, is time that could be spent working on fixing bugs, and
beginning to prepare for XFree86 4.3.0.  The longer I am kept away from
4.3.0 development, the longer users will have to wait for 4.3.0 in RPM
format.

Hope this clears things up.  Please be patient.