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

From: Sasha Levin
Date: Wed Oct 30 2024 - 10:10:53 EST


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