The Degrading Quality Of X.Org Releases?

[phoronix]

Phoronix: The Degrading Quality Of X.Org Releases?

On the X.Org mailing list, Alan Coopersmith had raised concerns over the release criteria for X11 and how with recent releases (namely X.Org 7.3), the de facto standard for making a release was far from being met. Alan, Sun's X engineer, had listed the release criteria as the blocker bug list being cleared, the complete tree/release modules being build-able on at least one platform, XTS successfully running on at least one platform, and the documentation being updated and then released.

http://www.phoronix.com/scan.php?pag...item&px=NjA3Mg

[R3MF]

it is a crying shame this wasn't sorted, because it must be THE reason why SUSE is apparently going to ship with 7.2.

which is a shame.

[yoshi314]

i got to admit, that was one rushed release.

keyboard leds do not work by default (although there's a workaround), also gentoo and debian had to fix their packages due to dbus/hal related lockups.

[Prototyped]

Originally Posted by yoshi314

i got to admit, that was one rushed release.

keyboard leds do not work by default (although there's a workaround), also gentoo and debian had to fix their packages due to dbus/hal related lockups.

What's the workaround? I've been scouring the web for any such information, with no luck.

[yoshi314]

when you run kbstate app in kde (and have it sit in the tray) leds start working again. probably, as i didn't try myself.

[Prototyped]

Originally Posted by yoshi314

when you run kbstate app in kde (and have it sit in the tray) leds start working again. probably, as i didn't try myself.

Oh, I see. It does provide me with the status of Num Lock and Caps Lock on the panel. I guess that'll do in the interim. (Before this I was using xkbleds, but this is superior.)

[Korla Plankton]

This might be a little OT, and on my first post, too... but...

"We must have timed releases but at the same time we need to expect at least the same level of quality."

Suggestions on how to achieve this?

Apple and MS do it by attracting developers with things like money and health benefits.

I think that, without money to keep a significant number of developers working on 9 to 5 schedules, and without a clear hierarchy of bosses to drive their subordinates to meet a schedule (with the ever-present threat of losing your livelihood if you consistently don't,) we pretty much have to adopt the "release it when it's ready" attitude. Or else we will see this degradation in quality.

Agree? Disagree?

[Ex-Cyber]

Originally Posted by Korla Plankton

I think that, without money to keep a significant number of developers working on 9 to 5 schedules, and without a clear hierarchy of bosses to drive their subordinates to meet a schedule (with the ever-present threat of losing your livelihood if you consistently don't,) we pretty much have to adopt the "release it when it's ready" attitude.

I don't think that's at the root of the problem here, and the proposed solution ignores the reality of the situation. A bunch of the main X.Org developers are already working for major companies, and having "a clear hierarchy of bosses" is pretty much impossible when dealing with an open development process working on the preeminent implementation of an established open standard; there are multiple major interests involved that don't fit neatly into a hierarchy.

[nhaehnle]

Originally Posted by Korla Plankton

This might be a little OT, and on my first post, too... but...

"We must have timed releases but at the same time we need to expect at least the same level of quality."

Suggestions on how to achieve this?

By watchfully preventing regressions from creeping into the master branches.

On the Mesa side, this is precisely why I've started piglit, and keep mentioning it. Automatic regression testing is *very* useful (and is being adopted by more and more developers).

By the way: The link in the article seems not to point where intended...