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

[Daniel Vetter]

On Tue, Sep 11, 2018 at 7:31 PM, Mark Brown <broonie at kernel.org> wrote:
> On Tue, Sep 11, 2018 at 08:12:37PM +0300, Jani Nikula wrote:
>> On Tue, 11 Sep 2018, Guenter Roeck <linux at roeck-us.net> wrote:
>
>> > FWIW, for the most part I stopped reporting issues with -next after some people
>> > yelled at me for the 'noise' I was creating. Along the line of "This has been
>> > fixed in branch xxx; why don't you do your homework and check there", with
>> > branch xxx not even being in -next.
>
>> What would be the reason for *not* having all the branches, including
>> fixes, of a subsystem/driver in linux-next? Baffled.
>
> Some people only put things into -next after they've passed QA (like
> Steven's thing about 0day) so you'll see branches that are undergoing QA
> in git before they get merged into the -next branch.

This is why we have a pre-merge CI SLA of mean latency < 6h for the
full pre-merge run. This is from the time your patch hits the m-l to
when the most extensive runs have completed (representing about 1 week
of machine). Early smoke-test results show up much earlier. In
practice this means you're almost always limited by review
turn-around, and not by CI. Exactly to avoid the "the regression fix
is ready except not yet fully tested" issues.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch