It Looks Like X.Org 7.5 Will Be Released Late

[JeanPaul145]

With all due respect to the X.org developers:
I think we can call it a fact that X.org deadlines aren't being met. As far as I know these deadlines are set by a couple of X.org developers themselves, and not outside forces. Now if this were to be true then it would mean that the X.org project is, presently, unreliable with regards to new releases, and distro's should start taking that into account.

I get that X development is difficult, and that the X.org project is quite understaffed. However, then don't set unrealistic road maps, it only leads to frustration and troubles. One solution would be to have a previously defined number of releases per year (1 could suffice, given the current situation of under-staffing), look at which features are realistic to implement with the given resources, and stick to it. It would certainly improve goodwill of others dependent on X.org and lessen criticism.

What also might help is to write some great documentation on X.org programming, that even people without special gfx driver programming background can follow. It takes an investment initially (which is the main problem with this proposal), but I think that it could yield at least a couple of new X.org developers.

[airlied]

Isn't Xfree still alive somewhat ? I guess he was refering to the fact that X.org is a fork of Xfree ... So I guess what it's all about is that X.org was forked of Xfree just becuase Xfree wasn't working as it should and wasn't moving to the future... So the thing is people now are not happy with progress that Xorg has made so some suggest another fork or a new server ...

Feel free to correct me if I'm wrong, and please note it's not my opinion that Xorg needs a fork :P

Forks don't happen because "people" are unhappy. Forks happen because developers are unhappy. I'm sorry to say people that bitch in forums and even write the articles don't really matter to us. If you feel X.org owes you something, you probably owe it more.

The crap Michael says about distros needing X.org releases with new features isn't really true. They might like to have it, but unless they are contributing developers they don't *need* it, so without the developer contribution they don't get to set the schedule or bitch when the schedule slips. They just get to keep going with what they have today.

The only distro vendor actively contributing to the X server development process in terms of contributing new code and features that they want to see in their distro is Red Hat. Other distros provide contributions in terms of bug tracking and tracking driver issues but doing that doesn't give you anything other than a better X.org 7.4, it doesn't make an X.org 7.5

Non-distro contributions are the other major part with companies like Intel pushing the framework forward also where they need it themselves, and independent developers scratching itches all over the place.

Dave.
Dave.

[Kano]

I have got a small distro, i of course want that all my users are happy with the distro and therefore the X drivers have to work. I can not use my time to develop X drivers myself, maybe i find a hack to make one of my own cards to work with some bugs, but basically i can only report problems to upstream. What you refer to can only be done by really huge distribuitions.

[mirv]

I was just thinking that, even if x.org is a major component of any linux distro, it's free software. One of the caveats of that is that the developers will release it when they're ready, not when some company gives a deadline they'd like something by.
If people want it done by a certain time, they should help make it be done by that time. With that said, I hope more companies & people can help in the development of x.org (I'd like to, but simply don't have the free time).

[garytr24]

I think you're missing the part where our ratio of developers, to old crufty code from over a decade ago, is very low.

I think that's part of what I'm trying to say. For regular desktop use, something like quartz in OSX is really slick, and something like that could develop independently from X with a fresh codebase. I wish I knew enough about it to do it myself.

Wayland was written by an X developer. It doesn't replace the X server, it hosts X servers. Moreover, it's an experiment, not Moses on the mountain. Seriously. People thought the same thing about Xgl and glitz, back in the day. (Of course, "back in the day" is somewhere between three years ago, or last week, depending who you ask.)

I think he's also working on a clutter backend and gtk, so it doesn't only manage x servers, it could be a real live desktop. I used XGL :-).

Kristian Hogsberg discusses porting gui toolkits over to it here.

http://groups.google.com/group/wayland-display-server/browse_thread/thread/486a54fbb8aa133?pli=1

I don't think the failure of a project makes for a very good argument against starting projects. Take Windows and x86. People continue to do stuff inelegantly for years for the sake of backwards compatibility. It's nice that the ABI's don't change, but itanium really is a better way to do things. Also, the switch to 64-bit hasn't really happened smoothly or quickly on that platform compared to linux.

I think linux/unix is in a different position because people keep source code for things and have free compilers. Backwards-compatibility is more important for people that lose their source code.

So now, people are whining that stuff isn't moving fast enough, which means they prefer latest and greatest over compability with old stuff.

All this to say, compared to proprietary software stacks, the free software community has less to lose and more to gain by trying new things instead of only building on old ones.

[airlied]

I have got a small distro, i of course want that all my users are happy with the distro and therefore the X drivers have to work. I can not use my time to develop X drivers myself, maybe i find a hack to make one of my own cards to work with some bugs, but basically i can only report problems to upstream. What you refer to can only be done by really huge distribuitions.

You missed the point, you can keep shipping Xorg 7.4 with updated X server and updated drivers, and contribute back any bugs or fixes you think.

You don't however *need* Xorg 7.5, like these articles imply, you shouldn't be planning your distro releases around unreleased components etc.

Dave.

[Kano]

I dont ship Xorg 7.4, but Xserver 1.4 - but together with realtively current radeon(hd).

[val-gaav]

Forks don't happen because "people" are unhappy. Forks happen because developers are unhappy.

I'm fully aware of it... If that was not the case then for example KDE would have a fork after 4.0 release.

I'm sorry to say people that bitch in forums and even write the articles don't really matter to us. If you feel X.org owes you something, you probably owe it more.

Well that is true, yet it's really natural for users to bitch all about and call for forks (the same as it is for devs to not care ).. happens all the time in the FOSS community.

and if anything I am happy with the X.org and radeon driver progress, so no bitching from me ... I just tried to get the fork issue up Xfree vs Xorg, that's all...

[hdas]

Late to the party, but I don't exactly understand what's the ruckus about . Is it about versioning? If so, there is xorg-server-1.6 and it could be called xorg-7.5 to make people happy. (<troll> Hell, AMD 'updated' fglrx from 8.6 to 9.6 just to please customers using kernel 2.6.9. Btw, where's 9.7 with support for fc1 with 2.4.30-nptl? </troll>.)

Aside, regarding quality, I have been quite happy with the past few xorg releases (in fact all of them). (On my gentooo system, I had used xorg-server-1.3 for a long time, skipped 1.4 after hearing things and was too busy to upgrade, enjoyed 1.5 offlate and recently upgraded smoothly to 1.6.)

The only thing sane users should want and developers should aim is a bug-free xorg release. Let developers take their time before releasing (as long as the current release works good and is well maintained). Only thing, as mentioned before many times, please don't excite us with dummy release dates - you may keep that in your personal calendars .

[bridgman]

>>Hell, AMD 'updated' fglrx from 8.6 to 9.6 just to please customers using kernel 2.6.9.

Not just 2.6.9 -- the support was for the latest RHEL 4.x release

Regarding Xorg schedules, it seems to me that perhaps the solution is not to get so excited about the initial schedule estimates, and not to treat them as "deadlines", "commitments" or "promises" since they are none of the above.

AFAIK Xorg releases (just like most of the other open source projects) are scoped out at the start to make tradeoffs between content and schedule, and from that point on I believe execution is managed along the lines of "it'll be done when it's done, but we'll revisit the plan if things seem to be going *totally* off the rails".

If all the major distros synchronized their freeze dates (as has been suggested) then it might make sense to switch xorg to a time-driven release model rather than the current content-driven model, but AFAIK that kind of cross-distro coordination has not happened yet.