linus-next: improving functional testing for to-be-merged [#linux #kernel] pull requests
https://lore.kernel.org/all/ZxZ8MStt4e8JXeJb@sashalap/
"'[…] Linus Torvalds expressed concerns about the quality of testing that code receives before he pulls it. The subsequent discussion side-tracked to the testability of linux-next, but we didn't directly address Linus's original concern about pre-pull testing quality.
In an attempt to address the concerns, we're trying out a new "linus-next"
tree […]"
2/ @kees replied to the "linus-next" proposal from Sasha and raised a few points I fully agree with, as that proposal felt a bit off for me.
https://lore.kernel.org/all/792F4759-EA33-48B8-9AD0-FA14FA69E86E@kernel.org/
"'Are people putting things in linux-next that they don't expect to send to Linus? That seems like the greater problem.
[…]
Why not just use linux-next? […]
[…] have a bot that replies to all PRs with a health check, and Linus can pull it if he thinks it looks good. […]"
@vbabka and @ljs, that "Are people putting things in linux-next that they don't expect to send to Linus? That seems like the greater problem." from @kees reminded me of a question you might be able to help out with:
From a quick look it seems to me that the "mm-unstable" branch is in -next (via "mm-everything"). Does that contain stuff for the next merge window only, or more experimental stuff as well? It looks like the latter to me.
Well, good points, but fwiw, afaiui only patches that *were* reviewed by one of the official maintainers are supposed to be included in -next. To quote Stephen from https://lore.kernel.org/linux-next/20240716083116.27f179bd@canb.auug.org.au/
"'You will need to ensure that the patches/commits in your tree/series have
been:
[…]
* reviewed by you (or another maintainer of your subsystem tree),
* successfully unit tested, and
* destined for the current or next Linux merge window."'
> I think the issue is that more people need to test against -next.
Avoiding "this might eat my data" fears for the testers is very important detail here to realize that – having patches in there that come from a "unstable" branch is enough to scare people away when it comes to mm or filesystems.
So chancing that name might already help.
eating data is always a risk spectrum (even in stable release there is a risk that it happens) -- and depending on how risky something looks people then decide what they use/test: stable, stable-rc, mainline outside the merge window (that's me currently), mainline all the time, -next.
The less likely the "might eat data" risk is perceived in -next, the more likely people will be willing to help with testing it.
@kernellogger @ljs @kees @vbabka There is also the option of running tests in a VM or whatever - dogfooding -next is probably foolish but you don’t have to give it your live production data.