Re: linus-next: improving functional testing for to-be-merged pull requests
From: Sasha Levin
Date: Mon Oct 28 2024 - 18:46:29 EST
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/).
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).
--
Thanks,
Sasha