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.
Last edited by bridgman; 07-16-2009 at 10:01 PM.
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.
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 ?
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
You're bluffing, right? 1, 2, 3, 4, 5, 6, 7, 8, 9, 10.. Ten Companies, and more....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..
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
Last edited by t.s.; 07-17-2009 at 05:57 AM.
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.