lkml.org 
[lkml]   [2016]   [Mar]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: i915 4.5 bugfix backport and release management issue?
On Tue, Mar 29, 2016 at 12:43 AM, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> On Tue, Mar 29, 2016 at 4:39 AM, Andy Lutomirski <luto@amacapital.net> wrote:
>> AFAICT something got rather screwed up in i915 land for 4.5.
>>
>> $ git log --oneline --grep='Pretend cursor is always on' v4.5
>> drivers/gpu/drm/i915/
>> e2e407dc093f drm/i915: Pretend cursor is always on for ILK-style WM
>> calculations (v2)
>>
>> $ git log --oneline --grep='Pretend cursor is always on' v4.6-rc1
>> drivers/gpu/drm/i915/
>> e2e407dc093f drm/i915: Pretend cursor is always on for ILK-style WM
>> calculations (v2)
>> b2435692dbb7 drm/i915: Pretend cursor is always on for ILK-style WM
>> calculations (v2)
>>
>> The two patches there are almost, but not quite, the same thing, which
>> makes me wonder how they both ended up in Linus' tree without an
>> obvious merge conflict.
>>
>> I have no idea what caused this. However, I think (on very little
>> inspection, but it's consistent with problems I have with 4.5 on my
>> laptop) that the first one is an *incorrect* fix for a regression in
>> 4.5 and the second is a correct fix for the same regression. 4.6-rc1
>> seems okay.
>>
>> I reported the regression and everyone involved has known about it for
>> weeks. Nonetheless, 4.5 final is busted.
>
> Quoting from e2e407dc093f
>
> "(cherry picked from commit b2435692dbb709d4c8ff3b2f2815c9b8423b72bb)"
>
> i.e. this is intentionally twice in the history. We started to soak
> bugfixes in -next and then cherry pick them because we had too much
> fun with things blowing up, and also too much fun with really messy
> conflicts. It's not a botched patch in 4.5 or anything else nefarious
> at all.

Bah, sorry, I read it wrong. They have the same final state but they
were on different bases. I somehow reversed this in my head and
thought they had the same initial state and different final states.

>
> - We've genuinely failed to cherry-pick a bugfix over. It happens,
> despite our best efforts (which of course includes running stuff on
> Linus' tree). Please do a reverse bisect so we know which precise
> commit fell through the cracks.

If I find some time, I'll try. I've already failed miserably at
bisecting this thing once.

--Andy

\
 
 \ /
  Last update: 2016-03-29 10:21    [W:0.784 / U:0.056 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site