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.
Originally Posted by DanL
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.
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
Reading Linus' emails brings a tear of joy to my eye .
Have a thrilling time then: http://en.wikiquote.org/wiki/Linus_Torvalds
Originally Posted by Melcar
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.
And this is one good reason why a separation between kernel and drivers is needed.
its really cool an intel guy fix amd radeon bugs in the kernel and the amd radeon driver use an intel shader compiler...
awesome thats teamwork.. next round intel should use galium3D to profit from amd's work
Linux/opensouce is great just because they work togetter.
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.
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.
Tags for this Thread