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 3DAEB1287 for ; Wed, 5 Sep 2018 14:46:29 +0000 (UTC) Received: from mx1.suse.de (mx2.suse.de [195.135.220.15]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 568A77AF for ; Wed, 5 Sep 2018 14:46:28 +0000 (UTC) Date: Wed, 05 Sep 2018 16:46:26 +0200 Message-ID: From: Takashi Iwai To: Sasha Levin In-Reply-To: <20180905144155.GK16300@sasha-vm> References: <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> <20180905144155.GK16300@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:41:56 +0200, Sasha Levin wrote: > > On Wed, Sep 05, 2018 at 04:30:36PM +0200, Takashi Iwai wrote: > >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... > > You can always do that by pointing it out on the review request mail. OK, that should work, then. > >> 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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fpatchwork%2Fpatch%2F909923%2F&data=02%7C01%7CAlexander.Levin%40microsoft.com%7C9410861ca37a4c2f0ca908d6133c26cb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636717546400542729&sdata=J0WTTH%2F9bOE5ipwDpxRzHTAxRppc6HoxvMr25HzFaaA%3D&reserved=0 . 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. > > So right now I'm lagging a few weeks behind upstream. If I limit it to > patches that are at least 1 month old will that help with your concerns? A few weeks after rc-release or the final release? If it's the latter, that should be fine. thanks, Takashi