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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <e6aa8071-e204-45a1-8228-30533ef787bb@leemhuis.info>
Date: Thu, 31 Oct 2024 09:13:57 +0100
From: Thorsten Leemhuis <linux@...mhuis.info>
To: Sasha Levin <sashal@...nel.org>
Cc: Christoph Hellwig <hch@...radead.org>, Kees Cook <kees@...nel.org>,
 torvalds@...ux-foundation.org, ksummit@...ts.linux.dev,
 linux-kernel@...r.kernel.org
Subject: Re: linus-next: improving functional testing for to-be-merged pull
 requests

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