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

["Paul E. McKenney" <paulmck@kernel.org>]

On Thu, Oct 24, 2024 at 09:11:49PM -0400, Steven Rostedt wrote:
> On Thu, 24 Oct 2024 07:39:00 -0700
> Guenter Roeck <linux@roeck-us.net> wrote:

[ . . . ]

> > Note that I do collect known fixes in my 'fixes' and 'testing' branches,
> > primarily to have something clean available to keep testing. Linus even
> > pulled my fixes branch once directly because the responsible maintainers
> > didn't send pull requests to him for weeks.
> 
> Or are you saying that it's helpful to "fix" linux-next before fixing
> Linus's tree? That way others will have the fixes too?

It is a risk-management issue, and so the answer will vary depending on
the situation.

For one extreme, if the fix is a regression, but the bug is an odd corner
case that is unlikely to be triggered, then it is very helpful to run
it through 0day and -next before sending the pull request to Linus.
This is because the delay won't inconvenient many people, if any, and
0day and -next can help catch any bugs introduced by the fix.

At the other extreme, if the fix is for a regression that (say) bricks
50% of the systems out there, clearly speed is of the essence.  And let's
face it, in this case, Linus might well just apply your initial patch.
Which would expose it to both 0day and -next.

But!!!  In this case, I sure would hope that there would then be some
serious follow up to fix the bug in the validation, which clearly failed
to catch a very ugly bug.

							Thanx, Paul