Re: drivers/drm/i915 maintenance process
From: Jesse Barnes
Date: Mon Jun 06 2011 - 16:36:45 EST
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
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...
Jesse Barnes, Intel Open Source Technology Center
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/