If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.
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.
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.
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.
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.