On Tue, Jul 14, 2015 at 11:17:26PM +0300, James Bottomley wrote:
> On Tue, 2015-07-14 at 09:29 -0400, Steven Rostedt wrote:

> > Mark Brown mentioned the down side. Depending on what the bug is,
> > especially if it breaks Linus's build, or causes some other major
> > breakage, to wait in next means that Linus's tree (that everyone is
> > based on) will be broken for that long too. Which could stop other
> > types of testing of Linus's tree.

> If you followed process in the first place, how could you possibly break
> the build except for some corner case configuration which can wait for
> the fix?  linux-next and 0day pick up this kind of breakage fairly
> instantly.  If you wait before sending a pull, you'll see the reports in
> time to correct.

The specific case I'm thinking of had a dependency on some other changes
in -next that weren't targeted for Linus' tree and which triggered only
non-x86 architectures (but fairly obviously on some of them IIRC,
probably something like all*config).  With the other changes in -next
everything was fine, and with x86 everything was fine.  Most of the
testing on -next is on the integrated tree, though 0day probably should
have triggered.  

That interaction with other bits of -next definitely feels like a weak
spot for me when I'm sending changes to Linus.

> > I've been trying to get time to test against -next before the merge
> > window opens, because my tests usually discover these there. But I
> > don't always have time to do so.

> Well, the more, the merrier.  If you have a suite of tests, just package
> it up and send it off to Fengguang if you don't have time to run it.

Or get them into kselftest!