From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 05DA8EB2 for ; Wed, 5 Sep 2018 13:28:01 +0000 (UTC) Received: from mail-it0-f67.google.com (mail-it0-f67.google.com [209.85.214.67]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 75B038B for ; Wed, 5 Sep 2018 13:28:00 +0000 (UTC) Received: by mail-it0-f67.google.com with SMTP id h3-v6so9837798ita.2 for ; Wed, 05 Sep 2018 06:28:00 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <5c9c41b2-14f9-41cc-ae85-be9721f37c86@redhat.com> <20180904213340.GD16300@sasha-vm> <20180905081658.GB24902@quack2.suse.cz> <1536141525.8121.2.camel@HansenPartnership.com> <20180905104700.GE9781@sirena.org.uk> <6a25761a-c640-4eb2-952c-4bcd91da28a2@email.android.com> From: Daniel Vetter Date: Wed, 5 Sep 2018 15:27:58 +0200 Message-ID: To: Takashi Iwai Content-Type: text/plain; charset="UTF-8" Cc: James Bottomley , Greg KH , "ksummit-discuss@lists.linuxfoundation.org" Subject: Re: [Ksummit-discuss] [MAINTAINER SUMMIT] Stable trees and release time List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Wed, Sep 5, 2018 at 3:03 PM, Takashi Iwai wrote: > On Wed, 05 Sep 2018 14:24:18 +0200, > James Bottomley wrote: >> >> On September 5, 2018 11:47:00 AM GMT+01:00, Mark Brown wrote: >> >On Wed, Sep 05, 2018 at 10:58:45AM +0100, James Bottomley wrote: >> > >> >> This really shouldn't be an issue: stable trees are backported from >> >> upstream. The patch (should) work in upstream, so it should work in >> >> stable. There are only a few real cases you need to worry about: >> > >> >> 1. Buggy patch in upstream backported to stable. (will be caught >> >and >> >> the fix backported soon) >> >> 2. Missing precursor causing issues in stable alone. >> >> 3. Bug introduced when hand applying. >> > >> >> The chances of one of these happening is non-zero, but the criteria >> >for >> >> stable should mean its still better odds than the odds of hitting the >> >> bug it was fixing. >> > >> >Some of those are substantial enough to be worth worrying about, >> >especially the missing precursor issues. It's rarely an issue with the >> >human generated backports but the automated ones don't have a sense of >> >context in the selection. >> > >> >There's also a risk/reward tradeoff to consider with more minor issues, >> >especially performance related ones. We want people to be enthusiastic >> >about taking stable updates and every time they find a problem with a >> >backport that works against them doing that. >> >> I absolutely agree. That's why I said our process is expediency >> based: you have to trade off the value of applying the patch vs the >> probability of introducing bugs. However the maintainers are mostly >> considering this which is why stable is largely free from trivial >> but pointless patches. The rule should be: if it doesn't fix a user >> visible bug, it doesn't go into stable. > > Right, and here the current AUTOSEL (and some other not-stable-marked) > patches coming to a gray zone. The picked-up patches are often right > as "some" fixes, but they are not necessarily qualified as "stable > fixes". > > How about allowing to change the choice of AUTOSEL to be opt-in and > opt-out, depending on the tree? In my case, usually the patches > caught by AUTOSEL aren't really the patches with forgotten stable > marker, but rather left intentionally by various reasons. Most of > them are fine to apply in anyway, but it was uncertain whether they > are really needed / qualifying as stable fixes. So, I'd be happy to > see them as opt-in, i.e. applied only via manual approval. > > Meanwhile, some trees have no stable-maintenance, and AUTOSEL would > help for them. They can be opt-out, i.e. kept until someone rejects. +1 on AUTOSEL opt-in. It's annyoing at best, when it backports cleanup patches (because somehow those look like stealthy security fixes sometimes) and breaks a bunch of people's boxes for no good reason. In general it'd be really good if -stable had a clearer audit path. Every patch have a recorded reason why it's being applied (e.g. Cc: stable in upstream, Link to the lkml thread/bug report, AUTOSEL mail, whatever), so that after the fact I can figure out why a -stable patch happend, that would be really great. Atm -stable occasionally blows up, with a patch we didn't mark as cc: stable, and we have no idea whyiit showed up in -stable even. That makes it really hard to do better next time around. Thanks, Danile -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch