X.Org: "A Wasteland of Unreviewedness"

[phoronix]

Phoronix: X.Org: "A Wasteland of Unreviewedness"

After David Airlie brought up the new DDX driver API for the X.Org Server, a new discussion was born concerning the lack of patch review taking place for the X.Org Server...

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

[plonoma]

It's natural for a big change like an API to need time to stabilize and be reviewed.
And it's important not to relax the review requirements with API's.
Make sure to get as much people to take a look at it as possible.
Very important to not rush these things. Certainly if you're aiming for a stable api.

(p.s. make sure versions are implemented in a way that you can like break the whole api constantly and
still make new things talk with old things without problems.)

[madjr]

i hope this doesnt happen to wayland.

[siride]

i hope this doesnt happen to wayland.

Maybe it's because of Wayland that this is happening. Why work on boring X server when you can work on fun, up-and-coming and exciting Wayland?

[crazycheese]

But, on the plus side, the rants got Aaron Plattner of NVIDIA to review the first four patches of David Airlie's for the driver API changes, per this message.

W00t w00t, nvidia programmer reviewing patches from amd programmer? : )

Maybe it's because of Wayland that this is happening. Why work on boring X server when you can work on fun, up-and-coming and exciting Wayland?

I don't see how exactly xorg is boring and wayland is fun. Those have different goals and different capabilities. When Wayland codebase grows, will you recommend starting "Yayland" from scratch, ie running from problem, instead of charging into the problem head on like they do now?

i hope this doesnt happen to wayland.

This will happen to Wayland.

[sandain]

W00t w00t, nvidia programmer reviewing patches from amd programmer? : )

I beleive that Dave Airlie works for Redhat, not AMD.

[daniels]

I beleive that Dave Airlie works for Redhat, not AMD.

correct. . .

[frantaylor]

It's natural for a big change like an API to need time to stabilize and be reviewed.
And it's important not to relax the review requirements with API's.
Make sure to get as much people to take a look at it as possible.
Very important to not rush these things. Certainly if you're aiming for a stable api.

(p.s. make sure versions are implemented in a way that you can like break the whole api constantly and
still make new things talk with old things without problems.)

This is the difference between linux and other operating systems.

When the primary developers have large resources at their disposal, they can make even bigger changes than this, and just fold them right into the product release cycle.

The linux developers rely on the community for testing so they send out unstable builds for everyone to debug.

At a big development house, when an incompatible change is pushed to the release branch, the testing department descends on the build like an unholy swarm. Hundreds of thousands of unit tests are run overnight by large teams of testers and entire buildings filled with servers. Every single customer regression that has ever been reported has been encoded as an automatic test. Companies that "eat their own dog food" will transition their own internal systems over to the new build before ship. They put the daily operation of their company on the line when they do this so it requires great confidence and a solid arrogant intolerance for problems.

If you've never experienced this kind of software development, you need to see it in action. It's really something to see a massive change folded into a product and a week later seeing all the unit tests passing. All the customers know is that the product just keeps getting better and better and faster and faster.

[gilboa]

At a big development house, when an incompatible change is pushed to the release branch, the testing department descends on the build like an unholy swarm. Hundreds of thousands of unit tests are run overnight by large teams of testers and entire buildings filled with servers. Every single customer regression that has ever been reported has been encoded as an automatic test. Companies that "eat their own dog food" will transition their own internal systems over to the new build before ship. They put the daily operation of their company on the line when they do this so it requires great confidence and a solid arrogant intolerance for problems.

Funny.

- Gilboa

[squirrl]

Maybe if you'd put out an easy-build-script more people would test your code.

Ant and that other thing isn't cutting it.

I need a top-level configure package with the ability to install side-by-side with a pre-existing installation of Xorg.

Before you rebut, think about making the test easier when you don't assume the testers have the same level of expertise you do.

In other words, sure I've built Xorg a few times throughout the years but now it's been three since I last ventured down that build path.