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 evenAutomating how? Having it be generated more often?
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.
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.