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

[Steven Rostedt]

On Mon, 10 Sep 2018 14:20:19 -0700
Guenter Roeck <linux at roeck-us.net> wrote:

> On Mon, Sep 10, 2018 at 04:45:19PM -0400, Steven Rostedt wrote:
> > 
> > The best we can do is make the automated testing of linux-next better
> > such that there's less -rc5 patches that need to go in in the first
> > place.
> >   
> 
> Would that help ? -next has been more or less unusable for a week or so.
> Maybe it is just a bad time (it hasn't been as bad as it is right now
> for quite some time), but
> 
> Build results:
> 	total: 135 pass: 133 fail: 2
> Qemu test results:
> 	total: 315 pass: 112 fail: 203
> 
> on next-20180910 doesn't really make me very confident that useful regression
> tests on -next are even possible. it seems to me that -next is quite often
> used as dumping ground for sparsely tested changes, and is far from "ready
> for upstream".
>

Honestly, I think this is something that Linus should yell at
maintainers for. I treat my pushes into linux-next the same as I treat
my pull requests to Linus. I don't push anything into next until it's
been fully run through my test suite, and passes. That also makes it
easier for me to know that whatever I have in next is also ready for
Linus (the way it was suppose to be).

With the 0day bot, I think it's become much better. But honestly, I
think any branch that causes next to fail to build, or run basic tests,
should be taken out of linux-next and a nasty message sent to the
guilty maintainer. With the exception that a breakage was caused by two
conflicting commits (for example, one that changes an API, and another
branch that uses that API without the update). Those types of breakages
is what linux-next is made for. But if the branch being pulled into
linux-next breaks something without the integration, then that's
unacceptable.

-- Steve