On Sat, 04 Jun 2011 23:05:23 -0700 "Keith Packard" keithp@keithp.com wrote:
drm-intel-next
This contains work destined for the 'next' release, it may include new functionality and performance enhancements. It may also cause regressions on some hardware. The tip of this tree will be sent to Dave Airlie for inclusion in the kernel during the next merge window. I've already sent all of what is on this branch to him for 3.0
This tree should be tested during the development process to try and catch bugs and regressions before they are merged. The most critical time for testing this is just *before* the release of the current RC kernel version as that is when it should have most of the code planned for the *next* release.
drm-intel-fixes
This contains bug fixes after the merge window has closed. I will fast-forwarded to each RC when possible so that we test the fully integrated kernel for regressions.
This tree should be tested during the stabilization process after RC1 comes out as patches are applied.
Can you keep drm-intel-next fairly up to date with respect to the fixes branch? I.e. keep it a superset of drm-intel-fixes for the most part?
In PCI-land, this means re-basing my -next tree periodically before the merge window opens (though not right before the merge window unless something unexpected happens, like a patch needing to be dropped; in that case I'll delay the merge window push a bit to allow for more testing).
Downstream PCI developers requested this since it makes feature development much easier (you get all the bug fixes destined for Linus while working on a new feature for the next window), and as a downstream gfx developer I'd like to see this on the Intel side as well, unless other developers have big objections...
Thanks,