linux-kernel - Re: [git pull] drm fixes

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] [thread-next>] [day] [month] [year] [list]

Message-Id: <0d30dc$k5i5ji@orsmga001.jf.intel.com>
Date:	Fri, 12 Nov 2010 17:21:19 +0000
From:	Chris Wilson <chris@...is-wilson.co.uk>
To:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Dave Airlie <airlied@...ux.ie>
Cc:	linux-kernel@...r.kernel.org,
	DRI mailing list <dri-devel@...ts.freedesktop.org>
Subject: Re: [git pull] drm fixes


On Fri, 12 Nov 2010 08:24:48 -0800, Linus Torvalds <torvalds@...ux-foundation.org> wrote:
> But when you cherry-pick it from some random internal tree that nobody
> will necessarily ever see, and that you don't even describe what it
> is, it's only pure confusion. I do
> 
>   [torvalds@i5 linux]$ git show 6aa56062eaba67adfb247cded244fd877329588d
>   fatal: bad object 6aa56062eaba67adfb247cded244fd877329588d
> 
> and so will everybody else. So from a documentation standpoint, you're
> actually adding negative information. Please don't.

My bad, I cherry-picked it from our public drm-intel-next tree and thought
it wise to include the cross-reference to explain the duplication and
merge conflicts and to provide some additional test history into the commit.
Obviously not enough information.

Is there a right approach here? I'm trying to be strict in that what is
sent upstream in -fixes are purely known regression fixes, and to preserve
test history on both -fixes and -next. That leads to situations like the
above where we have a commit that does not appear to relevant to stable at
first, but then is later shown to be required. How best to resolve the
eventual conflict that will show up in your tree? Just cherry-pick and be
dammed?
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/