Re: linus-next: improving functional testing for to-be-merged pull requests
From: Kees Cook
Date: Tue Oct 22 2024 - 00:55:04 EST
On October 21, 2024 9:07:13 AM PDT, Sasha Levin <sashal@xxxxxxxxxx> wrote:
>In an attempt to address the concerns, we're trying out a new "linus-next"
>tree is being created and maintained with the following characteristics:
>
> 1. Composed of pull requests sent directly to Linus
>
> 2. Contains branches destined for imminent inclusion by Linus
But this means hours or a day or 2 at most.
> 3. Higher code quality expectation (these are pull requests that
> maintainers expect Linus to pull)
Are people putting things in linux-next that they don't expect to send to Linus? That seems like the greater problem.
> 4. Continuous tree (not daily tags like in linux-next),
> facilitating easier bisection
I'm not sure how useful that is given the very small time window to find bugs.
>The linus-next tree aims to provide a more stable and testable
>integration point compared to linux-next,
Why not just use linux-next? I don't understand how this is any different except that it provides very little time to do testing and will need manual conflict resolutions that have already been done in linux-next.
How about this, instead: no one sends -rc1 PRs to Linus that didn't go through -next. Just have a bot that replies to all PRs with a health check, and Linus can pull it if he thinks it looks good.
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! :)
-Kees
--
Kees Cook