It Looks Like X.Org 7.5 Will Be Released Late

[bridgman]

There's one fundamental difference between X and the kernel that I haven't heard mentioned here. Linux for servers is a thriving and profitable business; Linux for clients (desktop, laptop, PDA, phone etc..) is promising and might make money outside of a few narrow niches one day.

Server ($$$) and Client (?$) both need the kernel; only client needs X, so much more $$ flows into kernel than into X.

Given the resources that are being made available for X vs the complexity of the features being demanded (functional parity with Windows but on perhaps 1/50th the investment) the development work is going surprisingly well. There is not a big demand for schedule predictability from the groups and individuals contributing resources, but there is a big demand for progress, and that results in the project management model (take aim, write down the plan, then everyone develops like crazy until it's done) you see today.

The spirit among the developers is very enthusiastic and positive; everyone seems to be trivializing Dave's comments. His point is not that priorities and approaches are being set based on the whims of the developers; his point is that many of the developers are working for successful companies with clear priorities, and those priorities are where the developers spend *most* of their time.

[deanjo]

(take aim, write down the plan, then everyone develops like crazy until it's done)

You forgot the final step........ BEER!!!!!

[bridgman]

You forgot the final step........ BEER!!!!!

Good point... actually from the few conferences I have attended it seems the sequence is "take aim, BEER, write it down, implement like crazy..."

I think I see the problem.

[airlied]

There's one fundamental difference between X and the kernel that I haven't heard mentioned here. Linux for servers is a thriving and profitable business; Linux for clients (desktop, laptop, PDA, phone etc..) is promising and might make money outside of a few narrow niches one day.

Server ($$$) and Client (?$) both need the kernel; only client needs X, so much more $$ flows into kernel than into X.

Given the resources that are being made available for X vs the complexity of the features being demanded (functional parity with Windows but on perhaps 1/50th the investment) the development work is going surprisingly well. There is not a big demand for schedule predictability from the groups and individuals contributing resources, but there is a big demand for progress, and that results in the project management model (take aim, write down the plan, then everyone develops like crazy until it's done) you see today.

The spirit among the developers is very enthusiastic and positive; everyone seems to be trivializing Dave's comments. His point is not that priorities and approaches are being set based on the whims of the developers; his point is that many of the developers are working for successful companies with clear priorities, and those priorities are where the developers spend *most* of there time.

What he said :-)

Red Hat must be still making money (even in this dark time, profits are good) and they keep paying me, so I must be doing something right ;-)

Our customer requirements for the Linux desktop were once described as "pretty and fast". This funded kernel modesetting, customers actually hated the bootup blinking that much.

Dave.

[bridgman]

Don't you hate it when you make a spelling error (there/their, second last word in airlied's quote) and then someone quotes you before you can fix it ?

[Yfrwlf]

Back on the original topic, the only complaint here is that everyone shouldn't look at Xorg release schedules as promises, as stated already, but perhaps that push partially stems from wanting to ask for development help in a round-about way. Regardless, X is important to Linux reaching desktops/etc, so may efforts to de-cruftify, rebuild, or feature-fortify graphical systems for Linux continue to be successful. ^^

I'll continue supporting through bug reporting until I learn more. :P

[t.s.]

..Those companies (off the top of my head: AMD, Apple, Canonical, Nokia, nVidia, Red Hat, Sun, SUSE, Via, VMWare) already provide manpower. People like myself, and many other developers, do contribute code..

You're bluffing, right? 1, 2, 3, 4, 5, 6, 7, 8, 9, 10.. Ten Companies, and more..
hm.. IF ONLY each companies providing 3 manpower, then X.org have about 30 devs, + other developers.

Btw, how much the minimum number of devs do X.org have so that X.org can have a constant and not-late release?

CMIIW. Sometimes, it's just not logic for me, why companies that stated above (if its true) have THAT LITTLE CONCERN to X.org?
Some of them said that they want to make linux a desktop-operating-system, rite? rite? And I guess, to have a better desktop on linux, we must have better X (and kernel?), rite? right? RIGHT? (IMO then, why can't they drop more devs on X.org to make that happen faster?)

PS: like somebody said before, it can be hurt to start making documentation bout X.org We all know that it will be much help for X.org it self in the future.

-- end of bitching here --

Oh, and don't forget, we do appreciate your (all of you, devs) work

[entropy]

For whom may be interested:

This morning I just stumbled across a talk by Theo de Raadt about
OpenBSD's release management/process. At 6:55 he comments on X11.

The OpenBSD Release Process

[nanonyme]

At 6:55 he comments on X11.[/URL]

Comments and talks for several minutes of how he disapproves with the modular X system and how it is maintained.

[daniels]

Frankly, Dave is right.

Bitching about why something is late or behind schedule without any offer to help or provide solutions does nothing but aggravate the developers.

Look at it from Dave's point of view - he spends his life toiling away working on X code which most would consider hardly glamorous or exciting.

He is already over worked and under appreciated, and now a bunch of users start bitching because the schedule has slipped without offering up any real help or solutions?

Please - ignoring the flames that occur when a schedule slips is the only way to remain sane.

This is pretty much it, yeah. Even if you cast aside the ideological 'they're too developer-focussed, they need to concentrate on the users' issue -- and you'd be insane to think that developers don't write software for users, aside from Theo de Raadt -- try pragmatism.

If all the developers eventually get discouraged and leave, the software won't get written, by definition. So if you want the software to advance, these threads probably aren't the way to go. When I finish my day job (X development, but not 1.7 or XKB2), it's a choice between going out and seeing my friends or a night in spent hacking X. Looking at the timestamps on IRC and commits from everyone might be fairly instructive as well. Plus, you never know, someone might be confined to bed all day with inflamed discs in his back, taking fewer painkillers in order to still be able to write code.

xserver 1.7 is in code freeze, as per the schedule (which was never announced as anything but a plan, as made plain in the emails and the subject), and the remaining work is Peter's Xi stabilisation, the final bits which need to be done in master and general bugfixing as well. The tree isn't exactly hugely unstable with massive amounts of disruptive work landing every day, so there's been no need to branch as far as I'm concerned. XKB2 (which is badly behind schedule) is the last big thing to get merged, and then I imagine it will get branched fairly soon after.

Code freeze in three days is plainly unrealistic, and the rest of the schedule pretty much hinges on when we get to that point, so it just depends on when it's stable enough to branch and declare full code freeze.

Anyway, back to it.