Results 1 to 10 of 10

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

  1. #1
    Join Date
    Jan 2007
    Posts
    15,416

    Default X.Org: "A Wasteland of Unreviewedness"

    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

  2. #2
    Join Date
    Sep 2010
    Posts
    486

    Default

    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.)

  3. #3
    Join Date
    Nov 2010
    Posts
    429

    Default

    i hope this doesnt happen to wayland.

  4. #4
    Join Date
    May 2010
    Posts
    135

    Default

    Quote Originally Posted by madjr View Post
    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?

  5. #5
    Join Date
    Apr 2010
    Posts
    1,946

    Default

    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? : )

    Quote Originally Posted by siride View Post
    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?

    Quote Originally Posted by madjr View Post
    i hope this doesnt happen to wayland.
    This will happen to Wayland.
    Last edited by crazycheese; 05-17-2012 at 12:10 PM.

  6. #6
    Join Date
    Oct 2007
    Posts
    91

    Default

    Quote Originally Posted by crazycheese View Post
    W00t w00t, nvidia programmer reviewing patches from amd programmer? : )
    I beleive that Dave Airlie works for Redhat, not AMD.

  7. #7
    Join Date
    Jul 2009
    Posts
    286

    Default

    Quote Originally Posted by sandain View Post
    I beleive that Dave Airlie works for Redhat, not AMD.
    correct. . .

  8. #8
    Join Date
    Jul 2009
    Posts
    351

    Default

    Quote Originally Posted by plonoma View Post
    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.

  9. #9
    Join Date
    Oct 2006
    Location
    Israel
    Posts
    626

    Default

    Quote Originally Posted by frantaylor View Post
    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
    DEV: Intel S2600C0, 2xE52658V2, 32GB, 4x2TB, GTX780, F20/x86_64, Dell U2711.
    SRV: Intel S5520SC, 2xX5680, 36GB, 4x2TB, GTX550, F20/x86_64, Dell U2412..
    BACK: Tyan Tempest i5400XT, 2xE5335, 8GB, 3x1.5TB, 9800GTX, F20/x86-64.
    LAP: ASUS N56VJ, i7-3630QM, 16GB, 1TB, 635M, F20/x86_64.

  10. #10
    Join Date
    Aug 2009
    Location
    south east
    Posts
    342

    Default Easy Build Script

    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •