Announcement

Collapse
No announcement yet.

X.Org: "A Wasteland of Unreviewedness"

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

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

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    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.)

    Comment


    • #3
      i hope this doesnt happen to wayland.

      Comment


      • #4
        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?

        Comment


        • #5
          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? : )

          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?

          Originally posted by madjr View Post
          i hope this doesnt happen to wayland.
          This will happen to Wayland.
          Last edited by crazycheese; 17 May 2012, 11:10 AM.

          Comment


          • #6
            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.

            Comment


            • #7
              Originally posted by sandain View Post
              I beleive that Dave Airlie works for Redhat, not AMD.
              correct. . .

              Comment


              • #8
                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.

                Comment


                • #9
                  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
                  oVirt-HV1: Intel S2600C0, 2xE5-2658V2, 128GB, 8x2TB, 4x480GB SSD, GTX1080 (to-VM), Dell U3219Q, U2415, U2412M.
                  oVirt-HV2: Intel S2400GP2, 2xE5-2448L, 120GB, 8x2TB, 4x480GB SSD, GTX730 (to-VM).
                  oVirt-HV3: Gigabyte B85M-HD3, E3-1245V3, 32GB, 4x1TB, 2x480GB SSD, GTX980 (to-VM).
                  Devel-2: Asus H110M-K, i5-6500, 16GB, 3x1TB + 128GB-SSD, F33.

                  Comment


                  • #10
                    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.

                    Comment

                    Working...
                    X