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

[Tony Lindgren <tony@atomide.com>]

* Steven Rostedt <rostedt@goodmis.org> [180911 15:46]:
> On Mon, 10 Sep 2018 19:13:29 -0400
> Steven Rostedt <rostedt@goodmis.org> wrote:
> 
> > On Mon, 10 Sep 2018 16:03:03 -0700
> > Eduardo Valentin <edubezval@gmail.com> wrote:
> > 
> > > I thought that was the case already, everthing that goes to linux-next
> > > is ready to go to Linus.  
> > 
> > It's suppose to be, but not always, and this is why I suggested that
> > Linus start yelling at those that are not doing it.
> > 
> 
> This may have come across a bit too strong. We don't need Linus to
> yell, but there should definitely be consequences for any maintainer
> that pushes untested code to linux-next. At a bare minimum, all code
> that goes into linux-next should have passed 0day bot. Push code to a
> non-linux-next branch on kernel.org, wait a few days, if you don't get
> any reports that a bot caught something broken, you should be good to
> go (also you can opt-in to get reports on 0day success, which I do, to
> make that cycle even shorter). And that's a pretty low bar to have to
> pass. Ideally, all maintainers should have a set of tests they run
> before pushing anything to linux-next, or to Linus in the late -rcs. If
> you can't be bothered just to rely on at least 0day then you should not
> be a maintainer.

Based on the regressions I seem to hit quite a few Linux next
regressions could have been avoided if Andrew's mm tree had seem some
more testing before being added to next. Probably because Andrew
queues lots of complicated patches :)

So yeah what you're suggesting might help with that if we establish
a let's say 24 hour period before adding branches to next. At
least that gives the automated systems a chance to test stuff
before it hits next. And people who want to can then test various
branches separately in advance.

Regards,

Tony