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

[Thorsten Leemhuis <linux@leemhuis.info>]

On 30.10.24 15:10, Sasha Levin wrote:
> 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.

Cool!

> 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?

So here is the thing: with regression tracking I'm already having a huge
never ending and hard task that creates a lot of work every day -- work
I'm not getting payed for now since months with no concrete funding
solution yet on the horizon. So I don't want to put even more work on my
shoulders with helping in other areas currently, sorry.

That being said: I'm willing to help with creating improvements for our
docs (something along the lines of "you should have a -fixes branches
that is never rebased that is included in the -pending-fixes branch of
-next and -auto-pending-fixes") and even trying to talk maintainers into
that do not yet have such a branch into maintaining one.

Ciao, Thorsten