[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZxdyYjzxSktk34Zz@sashalap>
Date: Tue, 22 Oct 2024 05:37:38 -0400
From: Sasha Levin <sashal@...nel.org>
To: Christoph Hellwig <hch@...radead.org>
Cc: Kees Cook <kees@...nel.org>, torvalds@...ux-foundation.org,
ksummit@...ts.linux.dev, linux-kernel@...r.kernel.org
Subject: Re: linus-next: improving functional testing for to-be-merged pull
requests
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:
>> > 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.
>
>Yeah.
During the -rc cycles, sure.
However, folks have been consistently sending content for the next
release early - usually a week or two before the merge window even
opens.
For that matter, we've already seen pull requests destined for 6.13
getting pulled into linus-next.
>>
>> > 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.
>
>They shouldn't. If they do we do indeed have a problem.
Not in the sense that it's not expected to be sent to Linus, but more in
the sense that folks are shoving things in -next before they passed all
the "local" tests a maintainer can run.
We end up with content that is destined to Linus, but is immature.
>> > 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.
>
>Same.
>
>> >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.
>
>Exactly!
We had multiple issues just this release cycle that would have been
caught by this tree and not by 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.
>
>Not just -rc1, otherwise agreed.
>
>> 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.
We could add a report for the above, but:
1. Linus consistently pulls patches that haven't seen the light of day.
2. Linus explicitly objected to making a linux-next a must have.
So unless these results would be actually used, what's the point in
writing all of that?
--
Thanks,
Sasha
Powered by blists - more mailing lists