On Sat, 04 Jun 2011 23:05:23 -0700 "Keith Packard" <keithp@xxxxxxxxxx> wrote: > 1) 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. > > 2) 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, -- Jesse Barnes, Intel Open Source Technology Center _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
