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

[Sasha Levin]

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