X.Org 7.4 Creeps Closer To Release

[phoronix]

Phoronix: X.Org 7.4 Creeps Closer To Release

Earlier this month we had shared the progress of X.Org 7.4 with the features slated to be included in this next X release, what features have been postponed, and the repeated delays that always seem to plague the X.Org development community. Since then there still has yet to be any official update on its status, but the Wiki continues to claim a May 2008 release. Fortunately, yesterday Adam Jackson stepped up again and released a number of X package updates, which places us a bit closer to reaching this much-delayed release.

http://www.phoronix.com/vr.php?view=12368

[NeoBrain]

Makes me kinda sad that there are so few Xorg developers that the release will get a one year delay :(

[deanjo]

Makes me kinda sad that there are so few Xorg developers that the release will get a one year delay :(


I'm actually kind of glad they don't release new major versions every other month. IMHO more projects have to slow down when releasing new versions. Fix the existing bugs before slapping in more features to further complicate the process.

/evileye glare @ wine.

[yoshi314]

i think xorg is doing ok. such major piece of software doesn't need often release dates. they may be scarce bu they better be good.

same goes for glibc.

[_txf_]

It is all well and good to have slow or few releases in a year, but I still think that it is a bad situation when features are cut and the realease is still delayed. Frankly it should be one or the other

[bridgman]

Given that xorg is almost entirely a volunteer effort, I see it differently; I'm consistently impressed with what we *do* get.

[LydianKnight]

It's indeed a volunteer effort, but the time line pressure makes for a worse release experience in my opinion, there's tons of projects that just bears the traditional phrase 'when it's done' and, in this case, I think it would be better for Xorg.

Once I pinged the xorg mailing list for a report on the status for 1.4.1 release, and it was nice because it ended generating a bit of traffic, but that's not enough... polling is not a bad method for requesting some real progress, but definitely not a solution. The real solution? just let them release the drivers and make the releases as soon as they're ready.

But don't take me wrong... it would be great if they could fit the release planning criteria, but they actually fail because some drivers are broken, discussions on whether the Xorg tree should be merged (ala Kernel or XFree86 to be more graphics-wise) or not, and a variety of reasons that slow down the actual progress... a good work for their part? absolutely. a good work on their planning? absolutely not.

(but that's just my opinion on the subject)

Julio

[Vadi]

This comment is interesting also:

http://www.markshuttleworth.com/archives/146#comment-300627

I hope something good comes out of that.

[yoshi314]

Given that xorg is almost entirely a volunteer effort, I see it differently; I'm consistently impressed with what we *do* get.

speaking of which, i would be nice if amd would hire a few programmers to have them work on x.org exclusively.

right now amd has recruited few x.org people but they are mostly occupied with x.org development side-quests ;-) [like helping with documentation releases, which is not a bad thing]

there are few x.org developers already working in that manner getting paid by various companies, but the more the better.

[Regenwald]

well, there's definitely a need for more x-coders. it is one of the most important piece of software in linux. i hope that companies like nokia get more devolopers to work on it...

[yoshi314]

nokia, being a mostly portable device oriented, has probably little interest in mainline X, but maybe some more embedded oriented branches of it would be in its field of interest.

[Regenwald]

at least, they are *paying* some devs to work on X (see presentations from xdc..). They need a small, fast x-server for their embedded devices. and mpx is necessary for multi-touch in mobile devices.
do you see what i mean?

[Vadi]

How many of the people here suggesting that companies hire programmers to work on X have donated ($) to X themselves?

[timofonic]

What I see is a lack of resources in X.org, specially in certain topics.

X.org is quite complex and certain stuff is difficult to priorize, as various components could be equally important because working in the same topic instead being separate ones. I found pathetic that companies that benefit from X.org not support developers in a more than enough way, as X.org is one of the most important projects for UNIX and not just for the Open Source ones.

Important stuff that needs to have more development resources is the GEM/TTM stuff for memory management. The problem here is that there are some kind of debate about what one is better (see here (http://aseigo.blogspot.com/2008/05/i915-and-gem.html) for a small example) and that is making the adoption a lot longer than expected, so I think there must be some kind of official and technical debate between the responsible parts and end with some kind of consensus instead a fight that benefits nobody.

For me the X.org team is maybe being more worried in not so important stuff and forgetting more important ones, but that could not happen if they had some more resources to use.

There are another big problem and it's that subprojects like radeon and nouveau working with too few resources and even doing amazing things, but it's clear that they need *A LOT* more support than they have now too.

[Regenwald]

true. as far as i know, kernel devs help developping ttm. but i don't unterstand why intel have to "fork" (kind of) it with their gem. it doesn't have a performance improvement (yet?), it just costs time & energy. i thought that ttm is a good thing, more and more drivers could use it as a "base"/part, everything seems to be good^^...

[timofonic]

Even if one is worser or better, there finally can be one (like the inmortals, hehe). They better do some technical and formal discussion instead making a hostile alternative that will benefit nobody and will make the adoption of the concept used by both a lot longer than expected.

This is hardware and kernel stuff, not just an application where a fork or alternative isn't a problem at all. The work they use for making two separate versions of something with similar concept could be made with the double of available resources and even better if all parts finally end with some kind of common design that suits everybody (like in democracy).