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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20120105100251.3fc7dfef@jbarnes-desktop>
Date:	Thu, 5 Jan 2012 10:02:51 -0800
From:	Jesse Barnes <jbarnes@...tuousgeek.org>
To:	Daniel Vetter <daniel@...ll.ch>
Cc:	Keith Packard <keithp@...thp.com>,
	"Airlie, Dave" <airlied@...ux.ie>,
	Intel drivers <Intel-gfx@...ts.freedesktop.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	dri-devel@...ts.freedesktop.org
Subject: Re: [Intel-gfx] [PULL] drm-intel-next

On Thu, 5 Jan 2012 16:24:08 +0100
Daniel Vetter <daniel@...ll.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

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)