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

[Sasha Levin]

On Tue, Oct 22, 2024 at 07:22:12AM -0700, Paul E. McKenney wrote:
> On Tue, Oct 22, 2024 at 02:06:46PM +0200, Jiri Kosina wrote:
> > On Mon, 21 Oct 2024, Paul E. McKenney wrote:
> >
> > > I have to ask...
> > >
> > > Wouldn't more people testing -next result in more pressure to fix
> > > linux-next problems quickly?
> >
> > I believe I brought up pretty much exactly this at this year's maintainer
> > summit.
> >
> > >From the discussion it turned out the many people believe that this
> > investing into this is probably not worth it, as it will require much more
> > continous, never-ending effort (for which there are probably not enough
> > resources) than just dealing with the fallout once during the -rc1+ phase.
>
> Thank you for the response and the information!
>
> But why won't this same issues apply just as forcefully to a new
> linus-next tree?
>
> Full disclosure:  Testing and tracking down bugs in -next can be a bit of
> a hassle, to be sure, but I expect to continue to do so.  For one thing,
> dealing with -next is way easier than testing patches on the various
> mailing lists.

I'm not trying to change the workflow here, I think all this amounts to
is just a quality of life improvement for Linus who could ideally merge
faster if he knows that the pull requests he's looking at will build and
won't brick his laptop.

If we start playing games around "must spend X days in linus-next", then
yes - I agree with you.

--
Thanks,
Sasha