On Thu, 5 Jan 2012 16:24:08 +0100 Daniel Vetter <daniel@xxxxxxxx> 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:
signature.asc
Description: PGP signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
