Re: linus-next: improving functional testing for to-be-merged pull requests

Steven Rostedt
2024-10-25T01:17:33Z

On Thu, 24 Oct 2024 10:53:19 -0700
Luis Chamberlain <mcgrof@kernel.org> wrote:

> On Thu, Oct 24, 2024 at 02:49:28AM -0400, Steven Rostedt wrote:
> > Now I have to ask. What's the benefit of pushing to linux-next over
> > waiting for the zero-day bot?
>
> 0-day only does build tests by default, there are many places which have
> actual run time tests which *run* off of linux-next, those are both bots
> and human. Granted you can get your own run time tests out of your own
> branches but that's on each developer to set up and a developer's test
> exposure of just one branch is small compared to linux-next. For example
> I've seen obscure bugs creep up on linux-next for modules which only some
> odd arch or setup was able to capture before which no test we had during
> development was able to capture. So more exposure to system variability
> and test variability.

I have a test suite that takes 8 to 13 hours to run (depending on how
many commits I'm testing) that I run before sending to Linus or linux-next.

>
> The other benefit is you get to see *way ahead of time* possible merge
> conflicts, and if you can coordinate with the respective maintainers
> which your code conflicts with, you can prepare so that this is smooth
> sailing upon pull request to Linus.
>

Remember, this is talking about fixes after -rc1 not for things heading
to the merge window. I find linux-next extremely useful for that work.
But for fixes, what benefit is it to push to linux-next before sending
to Linus a fix that adds a missing mutex_unlock() in the error path?

-- Steve