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

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

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.

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?


--
Thanks,
Sasha