David Airlie of Red Hat, the DRM subsystem maintainer, generally has been allowing new Direct Rendering Manager (DRM) code to be introduced to his drm-next tree up to around the time a given kernel release occurs. After that, within days, it could end up landing in the mainline Linux kernel when the merge window opens ahead of the next -rc1 release. David though is deciding to be a more strict about changes late in the cycle in hopes of leading to better tested code and less fallout from driver problems each kernel development cycle.
Just recently for Linux 3.17 there were two Intel GPU driver features that got reverted due to concerns by Linus Torvalds and it's not too uncommon for him to run into DRM problems. Linus has openly asked in the past what's wrong with the DRM crowd, DRM has been problematic with unbaked code, and expressed other frustrations.
Airlie announced on Monday, "I've been been getting too lax on when I merge stuff to drm-next and I think people are taking advantage of my good nature. So we are going to try something new this cycle, I'm going to use -rc5 of the current kernel as the cut off for major feature merges to the -next. That means that subsystem maintainers should have their -next trees to me by -rc5, with allowances with advance warnings up to -rc6, i.e. maintainer on holidays etc."
With Linux 3.17-rc2 having just been released, that means there's just about three weeks left until David will cut off the new material he's willing to have land within the DRM subsystem update for Linux 3.18.
Among the graphics changes to ideally look forward to so far for Linux 3.18 include AMD R600 UVD support, hopeful Nouveau re-clocking improvements, Radeon Userptr support, and various Intel graphics updates.