Announcement

Collapse
No announcement yet.

DRM Maintainers Are Running Out Of Time To Ship New Features For Linux 4.12

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

  • #11
    Originally posted by L_A_G View Post
    ... David obviously knows that he lost Linus' trust with that debacle, but I'd say it's pretty clear that he's now being a bit overzealous in his attempt to regain Linus' trust. If this leads to enough complaints I suppose this could lead to Linus putting the word out that he's looking for someone to replace David.

    You obviously need to have a freeze on the submission of new code at some point, but doing that before Linus pushes the previous version out the door is a bit too early if you ask me.
    This is overstating things quite a bit IMO.

    The cut-off point for new code (new functionality, not bug fixes) in the drm subsystem has been rc5 of the previous release for the last couple of years or more, and Dave is enforcing rc6 this time. That gives people a week past the official drop-dead date, not what I would call over-zealous.

    The idea of the rc5 cutoff was to allow a couple of weeks for Dave to integrate changes from all the different driver maintainers (there are quite a few these days) and for everyone else to test the merged code before the merge window opened and all that code went up to Linus in a slug.
    Last edited by bridgman; 04-04-2017, 11:44 AM.

    Comment


    • #12
      Meanwhile, binary blob drivers can add new features whenever the heck they please.
      This can also be done for OSS drivers. The simple and single question is will it get delivered near term or in 2 month time.

      Comment


      • #13
        Originally posted by bridgman View Post

        This is overstating things quite a bit IMO.

        The cut-off point for new code (new functionality, not bug fixes) in the drm subsystem has been rc5 of the previous release for the last couple of years or more, and Dave is enforcing rc6 this time. That gives people a week past the official drop-dead date, not what I would call over-zealous.

        The idea of the rc5 cutoff was to allow a couple of weeks for Dave to integrate changes from all the different driver maintainers (there are quite a few these days) and for everyone else to test the merged code before the merge window opened and all that code went up to Linus in a slug.
        If this is just a pre-existing practice he's now being more rigorous about enforcing then why did he push the tinyDRM that caused Linus to go on his last rant? I mean it had only been pushed to him the day before so it should most definitely have run afoul of this practice. Even he himself didn't seem to care about this practive when he didn't even compile test it before passing it on as if it was actually ready for prime time.

        Say what you want, but if he had this practice in place before the fiasco I'd say it looks worse for him than if he implemented it afterwards as a measure to ensure it wouldn't happen again.
        "Why should I want to make anything up? Life's bad enough as it is without wanting to invent any more of it."

        Comment


        • #14
          Originally posted by L_A_G View Post

          If this is just a pre-existing practice he's now being more rigorous about enforcing then why did he push the tinyDRM that caused Linus to go on his last rant? I mean it had only been pushed to him the day before so it should most definitely have run afoul of this practice. Even he himself didn't seem to care about this practive when he didn't even compile test it before passing it on as if it was actually ready for prime time.

          Say what you want, but if he had this practice in place before the fiasco I'd say it looks worse for him than if he implemented it afterwards as a measure to ensure it wouldn't happen again.
          Seems to me like he just made a personal judgement call on pros vs cons as someone who understands the DRM subsystem well. Linus just didn't approve. Following processes rigorously avoids the reaction from before but it will be really painful for developers since it means maintaining API-compatibility out of tree for yet another cycle

          Comment


          • #15
            Originally posted by nanonyme View Post
            Seems to me like he just made a personal judgement call on pros vs cons as someone who understands the DRM subsystem well. Linus just didn't approve. Following processes rigorously avoids the reaction from before but it will be really painful for developers since it means maintaining API-compatibility out of tree for yet another cycle
            Pushing code up the chain that was only committed the day before without as much as compile testing it gives me at least the impression that David's personal judgement may be slightly out of whack. For his sake I hope this showed him that the same code quality standards should apply to everyone and nobody should be exempt from deadlines for merge windows. I seriously doubt delaying the mainlining of tinyDRM by a couple of months would have harmed the developers of it as they already had to maintain out-of-tree compatibility.

            For those thinking I'm being too harsh on David I'm going to have to disagree. The higher up the totem pole you are, the more you should be under a magnifying glass. When you mess up you either shape up in an attempt to ensure you don't make the same mistake again or then you step down in favor of someone else. My view on career advancement is basically a modification on the Peter Principe: "You should eventually be promoted to the point where you're can no longer perform effectively and then be demoted to your previous job".
            "Why should I want to make anything up? Life's bad enough as it is without wanting to invent any more of it."

            Comment


            • #16
              Originally posted by Hibbelharry View Post
              This can also be done for OSS drivers. The simple and single question is will it get delivered near term or in 2 month time.
              With OSS drivers you need to upgrade the whole kernel to get new features. With binary blobs, you just download the new driver and install it.

              Comment


              • #17
                Originally posted by L_A_G View Post

                Pushing code up the chain that was only committed the day before without as much as compile testing it gives me at least the impression that David's personal judgement may be slightly out of whack. For his sake I hope this showed him that the same code quality standards should apply to everyone and nobody should be exempt from deadlines for merge windows. I seriously doubt delaying the mainlining of tinyDRM by a couple of months would have harmed the developers of it as they already had to maintain out-of-tree compatibility.

                For those thinking I'm being too harsh on David I'm going to have to disagree. The higher up the totem pole you are, the more you should be under a magnifying glass. When you mess up you either shape up in an attempt to ensure you don't make the same mistake again or then you step down in favor of someone else. My view on career advancement is basically a modification on the Peter Principe: "You should eventually be promoted to the point where you're can no longer perform effectively and then be demoted to your previous job".
                I do disagree with that. There is such a thing as intuition you know?

                Comment


                • #18
                  Originally posted by RealNC View Post
                  With OSS drivers you need to upgrade the whole kernel to get new features. With binary blobs, you just download the new driver and install it.
                  It is true that nVidia tends to be very prompt, it is also true that you are at nVidia and AMD's whim for that. I'd rather rely on the linux kernels schedule than some corporate schedule.

                  Comment


                  • #19
                    Originally posted by RealNC View Post
                    With OSS drivers you need to upgrade the whole kernel to get new features. With binary blobs, you just download the new driver and install it.
                    There is also a middle ground, eg the kernel driver packages from our hybrid driver, which also support open source userspace. They can be downloaded and installed on any supported kernel, and only replace a few kernel modules.

                    Downside of that approach (as with binary drivers) is that the kernel driver code has to be explicitly backported to each of the supported kernels, using something like our Kernel Compatibility Layer to encapsulate the changes required to run on older kernels. You end up constantly chasing kernel updates and it's easy to get behind.
                    Last edited by bridgman; 04-05-2017, 03:30 PM.

                    Comment


                    • #20
                      Originally posted by duby229 View Post
                      I do disagree with that. There is such a thing as intuition you know?
                      Say what you want, but I'd say this is a rather good example why you shouldn't make decisions like this based on intuition.

                      Not that intuition doesn't have it's place. It's useful in situations like ordering at a restaurant you've previously never been to or when picking a holiday destination, but it's the last thing you should be counting on when making important choices at work.
                      "Why should I want to make anything up? Life's bad enough as it is without wanting to invent any more of it."

                      Comment

                      Working...
                      X