lkml.org 
[lkml]   [2012]   [Jan]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [Intel-gfx] [PULL] drm-intel-next
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
[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2012-01-05 19:05    [W:0.048 / U:0.488 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site