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

[Sasha Levin <sashal@kernel.org>]

On Wed, Oct 30, 2024 at 07:46:40AM +0100, Thorsten Leemhuis wrote:
>On 29.10.24 16:07, Sasha Levin wrote:
>> On Tue, Oct 29, 2024 at 01:46:23PM +0100, Thorsten Leemhuis wrote:
>>> Hmmm. After all those mails in this thread improving (and maybe even
>>> separating & somewhat automating[1]) pending-fixes to me still sounds
>>> like time better spend, as then more things could tested before they
>>> even read a PR; but yes, I understand, the timing/order of merges can
>>> mess things up, so testing on PR time has benefits, too.
>> Automating how? Having it be generated more often?
>
>Have the list of -fixes trees which a "no rebases" policy somewhere and
>a script that regularly merges them into a tree. But as indicated, it's
>not that easy in practice and can't be fully automated, as there will be
>merge conflicts occasionally. But Linus wants to see them, so they will
>happen at pull requests time, too -- doing it constantly has the benefit
>that you can notice and resolve them ahead of time.
>
>How much work this is: no idea, maybe Stephen could help answering that
>from experiences for pending-fixes. But I expect conflicts should not
>happen as often as they do when it comes to merging -for-next branches.
>
>But that obviously only helps outside of merge windows.

Do you want to give it ago?

I've pushed something to
https://git.kernel.org/pub/scm/linux/kernel/git/sashal/linus-next.git/log/?h=auto-pending-fixes
, and scripted a bit around it to try and keep it updated.

We can try a model where it tries to avoid rebases as much as it can,
and if it needs to rebase it will tag the old HEAD before re-creating
the branch?

-- 
Thanks,
Sasha