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: <ZyI-Y00J3DBUkon3@sashalap>
Date: Wed, 30 Oct 2024 10:10:43 -0400
From: Sasha Levin <sashal@...nel.org>
To: Thorsten Leemhuis <linux@...mhuis.info>
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 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