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

[Daniel Vetter]

On Fri, Sep 7, 2018 at 10:40 AM, Geert Uytterhoeven
<geert at linux-m68k.org> wrote:
> On Fri, Sep 7, 2018 at 4:45 AM Steven Rostedt <rostedt at goodmis.org> wrote:
>> Another issue about having fixes sit in linux-next for some time after
>> -rc5, is that by that time, linux-next is filled with new development
>> code waiting for the next merge window. A subtle fix for a bug that
>> wasn't caught by linux-next in the first place (how else would that bug
>> still be around by rc5?) is highly likely not to catch a bug with the
>> fix to that subtle bug.
>
> Or the issue may never show up in linux-next at all.
>
> With strict by-subsystem merge policies, splitting a complicated patch set
> by subsystem and scheduling it for inclusion across multiple kernel
> versions can be challenging.  If anything slightly related is applied
> independently, or due to a scheduling oversight or merge window miss, this
> may lead to a regression in mainline that is never present in linux-next,
> and usually only detected late, leading to a fix after -rc5.

Aside: I'm still baffled at how much soc people split up their work.
As you point out, testing becomes a game of luck, because integration
happens only in the merge window for real.

Anything I'm involved in I'm insisting on a proper topic branch that
everyone pulls in, to make sure that we can test the full interactions
when we actually feature-freeze before the merge window. Usually that
means baking the merge into the drm side, because we do a lot more
testing than others (e.g. upstream intel audio validation is done
through the drm trees too - it doesn't work that great because it's
post-merge only for sound).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch