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 B7DC411A6 for ; Wed, 5 Sep 2018 14:30:39 +0000 (UTC) Received: from mx1.suse.de (mx2.suse.de [195.135.220.15]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E57BFA8 for ; Wed, 5 Sep 2018 14:30:38 +0000 (UTC) Date: Wed, 05 Sep 2018 16:30:36 +0200 Message-ID: From: Takashi Iwai To: Sasha Levin In-Reply-To: <20180905142038.GI16300@sasha-vm> 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> <20180905142038.GI16300@sasha-vm> MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII 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, 05 Sep 2018 16:20:40 +0200, Sasha Levin wrote: > > On Wed, Sep 05, 2018 at 03:03:13PM +0200, 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. > > So right now you can opt-out your tree if you'd like. I'm not trying to > force it on any particular maintainer. If you'd like to ack each patch I > send before it goes in a tree this is something we can definitely do. Yeah, that would help in my case. Particularly, I'd like to have an option to defer the patch merge. For example... > FWIW, it looks like your tree is in a very good shape compared to most > other trees I encounter, so I end up sending fewer proposed stable > commits your way. > > I tried picking a random commit that went through my selection process > and chose https://lore.kernel.org/patchwork/patch/909923/ . Is this type > of patch that should not belong in stable? ... this is an example I'd hold for a while until a bit more testing has been done after the release of Linus tree. This is clearly a fix, but it's no regression fix or such but just catching some logically possible error case. Hence there hasn't been any test coverage or explicit unit testing. So, this kind of change might have a slightly higher risk of regression than the obvious fix (which is usually with cc-to-stable). Note that this particular patch might have been picked up lately enough, but you get an idea. thanks, Takashi