X Server 1.4.1 was originally scheduled to be released on the first of November as a bug-fix release for X Server 1.4.0, which was released in conjunction with X.Org 7.3. However, a delay had pushed the planned X Server 1.4.1 release to November 11. When that date had come X Server 1.4.1 was far from being ready. Then in December there were two open bugs blocking this release, but still no sign the release would be coming any time soon -- the Wiki page still reflected the early November launch. On December 15 was then an X Server 1.4.1 Pre-Release, which gave us hope the final release was near. However, much time had passed and X Server 1.4.1 still wasn't to be found.
Today -- just 212 days after the planned November launch date -- X Server 1.4.1 is finally released! Daniel Stone announced its release this morning on the xorg mailing list. X Server 1.4.1 has had 62 changes to it since the 1.4.1 pre-release, and that release had 46 changes, which brings the change total for this release up to 108. Even though X Server 1.4.1 has more than 100 changes, it wasn't enough to clear out the blocker bug, which still has two open bugs. The two open bugs surround the XKB map setting and a server memory leak with DBUS.
As described by Daniel, this release contains a few security and input fixes, some memory leak fixes, and a few other miscellaneous bits. For those paying attention to the CVEs, or Common Vulnerabilities and Exposures, eight of the known security issues are fixed in this release. If you're using DragonFly BSD, there is build support for that operating system within X Server 1.4.1.
In addition to X Server 1.4.1 running late, X.Org 7.4 / X Server 1.5.0 is continuing to run a few months behind schedule. X.Org 7.4 was originally slated to ship in February, but it didn't even have a release manager until February when Red Hat's Adam Jackson had stepped up to the plate. Adam had then rescheduled X.Org 7.4 for a May release, in order to make the cut for Fedora 9. As we are still talking about it, X.Org 7.4 obviously didn't make it out in May as intended, but an early X Server 1.5 pre-release was included. As we reported in late May, X.Org 7.4 is creeping closer with X Server 126.96.36.1992 having been released and there have been updates to many of the X.Org packages. However, this 188.8.131.522 was supposed to be out in March, not May.
Adam Jackson has made no official announcement, but it's looking like a July or early August release of X.Org 7.4 / X Server 1.4.0. For this critical element of the Linux desktop, this update will be out five or six months later than what was originally planned and almost a year after the release of X.Org 7.3. On top of that, X.Org 7.4 is shipping with a slimmer set of features than what was planned. X.Org 7.4 was supposed to have Multi-Pointer X (MPX), but that was delayed (though it will be ready for X.Org 7.5). Also sliced out of this release was input hotness, or XKB 2 and Xi 2. For more information on some of the X.Org 7.4 features, check out this article. After X.Org 7.4 is out, expect X.Org 7.5 / X Server 1.6.0 not until 2009.
In September of last year Sun's Alan Coopersmith had voiced his concerns over the degrading quality of X.Org releases. His concerns at the time were over the release criteria for X11 and how releases are going out without the blocker bug list being cleared, the complete tree/release modules not even being buildable on at least one platform, XTS (X Test Suite) not being able to successfully run on one platform, and documentation not being updated. Sadly, the state of X.Org hasn't improved since then but only worsened. Granted, a number of X.Org developers aren't even paid for their development contributions -- and these statements are by no means to attack their personal work -- but even with what has turned into a very long release cycle for X.Org 7.4, not all of the features will be completed. The X.Org 7.4 tracker bug has over 36 open bugs right now, and does anyone want to bet on how many of these will not be closed before the release? Even with more than 200 extra days when pushing out a maintenance release, X Server 1.4.1 still failed to meet the once-standard release criteria.
More must be done to improve the quality of these X.Org releases. At Phoronix we are even willing to offer -- cash and/or computer hardware -- bounties for having X.Org release schedules met and bug lists being cleared out. With Mark Shuttleworth calling for Free Software Synchronicity, hopefully Canonical and other vendors will too work on improving the state of X. More work is also needed for better standardization and less fragmentation, with bickering between TTM and GEM being a recent example. Instead of reworking the TTM memory manager to address its shortcomings and stabilize it, Keith Packard and his Intel-backed posse had instead drafted their own separate solution now known as the Graphics Execution Manager.
What do you think about X Server 1.4.1, X.Org 7.4, and the X.Org release quality in general? Are these delayed and much drawn out release cycles a barrier to the greater adoption of Linux? Tell us in the Phoronix Forums.