Re: [Intel-gfx] [PULL] drm-intel-next

[Jesse Barnes <jbarnes@virtuousgeek.org>]

[-- Attachment #1: Type: text/plain, Size: 1806 bytes --]

On Thu, 5 Jan 2012 16:24:08 +0100
Daniel Vetter <daniel@ffwll.ch> wrote:
> I'd also like to express my frustration with the general -next process for
> drm/i915:
> - This drm-intel-next tree is less than 24h ours old (if you look at when
>   it showed up at an official place where both our QA and the community
>   can pick it up and test it). I fear we'll ship yet another disaster like
>   the stack eating bug the vt-d/ilk w/a patch caused with an unbounded
>   recursion. Our QA actually caught it in testing, but there was simply
>   not enough time to fix things up before the buggy code landed in -linus.
> - Because the drm-intel-next merge cycle started so late there has simply
>   not been enough time to include quite a few bugfixes for serious issues
>   like 20s delays in intial modeset, userspace-triggerable kernel OOPSes
>   and deadlocks and reproducible hard hw hangs. For most of these there
>   are testcases in intel-gpu-tools, and these issues span the entire set
>   of hw generations drm/i915 currently supports. But this late it's imo
>   no longer advisible to merge them, so we'll ship 3.3 with a bunch of
>   known (and sometimes longstanding) serious issues that have fixes.

Yeah I have to second this and additionally complain about the patch
lossiness & latency.  Part of this is my fault for not reviewing things
as much as I should, but those reviews often get lost too...

Eugeni's i2c patches are a good example.  They've been out there since
early Oct, have received review and testing, and should have been in
-next for many months now (in previous releases!).

What can we do to improve the process to get trees updated more
regularly and get fixes integrated faster?

Thanks,
-- 
Jesse Barnes, Intel Open Source Technology Center

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]