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

[Daniel Vetter <daniel.vetter@ffwll.ch>]

On Wed, Sep 5, 2018 at 3:03 PM, Takashi Iwai <tiwai@suse.de> 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.
>
> 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