Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751978AbdCPHip (ORCPT ); Thu, 16 Mar 2017 03:38:45 -0400 Received: from mail-wr0-f193.google.com ([209.85.128.193]:34192 "EHLO mail-wr0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751629AbdCPHim (ORCPT ); Thu, 16 Mar 2017 03:38:42 -0400 Date: Thu, 16 Mar 2017 08:38:30 +0100 From: Daniel Vetter To: Greg KH Cc: Daniel Vetter , Jani Nikula , intel-gfx , Linux Kernel Mailing List , stable Subject: Re: [Intel-gfx] The i915 stable patch marking is totally broken Message-ID: <20170316073830.23jcxeff4wyurgak@phenom.ffwll.local> Mail-Followup-To: Greg KH , Daniel Vetter , Jani Nikula , intel-gfx , Linux Kernel Mailing List , stable References: <20170312194440.GA32007@kroah.com> <20170312204621.vzvmzgnuio2fqmr7@phenom.ffwll.local> <20170312220121.GB30510@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Linux phenom 4.8.0-1-amd64 User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2634 Lines: 62 Hi Greg, On Mon, Mar 13, 2017 at 07:40:50AM +0100, Daniel Vetter wrote: > On Sun, Mar 12, 2017 at 11:01 PM, Greg KH wrote: > > So if a commit says "cherry-pick", I guess I can always assume it's safe > > to add, right? If not, _then_ I have to run the "search backwards" > > logic, right? > > > > Ok, let me think about this a bit to see if that's possible to script... > > Yes, but it shouldn't be hard to avoid the linear search: > > 1. make sure you have the latest linux-next (to make sure all the sha1 > commit-ish resolve to something meaningful). You probably want to do > that before you board a plane :-) > > 2. When you parse an upstream commit that says "commit cherry-picked > from $original_sha1", then add a git note for $original_sha1 that > you've seen it already and can ignore it. > > 3. Run that script over v4.9..v4.10 to backfill your git notes branch. > > 4. Make sure you sync that git notes branch (and if you use git notes > already, just use a different git notes branch name to avoid > conflicts). > > 5. When you spot a patch with cc: stable, check for a git note that > says you've looked at it (or one of it's cherry-picks) already, if so, > silently ignore it. > > That should massively drop the ratio of failed patches, at least every > time I look at your failed patche mail I think they're just > double-applied ones. There's ofc a few patches that fail to apply, 3 > months of drm/i915 development even wreak the context of simple > bugfixes sometimes, but most are not (which is btw why you don't get > replies for most of these). Are you implementing this? If you need inspiration, we also have a fairly generic cherry-pick branch command, which filters out duplicated cherry picks already with: git log drm-intel-fixes --format=format:%h --after=6months \ --grep="cherry picked .* $commit" See https://cgit.freedesktop.org/drm-intel/tree/dim?h=maintainer-tools#n713 Please make sure you have something like this ready soon, otherwise we're going to have this exact conversation again, like we did for the last few merge windows ... :( If you can't implement this, then I guess we have to try to avoid double-tagging stuff with cc: stable. But that will work against 10+ years of "pls cc: stable bugfixes" training from you. And we'd need to predict when exactly the merge window cutoff is. Which is going to get it wrong by 1-2 weeks each release, so trying to fix this on our side will be at best an 80% solution, after 1y of hard re-trainig work :( Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch