[Intel-gfx] [PULL] drm-intel-next
Jesse Barnes
jbarnes at virtuousgeek.org
Thu Jan 5 19:02:51 CET 2012
On Thu, 5 Jan 2012 16:24:08 +0100
Daniel Vetter <daniel at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/intel-gfx/attachments/20120105/49321f97/attachment.sig>
More information about the Intel-gfx
mailing list