Re: [Ksummit-discuss] [MAINTAINER SUMMIT] Stable trees and release time

[Sasha Levin <Alexander.Levin@microsoft.com>]

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 <broonie@kernel.org> 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.

>> 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&amp;data=02%7C01%7CAlexander.Levin%40microsoft.com%7C9410861ca37a4c2f0ca908d6133c26cb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636717546400542729&amp;sdata=J0WTTH%2F9bOE5ipwDpxRzHTAxRppc6HoxvMr25HzFaaA%3D&amp;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?


--
Thanks,
Sasha