Received: by 10.223.164.202 with SMTP id h10csp3759173wrb; Mon, 20 Nov 2017 04:40:55 -0800 (PST) X-Google-Smtp-Source: AGs4zMZRTHsvLabpO41uw6z/vma1EvS8aDMBzuhwrR/fo54M5G2B/rwyWoPzmGA0DcGK0X2jjlAF X-Received: by 10.98.71.144 with SMTP id p16mr11095850pfi.15.1511181655653; Mon, 20 Nov 2017 04:40:55 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1511181655; cv=none; d=google.com; s=arc-20160816; b=fdG3fWyf7K+TKlSgLuh2Ni2G9Ev3EwKmwB82zK3SJD3VQMR2OaNoaFvaLcfwfhxvnL w4YnhovypJAEknjkSe0/dEpYQYduy3EKMCG9iRRD2qZ3P/hieKlN+Dq2rX7ctCSQAQNP +SPfbV+p0wWubHPSEhZEgObZ/ob/NhHVdBeaI+N6DS4IhnYtEbY4ADVtbnOChEXELBUL xwhFbLvNXTAMAA3fmKpzgktFqfdak2tuKpFOF3cobMvKwogUY1VbU2MsiRF4VChDonCo 9Hg/w2Tb5Q0zZRDGRL+tk0pO1pBQ5wqumpjm3QCJA8XGtgLBfvKvGUhoJG6/58q0F2Xl 8CtQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:mail-followup-to :message-id:subject:cc:to:from:date:dkim-signature :arc-authentication-results; bh=0akX6qifNBUokFg++XQlLmF3vFnASGVuQNl8f3xNMrQ=; b=OS8MEXkbOZG2GAo0/rdjmiZWBy5zY0OiJB02sqU+9tqM8AKeU0pN141YwDjzzAity7 uD/nUHlBPp0EpGatQollhDcNAxbvBQjqQx1CyokFkELwUo2upaW7s5e6L9uMkJ3b3dHD tX5lgqurSmx7Ddq2BTN3JccJmOylyXkoub7x8AsfVA21+C4MSUFC7lp9paVnCkUTfXuo 4ISs5MzL+G2OAp8b/3eGpdNHEWakNwGm/te9BcSgeooFCqOgm85INacP9Wp85bn4fsp4 AzQzbC+Z5SC8BNCmsmQtAIpSxg/qvrkDBc0Dzd8mcmcxIrn8ux6f4DIPi+JiWp/d3yqQ uw/Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@ffwll.ch header.s=google header.b=a0LlipCd; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f81si9082100pfj.30.2017.11.20.04.40.45; Mon, 20 Nov 2017 04:40:55 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@ffwll.ch header.s=google header.b=a0LlipCd; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751153AbdKTMji (ORCPT + 67 others); Mon, 20 Nov 2017 07:39:38 -0500 Received: from mail-wm0-f49.google.com ([74.125.82.49]:47024 "EHLO mail-wm0-f49.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751106AbdKTMjf (ORCPT ); Mon, 20 Nov 2017 07:39:35 -0500 Received: by mail-wm0-f49.google.com with SMTP id u83so10038982wmb.5 for ; Mon, 20 Nov 2017 04:39:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=sender:date:from:to:cc:subject:message-id:mail-followup-to :references:mime-version:content-disposition:in-reply-to:user-agent; bh=0akX6qifNBUokFg++XQlLmF3vFnASGVuQNl8f3xNMrQ=; b=a0LlipCda7O0pqT7Yk6ErKOnpLJ8Zy4l3B17MNq1REJjbYeaHzlvRAGBtczLakayA0 9q2tUiF+L5plCE37D68drVjEWK9dynC1lvDwKzpusgjThH4ANoq7w3db/ipq2ZabnVqE RCDpLuQUUerIaCJVqxpT3wDYopMtuh9vsvDN0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=0akX6qifNBUokFg++XQlLmF3vFnASGVuQNl8f3xNMrQ=; b=CkFh7zhxDfc8iHUhSD5v0hRESv2fdnkN80SSLSWr0t1YEI0JMjdnVW0QJ1ByUPRp4A /Uddbmi6d7aQQj/8ZR5n3XYHCgWgI2nKf1gINo57VFmhzIdXhwpub96CRUHpUlFV+wbj wAJZo1Pu+t8K5vmGCuMChMr9WhXIr+oOSA4tNsZalSUsE6XVbVp4ydoidouTr6GhC2Jl AHJ0SJ2XksGp96oss7P8bNhp3vHQrJTQSDG4Ub+duPUAtd8znuCBPbIxUd8Aa25K/HWd qdNGBWTxWjTZwv1En8Na34vfAQd+XMNXk+4+PDP4/Va6mmSshAPzyjZcJTvZ5DSEXnnF FzDw== X-Gm-Message-State: AJaThX6WocGpsHB00UAEmdM6Kka2gAZ1f3RUmngsGD8QbJG1gQBqEP3c SYdStoQeOCSgbfcJSRpatjb/PA== X-Received: by 10.80.155.6 with SMTP id o6mr20311760edi.39.1511181574141; Mon, 20 Nov 2017 04:39:34 -0800 (PST) Received: from phenom.ffwll.local ([2a02:168:5635:0:39d2:f87e:2033:9f6]) by smtp.gmail.com with ESMTPSA id l4sm9677377edc.20.2017.11.20.04.39.33 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 20 Nov 2017 04:39:33 -0800 (PST) Date: Mon, 20 Nov 2017 13:39:31 +0100 From: Daniel Vetter To: Emil Velikov Cc: Greg KH , "intel-gfx@lists.freedesktop.org" , "linux-kernel@vger.kernel.org" , ML dri-devel , alexander.levin@verizon.com, "stable@vger.kernel.org" Subject: Re: Autoselect patches for stable (Was: Re: [PATCH AUTOSEL for 4.9 36/56] drm/i915: Fix the level 0 max_wm hack on VLV/CHV) Message-ID: <20171120123931.yuqyjxs4mq2ldoow@phenom.ffwll.local> Mail-Followup-To: Emil Velikov , Greg KH , "intel-gfx@lists.freedesktop.org" , "linux-kernel@vger.kernel.org" , ML dri-devel , alexander.levin@verizon.com, "stable@vger.kernel.org" References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Linux phenom 4.9.0-3-amd64 User-Agent: NeoMutt/20170609 (1.8.3) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Nov 20, 2017 at 11:21:52AM +0000, Emil Velikov wrote: > Hi all, > > Since I'm going slightly off-topic, I've tweaked the subject line and > trimmed some of the conversation. > I believe everyone in the CC list might be interested in the > following, yet feel free to adjust. > > Above all, I'd kindly ask everyone to skim through and draw their conclusions. > If the ideas put forward have some value - great, if not - let my email rot. > > On 17 November 2017 at 13:57, Greg KH wrote: > > >> > >> I still have no idea how this autoselect picks up patches that do *not* > >> have cc: stable nor Fixes: from us. What information do you have that we > >> don't for making that call? > > > > I'll let Sasha describe how he's doing this, but in the end, does it > > really matter _how_ it is done, vs. the fact that it seems to at least > > one human reviewer that this is a patch that _should_ be included based > > on the changelog text and the code patch? > > > > By having this review process that Sasha is providing, he's saying > > "Here's a patch that I think might be good for stable, do you object?" > > > > If you do, great, no harm done, all is fine, the patch is dropped. If > > you don't object, just ignore the email and the patch gets merged. > > > > If you don't want any of this to happen for your subsystem at all, then > > also fine, just let us know and we will ignore it entirely. > > > Let me start with saying that I'm handling the releases for Mesa 3D - > the project providing OpenGL, Vulkan and many other userspace graphics > drivers. > I've been doing that for 3 years now, which admittedly is quite a > short time relative to the kernel. > > There is a procedure quite similar to the kernel, with a few > differences - see below for details. > We also autoselect patches, hence my interest in the heuristics > applied for nominating patches ;-) > > That aside, here are some things I've learned from my experience. > Some of those may not be applicable - hope you'll find them useful: > > - Try to reference developers to existing documentation/procedure. > Was just reminded that even long standing developers can forget detail X or Y. > > - CC developers for the important stuff - aka do not CC on each accepted patch. > Accepted patches are merged in pre-release branch and a email with > accepted/deferred/rejected list is sent. > Patches that had conflicts merging, and ones that are rejected have > their author in the CC list. > Rejected patches have brief description + developers are contacted beforehand. > > - Autoselect patches are merged only with the approval from the > respective developers. > IMHO this engages developers into the process, without distracting > them too much. Getting explicit confirmation for autoselected patches sounds like a very good idea to me. We intentionally limit the amount of patches we cc: stable, because we simply don't have the manpower around to support stable fully (i.e. with proper CI and everything). And less backported patches means fewer regressions, which is more important than fixing someone else's bug. Of course our CI is open, so if someone is supremely bored and wants to backport more stuff for drm/i915, they could do that. But atm it doesn't happen, and then having to deal with the fallout is not really great (like I said, we don't really have anyone dedicated, and I much prefer we fix/improve upstream). For the actual products we're shipping we have dedicated teams doing the backports. The upstream stable releases essentially have no value for us from a customer support pov (for drivers, I guess core stuff is an entirely different matter), there's not a single serious customer or bigger user using that. It only costs, by spamming us with mails and bug reports for stuff we didn't even nominate :-) Just my 2 cents here, but I think this perpespective matches with other big drm drivers like amdgpu (I just discussed this exact topic of how upstream stable is useless with Alex). -Daniel > > It is by no means a perfect system - input and changes are always appreciated. > > > That said, here are some suggestions which should make autosel smoother: > > - Document the autoselect process > Information about about What, Why, and [ideally] How - analogous to > the normal stable nominations. > Insert reference to the process in the patch notification email. > > - Make the autoselect nominations _more_ distinct than the normal stable ones. > Maintainers will want to put more cognitive effort into the patches. > > > HTH > Emil > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch From 1584583896347485038@xxx Mon Nov 20 11:22:44 +0000 2017 X-GM-THRID: 1584583896347485038 X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread