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

[Thorsten Leemhuis <linux@leemhuis.info>]

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.

Ciao, Thorsten