Linus: What's Wrong With The Whole DRM Crowd?

[Smorg]

I know that the DRM devs always push the merge window policy and/or commit code within the merge windows that really isn't ready just for the sake of not waiting for the next kernel release

This is more indicative of a process problem than failure of devs to fit themselves to the process. DRM always seeing high activity with large changes isn't a bad thing by virtue of the development cycle that might best suit DRM not fitting with that of the rest of the kernel. Fortunately git workflows help accommodate such differences, but there's still the merge window problem. This is why there's a need for zen kernels and the like to do backporting which just creates extra work. From a desktop perspective it makes sense to want bleeding edge in areas like DRM where there's lots of work to be done, the breadth of what's been implemented matters, and newer generally is better.

[agd5f]

As Dave noted, part of the problem is the drm drivers are huge (possibly the largest drivers in the kernel), covering tons of devices, most of which the developers don't have access to. Think of how many oems make radeon cards. Couple that with the fact that few drm users test the kernel during the merge window or rc phases, so we tend to get a lot of bugs just after release or late in the release cycle generally for hw configurations we don't have.

[89c51]

come on guys

would you REALLY prefer everything to be nice and devs be nice and polite to eachother and stuff??


this kind of drama spices things up dont you think

[Melcar]

Reading Linus' emails brings a tear of joy to my eye .

[ArchLinux]

Reading Linus' emails brings a tear of joy to my eye .

Have a thrilling time then: http://en.wikiquote.org/wiki/Linus_Torvalds

[elanthis]

No kidding the DRM drivers are huge.

I have a lot of respect for the DRM/Mesa devs (even if sometimes my impatience indicates otherwise because a graphics driver is literally a combination of the three hardest kinds of programming there is: kernel dev, compiler dev, and simulation(game) dev.

The kernel guys think they've got it hard, and I know personally that both the compiler and games guys have it hard, but the graphics driver devs... they are the combination of all that is awesome in the computer-science world.

[brent]

And this is one good reason why a separation between kernel and drivers is needed.

[siride]

For those who think Linus is just being mean, he's got a good point about keeping the Git history clean. Rebasing public branches really is a big no-no, and it can easily be avoided. Not avoiding it results in seriously fucked up commits and a lot of trouble downstream. It doesn't seem like Linus is complaining about the code quality so much as the development process, and that seems pretty darn fair to me.

[avilella]

git jargon

I am a bit lost with all the git jargon that is used in this example email, and others. I wonder what is the easiest to understand tutorial out there for git that would allow me to understand why "rebasing" can be a good or bad practise.

[deanjo]

For those who think Linus is just being mean, he's got a good point about keeping the Git history clean. Rebasing public branches really is a big no-no, and it can easily be avoided. Not avoiding it results in seriously fucked up commits and a lot of trouble downstream. It doesn't seem like Linus is complaining about the code quality so much as the development process, and that seems pretty darn fair to me.

Agreed. I understand with Linus's beef and I fully agree with him. With the tools provided there is no need for the sloppy practices like this. They have all the proper tools they are just failing to utilize them properly thus defeating one of the main purposes of revision control. It looks like giving a mechanic a full set of tools only to see him bring out a hammer to set a set a screw.