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

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

On Mon, Oct 28, 2024 at 06:46:19PM -0400, Sasha Levin wrote:
> On Mon, Oct 21, 2024 at 11:48:34PM -0700, Christoph Hellwig wrote:
> > On Mon, Oct 21, 2024 at 09:54:53PM -0700, Kees Cook wrote:
> > > For example, for a given PR, the bot can report:
> > > 
> > > - Were the patches CCed to a mailing list?
> > > - A histogram of how long the patches were in next (to show bake times)
> > > - Are any patches associated with test failures? (0day and many other
> > > CIs are already running tests against -next; parse those reports)
> > > 
> > > We could have a real pre-submit checker! :)
> > 
> > That would be very useful.  Items 1 and 2 should be trivial, 3 would
> > require a bit of work but would still be very useful.
> 
> If you've been following so far, there is a bot that is capable of doing
> most of the above
> (https://git.kernel.org/pub/scm/linux/kernel/git/sashal/next-analysis.git/).

Nice!!!

What does this make of these commits of mine?

744e87210b1ae rcu: Finer-grained grace-period-end checks in rcu_dump_cpu_stacks()
cbe644aa6fe17 rcu: Stop stall warning from dumping stacks if grace period ends
26ff1fb02991e rcu: Delete unused rcu_gp_might_be_stalled() function

> Here's a histogram that describes v6.12-rc4..v6.12-rc5 as far as how
> long commits spent in -next:
> 
> Days in linux-next:
> ----------------------------------------
>  0 | +++++++++++++++++++++++++++++++++++++++++++++++++ (89)
> <1 | +++++++++++ (21)
>  1 | +++++++++++ (21)
>  2 | +++++++++++++++++++++++++ (45)
>  3 | ++++++++++++++ (25)
>  4 | +++++ (10)
>  5 |
>  6 | + (2)
>  7 |
>  8 | + (3)
>  9 | ++ (4)
> 10 |
> 11 | +++ (6)
> 12 |
> 13 |
> 14+| ++++++++ (15)
> 
> This is where I think the value of linus-next comes during the -rc
> cycles: the (89 + 21) commits that haven't gone through the -next
> workflow before being pulled. I'm not looking to delay the process and
> add latency, I'm looking to plug a hole where code would flow directly
> to Linus's tree bypassing -next.
> 
> With linus-next, we can at least squeeze in build tests as well as some
> rudimentary testing if we get a few hours before Linus pulls (and we
> usually do).

OK, if linus-next is only active just before the merge window opens,
then I have fewer testing-bandwidth concerns.

							Thanx, Paul