[Ksummit-discuss] [MAINTAINERS SUMMIT] Bug-introducing patches

[Laura Abbott]

On 09/06/2018 07:52 PM, Guenter Roeck wrote:
> On 09/06/2018 06:49 PM, Sasha Levin via Ksummit-discuss wrote:
>>
>> This is a *huge* reason why we see regressions in Stable. Take a look at
>> https://lists.linuxfoundation.org/pipermail/ksummit-discuss/2018-September/005287.html
>> for a list of recent user visible regressions the CoreOS folks have
>> observed this year. Do you want to know when they were merged? Let me
>> help you: all but one were merged in -rc5 or later.
>>
> 
> My conclusion from that would be that patches are applied to stable
> before they had time to soak in mainline. Your argument against
> accepting patches into mainline might as well be applied to patches
> applied to stable.
> 
> I think you are a bit hypocritical arguing that patches should be
> restricted from being accepted into mainline ... when at the same
> time patches are at least sometimes applied almost immediately to
> stable releases from there. Plus, some if not many of the patches
> applied to stable releases nowadays don't really fix critical or
> even severe bugs. If the patches mentioned above indeed caused
> regressions in mainline, those regressions should have been found
> and fixed _before_ the patches made it into stable releases.
> Blaming mainline for the problem is just shifting the blame.
> 
> I would argue that, if anything, the rules for accepting patches into
> _stable_ releases should be much more strict than they are today.
> If anything, we need to look into that, not into restricting patch
> access to mainline.

Part of my proposal for a longer -rc time for stable was for this
exact problem: patches that have been merged in mainline but
tagged for stable may not have had time to test to find all
bugs. The thought was a longer stable -rc cycle would help
in finding those. I think you've hit upon the real problem
though which is that the patches probably shouldn't have been
in stable in the first place.

Thanks,
Laura