Linus: What's Wrong With The Whole DRM Crowd?
David Airlie sent in a DRM pull request to Linus Torvalds for the Linux 2.6.37 kernel this week to fix some Intel DRM driver bugs as well as one ATI Radeon KMS fix. However, this pull request sparked another rant by Linus Torvalds about the quality of the work of the open-source Linux (DRM) graphics driver developers.
Linus is known for an occasional colorful email and in the past has had a number of issues with code in the DRM sub-system, such as calling the initial Graphics Execution Manager (GEM) push by Intel as being untested crap. It was also via Linus that Nouveau unexpectedly got merged into the mainline kernel. With this 2.6.37 DRM bug-fix pull (mailing list thread), Linus has become once again frustrated. This time it's over the DRM code being messy, useless re-basing of Git trees, large amounts of DRM code always being changed later in the release cycles, and pulling "random crap" into tree.
This new code did end up being pulled into the Linux kernel and will be found in the 2.6.37-rc3 release, but below is the unhappy email from Linus.
Linus is known for an occasional colorful email and in the past has had a number of issues with code in the DRM sub-system, such as calling the initial Graphics Execution Manager (GEM) push by Intel as being untested crap. It was also via Linus that Nouveau unexpectedly got merged into the mainline kernel. With this 2.6.37 DRM bug-fix pull (mailing list thread), Linus has become once again frustrated. This time it's over the DRM code being messy, useless re-basing of Git trees, large amounts of DRM code always being changed later in the release cycles, and pulling "random crap" into tree.
This new code did end up being pulled into the Linux kernel and will be found in the 2.6.37-rc3 release, but below is the unhappy email from Linus.
F*%^ me, why does drm always have to be so messy?
You guys pull each others trees, and then rebase them. Yes, git is smart enough that it will merge it all fine, but dammit, now that multi-hundred-line Radeon commit exists twice in the tree. Do this:
git show --stat 16790569eddf fba4312e223f
git show --stat 21e2eae4daae a41c73e04673
and cry.
And yeah, it's ugly. And if that patch introduces a regression (which is entirely possible, it's not like it's small and trivial and obviously correct) it will just make bisection harder, and add confusion. And it's totally pointless. It only adds pain. And it makes the history harder to read.
Why did the Intel drm tree merge a patch that had _nothing_ what-so-ever to do with Intel DRM? WHY?
And why did the drm tree rebase a tree that had obviously been public and pulled from? WHY? Why did you make it public before it was ready? And/or why was it so ugly that it needed to rebase it? Why do these things keep happening?
What's wrong with the whole drm crowd? Even if it isn't rebasing, why is drivers/gpu/drm always so very visible in the later -rc trees?
I'm asking "why", but what I really want you guys to do is to ask _yourself_ why. And ask "Why is that? What am I doing wrong that this keeps happening?"
Really. Spend some time pondering. What the hell just happened, and why did it happen, and how can you guys stop doing it?
Chris: stop pulling in random crap in your tree. Do _your_ development, in your tree. Nothing else.
And Dave, I have no idea why those two commits were rebased. They seem identical in the tree that Chris had pulled. They have the same base commit. What was the point?
Linus
29 Comments